В спиральной модели нет фиксированных этапов – например, разработки спецификации или проектирования. Она может включать в себя любые другие модели разработки. Например, на одном витке спирали может использоваться прототипирование для более четкого определения требований, а на следующем витке может применяться каскадная модель.
Совершенно противоположный по идеологии подход к разработке принято называть гибким (Agile). Считается, что он изначально появился как ответ на невозможность использования «водопадной» модели в сложных творческих проектах по разработке ПО. Один из центральных постулатов Манифеста Agile, на положениях которого основана вся философия гибкой разработки проектов, таков: изменения в проекте допустимы на любой стадии реализации. Для менеджеров – приверженцев классического подхода, как ты понимаешь, это делает управление проектом похожим на ад: все бюджетирование «идет лесом», сроки реализации проекта туманны, требования неясны. Но, если вдуматься, это и есть признаки типичного проекта по разработке видеоигры. Отчасти это и делает применение «гибких» методик в сфере разработки игр весьма распространенным.
Суть гибкого подхода – использование достаточно коротких итераций разработки в ответ на вводимые изменения в требованиях.
Почти полное отсутствие плана разработки в этом случае компенсируется постоянными взаимодействием с заинтересованными лицами проекта (например, с заказчиком) и обратной связью от них, что довольно сильно снижает продуктовые и проектные риски. А отсутствие изначальных принятых и согласованных требований позволяет вносить в проект изменения и постоянно экспериментировать.
Основные недостатки этого подхода – все, что связано с довольно сложным взаимодействием в ходе работы над проектом, соблюдением принципов методологии и планированием ресурсов.
Гибкая модель (на примере Scrum)
Когда речь заходит о гибких методологиях, практически у 90 % менеджеров в голове возникает одно слово – Scrum. Это одна из наиболее популярных итерационных моделей разработки ПО, относящихся к Agile. Методология хорошо задокументирована, и ты легко найдешь подробный материал для ознакомления. Я лишь кратко постараюсь осветить основные положения и процессы.
Основных ролей в Scrum три.
1. Владелец продукта (Product owner)
2. Команда разработки (Development team)
3. Scrum-мастер (Scrum master)
Владелец продукта (ВП) – это заказчик или представитель заказчика. Он обладает техническими знаниями в такой мере, чтобы формулировать требования к разрабатываемому продукту. Владелец продукта отвечает за формирование видения (vision) продукта и принятие окончательных решений. Инструмент ВП – Журнал Продукта (Product Backlog), который используется для записи требований к продукту в порядке их приоритета. В этом же журнале прописываются критерии готовности реализации требований (Definition of Done).
Роль Scrum-мастера отличается от менеджера продукта; это, скорее, капитан команды (кстати, термин scrum был заимствован из регби, где им обозначают схватку команд при розыгрыше мяча). Его основная задача – обеспечить выполнение требований методологии и постоянный ритм работы, а также уберечь команду от внешних мешающих работе воздействий. При этом он также разработчик и выполняет задачи по реализации проекта.
Команда разработки (КР) состоит из специалистов, задача которых – реализация задач по проекту и разработка финального продукта. Согласно идеологии Scrum к команде предъявляются следующие требования.
1. Команда должна быть способна к самоорганизации (и это понятно, ведь начальника в виде менеджера проекта или продюсера над ними нет).
2. Специалисты должны обладать всеми необходимыми навыками для реализации продукта, то есть команда должна быть многофункциональной.
3. Ответственность за выполненную и невыполненную работу несет вся команда, а не индивидуальные члены.
При этом рекомендуемый размер команды – 7 ± 2 человека. Считается, что у команды большего размера неизбежно возникнут сложности с коммуникацией. Если же размер команды меньше, то она может не обладать всеми необходимыми компетенциями для реализации проекта.
Инструмент команды – Журнал Спринта (Sprint Backlog), в котором требования ВП преобразуются в конкретные задачи.