Руководство по скраму | 31. Как создать и интерпретировать диаграмму выгорания?

Опубликовано: 2022-06-21

Диаграмму выгорания относительно легко создать. Существует множество инструментов для его создания на основе работы, зарегистрированной членами команды разработчиков. Несмотря на простоту, его интерпретация может предоставить ценную информацию для всей Скрам-команды. Прочтите эту статью, чтобы узнать, как создать и интерпретировать диаграмму выгорания.

Как создать и интерпретировать диаграмму выгорания? - оглавление:

  1. Как создать диаграмму выгорания?
  2. Кто отвечает за диаграмму выгорания?
  3. Как интерпретировать диаграмму выгорания?
  4. Реальная и идеальная диаграмма выгорания
  5. Выбор единицы измерения
  6. Резюме

Как создать диаграмму выгорания?

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

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

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

С помощью правильных инструментов также можно свободно масштабировать диаграмму. Это дает представление о сгорании не только на уровне отдельного спринта, но и в масштабе квартала или всего проекта.

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

Кто отвечает за диаграмму выгорания?

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

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

Однако на практике задача обновления диаграммы выгорания обычно ложится на плечи Скрам-мастера. Это происходит особенно в начале его работы с новой Командой Разработки, когда Скорость Команды все еще изменчива и ее трудно оценить. Тем не менее, рекомендуется делегировать эту задачу одному из Разработчиков. В конце концов, диаграмма предназначена для честного и внутреннего измерения хода работы по оценке самих разработчиков.

chart

Как интерпретировать диаграмму выгорания?

Подробно внешний вид графика Burndown мы описали в предыдущей статье. Здесь лишь напомним, что по оси X показано время, оставшееся до завершения работы. С другой стороны, ось Y показывает объем оставшейся работы.

Реальная и идеальная диаграмма выгорания

Для интерпретации диаграммы сгорания ключевым фактором является не только регулярное построение реального «сгорания», т.е. выполнения задач Командой Разработки. Не менее важным для картины является ее сравнение с идеальным падением линии горения (ориентир).

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

График выработки также позволяет определить значение, называемое скоростью команды разработчиков в долгосрочной перспективе. Ей мы посвятим отдельную статью. Здесь мы просто упомянем, что это значение определяется объемом работы, выполненной в течение одного Спринта.

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

Выбор единицы измерения

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

Вот почему многие Scrum-команды используют измерение, основанное на времени. В зависимости от масштаба это дни или человеко-часы. Каждый разработчик оценивает, а затем регистрирует количество времени, затраченное на выполнение своих задач.

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

Независимо от единицы измерения, стоит помнить принцип расчета скорости Команды Разработки. В данный день или спринт учитываются только задачи, которые были фактически выполнены. Это означает, что начатые задачи будут засчитаны в счет следующего дня или Спринта, даже если отсутствует только финальное тестирование.

Резюме

How to create and interpret a burndown chart?

Благодаря доступным инструментам мониторинга команды создание диаграммы выгорания становится простой задачей. Наиболее важным вопросом является обеспечение его согласованности, ясности и доступности для всех членов Скрам-команды.

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 31. How to create and interpret a burndown chart? caroline becker avatar 1background

Автор: Кэролайн Беккер.

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

Просмотреть все сообщения

Руководство по скраму:

  1. Глоссарий основных терминов, ролей и понятий
  2. Что такое Скрам?
  3. Скрам-ценности
  4. Как внедрить Scrum в вашей компании?
  5. Скрам-команда — что это такое и как она работает?
  6. Кто такой владелец продукта?
  7. Самые распространенные ошибки владельца продукта
  8. Кто такой скрам-мастер?
  9. Характеристики хорошего скрам-мастера
  10. Самые распространенные ошибки скрам-мастера
  11. Какую статистику и показатели должен отслеживать скрам-мастер?
  12. Сотрудничество между владельцем продукта и скрам-мастером
  13. Команда разработчиков в Scrum
  14. Самые распространенные ошибки разработчиков
  15. Скрам артефакты
  16. Масштабирование Скрама
  17. Бэклог спринта
  18. Что такое бэклог продукта?
  19. Что такое пользовательские истории?
  20. Создание лучшей пользовательской истории с INVEST
  21. Самые распространенные ошибки User Story
  22. Критерии приемлемости пользовательской истории
  23. Оценка и баллы в Scrum
  24. Планирование покера
  25. Игра на оценку команды
  26. Определение приращения
  27. Скрам-события
  28. Что такое спринт в Scrum?
  29. Обязательства команды Scrum — цель продукта, цель спринта и определение завершения
  30. Что такое диаграмма выгорания?
  31. Как создать и интерпретировать диаграмму выгорания?
  32. Преимущества и недостатки диаграммы выгорания
  33. Канбан-доски в Scrum и Scrumban
  34. Скорость в Scrum — скорость команды разработчиков
  35. Ежедневный Скрам
  36. Планирование спринта
  37. Обзор спринта
  38. Что такое ретроспектива спринта?
  39. Распространенные ошибки во время ретроспективы спринта
  40. Развитие бэклога продукта