Доброго времени суток!

Хочу рассказать про интересный результат мозгового штурма, который мы провели на прошлой неделе.

Интересность момента заключается в том, что мы переосмыслили возможности Gantt диаграммы для работы с Agile проектами. До штурма, я и мои коллеги думали об этой диаграмме как об одном из многих способов отображения плана проекта и его прогресса. В таком приближении мы имеем список задач, список разработчиков, календарь и массив отчетов от команды о прогрессе, которые можем показывать в разных представлениях — Gantt, PERT и Backlog.

Оказалось, что мы заблуждались. Кроме «локального» негативного результата мы получили довольно важные обобщения на уровне идеологии и философии управления Agile проектами.


Предыстория

Мы разрабатываем онлайн инструмент для работы с планами проектов в разных режимах отображения. Мы начали с детерминантных процессов и реализовали диаграммы Gantt и PERT с критическим путем. Сейчас подключаем эмпирические процессы, такие как Скрам. Общая идеология, которую мы предлагаем пользователям сервиса — интеграция обоих типов процессов.

Итак, у нас есть общий детерминантный план проекта, смоделированный при помощи Gantt диаграммы. Теперь мы начинаем Скрам итерацию. Нам нужно вырезать диапазон задач из этого Gantt-а, который включен в итерацию и иметь возможность переключать представление между диаграммами Gantt и Backlog. Первая модель, которую мы начали имплементировать, задумывалась просто: на странице плана итерации есть две соответствующие закладки, переключаясь между которыми, пользователь видит либо Gantt либо Backlog итерации. При этом репортинг по задачам построен так: пользователь периодически (от двух до восьми раз в день) пишет в систему короткие сообщения, или твитты, состоящие из двух полей. Первое поле — классический твитт — короткий текст с описанием статуса имплементации и второе — число, соответствующее времени, оставшемуся до завершения задачи в часах. При переключениях между закладками «Gantt» и «Backlog» эти данные должны попадать либо в «клеточки» Backlog-а:


либо пересчитываться в прогресс задачи на Gantt-е:


Все началось, когда программист (Володя), который реализовывал этот функционал, разослал сообщение, что у него возникли серьезные логические противоречия во время имплементации. Мы собрались возле доски с фламастерами и начали мозговой штурм.

Проблема

Володя описал 2 противоречия с которыми он столкнулся:
1. Если по задаче приостанавливается выполнение, то Gantt демонстрирует постепеный «фантомный» прогресс по задаче. Причем чем длиннее простой, тем больший прогресс показывается;
2. Невозможно показать перемещение ресурсов. Распределение людей по задачам в Скраме очень динамично и это становится проблемой для Gantt.

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

В этой схеме мы вычисляем прогресс задачи на Gantt по такой формуле: progress% = 100 * hours_spent / (hours_spent + hours_left), где progress% — это прогресс в процентах, hours_spent — это количество потраченных часов и hours_left — последняя оценка в оставшихся на имплементацию часах. Эта формула работает до тех пор, пока мы не выходим за плановую длительность задачи. Представим себе спекулятивный пример: по задаче ничего не сделано, на ее реализацию нужно 8 часов, мы забыли про эту задачу и вернулись к ней через месяц. Прогресс будет равен 100 * 20*8 / (20*8 + 8) = 95%! При не начавшейся работе!

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

Перемещение людей между задачами на Gantt также требует радикальной переделки структуры задач и связей. Результат — во время спринта Gantt быстро теряет актуальность.

Не найдя технического решения проблемы, мы перешли на уровень выше — к абстракции.

Абстракция

Уже давно было замечено, и высказано, кажется, Эйнштейном, что «серьезная проблема на может быть решена на том-же уровне, на котором она возникла». Мы на время выкинули детали и начали искать принципиальные отличия между Gantt-ом и Backlog-ом. И нашли…

Было сформулировано несколько слоганов (лаконичных и емких идей), которые определили дальнейший ход штурма:
— Gantt — статическая диаграмма, а Backlog — динамическая.
— Backlog проецируется в последовательность Gantt диаграмм — никак не на одну диаграмму.
— Каждому дню в Backlog соответствует отдельная Gantt диаграмма.

Немного деталей добавилось после сопоставления степеней свободы у этих двух диаграмм…

Степени свободы Backlog:
— длительность задач
— исполнители задач
— количество задач в итерации

Cтепени свободы Gantt:
— прогресс выполнения задачи

Наконец, нам удалось сформулировать решение проблемы, которое «зацепило» не только страницу плана, но и идеологию всего приложения…

Решение

Gantt не применим для плана Agile (или эмпирической) итерации. Это — зона действия Backlog-а или подобных ему динамических диаграмм. Граница детерминантного и эмпирического процесса пролегает между уровнем общего плана проекта и его фаз с одной стороны, и уровнем итерации — с другой.

В нашем приложении (пока) нету описанных уровней, мы работаем с отдельными планами как с документами. Когда мы создаем новый план, мы спрашиваем пользователя с каким процессом он идет — с детеминантным или эмпирическим. Сделав этот выбор, пользователь однозначно определяет подход к визуализации проекта. На странице плана в детерминантном подходе пользователь видит закладки Gantt и PERT, в эмпирическом — Backlog и Burndown.

Светлых Вам мыслей!