Согласно Руководству по Скраму, Скрам — это итеративно-инкрементальная разработка:
Scrum использует итеративный, инкрементальный подход для оптимизации предсказуемости и контроля рисков (Руководство по Скраму).
{$co}
Слова “итеративный” и “инкрементальный” перечислены через запятую. Это разные подходы? Можно работать в чистой итеративной разработке и не использовать итерации (Спринты)? Или работать Спринтами, но в чистом инкрементальном стиле? Запутались? Возвращаемся к основам и разбираем разницу между итеративной и инкрементальной разработкой.
Итеративная разработка
Итеративную разработку часто путают с итерациями. Но это просто однокоренные слова. Итеративная разработка означает ИЗМЕНЕНИЕ того, что делалось на предыдущих этапах. Например, Скрам-команда реализовала фичу и представила ее на Обзоре Спринта. Стейкхолдеры дали обратную связь и Владелец Продукта положил в Бэклог Продукта новые элементы:
“Изменение фичи 1”
“Изменение фичи 2”
“Изменение фичи 3”
Рис. 1: итеративная разработка подразумевает изменения
Изменения могут касаться нефункциональных требований. Например, команда переделывает архитектуру, потому что изменились требования к нагрузке.
Если вы замечали, как по весне перекладывается асфальт на российских дорогах, то это пример итеративной разработки. Старый слой асфальта снимается, кладется новый слой.
Итеративную разработку используют художники и артисты. Сделав эскиз, художник может поменять его, потом добавляет краски и меняет контуры объекта.
Инкрементальная разработка
Инкрементальная разработка означает ДОБАВЛЕНИЕ того, чего не существовало ранее. К примеру, команда реализовала новую фичу, которой не было ранее, и теперь клиент заходит в свой личный кабинет с помощью аккаунтов в социальных сетях.
Рис. 2: инкрементальная разработка это добавление нового
Итеративно-инкрементальная разработка
В продуктовой разработке инкрементальность и итеративность усиливают друг друга. Помимо добавления новых функций, команда работает над изменениями старых. Например, Спринт 1 может быть посвящен инкрементальной разработке (новые функции), а Спринт 2 и Спринт 3 изменениям по итогам обратной связи.
Что следует учесть при итеративного-инкрементальном стиле разработки? Здесь можно прислушаться к советам Алистера Коберна, одного из подписантов Аджайл Манифеста:
Заранее примите то, что вы неизбежно будете переделывать пользовательский интерфейс и архитектуру вашего продукта. Иногда многократно.
На каждую новую фичу планируйте как минимум 2 переделки пользовательского интерфейса, одну переделку требований и изменение архитектуры.
Учитывайте, что обычно первая переделка занимает 1 / 3 изначального времени разработки, вторая 1 / 2.