Метрики в Scrum и Kanban

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

    Cumulative Flow Diagram

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

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

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

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

    • Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
    • WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
    • Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
    • Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
    • Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
    • Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).


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

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

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

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

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 637 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      0
      Kanban имеет одну фатальную проблему — он не даёт точки отсечения сотрудника. scrum даёт. Если человек не выполняет спринты из раза в раз — плохой программист (каким бы хорошим он ни был — не делает спринты, какая от него польза?). А в kanban этой простой и ясной метрики нет.
        0
        Как же? Все как раз проще. Берете определенный класс задач по оценкам команды и смотрите на cycle time при их выполнении у каждого члена команды. Если отличается сильно у одного, то это повод разобраться. Возможно он всем помогает и благодаря ему вообще движется разработка. Что такое «человек не выполняет спринты» я вообще понять не могу. В Scrum как раз вся командная активность прячется за спринтом и разобраться кто хороший кто плохой потом не так просто.
          0
          Во избежании данной проблемы мы и на Скрам проектах следим за Cycle Time. А тот, кто помогает по другим задачам, в те задачи время и заносит. Все честно и прозрачно=)
          0
          Только основываясь на опыте Скрама, Канбан судить не берусь.
          Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
          К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
          Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое