Velocity команды что такое

Скорость — убийца Аджайл-команд

Алексей Бушманов

08.07.2019

Комментариев нет

Что такое скорость (velocity)?

Velocity — это показатель в Аджайл-мире, который дает представление о приблизительной «скорости» команд. После измерения скорости нескольких спринтов, в которых у вас есть стабильная команда и один и тот же продукт, если вы определите среднее число сторе-поинтов (story points) поставленных командой историй (фич), вы определите среднюю скорость команды. Это можно сделать в случае, если для оценки историй вы используете числовые оценки.

Есть несколько условий, которые важны для того, чтобы измерение скорости имело смысл:

Вы можете не учитывать вклад некоторых внешних факторов при расчете скорости, но чем больше предположений вы сделаете, тем менее полезным будет полученное число.

Скорость — исключительно внутренняя метрика команды

Часто скорость используется в качестве инструмента для проверки работы команды извне, например, когда Владелец продукта дает четкие сроки, когда будут готовы новые функции продукта или озвучивает скорость команды заинтересованным сторонам и клиентам во время обзора спринта.

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

Использование скорости вне команды, не говоря уже об измерении производительности команды с использованием скорости, чрезвычайно опасно. И у меня есть для этого две веские причины, с которыми вы можете столкнуться, когда пытаетесь использовать скорость как показатель эффективности команд:

Скорость не равна производительности

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

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

Другие (более полезные) показатели

Первый довольно очевиден: если ваши истории примерно одинакового размера, простое количество завершенных историй за один спринт покажет то же самое, что и скорость. Это работает хорошо, даже если есть различия в размере историй — как только вы усредните их количество после нескольких спринтов, вы все равно получите достаточно точное число.

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

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

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

Источник

Метрики в Scrum и Kanban

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

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

Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.

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

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?

Источник

Velocity Scrum

Если представить себе движение автомобиля, то скорость в нём оценивается по спидометру. Глядя на него всё предельно ясно. Однако в жизни в целом и в каком-то конкретном деле нет спидометра, и как оценить скорость объективно – уже вопрос. Если представить, что в автомобиле сломался спидометр, то скорость может быть оценена постфактум, то есть когда человек будет ехать 60 минут и проедет, например, 100 км, затем за 60 минут – 120 км, то он будет видеть, с какой скоростью двигался – около 110 км/ч. При этом, если во время следующих 60 минут он остановится и потратит на заправку 12 минут, на обед 15 минут и проедет 55 км, то средняя скорость за весь путь составит – 98 км/ч.

Как и при движении на автомобиле, скорость можно измерять и в Scrum, и называется это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных отметок, как, например, определённое количество километров через каждые 60 минут.

Для примера предоставим график Velocity, отображающий по горизонтальной оси количество Sprints, а по вертикальной – Story Points.

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

Если сравнивать с движением по дороге, то список ассоциаций, влияющих на скорость, может быть такой:

Хочется, однако, отметить, что по поводу метрики Velocity в Scrum ходят споры, и кто-то считает данные графики не очень полезными и сложными в определении возможных проблем, да и самого разгона. В целом все сходятся во мнении, что Velocity должен использоваться специалистом как дополнительное наглядное отображение эффективности, которое, как калька, накладывается на другие данные, помогая скорректировать аналитическую работу Scrum Master.

Story Points

Чтобы отчетливо понимать как формируется Velocity в Scrum, нужно понимать как грамотно оценивать Story Points. Данное понимание приводит к развитию максимально продуктивной команды.

Scrum Master

Источник

Про velocity команды, паровоз и ошибки

Чтобы объяснить принцип работы velocity команды, расскажу вам одну историю из своего прошлого.

Будучи молодым и горячим, отправился я осваивать севера. Надо сказать, в ту пору таких как я были десятки, если не сотни. Силы и рвения хоть отбавляй, а вот опыта катастрофически не хватало.

Да еще и с пересменкой в тот год случилась какая-то накладка, вот и вышло, что почти все в нашей транспортной бригаде оказались молодыми да зелёными.

Но, собственно, к сути.

Был у нас локомотив, и поручение перевезти от места добычи до городской ТЭЦ 50 тысяч тонн угля. В пункте назначения вагоны нужно было разгрузить и вернуть на исходную точку, чтобы загрузить по-новой. Согласно утверждённому расписанию движения, отправка состава была запланирована раз в сутки.

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

Но нужно было собираться в первый рейс, и всей бригадой мы решили прицепить 35 вагонов.

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

Возвращение состава с семью неразгруженными вагонами весьма озадачил всю бригаду. И на то были причины. Руководство требовало назвать сроки полного вывоза всего угля, чтобы учитывать данную информацию при составлении планов на следующий отчетный период. Но отправленный состав с 35 вагонами вернулся с 7 неразгружеными обратно.

Пока это не было похоже на предсказуемый результат.

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

Третий состав, ушедший с 27 вагонами, на узловой станции был неоднозначно воспринят представителями руководства. Кое-кому такой состав показался уж слишком коротким.

В этот раз, дополнительных вагонов к нашему составу прицепили всего 5 штук (как в первый рейс).

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

Конечно, всё описанное было метафорой.

Никто не будет отправлять обратно состав с не выгруженным углем. А вот задачи в бэклог возвращаются запросто, ровно как и «влетают» в работу незапланированные.

Именно поэтому, правильное планирование выполняет сразу несколько задач.

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

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

Отдельной строкой хотелось бы вынести такую ошибку, как забота о статистике вместо заботы о предсказуемости и поставке. В таком случае действия команды направлены на обеспечение стабильно хороших цифр (из-за обязательств перед руководством, поставленных KPI, самооценки и пр.) вместо инвестиции ресурсов в анализ причин возникших отклонений и работу над ошибками.

Правда, список ошибок расширяется еще на пару пунктов:

При этом, инструмент весьма непростой в освоении, недешёвый в обслуживании и тонкий в настройке. И в то же время, успешный навык использования velocity ставит команду на принципиально новый уровень развития и профессионализма.

Источник

Планирование спринта — Capacity vs Velocity

Хороший план сегодня лучше безупречного плана завтра. (Джордж Паттон)

На протяжении многих лет я экспериментировал с двумя различными подходами планирования спринта и объема работ. Вот мои мысли об этом:

Давайте рассмотрим оба подхода.

Планирование на основе Capacity (вместимости) спринта

Преимущества:

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

Недостатки:

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

Планирование основанное на Velocity (Скорости) команды

Выполнение спринта на основе скорости команды устраняет вышеуказанные проблемы и имеет некоторые дополнительные преимущества:

Планирование спринта самый нижний уровень планирование и без понимания того, КУДА и КАК вы идёте любая работа становиться бесполезной. На эти вопросы помогает ответить Roadmap. О подходах к составлению Roadmap продукта поговорим в следующей статье.

Помните, Scrum не решает ваши проблемы. Scrum показывает вам ваши проблемы. Вы должны решить проблемы самостоятельно. (Рон Джеффрис)

Источник