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

Для начала давайте разберёмся, что именно мы собираемся сочетать — дадим определения. Может быть, уже одно это хорошо прояснит некоторые вопросы.

Календарное планирование

Календарное планирование — это планирование через Гантт, сетевые диаграммы и подобные штуки. Когда строится сквозной план через весь майлстоун (проект). Проставляется длительность задач и зависимости между ними. Является основной классической практикой используемой, чтобы найти критический путь и определить длительность майлстоуна.

Майлстоуном — я называю часть времени проекта, где у нас появляется набор задач, по которому нужно уложиться в сроки. Вообще говоря, это не правильное определение. Изначально проектом, как раз, и называлась совокупность работ по достижению некоторого результата в оговоренные сроки. А майлстоунами назывались просто важные вехи в проекте.

Но в аутсорсе, где я работал 16 лет, термином «проект» называют почти любые активности для некоторого заказчика. Пришёл новый заказчик, хочет разработать или доработать какой‑то продукт — назовём это проектом!

Например, на почасовых проектах, как правило, заказчик нанимает команду, а результат даже нигде не фиксируется. А таких «проектов», по‑моему, большинство в аутсорсе. Как правило, задачи поставляются итеративно, а сроки ставятся уже для отдельных эпиков или наборов задач. Но параллельно есть ещё куча задач, по которым сроков нет.

Поэтому я, со временем, стал называть майлстоунами — временнЫе отрезки в рамках проекта, где появляются жёсткие сроки по части задач.

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

Agile

Agile — Scrum / Kanban, работа итерациями. Когда описание задачи детализируется по мере приближения к работе над ней. А плана на весь проект либо нет вообще, либо он крайне приблизительный.

Часто ошибочно считают, что если команда работает итерациями, просто беря задачи из бэклога, то это они по Agile работают. На самом деле это не так. Я бы назвал это просто инженерным конвейером: требования на вход ‑→ инкременты продукта на выход.

Изначально в Agile вопрос о сроках тоже стоял. Причём серьёзно. Agile начался с опыта команды Кента Бека (автора книги «Экстремальное программирование» — про одноимённую методологию). Тогда в компании Chrysler разрабатывали систему расчёта зарплатных ведомостей. По классической проектной модели с большой командой. Но проект развалился почему‑то, про это Бек деталей не даёт. Кажется, они сильно начали превышать сроки и бюджет, как обычно и бывает.

И тогда Бек с командой из нескольких человек (наверняка, очень сеньористых) решили сделать по‑другому. Наметили себе срок в 3 недели и сделали за эти 3 недели рабочий прототип. Который мало что умел, но основные операции уже выполнял. Потом показали его начальству, и тем понравилось. Взяли ещё 3 недели и доработали этот прототип. Опять показали начальству, получили замечания и критику. И так далее. В итоге, за несколько месяцев они получили рабочую систему, которая была принята в эксплуатацию!

То есть, в Agile вопрос о сроках изначально был. Но его поставили с ног на голову. Решили укладываться в сроки не аккуратным планированием сетевых диаграм и проработкой рисков и буферов. А выделили самые‑самые‑самые критичные требования и реализовали только их. За очень небольшое время. А потом подобным же образом стали дорабатывать.

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

Но этот принцип в себя потом впитали и Rational Unified Process, где сначала разрабатывается прототип, который должен покрывать требования в ширину и закрывать основные архитектурные риски. И методология FFF (Fixed time, fixed budget, flexible scope). Причём, в FFF это уже основной принцип — для попадания в сроки нужно варьировать не сроки, а скоуп.

Про это же самое писали и ДеМарко с Листером в своей книге «Вальсируя с медведями. Управление рисками в проектах по разработке ПО»:

Самый лучший способ справится с любыми рисками — начать работу как можно раньше!

И Макконнелл в моей любимой «Сколько стоит программный проект?»:

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

Цитаты не дословные.

Как сочетать календарное планирование и Agile

Теперь, когда мы разобрались в определениях, гораздо легче разобраться, как сочетать эти штуки:

Определить по каким именно задачам в проекте у вас есть сроки. И есть ли они? Построить Гантт по этим и только по этим задачам (писал про это здесь).
Разбить эти задачи на два приоритета: Must Have и Stretch. И проверить, что в Гантте сначала по таймлайну идёт Must Have, а потом уже Stretch. Или вообще не выносить Stretch на Гантт. Очень помогает User Story Mapping, где мы как раз определяем, какие требования относятся к «скелетным», т. е. Must Have — то, что надо закрывать в первую очередь.
Попытаться разбить Must Have задачи по итерациям, чтобы как можно быстрее получить рабочий прототип. Прототип, который займёт 20% времени, но закроет большую часть рисков и удовлетворит 80% требований заказчика (правило Парето). При этом не обязательно искусственно запихивать задачи в размер итераций — какие влезли в итерацию, такие влезли. Главное — регулярно показывать демы и получать фидбек заказчика по тем задачам, которые уже готовы.
Метод набегающей волны: скоуп детализируется по мере приближения к нему. Это отличный метод. Но на Гантте лучше оставить только верхнеуровневые, не детальные задачи, чтобы не перегружать Гантт.
Следовать всем принципам Agile. Но при этом следить за общими сроками. Стараться максимум задач выносить в Stretch. И фокусироваться в первую очередь на Must Have задачах.

Надеюсь, это поможет немного разложить у себя в голове по полочкам и в итоге совместить полезные принципы и практики календарного планирования и Agile.