БЛИЖАЙШИЕ МЕРОПРИЯТИЯ:
22-23 июня: КИЕВ,
Certified ScrumMaster by ScrumAlliance | Курс c Натальей Трениной (на русском языке)
27 июня: ХАРЬКОВ,
AgilePizza #68
27 июня: КИЕВ,
AgilePizza #69

2008/06/09

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий.

"Планы бесполезны, планирование необходимо".
Ейзенхауэр


Gantt chartДиаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS.

Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта?

Давайте разберёмся.

Пару слов о терминологии.

В данной статье "традиционными подходами" к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё множество других, которые тяжело классифицировать.

При помощи диаграмм Ганта при традиционных подходах к планированию и управлению проектами выполняются начальное препланирование, определяя работы, которые необходимо выполнить, зависимости между ними, распределяя проектные ресурсы. Это препланирование обычно выполняется руководителями проектов, и иногда ещё до того, как набрана команда. Знания, которые генерируются в ходе таких активностей несомненно полезны для любых проектов. В том числе и Agile. Так почему же диаграммы Ганта не рекомендуют использовать при Agile планировании?

Давайте рассмотрим, как выполняется планирование в идеальном Agile проекте:

  1. Для того чтобы получить наиболее полную картину, вся команда вовлечена в процесс планирования.

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

    Ответственность за адекватность планов лежит на плечах всей команды, а не одного человека.
  2. Планирование Agile проекта выполняется в течение всего жизненного цикла проекта.

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

    Такой подход постепенной детализации планов позволяет экономить время на планирование, за счёт того, что более далёкие аспекты проекта, которые с большей долей вероятности подвержены изменениям, не прорабатываются с такой же степенью детализации, как те аспекты, которые будут пущены в работу в ближайшее время. Зачем тратить время на то, что ещё не факт войдёт ли в проект?
  3. Механизмы управления требованиями в Agile проетках (к примеру product backlog, user stories) позволяют уменьшить зависимости между единицами требований, таким образом Agile проекты не нуждаются в таком детальном отслеживании зависимостей в требованиях, как единицы требований, используемые в традиционных проектах.

    При помощи отслеживания зависимостей и задержек выполнения плана WBS
    традиционного проекта помогает предсказать дату завершения фазы проекта. В Agile проектах для предсказания дат и объёма работы, используется метрика Velocity, для использования которой нет необходимости в отслеживании зависимостей между требованиями и работами.

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

Что можно посоветовать:
  1. Я думаю, что рисовать WBS стоит всей командой, а не отдельному человеку - менеджеру. В этом случае WBS становится достоянием команды и его можно использовать в виде настенного постера - WallGantt. Смотрите ссылки ниже.
  2. Стоит обновляйте WallGantt как только вы узнаете нечто, что влияет на планы. Скорее всего не реже, чем раз в итерацию. Это позволит содержать Гант up-to-date и избежать ложности планов, к которой многие из нас так привыкли при традиционном планировании.
  3. Если рисовать WBS не по задачам, а по требованиям (элементам product backlog), то это позволит избежать микроменеджмент команды, но всё-таки позволит сгенерировать информацию, полезную для команды. В противном же случае вы рискуете заменить ежедневное живое планирование артефактом. Это точно не то, чего мы добиваемся в Agile проектах.
Полезные ссылки:

5 comments:

Anonymous said...

Как Вы думаете, сколько итераций должно быть затронуто в диаграмме?

Alexey Krivitsky said...

Я бы рисовал эту диаграмму на релиз - если вы не выпускаетесь каждую итерацию.

В этом случае Gantt Wall будет служить визуальным планом релиза.

Serhiy Yevtushenko said...

Леш, как на меня, диаграммы Ганнта не используються по еще нескольким причинам :
1) Трудоемкость ведения диаграммы (например, в майкрософт проджекте). Введение\перестройка диаграммы требует кучу времени
2) Требование микрооценки задач (в днях или часах). Оценка на уровне дней может приводить к эффекту задержки завершения задачи (У меня стоит естимейт на задачу - два дня (день), и я поэтому использую это все время, отведенное мне на задачу
3) Невозможность быстрого конструирования планов с участием всей команды при использовании средств для ведения Ганнт Диаграмм
4) Необходимость выделения ресурсов для поддержания Ганнт Диаграммы в актуальном состоянии (Попробуй обновлять Ганнт диаграмму каждый день - ощутишь соответсвующие затраты времени).

Anonymous said...

1) Цитата: " В Agile проектах для предсказания дат и объёма работы, используется метрика Velocity, для использования которой нет необходимости в отслеживании зависимостей между требованиями и работами"

Простите, но если мы не произвели достаточно подробную детализацию работ (= не построили WBS), то как эту Velocity применить? Да, мы знаем скорость прохождения предыдущих итераций, но не зная объёма будущих - предсказать дату завершения проекта не можем... Школьый курс физики: t=S/v, при неизвестном "S" хочешь не хочешь, а "t" - тоже загадка :)

2) Цитата: "Если рисовать WBS не по задачам, а по требованиям (элементам product backlog), то это позволит избежать микроменеджмент команды, но всё-таки позволит сгенерировать информацию, полезную для команды"

Нет проблем "рисовать WBS по требованиям". Но ведь надо перейти от WBS непосредственно к плану, а для этого необходимо оценить трудоёмкость работ. Во многих случаях оценить трудоёмкость требований - невозможно. И неизбежно надо продумать, какие задачи следует реализовать для достижения требования, и уже после этого оценить трудоёмкость именно задач.

Alexey Krivitsky said...

Отвечаю на последний коммент:

1 Обычно для долгосрочного планирования достаточно грубых оценок функционала. Зная сколько таких грубых единиц команда выпускает за итерацию (это и есть велосити) можно строить грубые планы. Обычно этой точности хватает для такого вида планирования.

Детальное планирование делается на более короткий срок, и тут в игру вступают задачи.

Делая долгосрочное планирование по задачам, мы

во-певрых тратим много времени,

во-вторых обсуждаем много деталей, которые скорее всего устареют пока мы начнём эти работы,

в-третьих мы не иметь свободу балансировки ресурсов и не хотим привязывать задачи на людей на месяцы вперёд.

2 Трудоёмкость можно оценивать без детализации. Это не сразу понятно, но стоит опробовать на практике оценивание путём сравнения сложности и всё станет на свои места.

Я не буду сейчас объяснять как это работает. Просто там ряд полезных ссылочек:

- книга

- видео (на английском)

- ключевые слова для поиска материалов: story points, planning poker

- если у вас получиться посетить мой тренинг, мы с вами подробно обсудим все эти детали, и, я уверен, вы поймёте, что я имею в виду, и согласитесь с тем, что это работает.

Удач!