Автор: Алексей Кривицкий.
Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS.
Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта?
Давайте разберёмся.
Пару слов о терминологии.
В данной статье "традиционными подходами" к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё множество других, которые тяжело классифицировать.
При помощи диаграмм Ганта при традиционных подходах к планированию и управлению проектами выполняются начальное препланирование, определяя работы, которые необходимо выполнить, зависимости между ними, распределяя проектные ресурсы. Это препланирование обычно выполняется руководителями проектов, и иногда ещё до того, как набрана команда. Знания, которые генерируются в ходе таких активностей несомненно полезны для любых проектов. В том числе и Agile. Так почему же диаграммы Ганта не рекомендуют использовать при Agile планировании?
Давайте рассмотрим, как выполняется планирование в идеальном Agile проекте:
Что можно посоветовать:
"Планы бесполезны, планирование необходимо".
Ейзенхауэр
Ейзенхауэр
Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS.Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта?
Давайте разберёмся.
Пару слов о терминологии.
В данной статье "традиционными подходами" к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё множество других, которые тяжело классифицировать.
При помощи диаграмм Ганта при традиционных подходах к планированию и управлению проектами выполняются начальное препланирование, определяя работы, которые необходимо выполнить, зависимости между ними, распределяя проектные ресурсы. Это препланирование обычно выполняется руководителями проектов, и иногда ещё до того, как набрана команда. Знания, которые генерируются в ходе таких активностей несомненно полезны для любых проектов. В том числе и Agile. Так почему же диаграммы Ганта не рекомендуют использовать при Agile планировании?
Давайте рассмотрим, как выполняется планирование в идеальном Agile проекте:
- Для того чтобы получить наиболее полную картину, вся команда вовлечена в процесс планирования.
Выполняя коллективное планирование команда обсуждает цели, тактику их достижения, что несомненно является полезным групповым упражнением, объединяющим команду вокруг общих целей и взаимных обязательств.
Ответственность за адекватность планов лежит на плечах всей команды, а не одного человека. - Планирование Agile проекта выполняется в течение всего жизненного цикла проекта.
Планы уточняются по мере того, как команда и заказчики узнают больше о разрабатываемом продукте, технологиях, возможностях команды. Это непрерывный процесс, "agile planning" - это действие, не артефакт.
Такой подход постепенной детализации планов позволяет экономить время на планирование, за счёт того, что более далёкие аспекты проекта, которые с большей долей вероятности подвержены изменениям, не прорабатываются с такой же степенью детализации, как те аспекты, которые будут пущены в работу в ближайшее время. Зачем тратить время на то, что ещё не факт войдёт ли в проект? - Механизмы управления требованиями в Agile проетках (к примеру product backlog, user stories) позволяют уменьшить зависимости между единицами требований, таким образом Agile проекты не нуждаются в таком детальном отслеживании зависимостей в требованиях, как единицы требований, используемые в традиционных проектах.
При помощи отслеживания зависимостей и задержек выполнения плана WBS
традиционного проекта помогает предсказать дату завершения фазы проекта. В Agile проектах для предсказания дат и объёма работы, используется метрика Velocity, для использования которой нет необходимости в отслеживании зависимостей между требованиями и работами.
Зависимости же между задачами в Agile проектах осуществляются командой благодаря ежедневной синхронизации на т.н. standup митингах.
Что можно посоветовать:
- Я думаю, что рисовать WBS стоит всей командой, а не отдельному человеку - менеджеру. В этом случае WBS становится достоянием команды и его можно использовать в виде настенного постера - WallGantt. Смотрите ссылки ниже.
- Стоит обновляйте WallGantt как только вы узнаете нечто, что влияет на планы. Скорее всего не реже, чем раз в итерацию. Это позволит содержать Гант up-to-date и избежать ложности планов, к которой многие из нас так привыкли при традиционном планировании.
- Если рисовать WBS не по задачам, а по требованиям (элементам product backlog), то это позволит избежать микроменеджмент команды, но всё-таки позволит сгенерировать информацию, полезную для команды. В противном же случае вы рискуете заменить ежедневное живое планирование артефактом. Это точно не то, чего мы добиваемся в Agile проектах.