К основному контенту

Диаграммы Ганта и 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 проектах.
Полезные ссылки:

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: