Итеративная разработка: гибкость и минимизация рисков

Короткие итеративные циклы в работе далеко не новы, но они лучше остальных подходят для условий неопределённости. Адаптировать продукт можно буквально на ходу. Знаменитую фразу про «украл, выпил, в тюрьму» можно перефразировать для итеративных проектов примерно так: «запланировали, сделали, переделали… переделали снова… и снова…».

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

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

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

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

Если сильно упростить, то это научный аналог метода проб и ошибок: попробовали концепцию, не получилось, вернулись в исходную точку, попробовали новую концепцию, получилось, двинулись дальше и так далее, от итерации к итерации.

Почти все гибкие методологии управления проектами близки к такой идеологии. Метод итераций широко применяется в Agile-подходах: Scrum, Kanban, бережливое производство (lean), Six sigma, метод критического пути и т.д.

Тем не менее, итеративную разработку можно внедрить где угодно, привязка к Agile не обязательна. Простейший пример – связка с MVP. Сначала вы разрабатываете минимальный жизнеспособный продукт, а затем планомерно улучшаете его и доводите до совершенства. Получается, что первая итерация – это создание MVP, а все последующие – улучшение продукта.

Основная проблема коротких итераций – потенциальная возможность застрять в бесконечных циклах доработок, когда проект рискует превратиться в одно сплошное «вечное улучшение». Это будет состояние, похожее на «Ещё чуть-чуть, и мы точно выпустим первую стабильную версию!», которое никогда не заканчивается.

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

Итеративная разработка Vs Инкрементная

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

При итеративной разработке продукт создаётся постепенно, с остановками для оценки результата. Например, может собираться обратная связь от потенциальной аудитории, от заказчиков и других стейкхолдеров. А может даже проводиться комплексный анализ рынка, чтобы понять, потерял ваш продукт актуальность или нет. В любой момент может быть принято решение об остановке разработки или её кардинальном переформатировании (вплоть до того, что разработку могут начать с нуля).

А инкрементный подход – это когда продукт проектируется таким, каким он должен получиться на выходе. В соответствии с планом (или календарным графиком) разработка разбивается на небольшие шаги (инкременты), и начинается работа. Границами инкрементов могут выступать, например, какие-то специальные самодостаточные функции или реализация подсистем. После каждого шага нет остановок или какого-то комплексного анализа. Деление на инкременты делается скорее для удобства управления. Конечный продукт планомерно обрастает новыми функциями по мере их реализации – но всё в рамках изначального генерального плана. Отклонения от плана маловероятны.

Это чем-то напоминает подход Waterfall, только разбитый на более мелкие шаги – инкременты. Каждый новый инкремент не меняет уже реализованные функции, а только дополняет их.