Скорость спринта служит спидометром 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 баллов.
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 для получения более полного представления об эффективности работы команды.
Одно из важных ограничений заключается в том, что скорость не отражает качество работы или коммерческую ценность итогового продукта. Это количественный показатель, не учитывающий качественные стороны сложности каждой конкретной пользовательской истории.
Скорость характеризует отдельную команду и не служит критерием для сравнения производительности разных команд. Группы в команде могут работать неодинаково, поэтому скорость может варьироваться. Если одна команда в целом работает медленнее других, это еще не значит, что она менее успешна.