Вернуться в блог
Продуктивность команды
Вернуться в блог
Продуктивность команды
Кабина самолета оснащена приборами и датчиками, которые дают пилотам информацию, необходимую им для безопасного и эффективного управления самолетом. Авиагоризонт, индикатор воздушной скорости, высотомер, координатор поворота, индикатор курса и индикатор вертикальной скорости предоставляют важные данные. И это только основные летные приборы.
Но хотя некоторые показатели, например высота, важнее других, пилот никогда не полагается только на один показатель при управлении самолетом.
У команд Scrum также есть множество инструментов и метрик, которые помогают им в их работе. Многие фокусируются только на одной метрике: скорости спринта. Однако сосредоточение только на одной метрике, не обращая внимания на другие показатели, может привести команду к падению или выгоранию, подобно пилотам, которые забывают проверить уровень топлива.
В этой статье рассматривается, как скорость спринта может быть полезна для вашей команды, а также почему люди иногда неправильно понимают или даже злоупотребляют этой метрикой.
Скорость спринта (Sprint Velocity) - это количество сторипойнтов, завершенных командой за один спринт. Некоторые команды используют различные единицы измерения, такие как часы или количество завершенных историй, для расчета своей скорости. Но независимо от используемых данных, концепция остается прежней: скорость показывает, сколько работы команда выполнила за один спринт.
Команды рассчитывают скорость в конце каждого спринта. Просто сложите количество сторипойнтов, выполненных во время спринта. Вашей метрикой скорости будет абсолютное количество очков истории, выполненных вашей командой.
Например:
Предположим, что вы оценили историю A в 4 сторипойнта, историю B в 2 сторипойнта, и историю C в 3 сторипойнта, и все три были завершены. Ваша скорость будет равна 9. Но если вы завершили только половину истории A, вы не можете учесть никакие сторипойнты от нее, и ваша скорость для этого спринта будет равна 5. В Scrum требуется, чтобы задачи помещались в один спринт. Исключение незавершенных сторипойнтов из скорости побуждает команды делать задачи более мелкими в будущем.
Скорость измеряется на уровне команды, а не для отдельных участников. Это связано с тем, что оптимизация работы команды превосходит преимущества оптимизации работы отдельных участников. Хоть это и не указано явно в Scrum гайде или Agile манифесте, это предполагаемый принцип для обоих подходов.
Скорость (velocity) может помочь командам более точно планировать свои спринты. Это связано с тем, что это помогает командам понять, сколько очков истории они обычно могут выполнить за один спринт. Это число также может послужить началом разговора, когда вы готовите почву для ваших ретроспектив.
Во время планирования спринта вы можете использовать скорость для расчета того, сколько работы вы можете взять на команду за один спринт. Многие команды находят ценность в расчете средней скорости за последние три спринта. Затем это число может служить ориентиром для количества сторипойнтов, запланированных на предстоящий спринт.
Предположим, что ваша средняя скорость за последние три спринта составляет 9 сторипойнтов. В этом случае сумма сторипойнтов в задачах, которые вы выбираете для предстоящего спринта, не должна превышать это число.
Скорость устанавливает ожидания во время планирования спринта относительно объема работы, который ваша команда может завершить. Но это не жесткий предел. Если команды превышают скорость, это нормально. Например, это может случиться, когда новые команды приобретают все больше опыта работы с кодовой базой или взаимодействия друг с другом.
Многие команды используют скорость спринта в виде нисходящей линии на диаграмме сгорания (Burndown chart). Диаграммы сгорания помогают командам получить более ясное представление о том, как выглядит процесс выкатки задач в течение спринта. Уменьшается ли количество сторипойнтов плавно в течение спринта или часто происходит спешка к концу?
Сравнивая фактические результаты с "идеальной линией сгорания", вы можете определить, находитесь ли вы в заданном темпе или отстаете.
Вы можете использовать скорость во время ретроспектив, чтобы обнаружить потенциальные проблемы или измерить эффективность изменений, которые вы внесли в рабочий процесс. Это отличный способ подготовить почву в начале ретроспективы:
Например, ведущий ретроспективы может сказать:
"В этом спринте мы закрыли задач на 21 сторипойнт. Наша средняя скорость за последние три спринта составляет 25 сторипойнтов. Это означает, что наша скорость немного снизилась в этом спринте по сравнению с предыдущим".
Если ваша скорость сильно колеблется между спринтами, это может указывать на то, что ваши пользовательские истории (user stories) слишком большие. В этом случае вам может потребоваться разделение историй на более мелкие части. Но это также может указывать на какие-либо блокеры в задачах, или другие проблемы в процессе, которые требуют диагностики во время ретроспектив.
Предположим, что количество ошибок в работе вашей команды начало увеличиваться в последнее время. Это может указывать на то, что команда работает слишком быстро, завершая много задач без достаточного тестирования. В этом случае вы можете стремиться к более низкой скорости (да, замедляться!).
Ожидаемым результатом замедления скорости является уменьшение дефектов в последующих спринтах, потому что команда уделяет больше времени на код ревью, пишет больше тестов. Более низкая скорость в этом случае может привести к более здоровому показателю Escaped Defect Rate - еще одной популярной метрике Agile.
В Scrum пользовательские истории (user stories) должны вписываться в один спринт и, в идеале, быть способными к завершению не более чем за один день. Когда этого не происходит, вы можете обнаружить, что у команды хоть и завершают пользовательские истории, но не могут добавить эти сторипойнты в скорость текущего спринта, поскольку не завершили например весь эпик, что вызывает колебания в метрике.
Вы можете улучшить скорость спринта следующим образом:
В начальных спринтах, скорость команды, практически наверняка будет сильно колебаться. Вы все еще калибруете оценки, созвоны занимают больше времени, и разработчики могут быть незнакомы с кодовой базой, поэтому времени на выполнение задач остается меньше, так как команда всё еще разбирается в процессах.
Поэтому крайне важно начинать полагаться и ожидать относительно стабильной скорости выполнения задач только после трех-пяти спринтов. Оптимизация скорости в этот период была бы неэффективной и несущественной. У вас просто не будет надежных данных для осмысленной метрики.
Мартен Дальмейн, руководитель продукта в Rodeo и представитель Serious Scrum, рекомендует заранее информировать всех об этой начальной переменчивости. Управление ожиданиями помогает стейкхолдерам сохранить веру в Scrum. Это также защищает мотивацию вашей команды.
Также важно правильно поставить цель для ваших усилий по оптимизации. Увеличение скорости выполнения задач имеет смысл, если вы сосредоточены на повышении продуктивности. Однако в некоторых случаях более низкое значение может быть предпочтительнее, когда вы стремитесь улучшить качество работы, например, в случае снижения числа ошибок.
Парадокс скорости выполнения задач наглядно иллюстрируется результатами опроса. Респонденты опроса поставили скорость выполнения задач на второе место среди популярных метрик, но в то же время она оказалась наиболее часто упоминаемой как бесполезная метрика. 😯
Скорость выполнения задач может помочь или навредить вашей команде в зависимости от того, как и кем она применяется. Ниже мы ответим на четыре вопроса о скорости выполнения задач в рамках спринта, чтобы прояснить общие недоразумения и злоупотребления.
Иногда владельцы продукта (Product Owners, PO) используют скорость выполнения задач для прогнозирования выполнения спринта, функционала или проекта перед стейкхолдерами. Предположим, что общее количество сторипойнтов для вашего проекта составляет 100, а ваша средняя скорость выполнения задач в рамках спринта составляет 10. Тогда вы можете прогнозировать, что вам потребуется 10 спринтов для завершения проекта.
В этом случае есть две проблемы при использовании скорости выполнения задач:
Обратите внимание на разницу между этим способом использования скорости выполнения задач и тем, о чем мы ранее говорили, о ее использовании командой для определения ограничения во время планирования спринта. Прогнозирование, как в этом примере, служит только внешним стейкхолдерам, в то время как использование скорости выполнения задач в качестве ограничения или предела того, что может быть достигнуто, помогает команде более точно планировать свои спринты.
Скорость выполнения задач является ненадежной метрикой для отслеживания производительности команды. Использование этого числа также противоречит фундаментальным принципам Agile, таким как доставка ценности клиенту и доверие к командам, чтобы они самостоятельно организовывались и выполняли работу.
Скорость выполнения задач плохо подходит в качестве метрики производительности и превращается в "театр измерений" по нескольким причинам:
Основная идея Agile заключается в том, что самое главное - это доставка ценности клиенту в ранние сроки и часто, и что самоорганизующаяся команда лучше всего знает, как это сделать. Пока команда достигает своих целей спринта и непрерывно создает ценность для клиента, то, как они это делают, является их делом и не должно зависеть от скорости выполнения задач, числа, которое мало говорит о доставленной ценности, особенно если рассматривать его в изоляции от других метрик.
Мартен Дальмейн лаконично подводит итог в одной из своих статей: "Компании, которые одержимы скоростью выполнения задач, ничего не понимают в Scrum".
Вопрос о том, должна ли скорость выполнения задач всегда увеличиваться, зависит от того, кого вы спросите.
Сооснователь Scrum Джефф Сазерленд довольно ясно высказывается по этому поводу в своей книге "Scrum: Искусство выполнения работы в два раза быстрее за половину времени":
"Как только у вас есть скорость выполнения задач, вы можете определить самое важное в Scrum: что мешает вам двигаться быстрее? Что вам мешает ускоряться?"
Если это не ясно, то на его веб-сайте указано:
"Скорость выполнения задач хорошо функционирующей команды Scrum должна постоянно расти примерно на 10% каждый спринт."
Однако многие практики Agile, такие как Мартен Дальмейн, эксперты, которых мы опросили, и Джон Катлер, который ввел термин "фабрика функций", не разделяют эту точку зрения. Они утверждают, что одержимость скоростью выполнения задач может привести к работе низкого качества, созданию функций продукта, не имеющих особой ценности для клиента, или выгоранию членов команды.
Здравый смысл сам по себе показывает, что более высокая скорость выполнения задач не всегда является целесообразной целью и что она не может постоянно увеличиваться до бесконечности. Уменьшение скорости выполнения задач естественным образом подходит в любой ситуации, где команда улучшает свои навыки, улучшает качество работы, увеличивает гибкость или настраивает более сложные требования от клиентов. Важно не зацикливаться на числе, а сосредоточиться на улучшении процессов и доставке ценности клиенту.
Итак, вернемся к нашему вопросу: должна ли скорость спринта продолжать расти? Мы бы сказали: «часто, но, конечно, не всегда и только по правильным причинам».
Скорость выполнения задач и объем работы - это две метрики подхода Agile, которые часто путаются. Обе они используются для измерения и прогнозирования того, сколько работы команда может выполнить, но делают это по-разному.
Например, у вас есть команда из двух разработчиков, средняя скорость выполнения задач которой составляет 10 SP. Один из разработчиков будет в отпуске весь следующий спринт. В этом случае у вас будет на 50% меньше разработчиков, и ваш объем работ на следующий спринт составит 5 SP.
Скорость выполнения задач (velocity) является необязательным показателем, который помогает командам достигать целей спринта. Команда должна владеть этой метрикой, отслеживать ее и решать, полезна ли она для их работы.
Allie Dyer Bluemel из Shortcut предлагает полезную оценку метрик, таких как скорость выполнения задач:
"Если их использование доставляет неприятности, если заполнение их является рутинной задачей, то измените способ их использования."
Когда дело доходит до скорости выполнения задач, вы и ваша команда находитесь в кабине пилота. Ваше внимание сосредоточено на цели спринта. Вы проверяете показатель скорости выполнения задач по мере необходимости. Владелец продукта (PO) в роли диспетчера держит вас в курсе вашего конечного пункта назначения.
В этой метафоре стейкхолдеры - это руководители на штаб-квартире авиакомпании. Они следят за затратами на топливо и числом пассажиров. Они никогда не связываются с вами по радио, чтобы задать вопросы или давать вам советы о приборах в самолете. Если вашим руководителям необходимо это делать, возможно, настало время отказаться от них, и от метрики скорости выполнения задач.