Velocity chart что это

Agile-метрики команд. Часть 2. Хорошие метрики

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

Agile-метрики команд. Часть 1. Сомнительные метрики

Оранжевые организация — большие любители все “мерять”. Лично мое мнение такое: мерять можно что угодно, однако в…

В этой статье мы рассмотрим какие метрики можно использовать со своими Agile командами.

Burn-up Chart

Что это: показывает как вы съедаете скоуп (объем) к дате или же наоборот, к какой даде будет сделан этот объем скоупа.

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

Или, что будет сделано к Рождеству?

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

В Agile мире, мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет, потому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.

End-to-end time to market (Lead time)

Что это: это метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.

Часто в разработке команды измеряют, как быстро они делаю саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

Однако, на много интереснее, сколько времени прошло в целом от идеи до реализации. И вот почему:

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

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

Эффективность потока (Flow Efficiency)

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

Например, возьмем упрощенный процесс разработки с точки зрения задачи:

Проработка деталей — Разработка — Тестирование — Выпуск

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

Если вы считаете время, которое тратится на “работу” над задачей, то есть активное время, а так же время, которое задача проводит в ожидании, вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.

Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%

Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.

Количество элементов в беклоге

Что меряет: меряет количество элементов в бэклоге 🙂

Зачем мерять? Что бы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.

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

Чем больше ваш бэклог, тем меньше вы понимаете, что в нем храниться, и тем меньше его фактическая актуальность

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

Нет цифры, которая бы идентифицировала предел 🙂 это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂

Срок жизни элемента беклога

Предыдущая метрика тесно связана с этой метрикой — чем старее задачи в беклоге, тем менее смысла они имеют.

Старость беклога обычно гворит о следующих проблемах:

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

Эволюция Definition of Done

Как померять работу Scrum Master? Очень просто — на сколько растет Definition of Done его команды. Этим же можно померять “взросление команды”.

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали более Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.

Источник

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

Алексей Бушманов
08.07.2019
Комментариев нет

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

Производительность Скрам-команды часто называют скоростью, поскольку это буквальный перевод Velocity —англоязычного термина из Scrum. Это величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Производительность является важной метрикой в Скраме и должна визуализироваться таким образом, чтобы все члены Команды могли ее видеть.

Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Стори Поинты по частично завершенным или незавершенным историям не должны участвовать в расчете производительности Команды.

Прогноз производительности должен отслеживаться в течение Спринта на основании Диаграммы Сгорания Работ Спринта. Конечно, в идеале итоговая производительность спринта должна совпасть с числом Стори Поинтов по всем задачам, запланированным на Спринт, но по факту она может отличаться как в меньшую, так и в большую сторону.

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

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

Без понимания Производительности невозможно планировать выпуск (релиз) продукта. Зная же Производительность, Владелец Продукта понимает, сколько Спринтов потребуется Команде, чтобы собрать функционал, готовый к поставке. В зависимости от длины Спринта, Владелец Продукта может запланировать дату релиза или понять, укладывается ли Команда в заданный свыше дедлайн.

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.

Критерии Приемки (Acceptance Criteria)

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

Оценка (Estimation)

Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.

Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Источник

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

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

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

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

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Источник

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

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

Velocity chart что это. Смотреть фото Velocity chart что это. Смотреть картинку Velocity chart что это. Картинка про Velocity chart что это. Фото Velocity chart что это

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

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

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

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

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

Недостатки:

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

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

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

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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *