Миф №1 – в Agile нет планирования

Я хочу разобраться с некоторыми из мифов об Agile-разработке программного обеспечения. Первый и, вероятно, самый известный миф: «В Agile нет планирования, вы просто решаете, что делать, по ходу дела».

Это совсем не так. На самом деле, я рискну сделать смелое заявление:

Во многих Agile-проектах больше планирования, чем в проектах Waterfall. На самом деле, планирования может быть даже слишком много. Возможно, что люди, работающие по Waterfall, сейчас поперхнулись кофе и разбрызгали его по всему столу. Давайте разберемся и поймем, почему я так считаю.

Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.

ПОДРОБНЕЕ

Дело не в планах, а в планировании

Это одна из моих любимых цитат:

«Планы ничего не стоят. Но планирование бесценно»

Это важный ключ к пониманию роли, которую планирование играет в Agile Software Development. В Waterfall идея состоит в том, что руководитель проекта составляет большой план в самом начале проекта. Помните, что содержание проекта обычно устанавливается заранее. Из него вы можете создать свою структуру разбивки работ, и свой план ресурсов (кто выполняет работу), и диаграмму Ганта (порядок, в котором выполняются задачи). И затем вы можете рассчитать свои затраты, потому что ресурсы стоят определенных денег.

Затем все ставят подписи (мы любим подписи!) на большом плане, и теперь проект согласован и заблокирован. Теперь все приступают к работе, следуя большому плану, который разработал руководитель проекта. Ну, а что сейчас делает менеджер проекта? Бездельничает, почитывая блоги? Конечно нет!

Его работа – защищать свой план любой ценой. Люди все время будут пытаться все изменить, добавить содержание, сдвинуть сроки, поменять человека А на человека Б, отложить это, удалить то, заменить одну технологию на другую, и поэтому руководитель проекта должен тратить много времени:

пытаясь остановить их (потому что кто-то подписал план, поэтому мы не можем изменить его, помните?);
записывая риски, если он не может предотвратить какие-то изменения (чтобы сообщить заинтересованным сторонам о бедствии, которое вскоре постигнет проект из-за этих незапланированных изменений).

Все это совсем не смешно, особенно, для руководителя проекта. Почему проекты попадают в такую историю?

Проекты Waterfall вверяют плану, когда нет информации

В проектах Waterfall строится большой план в начале проекта, когда:

мало или нет информации о работах;
мало или нет информации о продукте, как он выглядит и работает;
мало или нет информации о внешних проблемах и рисках (зависимости, конкуренты, партнеры и т.д.).

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

Это напоминает еще старую армейскую цитату:

«Ни один план не выдерживает контакта с врагом»

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

Agile-проекты планируются многократно небольшими порциями

Agile-проекты (использующие Scrum) не создают в начале один большой план. Они выполняют множество небольших мероприятий по планированию (каждый спринт), которые производят множество небольших планов (планы длиной в один спринт).

Таким образом, в начале двухнедельного (обычно) спринта вы разрабатываете план на следующие две недели: это называется «планированием спринта». На этом совещании команда перемещает задачи из бэклога продукта в бэклог спринта и обсуждает, сколько задач они могут выполнить и как они будут это делать.

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

хорошо известен и понятен (иначе он не будет кандидатом на выполнение в этом спринте);
может быть завершен в одном спринте (который обычно длится две недели).

Таким образом, вы придумываете небольшой план для небольшого объема работы, затем вы делаете эту работу. Затем вы делаете следующий план для следующей части работы, и так далее, снова, и снова, и снова.

И это называется «нет планирования»? Как же! Вы, скорее, устанете от планирования, когда будете делать это таким образом.

Действительно ли такой маленький план так ценен?

Вы можете подумать: «Но это совершенно бестолковый план, всего на две недели. План в Waterfall был большим и красивым и включал гигантские диаграммы Ганта, показывающие, что все будут делать в течение следующих шести месяцев!». Конечно, но помните:

План Waterfall был таким большим, так как он создавался в самом начале проекта. В то время, когда никто на самом деле не имел никакой информации о проекте (поскольку мы обнаруживаем информацию по мере продвижения);
План Waterfall был создан почти полностью одним человеком – руководителем проекта. Человеком, который практически не выполняет никакой работы по созданию продукта. Но этот человек составил план вместо команды, которая будет выполнять всю работу по созданию продукта.
Вся ценность заключается в процессе планирования, а не в плане, помните цитату выше?

В чем ценность процесса планирования?

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

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

Внимание, вопрос! Как вы теперь считаете: в Agile нет планирования или его слишком много?

Автор: Leon Tranter
Источник
Business photo created by freepik — www.freepik.com

Мифы об Agile. Миф №2: в Agile нет документации

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок