Выбор модели управления разработкой ПО

Перед тем как говорить о моделях управления разработкой ПО, нужно разобраться в сходствах и различиях между проектной и продуктовой разработкой, поскольку в них по-разному формулируются цели. Как вы помните, модель управления разработкой ПО — это совокупность методов планирования, отслеживания и контроля за процессом разработки ПО, направленных на своевременное и полное достижение поставленных целей. А если цели формулируются по-разному, то и модели управления применяются разные.

Проектная разработка выполняется в рамках проекта. Его определяют:

Таким образом, в проектной разработке команда собирается на ограниченное время для реализации конкретного ПО.

Продуктовая разработка — это создание и дальнейшее совершенствование программного продукта (приложения).

В отличие от проектной продуктовая разработка не имеет чётких целей и ограничений во времени и направлена на совершенствование продукта. Цель продуктовой разработки можно сформулировать как «создание приложения, максимально удовлетворяющего потребности пользователей». Но такая цель недостижима, поскольку в продукте всегда можно что-то улучшить. Таким образом, в продуктовой разработке команда постоянно занимается развитием и совершенствованием своего приложения.

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

Ещё один пример — разработка операционной системы Windows. Как определить, проектная это разработка или продуктовая? 5 октября 2021 года вышла последняя версия операционной системы — Windows 11. Есть конкретный срок и результат — новая версия операционной системы, — а значит, разработка проектная. С другой стороны, разработчики регулярно выпускают обновления, содержащие улучшения функциональности, оптимизируют ПО, устраняют уязвимости. Всё это признаки продуктовой разработки — нет конкретно сформулированной цели, ограничений по времени, команда непрерывно улучшает операционную систему. Таким образом, при разработке операционной системы Windows параллельно и взаимосвязанно ведётся и проектная, и продуктовая разработка.

Модели управления разработкой не делятся на плохие и хорошие — есть те, что подходят к ситуации, и те, что нет.

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

Если мы чётко понимаем, какой нужен результат, и уже реализовывали аналогичные задачи, можно составить достаточно точный план сразу на весь проект и применять каскадную модель.

Если мы примерно понимаем, но пока неточно знаем, какой нужен результат, составить детальный план на весь проект не получится, его придётся постоянно существенно корректировать. Тогда можно применить метод набегающей волны, позволяющий уточнить и детализировать план в процессе.

Использовать гибкие методологии в проектной разработке нежелательно, так как без плана работ на весь проект сложно гарантировать, что он завершится в срок.

Для продуктовой разработки применимы гибкие методологии и метод набегающей волны.

При использовании метода набегающей волны в продуктовой разработке общим планом становится дорожная карта (roadmap) — перечень будущих версий приложения с примерными датами релиза и ключевым функционалом этих версий. По мере выхода версий дорожная карта продлевается — в неё добавляются будущие перспективные версии.

Гибкие методологии применяются в отсутствие дорожных карт: в определённый момент времени на основе запросов от заинтересованных лиц выбирается самая актуальная функциональность.

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

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