Вопрос «Agile или Waterfall?» возникает, когда проекту одновременно нужны предсказуемость и возможность менять решение. Название подхода само по себе этого не обеспечивает. Команде ещё предстоит определить результат, выстроить зависимости и договориться, что делать при отклонении от плана.
В чём разница между Agile и Waterfall
Waterfall, или каскадная модель, строит работу как последовательность этапов: требования, проектирование, реализация, проверка и запуск. Agile — набор ценностей и принципов, в котором важны взаимодействие, работающий результат и реакция на изменения. Scrum — один из способов организовать такую работу, поэтому Agile и спринты не стоит считать синонимами.
| Вопрос | Waterfall | Agile |
|---|---|---|
| Насколько понятен результат? | Заранее можно достаточно подробно описать, что требуется | Существенные вопросы ещё нужно проверить на практике |
| Как устроен план? | Основу составляют связанные этапы и условия перехода | Решение и ближайшая работа уточняются с учётом обратной связи |
| Как работать с изменением? | Оценить влияние на объём, связанные работы, бюджет и сроки | Пересмотреть очередность и решение, сохранив понятную цель |
| Где главный риск? | Поздно узнать, что согласованное решение не решает задачу | Потерять направление за постоянным изменением списка работ |
В таблице — ориентиры, а не запрет на обратную связь в Waterfall или на документы в Agile. Проверять допущения и фиксировать договорённости полезно в обоих случаях.
Один проект — два способа начать
Возьмём учебный пример: команда делает запись на занятия. Требование «добавить выбор времени и подтверждение» может скрывать две совершенно разные ситуации.
В первой ситуации сценарий уже проверен. Команда переносит работающую запись в новую систему. Известны обязательные поля, правила отмены и внешние интеграции. Здесь разумно заранее согласовать этапы, условия приёмки и порядок переключения. Особенно внимательно нужно спланировать работы, которые трудно отменить.
Во второй ситуации пока неизвестно, как людям удобнее записываться. Возможно, им нужен выбор времени, а возможно — быстрый запрос администратору. Здесь полезно сначала проверить простейший сценарий на небольшой группе, изучить результат и только потом расширять решение. Подробно планировать все функции до такой проверки рано.
В обоих случаях остаются обязательные технические проверки и договорённости с командой. Отличается прежде всего степень уверенности в решении и допустимая цена ошибки.
Почему выбранный подход может не помочь
В главе «Приоритизация» разобрана знакомая ситуация: дизайнер ждёт уточнения, разработчик — макет, тестировщик — исправление. Каждый занят собственной работой, но задача в целом стоит. Добавление ещё одной задачи в план не устраняет ожидание.
Это хороший повод посмотреть на связи между специалистами. Зарезервировано ли время на консультацию? Известно ли, кто принимает спорное решение? Можно ли подготовить следующий этап до передачи результата? Такую проверку стоит проводить независимо от выбранной методологии.
В книге планирование связано с исполнением: команда регулярно возвращается к обещаниям, видит отклонение и пересобирает ближайшие действия.
Как выталкивающие таблицы соединяют полезные практики
Выталкивающие таблицы дают команде общий вид работы на разных горизонтах. На месяц видны крупные результаты, на неделю — ближайшие переходы между этапами, на день — конкретные действия. Подробное описание остаётся в трекере, а таблица показывает движение проекта.
Так можно сохранить ясную последовательность этапов, уточнять ближайшую работу по новым данным и проверять факт ежедневно. Это практическое сочетание сильных сторон разных подходов: структуры, адаптации и внимания к прохождению задач. Его ценность — в связи этих действий в один рабочий ритм.
Таблица не увеличит доступное время специалиста и не примет решение за руководителя. Она поможет раньше увидеть, где требуется вмешательство. Подробный разбор — в статье о выталкивающих таблицах.
Четыре вопроса перед выбором
- Какие части результата уже известны, а какие пока являются предположением?
- Как быстро можно получить обратную связь и сколько стоит переделка?
- Какие внешние зависимости задают обязательную последовательность?
- Кто и как будет обновлять план после проверки результата?
Ответы помогут выбрать рабочие правила. Затем нужен план проекта: что проверить первым, какой результат показать и когда команда пересмотрит следующие шаги.
Где сверить определения
Краткие определения опираются на Agile Manifesto и описание Waterfall у Atlassian. Пример с записью создан для этой статьи; разбор зависимостей и связанного планирования основан на книге.