Скотт Беркун - Сделано

Барри Боэм в своем эссе 1988 года на тему разработки ПО [23]пришел к выводу, что ошибки графиков растут пропорционально тому, насколько рано сделаны предположения (рис. 2.3). Если общий расчет графика осуществлен рано, он может попасть мимо цели аж на 400 %, причем в обоих направлениях (подозреваю, что ошибки в графике всегда играют против нас, отнимая больше времени, чем мы ожидали). На этапе проектирования, когда многие решения становятся очевидными, диапазон отклонений от графика немного сужается. Только когда проект перейдет в стадию реализации, расчеты становятся обоснованными и реалистичными, но даже тогда остается 20 %-ная вероятность того, что график недостаточно точен.

Рис. 2.3.Диапазон возможных отклонений от сроков проекта (адаптировано из Software Engineering Economics Боэма)

МП должны понимать, что со временем расчет графика становится точнее и обоснованнее. Графики требуют, чтобы на них обращали внимание по ходу работы и вносили корректировки по мере развития проекта.

Когда я работал над своими первыми масштабными проектами после окончания колледжа (Windows и Internet Explorer), кто-то гораздо более авторитетный, чем я, присылал сверху график моей команде. Поскольку я был неопытным новичком и не мог активно участвовать в процессе, мне и небольшому количеству программистов и тестировщиков оставалось только следовать этому «генплану».

Мы бурно обсуждали и согласовывали его отличия от графика, который составляли опираясь на конкретные задачи [24]. «Генплан» спускали сверху, и он был великолепно «причесанным», с аккуратными колонками, датами и цифрами. Словно некий артефакт, выкраденный из будущего.

Несмотря на наш цинизм, мы все же следовали «генплану». Хотя его происхождение оставалось туманным, мы доверяли тимлидам, а к тому же мы были слишком заняты своей работой. (Вообще-то они вполне могли объяснить нам эти графики, но мы были слишком заняты и слишком доверяли им, чтобы тратить на это время.)

Позже, начав составлять графики, я осознал одну истину. Их трудно назвать подарками из будущего. Нет никакой волшебной формулы или науки для идеальных графиков. Несмотря на неопытность, я понимал, что их составление всегда затрагивает множество разных аспектов текущего и будущего положения проекта. График – это просто прогноз сроков. Неважно, насколько точно он составлен или насколько убедительным кажется, – это всего лишь сводная запись множества мелких расчетов, причем каждый из них неизбежно подвержен самым разным непредвиденным упущениям и проблемам. Хорошие графики создают только лидер или команда, которые стремятся к точным суждениям по многим аспектам программной разработки. Для эксперта в одной узкой области производства это будет не под силу.

Итак, если все члены команды согласны, что график – это ряд предположений, то проблемы не в нем самом, а в его применении. Если график показывают на встрече команды или отправляют всем по электронной почте, возникает вопрос: насколько реальны указанные сроки? Если, например, не указаны пять самых вероятных рисков и прогнозы по ним, и тот, кто составил график, не может объяснить свои предположения, следует признать, что график возможен, но нереален [25]. Команда должна высказать свое мнение – какие соображения и какую информацию можно добавить или изменить, чтобы он стал более правдоподобным.

График работы вовсе не должен быть идеальным (большое облегчение, конечно, потому что идеальных графиков не существует). Достаточно, если он будет убедительным для команды и лидеров, допускать мониторинг и внесение поправок, а также указывать на вероятность успеха, которая удовлетворяет клиента, бизнес или спонсора проекта.

На этапе проектирования ( глава 5и глава 6) одна из задач команды – разбить проект на небольшие части. Эти части, которые нередко называют элементами (единицами) работы или иерархической структурой работ (work breakdown structure, WBS [26]), становятся пунктами общего графика проекта. Элементы работы (скрестим пальцы) оптимально распределяются [27]среди программистов, затем подсчитывается время на создание каждой из них и выстраивается график. Программист должен выделить каждому элементу работы определенное время и на основе этих прогнозов составить график.