Хотите узнать, насколько быстро может работать scrum-команда? Показатель скорости — это спидометр для agile-проекта, дающий непревзойденное представление о работоспособности команды. В этом руководстве вы узнаете секреты скорости в Scrum, научитесь вычислять ее и использовать этот эффективный показатель для прогнозирования результатов команды.
Что такое скорость в Scrum?
В Scrum и других методологиях управления agile-проектами скорость является показателем Agile, служащим для оценки объема работы, которую команда Scrum может выполнить за определенный период — обычно за один спринт.
Скорость можно выразить в баллах оценки сложности — единице измерения размера пользовательских историй или заданий с точки зрения сложности, риска и неопределенности. Это позволяет оценить работу детальнее, чем показатели на основе времени, например часы или дни.
Возьмем, к примеру, пользовательскую историю для разработки экрана входа в приложение. Исходя из предполагаемой сложности задания и усилий, требуемых для его выполнения, команда может назначить оценку сложности, равную трем баллам. Интеграция сложного платежного шлюза может получить восемь баллов из-за более высокой сложности и потенциальных рисков.
На количество баллов оценки сложности, которые каждый участник команды может выполнить за двухнедельный спринт, влияет множество факторов, таких как опыт участников, сложность заданий и динамика работы команды. Новые scrum-команды обычно набирают 5–10 баллов оценки сложности на человека на каждый двухнедельный спринт.
Зная свою скорость работы, команда может прогнозировать будущие спринты, а также планировать и ставить реалистичные цели, что способствует непрерывному совершенствованию. Благодаря этому показателю команды могут выстраивать стабильный рабочий ритм, прогнозировать сроки реализации проектов и управлять ожиданиями заинтересованных сторон.
Как рассчитать скорость в Scrum
Обычно скорость вычисляется в конце каждого спринта путем суммирования оценок сложности или других единиц измерения для всех полностью выполненных пользовательских историй.
Вот пошаговый процесс вычисления скорости в Scrum.
1. Запланируйте спринт
Перед началом спринта пропишите и назначьте баллы всем пользовательским историям из бэклога продукта. Например:
- назначить аутентификацию пользователей — 5 баллов;
- добавить интеграцию платежного шлюза — 8 баллов;
- внедрить функциональность поиска — 3 балла;
- разработать страницу профиля пользователя — 13 баллов;
- внедрить уведомления по электронной почте — 2 балла;
- оптимизировать запросы к базе данных — 21 балл;
- создать дашбоард администратора — 5 баллов.
Количество пользовательских историй, которые команда может взять в работу на предстоящий спринт, следует рассчитывать исходя из средней скорости предыдущих спринтов и других факторов, таких как праздники и внешние зависимости. Например, если при отсутствии праздников и внешних зависимостей средняя скорость составляет 15 баллов, то команда может взять на следующий спринт пользовательские истории на общую сумму около 15 баллов.
2. Перечислите все завершенные пользовательские истории
В конце каждого спринта создавайте список всех полностью завершенных пользовательских историй. Это должны быть истории, соответствующие критериям приемлемости и подтвержденные scrum-мастером и владельцем продукта.
Если пользовательская история готова на 90 %, она не относится к завершенным работам. Команде следует перенести ее на следующий спринт и переоценить баллы на основе оставшихся заданий.
3. Контрольные точки
Команда уже должна была присвоить оценки сложности каждой завершенной пользовательской истории. Если по какой-либо причине их необходимо пересмотреть, самое время это сделать.
Допустим, в текущем спринте команда выполнила три пользовательские истории: назначила аутентификацию пользователей, добавила интеграцию платежного шлюза и внедрила функциональность поиска. Вы можете присвоить этим заданиям следующие оценки сложности:
- назначить аутентификацию пользователей — 5 баллов;
- добавить интеграцию платежного шлюза — 8 баллов;
- внедрить функциональность поиска — 3 балла.
4. Суммируйте баллы для определения скорости
Далее вам нужно суммировать оценки сложности всех завершенных пользовательских историй. Сумма оценок сложности демонстрирует скорость спринта.
В приведенном выше сценарии общая сумма составит 5 баллов + 8 баллов + 3 балла = 16 баллов. Таким образом, скорость этого спринта составит 16 баллов.
5. Средняя скорость
Вы можете получить более надежный показатель для будущих спринтов, рассчитав среднюю скорость по количеству спринтов, выполняемых командой. Этот показатель особенно полезен для только что созданных команд или команд, размер или структура которых изменились.
Например, если скорости последних трех спринтов равны 14, 16 и 15, то средняя скорость будет равна (14 + 16 + 15) / 3 = 15 баллам.
Факторы, которые могут повлиять на скорость Scrum
На скорость и показатели Scrum могут влиять различные факторы. Их понимание может помочь при планировании и непрерывном улучшении производительности команды.
Размер команды и уровень квалификации
Количество участников команды и их уровень квалификации могут повлиять на объем работы, которую команда способна выполнить во время спринта. Более крупная команда может выполнить в течение спринта больше баллов оценки сложности. Однако увеличение количества людей может привести к проблемам с коммуникацией и согласованием действий.
И наоборот, небольшая высококвалифицированная команда может настолько эффективно выполнять сложные задания, что превзойдет большую, но менее квалифицированную команду.
Стабильность и опыт команды
Когда участники scrum-команды работают вместе на протяжении нескольких спринтов, в них обычно сглаживаются многие недостатки, мешающие новым командам. Они имеют отработанные схемы коммуникации и знают сильные стороны участников.
Эти команды имеют общий опыт, на который могут опираться при возникновении проблем. То, что участники хорошо друг друга знают, может значительно повысить скорость.
Сложность пользовательских историй
Спринт, состоящий из сложных историй, обычно имеет низкую скорость. Показатель скорости будет вводить в заблуждение, если сложность неточно отражает заданную оценку сложности.
Чтобы поддерживать постоянную скорость, некоторые команды стремятся сбалансировать спринт простыми и более сложными заданиями.
Внешние зависимости и ограничения
Если для обновления баз данных или интеграции API ваша команда полагается на помощь другой команды, а та команда опаздывает, это может напрямую снизить скорость работы вашей команды. Знание этих зависимостей и их планирование посредством эффективной коммуникации между командами может снизить негативное влияние на скорость.
Кроме того, при планировании спринта учитывайте государственные праздники или обязательные корпоративные мероприятия, поскольку они сокращают доступное рабочее время.
Использование скорости в Scrum
Когда вы узнаете скорость своей команды, этот показатель станет эффективным инструментом для ряда аспектов планирования спринта и управления проектами, в том числе следующих.
Оценка будущих спринтов
Зная среднюю скорость команды, вы избавитесь от неопределенности. Если средняя скорость вашей команды за последние три спринта составила 50 баллов, у вас есть подтвержденная данными основа для планирования следующего спринта. Если оценка сложности вашего следующего бэклога спринта составляет около 50 баллов, значит, вы берете на себя разумный объем обязательств.
Прогнозирование сроков выполнения проекта
Заинтересованные стороны больше полагаются на оценки на основе данных, чем на догадки или выдачу желаемого за действительное. Например, если оценка сложности бэклога проекта составляет 200 баллов, а средняя скорость команды — 50 баллов за спринт, можно с уверенностью предположить, что для завершения проекта команде, скорее всего, потребуется около четырех спринтов.
Выявление чрезмерно большого или маленького объема взятых обязательств
Скорость команды, внезапно упавшая до 30 баллов или резко возросшая до 70, — это тревожный сигнал. Постоянное уменьшение скорости может означать, что команда чрезмерно перегружена, а увеличение — что участникам команды назначен недостаточный объем работы. Эти знания позволяют вносить коррективы в режиме реального времени, например перераспределять задания или пересматривать цели спринта.
Отслеживание улучшений и итеративный прогресс
Отслеживая скорость с течением времени, вы можете понять, повышается ли эффективность команды или текущие проблемы требуют внимания. Если за несколько спринтов скорость возрастает с 40 до 60, это признак того, что усовершенствование процесса приносит результаты.
Отслеживание скорости в Jira
В Jira есть диаграмма скорости, а также множество других agile-отчетов, чтобы ваша команда разработчиков ПО могла без труда отслеживать скорость, прогнозировать будущую производительность и планировать спринты. Это универсальный инструмент для визуализации объема работы, который может выполнить ваша команда, позволяющий ставить цели для будущего спринта более точно.
Кроме того, в Jira доступны показатели Agile, контекстная аналитика, отчетность и функции управления проектами, необходимые команде для выхода на новый уровень планирования и производительности.
Скорость в Scrum: часто задаваемые вопросы
Скорость в Scrum — то же самое, что и производительность?
Нет, скорость в Scrum — не то же самое, что производительность. Скорость — это, в первую очередь, показатель для планирования и оценки объема работы, которую команда может выполнить в будущих спринтах.
Производительность обычно является более широким показателем, который может включать такие факторы, как качество работы, эффективность процессов и ценность для бизнеса.
Как повысить скорость работы команды?
Ускорению работы команды способствуют регулярные ретроспективы, на которых обсуждаются успехи и неудачи, а также планируются улучшения на следующий спринт. Кроме того, хорошей и стабильной скорости может способствовать сведение к минимуму переключений контекста, то есть менее частые переключения между разными задачами или проектами.
Чем ограничено использование скорости в Scrum?
Хотя скорость и является полезным инструментом планирования, она имеет свои ограничения и не должна считаться единственным показателем производительности при оценке работы команды. Чтобы получить комплексное представление о производительности команды, следует учитывать ряд других показателей Agile.
Одно из важных ограничений заключается в том, что скорость не отражает качество работы или коммерческую ценность итогового продукта. Это количественный показатель, не учитывающий качественные стороны сложности каждой конкретной пользовательской истории.
Скорость характеризует отдельную команду и не служит критерием для сравнения производительности разных команд. Группы в команде могут работать неодинаково, поэтому скорость может варьироваться. Если одна команда в целом работает медленнее других, это еще не значит, что она менее успешна.