Руководство по скраму | 34. Скорость в Scrum — скорость команды разработчиков

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

Скорость в Scrum помогает вам определить скорость, с которой команда Scrum выполняет задачи. Мы можем определить его как среднее количество Story Points, выполненных за один спринт. Velocity также может оценить продолжительность проекта на основе уже выполненных работ. Однако это имеет смысл только для зрелой команды, которая работает в равномерном и стабильном темпе. Взгляните на то, что такое Velocity и как заставить его работать лучше всего на вас!

Скорость в Scrum — содержание:

  1. Скорость в Scrum — Введение
  2. Фактическая и плановая скорость
  3. Трудности и риски, связанные с Velocity в Scrum
  4. Резюме

Скорость в Scrum — Введение

Скорость — это необязательный, но популярный метод измерения темпа работы Скрам-команды. Это связано с тем, что точно оцененная скорость позволяет в разумной степени предсказать время, необходимое для завершения проекта. Тем не менее, это мера, которая может быть применена только к данной Команде Разработки, которая будет выполнять задачи, которые она «оценила», используя знакомую единицу измерения, такую ​​как, например, Story Points.

Скорость команды разработчиков чаще всего представляется в виде диаграммы скорости. На оси X отмечены последовательные спринты. С другой стороны, по оси Y мы найдем количество Story Points или других соответствующих единиц, которые были завершены в данном спринте. С помощью диаграммы скорости Скрам-команда получает четкое представление об изменениях темпа своей работы. Если линия, отмеченная на графике, идет вверх, это означает, что Команда оптимизирует свою эффективность или снижает стоимость Story Points. Поэтому и Скрам-мастер, и Владелец продукта должны внимательно следить за линией, показывающей скорость команды.

velocity in scrum - speed of the development team

Фактическая и плановая скорость

Фактическая Скорость Команды Разработки описывает темп работы в завершенном Спринте и рассчитывается в конце каждого Спринта. Он принимает значение суммы Story Points за все завершенные User Stories. Фактическая Скорость Команды Разработки позволяет планировать и оценивать с некоторой долей вероятности темп будущих задач.

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

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

Трудности и риски, связанные с Velocity в Scrum

Скорости в Scrum часто придается слишком большое значение без учета следующих факторов:

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

Резюме

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

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

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

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

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

Scrum Guide | 34. Velocity in Scrum - Speed of the Development Team 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. Развитие бэклога продукта