А знаете ли вы, что работа с использованием итераций не делает вас автоматически Agile командой. Более того, это даже не значит обязательно, что у вас внедрена итеративная разработка.
Как не парадоксально, но верно и следующее – вполне возможно быть Agile командой без использования итераций (например, используя Kanban).
Давайте разберемся подробнее с этим.
Что такое итеративная разработка?
Итерационная разработка предполагает, что мы, вероятно, сделаем что-то неправильно, прежде чем получим правильный результат, и что все будет плохо, прежде чем станет хорошо (Goldberg and Rubin 1995).
Примером итерационной разработки может быть идея, трансформируемая в грубый прототип продукта, который, в свою очередь, видоизменяется и становится лучше. Это наверняка будет довольно плохой продукт cотсутствием многих фич, но он позволит нам прощупать идею, и решить хотим ли мы двигаться дальше.
Джефф Паттон приводит наглядный пример с портретом Мона Лизы, который демонстрирует итеративный подход.
Хочу отметить, что этот пример утрирован, нам не обязательно «итерировать» весь продукт целиком. Просто итеративная разработка предполагает любые изменения по своей сущности, не требуя обязательных фундаментальных изменений во всем продукте.
Что такое инкрементная разработка?
Инкрементная разработка подразумевает добавление – кусочек за кусочком, подобно тому, как строится дом – один кирпич за другим.
Если снова использовать пример с картиной Леонардо, это значит постепенное создание полотна без повторных изменений. Трудно представить, что сам Леонардо, таким образом, создавал свои шедевры.
Как отмечает Алистер Коберн в своем блоге:
Инкремент фундаментально означает Добавление.
Итеративность фундаментально означает Переработку.
В реальной жизни и наших проектах нам чаще всего приходится сталкиваться с комбинацией итеративной и инкрементной типами разработки, хотя и чистые варианты тоже возможны.
Таким образом, прямая привязка итераций к итерационной разработке не верна. В Скраме выбрана правильная терминология. Мы имеем дело со Спринтами, а не итерациями. Скрам определяет Спринт как ограниченный временной промежуток длиной в месяц или меньше (Scrum Guide, 2011). Все, точка!
Есть масса «гибких» команд, которые страдают от чрезмерной инкрементной разработки. Владелец продукта постоянно заставляет команду добавлять новые фичи, продукт растет как на дрожжах, пока не лопается как мыльный пузырь из-за того, что оказывается никому не нужным. Не была получена жизненно важная обратная связь от пользователей и, как следствие, не внесены необходимые изменения.
Есть и огромное количество водопадных команд, которые погибают от ничем не сдерживаемой итеративности и бесконечных изменений. Такие команды находятся в порочном круге постоянных переделок, у них нет времени на то, чтобы двигаться вперед.
Гибкая разработка предполагает комбинированный подход, где выдерживается баланс между инкрементной и итеративной разработкой.
Как найти этот баланс?
Не существует готового рецепта.Его вам придется создать самим, учитывая конкретный проект и продукт, над которым вы работаете. Но есть несколько принципов, которым полезно следовать.
Полезные ссылки по теме.
[…] Инкрементально-итеративный подход предполагает, что финальный продукт рождается в результате многочисленных экспериментов и получения обратной связи от конечных пользователей и заинтересованных лиц. Итеративность предполагает изменения того, что было сделано на предыдущих шагах. Это автоматически значит изменение правил игры и уход от Fixed Scope-Price-Time контрактов и переход к прямому взаимодействию бизнеса с разработкой (Customer Collaboration over Contract Negotiation). Влечет ли это за собой потенциальные организационные изменения? Скорее всего. […]