Показатели Scrum

Как и что могут измерять scrum-команды для оптимизации командной работы

Erika Sa Автор: Erika Sa
Просмотр тем

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

«Вы не можете улучшить то, чего не можете измерить», — отметил известный теоретик менеджмента Питер Друкер. Хотя это утверждение не распространяется на все стороны жизни, оно применимо к командам, практикующим agile-методики Scrum. Используя определенные показатели, scrum-команды могут корректировать, перенаправлять и улучшать свою работу.

Что такое Scrum?

Scrum — это методика Agile и стиль работы, который помогает командам решать сложные проблемы, итеративно разрабатывая решения в рамках поставленной цели. Характерным приемом Scrum является спринт, то есть фиксированный период времени, в течение которого scrum-команда выполняет заданный объем работы.

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

Что такое показатели Scrum?

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

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

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

Зачем нужны показатели Scrum?

Показатели Scrum помогают командам определять контрольные оценки и направлять свою работу. Они полезны как для опытных, так и для новых команд.

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

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

Можно ли использовать показатели Scrum в качестве KPI?

Да и нет. Показатели Scrum можно использовать для определения ключевых показателей эффективности (KPI) с учетом типа и объема работы. Но сами по себе показатели Scrum не позволяют измерить ценность для клиента или установить, поставила ли команда нужный продукт. Значения KPI в конечном счете должны продемонстрировать, насколько хорошо команда, следующая принципам Agile, поддерживает приоритеты компании.

При измерении эффективности scrum-команды следует учитывать и другие показатели, помимо Scrum, в том числе следующие.

  • Рентабельность инвестиций (ROI) для бизнеса — компании измеряют ее различными способами в зависимости от целей, в том числе учитывая рост доходов, ежемесячное активное использование (MAU) и многое другое.
  • Удовлетворенность клиентов — показатели опросов, такие как индекс потребительской лояльности (NPS) и индекс удовлетворенности клиентов (CSAT), могут быть полезны для отслеживания успешности проекта. Постоянно высокий показатель удовлетворенности клиентов по каждому релизу показывает, что scrum-команда действительно поставляет ценный продукт.
  • Удовлетворенность команды — просто спросив участников о степени их заинтересованности в проекте и взаимодействии с командой, можно выявить такие проблемы, как текучесть кадров, отток специалистов и недовольство разработчиков.

Ключевые мероприятия Scrum и оцениваемые показатели

While agile scrum defines several recurring events — sprint, sprint planning, daily scrum, sprint review, sprint retrospective — these don’t provide any guarantees of progress or success. However, each one allows team members to inspect and adapt how they work.

Инфографика: цикл спринта

Планирование спринтов

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

Цели спринта

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

Скорость команды

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

Ниже приведен пример диаграммы скорости, на котором представлена (1) оценка сложности работы; (2) общий принятый объем, то есть совокупная оценка всех задач в спринте; (3) сложность завершенных задач; (4) названия завершенных спринтов.

Инфографика: диаграмма скорости

Team Capacity

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

Тип работы

When your sprint backlog is a growing mix of feature work, bug fixes, and technical debt, it becomes tricky to see where your team is dedicating their time in the sprint. It’s easy for bugs or tech debts to sneak into your sprint, especially if the development team is passionate about quality. But if a team isn’t careful, it can end up after the sprint wondering why it didn’t ship enough customer values as planned.

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

Стендапы (ежедневные scrum-совещания)

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

При этом могут пригодиться следующие данные и показатели.

Прогресс в достижении целей спринта

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

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

Диаграмма Burndown для спринта

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

Ниже приведена диаграмма Burndown для спринта в Jira, на которой представлена (1) оценка работы; (2) остаточная величина, то есть суммарный объем оставшейся работы в спринте; (3) направляющая, которая служит ориентиром для команды.

Инфографика: диаграмма Burndown для спринта

Распределение рабочей нагрузки

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

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

Поиск аналитики в контексте

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

Подробнее об аналитике.

Выделение на панели бэклога

Ретроспектива спринта

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

Ниже приведен пример ретроспективы моей команды, опубликованной на странице Confluence.

Снимок экрана: ретроспектива спринта

Достижение целей спринта

Как ваша команда справилась с целями, поставленными при планировании спринта? Если команда вычеркнула все пункты из списка, отлично! Если нет, с чем возникли проблемы? Для оценки успеха команды могут пригодиться уже рассмотренные нами scrum-показатели. Любое улучшение рабочего процесса достойно того, чтобы его отпраздновать. Например, команда двигалась быстрее, потому что не набирала лишних работ. Команды, практикующие DevOps, могут также проанализировать ключевые показатели DevOps, такие как время цикла или частота развертывания, чтобы понять, как улучшить процесс поставки и повысить вероятность достижения целей спринта. Такой подход поможет решить проблему и составить более четкий план действий.

Удовлетворенность спринтом

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

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

Заключение

Цель Scrum — помочь командам работать лучше, а с помощью scrum-показателей команда может оценить реальную пользу этой методики. Использование scrum-показателей должно не обременять, а вдохновлять вашу команду. Необязательно следить за всем, что описано в этой статье. Можно начать с одного или двух показателей и посмотреть, помогают ли они повысить эффективность команды. С другой стороны, ваша scrum-команда, возможно, уже придерживается зрелой методики Scrum, так что scrum-показатели не принесут ей особой пользы. Здорово, если так! Просто не забывайте те полезные навыки, которые вы приобрели благодаря показателям. Проверяйте их время от времени, чтобы состояние дел в Scrum оставалось под контролем.

Связанные ресурсы

продолжение темы
Jira, Confluence, Scrum