Руководство по скраму | 11. Статистика и метрики, которые должен отслеживать скрам-мастер

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

Зачем скрам-мастеру статистика и метрики? Во-первых, проверить, эффективны ли его методы работы над предсказуемостью результатов и повышением эффективности команды. Но и следить за тем, как их действия влияют на Команду Разработки. То есть, как они формируют пользовательский опыт сотрудников (UX). Итак, в этой статье мы представляем статистику и показатели, которые должен отслеживать скрам-мастер.

Статистика и метрики, важные для скрам-мастера — оглавление:

  1. Измерение результатов работы Команды Разработки
  2. Мониторинг пользовательского опыта сотрудников Разработчики
  3. Резюме

Измерение результатов работы Команды Разработки

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

Statistics and metrics

Диаграмма выгорания

Диаграмма выгорания показывает скрам-мастеру и команде разработчиков, сколько работы уже сделано и сколько осталось сделать. По оси X показано время, оставшееся до завершения работы. Ось Y показывает объем оставшейся работы, запланированной в Журнале Спринта или Журнале Продукта.

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

Этот простой инструмент позволяет Скрам-мастеру не только видеть , насколько эффективно работает команда. Также помогает ответить на вопросы:

  • Какая часть работы уже выполнена?
  • Сколько заданий осталось выполнить?
  • Сколько времени займет разработка Продукта?

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

Диаграмма выгорания

Диаграмма выгорания — это обратная сторона диаграммы выгорания, описанной выше. Здесь также ось Y показывает объем оставшейся работы. С другой стороны, ось X показывает время завершения, выраженное либо в количестве спринтов, либо в датах.

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

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

Совокупная блок-схема

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

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

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

Statistics and metrics the Scrum Master should track

Мониторинг пользовательского опыта сотрудников Разработчики

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

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

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

Статистика и показатели – сводка

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

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

Scrum Guide | 11. Statistics and metrics the Scrum Master should track 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. Развитие бэклога продукта