День 2067. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 25. Айсберги всегда больше, чем кажутся
Практически все проекты выходят за рамки первоначальной оценки после более тщательного анализа проблем и запросов на изменение во время разработки. Чем дольше длится проект, тем большего его роста можно ожидать. Требования, предъявляемые к крупным проектам, обычно увеличиваются на 1–3% в месяц во время разработки. Если в ваших планах не предусмотрен такой рост, то вы наверняка отстанете от графика.
Так же, как на поверхности воды находится меньшая часть айсберга, так и большая часть работы над программным проектом изначально может быть неочевидна. Итеративные подходы к разработке подтверждают, что истинный размер айсберга неочевиден на первый взгляд. Поскольку ПО поставляется частями, заинтересованные стороны будут просить добавить дополнительные функции. И чем больше они увидят, тем больше им захочется.
Резерв времени
Один из способов не отстать от графика — предусмотреть резерв времени на случай непредвиденных обстоятельств. Запас времени помогает справиться с неопределённостью. В противном случае первое поступившее новое требование, выявление первой заниженной оценки или возникновение первой непредвиденной задачи сорвут график.
Резерв времени можно рассчитать на основе предыдущего опыта выхода за плановые границы и наблюдавшегося роста требований. Запланированные резервы времени могут идти как в конце нескольких взаимозависимых этапов разработки (питающие буферы), так и в конце всего проекта (буфер проекта). При Agile-разработке предусматривайте небольшие резервы времени в каждой итерации. Они помогут удержать цикл итераций в нужном русле и не откладывать незавершённую работу на более поздние итерации. Также можно предусмотреть дополнительную резервную итерацию в конце проекта, предназначенную для реализации отложенных и дополнительных требований и другой задержавшейся работы.
Резерв времени не влияет на конечный результат, он лишь обеспечивает запас прочности, позволяя учитывать неизвестные, непредвиденные обстоятельства и неточности оценки. Удаление резерва из графика не удаляет эти переменные, а просто снижает вашу способность справляться с ними и при этом выполнять обязательства. Руководитель, предлагающий убрать резервы времени, делает несколько предположений:
- Информация, которой вы располагаете сегодня, понятна, точна и стабильна.
- Все оценки точны или любые неточности будут уравновешивать друг друга.
- Известно, кто будет работать над проектом, и состав команды не изменится (никто не заболеет, не уволится и т.п.).
- Члены команды не будут отвлекаться на работу по поддержке предыдущего продукта или другие посторонние работы.
- Все зависимости проекта и риски от внешних факторов будут устранены вовремя.
Эти предположения загоняют команду разработчиков в угол и почти гарантированно приведут к нарушению графика. Лучший способ обосновать добавление в график резерва времени — показать, как он рассчитывается на основе предыдущего опыта работы. Данные, показывающие, насколько обычно растёт объём требований в ваших проектах, помогут обосновать необходимость включения в проект резерва времени.
Резервы времени также помогут в контрактных обязательствах. Когда клиент по ходу проекта попросит о небольшом изменении, наличие резерва времени позволит вам положительно ответить на его просьбу без риска сорвать график.
Итого
Планирование возможных событий не изменит того, что произойдёт на самом деле, но поможет преодолеть все сложности, не нарушая планов. Если вы не знаете всего размера айсберга, то ожидайте, что он будет больше, чем кажется, и планируйте соответственно. Даже если реализация проекта пройдёт успешно и выделенные резервы времени не используются, можно передать продукт досрочно — от этого выиграют все.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
>>Click here to continue<<