Agile не чуждо планирование

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

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

Я думал, методология Scrum должна быть гибкой, однако, фиксированные спринты намного уменьшают привычную гибкость. Когда появляется что-нибудь новое или срочное, я больше не могу попросить человека из команды помочь мне в этом вопросе.

Тогда меня расстроили эти слова. Но, оглянувшись назад, я понял, что могу извлечь из этого полезный опыт.

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

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

Планирование точно в срок (Just In Time Planning)

Ключом к пониманию планирования (и всего прочего) в проектах гибкой разработки является термин "точно в срок" (just in time). Agile не обходится без планирования, однако планы разрабатываются не предварительно, а именно тогда, когда нужны. Детальный план спринта создают только в начале самого спринта. План на день составляется утром того дня, когда участники команды приступают к первой задаче из списка работ.

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

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

Лидерство во благо

Если весь секрет в планировании точно в срок, что не так в словах того руководителя проекта? Почему бы не вносить изменения в планы, когда возникает что-нибудь новое?

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

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

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

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

Период обдумывания и переговоров

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

Agile не чуждо планирование

Мнение, что в Agile отсутствует элемент планирования, архитектура, проектирование и документация -- ошибочно. На самом деле, методология Agile превращает их в постоянные процессы, а не отдельные стадии проекта.

источник