День 1998. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Начало
Наверняка всем приходилось работать над проектом, который постепенно разбухал. Но был ли изначально чётко определён его объем?

Призрак разбухания проекта
Разбухание часто называют главной причиной того, почему реализация проекта не укладывается в запланированный график. Но вы не узнаете, имеет ли место разбухание проекта, если нет согласованной точки отсчёта: «Вот что мы намерены сделать в этот период времени».

Объём проекта можно определить как набор возможностей, с реализацией которого в конкретной итерации, сборке или выпуске продукта соглашаются заинтересованные стороны. Всякий запланированный этап работы начинается с базовой функциональности, которую команда должна реализовать на данном этапе. Это является отправной точкой, позволяющей определять изменение объёма.

Люди традиционно считают разбухание проекта чем-то плохим. Оно свидетельствует о том, что выявленные требования были неполными или неточными и это повлекло поток дополнительных требований. В любом крупном проекте невозможно заранее определить все требования, поэтому должны предполагаться изменение и рост количества требований по мере того, как пользователи пробуют ранние версии, получают новые идеи и лучше понимают задачу. Сдерживание изменений из-за боязни разбухания проекта может привести к созданию продуктов, которые не удовлетворяют все потребности клиентов. Но и непрерывное разбухание может навредить.

В Agile-проектах участники намеренно не пытаются выявить объём всего проекта и определяют объём каждой итерации. В список требований постоянно добавляются новые пункты. Владелец продукта расставляет приоритеты для новых требований с учетом ещё не реализованных, чтобы определить, какие из них должны быть реализованы в ближайших итерациях. Это помогает точно выявить потребности пользователей, но может привести к неопределённости времени доставки конечного продукта.

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

В каждом случае цель определения объема состоит в том, чтобы выяснить, какие возможности должна предоставлять конкретная часть проекта. Выявление этих возможностей помогает установить границу области применения и задать точку отсчёта для рассмотрения изменений в этой области в процессе разработки.

Окончание следует…

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.