Пятница. Демо через пару часов. В колонке «В работе» еще висят важные задачи, а заказчик уже ждет обещанную функциональность. Знакомая ситуация? В статье рассказываем, как тимлиду следить за прогрессом спринта с помощью Burndown Chart и CFD, не допуская серьезных отставаний в проекте.
Типовые проблемы с контролем потока задач
Сначала разберем, где чаще всего «болит» у руководителя команды в процессе ИТ-разработки.
Неясно, что происходит. Между стартом в понедельник и финишем в пятницу словно черная дыра. Видно, что задачи взяты в работу, но трудно понять реальную скорость их выполнения. Ежедневные стендапы не всегда спасают. Например, проблема кажется разработчику незначительной, или ему не хочется признаться, что буксует почти на финише.
Копится незавершенная работа (Work In Progress, WIP). Команда старается, все заняты, но задачи
Трудно прогнозировать результат. Один спринт успешный, а на следующем происходит срыв сроков. Такая ситуация подрывает доверие стейкхолдеров: владельца продукта, менеджера продукта, технического директора и других заинтересованных лиц. Руководство перестает верить оценкам команды. Это приводит к микроменеджменту и падению мотивации.
Тимлид сможет решить все эти проблемы, если не работать вслепую. Naumen Project Ruler предлагает настроить специальные дашборды, основанные на Agile- и
С помощью этих инструментов получится получить точную картину текущего спринта. Например, руководитель разработки увидит не просто статусы задач, а состояние дел всей команды. Это помогает вовремя заметить настоящие проблемы.
Теперь рассмотрим подробнее, на каких данных строятся диаграммы и как используются вместе.
Burndown Chart: отслеживаем скорость спринта
Burndown Chart — это линейный график, который показывает, сколько работы осталось сделать. По нему легко понять, успеет ли команда при текущей скорости закончить все вовремя.
Устроено это так. По вертикальной оси отображается объем оставшейся работы: обычно в story points или человеко-часах. На горизонтальной оси отмечается время: дни спринта при работе по Scrum, недели и месяцы при использовании других методологий.
Burndown Chart — это пульс спринта. График показывает, как быстро команда «сжигает» задачи
Внизу дашборда располагается желтая столбчатая диаграмма, показывающая объем завершенных задач. Линия с затратами, которую можно назвать идеальной, — зеленая. Линия фактических трудозатрат — синяя.
В идеальной ситуации (диаграмма слева) синяя линия уходит плавно вниз. Команда день за днем закрывает задачи, фактические трудозатраты соответствуют плановым. Эта линия называется «идеальным сгоранием».
Но реальный рабочий процесс (диаграмма справа) далеко не всегда проходит так гладко. График показывает реальное положение дел. Сначала синяя линия идет выше зеленой. Значит, фактические результаты меньше плановых, и команда отстает. В конце синяя линия идет резко вниз. Очевидно, что работу завершили в последний день.
На какие сигналы укажет Burndown Chart:
- в определенном спринте или даже систематически план и факт расходятся. Скорее всего первопричина этого — чересчур оптимистичная оценка задач либо изначально низкое качество организации работ;
- переработки (Crunch) — когда в последние дни все делают много, быстро и по принципу лишь бы закрыть задачу;
- «расползание» границ спринта (Scope creep) — это когда в спринт накидывают задач уже после начала, в нем возникают блокеры или отсутствует прогресс по
каким-то причинам.
Разберем, как это работает на практике.
Допустим, тимлид в середине недели анализирует Burndown Chart и видит тревожный сигнал. Допустим, линия фактического сгорания задач движется не вниз, а вверх. Значит, объем сделанной работы меньше, чем должен быть к этому времени по плану. Тимлид приходит к команде и задает вопрос: «Вот график, он показывает, что у нас выросли фактические трудозатраты. Что произошло?».
В ходе обсуждения команда выявляет две проблемы:
- Разработчики столкнулись со сложностями в архитектуре, которые потребовали пересмотра плана и добавления новых подзадач.
- Тестировщик обнаружил в ранее завершенной функциональности критичный баг, который влияет на текущий спринт. Ошибки необходимо исправить, но эта работа не учтена в изначальном плане.
Благодаря визуальному представлению информации в Burndown Chart удается не просто констатировать факт отставания, а инициировать конструктивный разговор. В итоге команда признает проблему, оценивает оставшиеся ресурсы и вместе с владельцем продукта перераспределяет их. Самое главное — проблему отставания нашли и решили в середине работы, а не в последний день.
Стоит отметить, что в Naumen Project Ruler данные Burndown Chart автоматически синхронизируются с другими Agile-инструментами. Например, Scrum-доской и дашбордами команды. Так, диаграмма сгорания позволяет отслеживать не только отклонения фактической линии списания трудозатрат от плановой, но и количество закрытых задач в каждый из дней.
Burndown Chart показывает скорость выполнения задач, но не выявляет причину отставания. Чтобы понять, где именно произошел «затор», нужен взгляд с другой стороны.
CFD: находим проблемные точки в спринте
Cumulative Flow Diagram (CFD), или накопительная диаграмма потока — это инструмент, который подробно показывает процесс выполнения работы. С его помощью оценивается распределение задач по статусам на протяжении всего спринта.
CFD состоит из нескольких цветных областей, соединенных друг с другом. Значения настраиваются пользователем. Например, такие: серый — «Бэклог», желтый — «В работе», красный — «На паузе», фиолетовый — «Тестирование», зеленый — «Готово». Чем шире цветной слой, тем больше задач сейчас находятся в этом статусе.
CFD помогает команде разобраться в причинах отставаний
В идеальной картине (диаграмма слева) все слои растут равномерно, поток ровный. Одна задача встала на паузу, но в итоге решена. Значит, к концу спринта работа будет выполнена.
В реальности (диаграмма справа) некоторые слои начинают расширяться. Например, желтый «В работе» и красный «На паузе». А линия, показывающая объем бэклога, неравномерная. Это означает, что в процессе добавлялись новые задачи.
Используя готовую диаграмму CFD в Naumen Project Ruler, тимлид может настраивать цветовую кодировку. Названия статусов задач также кастомизированы в системе. На дашборд они автоматически подгружаются из канбан-доски. Эти возможности созданы, чтобы персонализировать рабочее пространство, адаптировать под особенности конкретной команды.
Рассмотрим, какие проблемы помогает выявить и решить CFD.
Препятствия, так называемые «узкие горлышки». Если какая-либо из областей на диаграмме начинает значительно расширяться, это сигнализирует о серьезных трудностях на данном этапе. Задачи накапливаются, поток замедляется. Для тимлида и команды это значит, что нужно выяснить, что именно вызывает проблемы с производительностью и задержки.
Превышение WIP. Диаграмма наглядно демонстрирует, не слишком ли много задач одновременно имеют статус «В работе». Если да, то это сигнал. Например, необходимо соблюдать баланс в нагрузке разработчиков, корректировать WIP-лимиты, менять порядок приоритетов в задачах, избавляться от частых переключений между контекстом задач, что снижает эффективность.
Затягивание сроков и трудности с планированием. Руководителю важно понять, сколько часов обычно уходит на написание кода, тестирование, исправление багов. А также установить, сколько задач реально сделать за отведенное время, используя текущие ресурсы. Спрогнозировать это удастся, если накопилось достаточно данных за прошлые спринты.
Ширина выбранной цветовой области и шкала дней помогают рассчитать Cycle Time — среднее время, которое задача проводит на каждом этапе, а также Throughput — пропускную способность, сколько в среднем активностей завершается за один спринт. С этими данными тимлид, команда и владелец продукта смогут лучше спланировать следующую итерацию и предоставить стейкхолдерам реалистичную оценку сроков.
Медленная адаптация к изменениям. Когда меняются приоритеты проекта или в привычный процесс внедряются новые практики, необходимо анализировать эффект подобных перемен. Диаграмма потока наглядно отобразит их влияние на скорость и качество работы.
CFD не дает готовых решений, но помогает участникам проекта начать совместное обсуждение. Разберем на примере.
Допустим, команда разработки постоянно не успевает закрывать все запланированные задачи. Диаграмма Burndown Chart показывает почти идеальное сгорание до середины спринта, а затем резкое замедление.
Причины становятся понятны, если обратить внимание на данные CFD. Представим, что область «Тестирование» всегда начинает расти на 3–4 день и остается широкой до самого конца. При этом область «Готово» увеличивается очень медленно.
Проблема на этапе тестирования: задачи копятся, не проходят проверку. И видно, что к пятнице мало работы закончено
Проще всего решить, что тестировщики работают недостаточно быстро. Но тимлид старается избежать напряжения в команде. Поэтому инициирует общекомандное обсуждение: «Почему задачи накапливаются именно на этапе тестирования». В ходе дискуссии удается обнаружить системные проблемы:
- Позднее вовлечение QA-специалистов, потому что разработчики заливают код в ветку для тестирования крупными блоками в середине спринта.
- Отсутствие четких критериев готовности к тестированию: нехватка документации, множество задач с мелкими багами.
Благодаря CFD удается найти проблему не в людях, а в процессе, а также совместно выбрать оптимальный вариант решения. Например, чтобы равномерно передавать задачи на тестирование, внедрить дополнительные WIP-лимиты: не более двух задач назначать на разработчика одновременно. Критерии готовности к тестированию начать уточнять у тестировщиков на этапе планирования задачи. В команде ввести четкие правила Definition of Ready (достаточная детализация задачи, чтобы брать ее в работу) и Definition of Done (список требований для перевода в статус «Готово»). Это поможет завершать работу вовремя и обеспечивать качественный результат.
Таким образом, два дашборда дополняют друг друга. Диаграмма сгорания показывает, когда появляется риск не успеть, а диаграмма потока объясняет, почему это происходит.
Используя Burndown Chart и CFD вместе, тимлид получает объемную картину
Как использовать Burndown Chart и CFD в проектах
Данные о рабочей активности принесут пользу, только если применять их правильно. Разберем ключевые принципы.
Диалог, а не контроль. Тимлиду лучше всего анализировать прогресс вместе с командой и дополнять цифры живым общением. Это снижает тревожность, повышает вовлеченность и доверие. Идеальный вариант — показать диаграмму, объяснить ее цель и позволить специалистам самим предлагать улучшения. Метрики помогают задать правильные вопросы, но ответы напрямую связаны с человеческим фактором и особенностями рабочих процессов.
Наблюдение на тенденциями. Небольшое отклонение от графика или неудачный спринт всегда возможны. Но если на диаграмме сгорания фактические линии постоянно идут выше идеальных, тогда это системная проблема. Анализ долгосрочных тенденций позволяет вносить необходимые улучшения в то, как происходит планирование и выполнение работы.
Часть командных ритуалов. При обсуждении стоит потратить несколько минут, чтобы проанализировать Burndown Chart. К примеру, тимлид сообщает: «Вчерашний результат выше идеальной линии, поэтому сегодня стараемся выйти на нужную траекторию. Какие риски нам мешают?». В свою очередь на ретроспективе CFD становится основой для диалога. Например: «Что мы можем сделать на следующем спринте, чтобы ускорить прохождение тестирования?». Это делает ретроспективу более предметной и полезной.
Учет внеплановых задач. Если специалисты заняты срочным исправлением багов, соответствующие задачи необходимо добавлять на канбан-доску. Иначе на диаграмме потока будет отражена ложная информация — остановка работы.
При анализе диаграммы может показаться, что прогресс замедлился. На самом деле — здесь не учтены срочные задачи
Чтобы успешно встроить Burndown Chart и CFD в ежедневную рутину, команде необходимо научиться не только анализировать свою работу через графики и диаграммы, а еще делать обоснованные выводы и корректировать процессы.
Главное
Во время спринта критично понимать, какова реальная скорость работы и в чем причины задержек, если они есть. Решить эту проблему тимлиду помогают диаграммы Burndown Chart и CFD, которые реализованы в системе Naumen Project Ruler в виде настраиваемых дашбордов. Используя эти инструменты, руководитель получает данные для точной аналитики и диалога с участниками проекта: как быстро мы движемся, какие есть помехи и риски, что нам нужно предпринять, чтобы достичь результата.
Работаете в проектах по Agile-методологии? Попробуйте диаграммы Naumen Project Ruler для удобного управления спринтами. Оставьте заявку, и мы покажем, как это работает.
