Короткие итеративные циклы в работе далеко не новы, но они лучше остальных подходят для условий неопределённости. Адаптировать продукт можно буквально на ходу. Знаменитую фразу про «украл, выпил, в тюрьму» можно перефразировать для итеративных проектов примерно так: «запланировали, сделали, переделали… переделали снова… и снова…».
Итеративный подход – это как бесконечная череда попыток создать идеальное блюдо: каждый раз пробуешь, добавляешь ингредиенты, исправляешь ошибки, и вот уже к примерно к сотому разу получается шедевр.
Вместо отвлечённых примеров давайте погрузимся в детали и разложим всё по полочкам.
Определение итеративной разработки/управления проектами
Итеративное управление проектами – это подход, при котором работа выполняется небольшими повторяющимися циклами (итерациями). В каждой итерации создаётся и тестируется промежуточный результат, что позволяет команде постепенно улучшать продукт на основе своевременной обратной связи.
Если сильно упростить, то это научный аналог метода проб и ошибок: попробовали концепцию, не получилось, вернулись в исходную точку, попробовали новую концепцию, получилось, двинулись дальше и так далее, от итерации к итерации.
Почти все гибкие методологии управления проектами близки к такой идеологии. Метод итераций широко применяется в Agile-подходах: Scrum, Kanban, бережливое производство (lean), Six sigma, метод критического пути и т.д.
Тем не менее, итеративную разработку можно внедрить где угодно, привязка к Agile не обязательна. Простейший пример – связка с MVP. Сначала вы разрабатываете минимальный жизнеспособный продукт, а затем планомерно улучшаете его и доводите до совершенства. Получается, что первая итерация – это создание MVP, а все последующие – улучшение продукта.
Основная проблема коротких итераций – потенциальная возможность застрять в бесконечных циклах доработок, когда проект рискует превратиться в одно сплошное «вечное улучшение». Это будет состояние, похожее на «Ещё чуть-чуть, и мы точно выпустим первую стабильную версию!», которое никогда не заканчивается.
С другой стороны, если у команды есть чёткое видение конечного результата, такого состояния вполне можно избежать.
Итеративная разработка Vs Инкрементная
Технически подходы очень похожи. Но есть и различия, сейчас поясним в чём разница между инкрементной и итеративной разработкой продуктов.
При итеративной разработке продукт создаётся постепенно, с остановками для оценки результата. Например, может собираться обратная связь от потенциальной аудитории, от заказчиков и других стейкхолдеров. А может даже проводиться комплексный анализ рынка, чтобы понять, потерял ваш продукт актуальность или нет. В любой момент может быть принято решение об остановке разработки или её кардинальном переформатировании (вплоть до того, что разработку могут начать с нуля).
А инкрементный подход – это когда продукт проектируется таким, каким он должен получиться на выходе. В соответствии с планом (или календарным графиком) разработка разбивается на небольшие шаги (инкременты), и начинается работа. Границами инкрементов могут выступать, например, какие-то специальные самодостаточные функции или реализация подсистем. После каждого шага нет остановок или какого-то комплексного анализа. Деление на инкременты делается скорее для удобства управления. Конечный продукт планомерно обрастает новыми функциями по мере их реализации – но всё в рамках изначального генерального плана. Отклонения от плана маловероятны.
Это чем-то напоминает подход Waterfall, только разбитый на более мелкие шаги – инкременты. Каждый новый инкремент не меняет уже реализованные функции, а только дополняет их.
Из каких элементов (этапов) состоит цикл итеративной разработки
Каждая итерация включает в себя следующие этапы и элементы:
- Планирование (Plan)
Цель: определение задач и целей на конкретную итерацию.
Составляющие компоненты или шаги:
- Формирование бэклога (списка требований и задач).
- Определение ключевых целей и критериев успешности (в рамках конкретной итерации).
- Распределение обязанностей в команде (функции, задачи, планирование нагрузки).
- Оценка сроков выполнения.
- Анализ и проектирование (Analyze & Design)
Цель: разработать архитектуру и выбрать подходящие технические решения.
Составляющие компоненты или шаги:
- Определение структуры будущей системы.
- Подготовка входящих данных и ресурсов (схем, API, UX-дизайна, если речь о программной разработке).
- Проектирование задач и их декомпозиция при необходимости (проработка алгоритмов и ключевой логики работы).
- Разработка (Develop)
Цель: реализовать намеченные цели и задачи для конкретной итерации.
Составляющие компоненты или шаги:
- Непосредственно работа над реализацией списка задач (написание кода, реализация новых функций и т.п.).
- Интеграция с предыдущими версиями продукта / с уже реализованными функциями.
- Ведение документации по изменениям.
- Тестирование (Test & Review)
Цель: выявить ошибки и проверить то, что получилось, на предмет соответствия исходным требованиям (поставленным задачам/целям).
Составляющие компоненты или шаги:
- Различные тестирования и проверки (юнит-тесты, интеграционные тесты, UI/UX-тестирования и т.д.).
- Проверка на соответствие техническому заданию.
- Исправление найденных ошибок (если это возможно в размах текущей итерации, если нет – работа над исправлениями выносится в следующую итерацию).
- Демонстрация и обратная связь (Demo & Feedback)
Цель: получить фидбэк от пользователей и заказчиков (пример того, как это можно сделать в рамках подхода Voice of Customer).
Составляющие компоненты или шаги:
- Презентация текущего результата.
- Сбор обратной связи от заинтересованных сторон.
- Анализ (кластеризация) замечаний и выявление необходимых изменений (с расстановкой приоритетов и параметров важности/критичности).
- Корректировка и доработка (Evaluate & Adapt)
Цель: улучшить (оптимизировать) продукт на основе полученных данных.
Составляющие компоненты или шаги:
- Приоритизация новых задач (например, по методике Кано).
- Корректировка бэклога и стратегии.
- Подготовка к следующей итерации.
∞ Начало новой итерации (заход на новый цикл)
После завершения цикла начинается новая итерация, и процесс повторяется до тех пор, пока продукт не достигнет финального состояния или не будет выпущен в продакшен.
Такой подход позволяет гибко адаптироваться к изменениям, минимизировать риски и выпускать продукт быстрее, с нужным качеством и потребительскими свойствами – то есть максимально конкурентоспособный.
Плюсы итеративного управления проектами
- Гибкость и адаптивность. Вы можете вносить изменения в проект на любом этапе разработки, адаптируясь к новым требованиям и внешним условиям (буквально на ходу).
- Быстрое выявление и исправление ошибок. Это становится возможно благодаря этапам тестирования и сбора обратной связи, плюс в каждой итерации предусматривается место (время и ресурсы) для внесения корректировок.
- Возможность улучшения и усовершенствования продукта. Каждая итерация делает продукт лучше (актуальнее и конкурентоспособнее).
- Быстрое приближение к первой работоспособной версии продукта. Достаточно в первых итерациях поставить цель реализации минимальной жизнеспособной модели. Соответственно, работающий продукт уже можно демонстрировать заказчикам и потенциальной аудитории, собирать актуальную обратную связь. А это всегда твёрдая база для дальнейших шагов и оптимизаций.
- Снижение рисков. Разделение работы на небольшие циклы помогает выявлять потенциальные проблемы на ранних этапах, снижая вероятность провала всего проекта. Даже если потери будут, они будут минимальными.
- Повышение прозрачности процесса. И клиенты, и заказчики, и сама команда разработчиков будут видеть реальный результат своей работы, а также смогут вживую изучать все изменения и улучшения. Регулярные отчёты и обратная связь позволяют всем заинтересованным сторонам следить за ходом реализации проекта и понимать, на каком этапе находится работа.
- Улучшение взаимодействия команды. При итеративной разработке обсуждения проводятся чаще, а сами коммуникации становятся более продуктивными. Исполнители лучше понимают цели проекта и свои задачи. Соответственно, им становится проще находить эффективные решения и сглаживать острые углы.
- Возможность тестирования гипотез. Если продукт создаётся в условиях неопределённости, итеративный подход позволяет проверять идеи на практике и быстро корректировать общую стратегию.
Минусы и подводные камни итеративного управления
Не бывает идеальных подходов. Работа на основе итераций – не исключение. Недостатки итеративной разработки или управления можно описать так:
- Высокий риск бесконечных доработок. Достичь идеала нереально. Поэтому доработками, улучшениями и тестированием можно заниматься бесконечно. Итеративная разработка может привести к постоянному внесению изменений, из-за чего проект рискует не то, что никогда не завершиться, но даже не зарелизиться. Потенциальное решение такой проблемы: стараться определять чёткие цели итераций и устанавливать границы для количества исправлений (очерчивать пределы: бюджеты, время, качество).
- Рост затрат на управление проектом. Каждая итерация требует дополнительного времени на анализ, тестирование, обратную связь и планирование, что увеличивает срок реализации проекта. А время – это ценный ресурс, который легко конвертируется в оплату труда команды. Много времени = большой бюджет. Потенциальное решение: оптимизировать и максимально автоматизировать рабочие процессы, внедрить систему управления, поставить чёткие границы для сроков и бюджета.
- Опасность разрастания требований (в английском даже есть термин «Scope Creep», русск. «расползание рамок»). У гибкости и адаптивности есть обратная сторона – из-за того, что в исходный план постоянно вносятся изменения, стартовая модель проекта может существенно отличаться от реальной (той, что получается после каждой новой итерации). Соответственно, в какой-то момент можно полностью потерять нить – то, ради чего проект затевался. В итоге вы полностью утратите контроль над продуктом. Потенциальное решение: приоритизировать задачи и строго фиксировать критически важные требования (они должны выступать в роли некоего костяка или каркаса, чтобы было от чего отталкиваться и на основе чего оценивать конечный результат).
- Накопление технического долга. Случается в ситуациях, когда что-то остаётся недоделанным в рамках одной из итераций (например, из-за того, что задачи были неправильно оценены на входе и не уложились в разумные сроки стандартного цикла разработки). Чем чаще случаются такие недоделки и чем больше у вас на входе новых задач, тем выше вероятность того, что к реализации «задолженностей» уже никто и никогда не вернётся. Просто будет не до них. А большой объём технического долга в какой-то момент может стать проблемой для базовой архитектуры. Потенциальное решение: регулярно пересматривать актуальность ключевых функций и механизмов проекта, например, рефакторить код, внедрять автоматизированное тестирование и т.п., а также повышать приоритет незавершённых задач при переносе их в новую итерацию.
- Требуется высокая вовлечённость заказчиков и клиентов. Различные тестирования, опросы, исследования и т.п. отнимают массу времени и сил. И если клиенты ещё хоть как-то могут выделить минутку на опрос, то для заказчика получается ситуация, когда ему нужно обеспечить наличие постоянного представителя в команде разработчиков продукта (он будет отвечать за оперативную коммуникацию и формирование позиции по разным вопросам). Такое могут себе позволить далеко не все. А если оперативной обратной связи не будет, циклы разработки могут существенно замедлиться, что тоже недопустимо (для всех сторон процесса). Потенциальное решение: устанавливать регулярные точки контакта и обеспечивать прозрачность разработки на уровне информационных систем (например, за счёт систем управления проектами, к которым представители заказчика подключаются в особом статусе – со специальными аккаунтами и ограниченными правами доступа).
Выводы и рекомендации
Несмотря на то, что итеративный подход помогает повысить гибкость и качество разработки, он требует чёткой организации, контроля изменений и дисциплины команды. Если не учитывать потенциальные подводные камни, процесс может стать неуправляемым. Сроки будут постоянно отодвигаться, а затраты на разработку станут расти.
Чтобы обеспечить достаточный контроль и прозрачность, в проекте должна использоваться система управления, такая как Projecto. Тогда и участники команды, и представители заказчиков смогут наблюдать за реализацией в режиме онлайн, давать оперативную обратную связь, корректировать ключевые цели и задачи проекта.