Цитаты из книги «Сделано»

Фред Брукс писал: «Самое сложное в создании программной системы — решить, что создавать.

Существуют методы построения грамотных прогнозов. Самый известный из них — PERT [10], который позволяет минимизировать риски, выводя средний показатель по высоким, средним и низким прогнозам. Метод хорош по двум причинам. Во-первых, это заставляет всех осознать, что прогнозы — лишь предварительный диагноз и что результаты могут быть совершенно разными. Во-вторых, это дает менеджеру проекта возможность регулировать агрессивность или консервативность графиков (больше веса можно приписать низким или высоким прогнозам).

Качество спецификаций и проектирования диктует, насколько точными должны быть прогнозы технических специалистов. Это обсуждается между менеджерами проекта и программистами. Чем выше требования по прогнозам, тем выше должно быть качество спецификаций. Подробнее о спецификациях мы поговорим в главе 7.

Прогнозы должны опираться на предыдущие результаты работы. Хорошая привычка для программистов — отслеживать свои прогнозы по проектам. Им следует обсуждать это со своим менеджером, который должен стремиться понять, кто в его команде делает грамотный «мониторинг». Экстремальное программирование использует термин производительность, когда речь идет о вероятных результатах работы программистов (или команды) в зависимости от их предыдущих результатов [9].

Определить базовые показатели доверия прогнозам. Догадка = 40% доверия. Обоснованный расчет = 70%. Детальный и тщательный анализ = 90%. Лидеры команды должны согласовать, какая точность им нужна, сколько времени они дают программистам на ее расчеты и как справиться с рисками, если прогнозы не оправдаются. Не зацикливайтесь на цифрах: используйте их просто для того, чтобы четко обозначить качество прогнозов. Доверие на уровне 90% означает, что прогнозы оправдываются в 9 случаях из 10. Если вы решили попросить команду улучшить качество прогнозов, то нужно дать ей больше времени.

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

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

Экстремальное программирование называет эти части итерациями; спиральная модель — фазами; а некоторые организации — контрольными точками.

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

Как Том ДеМарко пишет в книге «Человеческий фактор»13: Одержимость методологией — еще один пример иллюзии высоких технологий. Люди убеждены, что самое главное — технология. <…> Но какими бы ни были технологические преимущества, они возможны лишь за счет значительных жертв со стороны команды.