Что такое velocity chart
Agile-метрики команд. Часть 2. Хорошие метрики
В прошлой статье мы говорили о том, какие метрики лучше не использовать в командах. Собственно с ней можно ознакомиться тут:
Agile-метрики команд. Часть 1. Сомнительные метрики
Оранжевые организация — большие любители все “мерять”. Лично мое мнение такое: мерять можно что угодно, однако в…
В этой статье мы рассмотрим какие метрики можно использовать со своими Agile командами.
Burn-up Chart
Что это: показывает как вы съедаете скоуп (объем) к дате или же наоборот, к какой даде будет сделан этот объем скоупа.
Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?
Или, что будет сделано к Рождеству?
В Agile мире, мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет, потому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.
End-to-end time to market (Lead time)
Что это: это метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.
Часто в разработке команды измеряют, как быстро они делаю саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.
Однако, на много интереснее, сколько времени прошло в целом от идеи до реализации. И вот почему:
Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу
А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика 🙂
Эффективность потока (Flow Efficiency)
Любая работа это совокупность активный стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.
Например, возьмем упрощенный процесс разработки с точки зрения задачи:
Проработка деталей — Разработка — Тестирование — Выпуск
В такой цепи “задача”, будет находиться в активном состоянии, когда над ней будет проводиться работа, например, программист пишет код. Как только он закончил, с точки зрения задачи, активная фаза закончилась, она перешла в стадию “ожидания тестирования”. Тестировщик приступит к работе тогда, когда освободиться от других задач.
Если вы считаете время, которое тратится на “работу” над задачей, то есть активное время, а так же время, которое задача проводит в ожидании, вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.
Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%
Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.
Количество элементов в беклоге
Что меряет: меряет количество элементов в бэклоге 🙂
Зачем мерять? Что бы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог — это склад. Излишние складские запасы — один из видов потерь.
Как за любым складом, за бэклогом нужно ухаживать, пересматривать, оценивать, чистить и инвентаризировать.
Чем больше ваш бэклог, тем меньше вы понимаете, что в нем храниться, и тем меньше его фактическая актуальность
Более того, чем больше всем элементов, тем больше времени тратиться на уход за ним, а так же, тем меньше прозрачность работы в нем.
Нет цифры, которая бы идентифицировала предел 🙂 это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” 🙂
Срок жизни элемента беклога
Предыдущая метрика тесно связана с этой метрикой — чем старее задачи в беклоге, тем менее смысла они имеют.
Старость беклога обычно гворит о следующих проблемах:
Чем меньше срок жизнь, тем понятнее контент беклога, проще с ним работать и повышается его актуальность.
Эволюция Definition of Done
Как померять работу Scrum Master? Очень просто — на сколько растет Definition of Done его команды. Этим же можно померять “взросление команды”.
Именно увеличение критериев готовности отлично отображает, на сколько растет техническая осознанность команды, на сколько быстро вы можете делать изменения, на сколько быстра обратная связь, на сколько вы близки к клиенту.
Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали более Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.
Производительность команды [Скорость](Velocity)
Производительность Скрам-команды часто называют скоростью, поскольку это буквальный перевод Velocity —англоязычного термина из Scrum. Это величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Производительность является важной метрикой в Скраме и должна визуализироваться таким образом, чтобы все члены Команды могли ее видеть.
Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Стори Поинты по частично завершенным или незавершенным историям не должны участвовать в расчете производительности Команды.
Прогноз производительности должен отслеживаться в течение Спринта на основании Диаграммы Сгорания Работ Спринта. Конечно, в идеале итоговая производительность спринта должна совпасть с числом Стори Поинтов по всем задачам, запланированным на Спринт, но по факту она может отличаться как в меньшую, так и в большую сторону.
Производительность — это ключевой механизм получения обратной связи для Команды. Она позволяет оценить, как внедрённые процессные изменения повлияли на эффективность ее работы. И хотя производительность Команды от Спринта к Спринту может меняться, в среднем у хорошо функционирующих Скрам-Команд она стабильно возрастает примерно на 10% за Спринт.
Этот показатель помогает достаточно точно прогнозировать, сколько историй Команда может делать за один Спринт (в Скраме это называется Вчерашняя погода). Для расчета прогноза необходимо взять среднее значение Производительности за последние три Спринта. Это означает, что для корректного расчета производительности Команде необходимо работать в том же составе, как минимум, три Спринта, что бывает очень сложно объяснить нетерпеливым стейкхолдерам.
Без понимания Производительности невозможно планировать выпуск (релиз) продукта. Зная же Производительность, Владелец Продукта понимает, сколько Спринтов потребуется Команде, чтобы собрать функционал, готовый к поставке. В зависимости от длины Спринта, Владелец Продукта может запланировать дату релиза или понять, укладывается ли Команда в заданный свыше дедлайн.
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены.
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Оценка (Estimation)
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Agile/Scrume/Kanban как выравнивать процессы, максимизировать процессы
Материал подготовлен в рамках обучения Product University, январь, 2021
Для начала определим кто такой менеджер?
Менеджер — это человек производящий и управляющий потоками, для оптимизации производственной деятельности и достижения поставленных целей и результатов.
Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrume, Kanban. Чтобы иметь представления как работать с командой.
Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.
А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.
Подход к проектам по разработке ПО
• Гибкая методология разработки,
• Постоянное формирование требований на основе целевого видения продукта
• Короткие горизонты планирования (1-2 мес.)
• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля
• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Особенность реализации проектов
• Фиксированы срок и стоимость проекта.
• Лучший контроль качества – контроль результата каждой итерации
Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки
Scrum – самая популярная из гибких методологий разработки
Позволяет решать задачи
• с минимальными затратами.
РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.
Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.
ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.
По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.
Как максимизировать и выравнивать процессы?
На самом деле здесь уже все продумано, и придумать велосипед не нужно!
Используется всего четыре артефакта:
Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.
Это краткое описание того, ради чего выполняется данный спринт, цель на спринт помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.
Sprint Burndown Chart
Есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.
Ритуалы в скрам это:
Sprint Planning Meeting (встреча по планированию спринта)
Daily Meeting (ежедневная встреча команды).
Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.
Sprint Review – сдача спринта Product Owner
По завершению каждого спринта команда обязана провести демонстрацию полученного результат.
Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.
Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.
Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Kanban — это метод для разработки продуктов, который помогает наладить текущие процессы и не перегрузить команду. Незавершенные задачи не простаивают и потоком движутся по цепочке создания продукта или его поддержки.
Kanban используют для реализации проектов.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с «передовой» и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.
В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи
Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.
Мини-справочник и руководство по 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 можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?