Работа в условиях смещения целей

Ни одна из битв не была выиграна в точном соответствии с планом, но не было и ни одной битвы, выигранной без него.

Дуайт Д. Эйзенхауэр

Постоянная смена направлений, в которых движется проект, стала одним из самых сильных аргументов в пользу коротких циклов и других элементов экстремального программирования (Extreme Programming, XP). Использование коротких циклов разработки позволяет проекту реагировать на существенные изменения направлений без потери предыдущих наработок, а все усилия по планированию и проектированию могли быть сосредоточены на вполне осязаемом коротком отрезке времени. Все это, по-моему, имеет глубокий смысл, поскольку дает возможность нацелиться на достижение череды краткосрочных побед. Но есть еще одна истина, о которой следует помнить: долгосрочные планы, даже самые приблизительные, облегчают внесение краткосрочных и среднесрочных изменений.

Смысл в том, что в момент изменения целей, требований или замысла, первоначальный план редко отбрасывается полностью. А все изменения делаются в соответствии с некоторой основной идеей, которой проект соответствовал до этого. Чем тщательнее разработан первоначальный план, пусть даже он носил весьма приблизительный характер, тем больше можно на него ориентироваться и тем быстрее могут быть внесены соответствующие поправки. Из этого следует, что с самого начала лучшей гарантией против непостоянства, связанного с изменениями, послужит вполне реальный план, поправки в который можно будет вносить уже в ходе реализации проекта. Вот что думает по этому поводу генерал-майор Дэн Лэйнер (Dan Laner), командующий израильскими силами обороны:

Я считаю, что сражение никогда не развивается по плану. План является лишь общей базой для внесения изменений. Очень важно, чтобы план был известен всем, тогда в него легче будет вносить изменения… современное сражение слишком изменчиво, и решения нужно принимать очень быстро, далеко не всегда сообразуясь с планом. Но, по крайней мере, все будут знать, каким было исходное состояние, и [тогда] более-менее поймут, к чему вы все ведете.

Особенность использования планов в условиях ожидаемого смещения целей состоит в том, чтобы не допускать слишком долгой работы без обновления плана. Если подобрать подходящие интервалы, смещение целей реально не отражается сразу на всем: просто наблюдается направление их движения с конкретной скоростью за определенное время. Если в проекте намечено несколько контрольных точек, или этапов (см. главу 2), они станут естественными интервалами для внесения поправок (а если на каждом этапе запланировано время на проектирование, то вы сможете вернуться к первому этапу, в который нужно внести поправки). Даже внутри трех– или шестинедельных этапов вы сможете отыскать одну-две промежуточные точки для вычисления новой траектории движения проекта относительно любых возможных изменений целей или требований. Поэтому продолжительность этапов должна соответствовать степени изменчивости проекта: чем чаще меняется его направление, тем короче должен быть этап.

На рис. 14.6 показан простой пример внесения изменений, связанных с корректировкой маршрута в направлении смещающейся цели. Проект стартовал в точке А и закончится, предположительно, в точке Б. Если через две недели после начала проекта (возможно, к завершению короткого этапа) руководители команды решат, что цели для Б изменились, направление проекта тоже должно сместиться, чтобы выровняться по точке Б. Еще через две недели будут внесены новые поправки и произойдет новая коррекция курса. Какая-то часть работ пропадет, но чем раньше будет изменено направление движения, тем меньше окажутся потери. Если перемещения совпадут с концом одного и началом другого этапа, у команды будет время, чтобы заняться проектированием, компенсирующим возникшие изменения, добавить работы, необходимые для модификации сделанного, и внести поправки в продолжительность этапов.

Рис. 14.6. Цели, требования и ограничения могут меняться, но если понятны скорость и направление этих изменений и вслед за ними предприняты соответствующие промежуточные шаги, процесс изменений будет управляемым

Даже если перемещения не совпадут с границами этапов, производственный конвейер по созданию программного кода поможет команде разработчиков придать этим промежуточным коррективам управляемый характер. Поскольку смены курса происходят на выходе из конвейера, опережая ход работ команды программистов, для происходящих изменений имеется некий буфер. Чем больше в конвейере заложено опережение по времени (рис. 14.7), тем больше объем этого буфера. Конечно, если предположить, что существует человек (руководитель проекта или ведущий программист), который уделяет достаточно времени управлению конвейером, то чтобы изменить направление, команде не обязательно полностью останавливаться. Для этого нужно, чтобы в конвейере (в его правой части) был предусмотрен достаточный объем предстоящей работы.

Рис. 14.7. В каждом плане имеется область охвата, определяющая количество допустимых изменений. Чем продуманнее план (и чем лучше в нем предусмотренывозможные изменения), тем больше область охвата

Однако тем самым предполагается, что изменения не будут радикально расходиться с первоначальным планом: в нем предусмотрен лишь вполне определенный диапазон возможных перемещений, то есть область охвата (см. рис. 14.7). Если новые требования или цели противоречат конкретному плану, нужно проводить новые серьезные проектные работы и исследования независимо от опережения, заложенного в конвейер (или, в отдельных случаях, от времени, выделенного на проектирование следующего этапа). Например, если первоначальный план предусматривал изготовление тостера, то в миттельшпиле вполне возможно скорректировать проект на изготовление духовки средних размеров, но никак не ускорителя элементарных частиц или нефтеналивного танкера.

На рис. 14.7 изображена приблизительная модель, отражающая число изменений проекта; в очерченной области представлено предусмотренное планом пространство изменений, которые команда может выдержать без новой серьезной работы. Такая же диаграмма может быть составлена на микроуровне для каждой работы. В зависимости от подходов, примененных программистом, его план будет иметь различные уровни охвата изменений требований или замысла, относящихся к данной работе.

У диаграммы, изображенной на рис. 14.7, есть одна странная, хотя и незначительная особенность. Хронологическая последовательность представлена на ней вертикально, подразумевая, что область охвата со временем может предоставить больше возможностей для передвижений, что в корне неверно. Более точным будет представление, что область охвата изменяется, расширяясь и сужаясь в зависимости от того, в какой стадии проект находится. Обычно эта область сужается по мере близости работы к завершению. Но каждое перемещение вносит коррективы в действующий план, а вместе с ним и в возможности охвата будущих перемещений.