Канбан «на пальцах»

Agile разработка - это система ценностей, а не процесс

Agile-манифест - это короткий набор из четырех фраз, которые показывают, что на самом деле важно (http://en.wikipedia.org/wiki/Values ) для практиков Agile. Эти фразы аналогичны словам "За Родину! За Сталина!", с которыми советские солдаты шли в бой. В них не определены конкретные процессы, но общего призыва было достаточно, чтобы сообщество само выработало определенные практики. (Для более детального обзора культуры и системы ценностей мира agile, читайте Agile is Culture, Not Process.

Agile практики берут лучшее из... фуршетов

Некоторые процессы считаются "Agile", если системы ценностей, лежащие в их основе, близки к системе ценностей Agile. Scrum и экстремальное программирование – яркие и наиболее распространенные примеры таких процессов. Куда менее известные, но не менее важные – Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD). Каждый из этих процессов объединяет несколько хороших практик и описание составляющих фаз процесса. Если бы вы выписали все хорошие практики из этих процессов, вы бы получили фуршетный стол, заставленный очень хорошими практиками, которые можно использовать для создания собственного процесса. И это именно то, чем занимается большинство организаций. Обычно люди проходят курс Certified Scrum Master, где узнают про роль Scrum Мастера в Scrum, но сегодня вы освоите основы Scrum, все его роли и составные фазы, а в довесок узнаете много дополнительных практик, которые не были упомянуты в первоначальном описании Scrum Кена Швабера и Майка Бидла. Чаще всего начинают с пары практик экстремального программирования: управления требованиями через пользовательские истории (user stories) и способом планирования релизов. Нормальным считается сокращение длины спринта в Scrum с одного месяца до пары недель, использование способа эстимирования из экстремального программирования, завершение каждой фазы ретроспективным митингом наподобие оного из Crystal или DSDM. Я лично добавляю такие практики, как дизайн и тестирование пользовательского интерфейса, визуализация пользовательских историй и более формализованные роли продукт оунера (Product Owner) и заказчика. Изначально простой Scrum рискует стать большим неповоротливым монстром. Сегодняшний типичный Agile процесс, вне зависимости от того, как вы его называете, берет лучшее с фуршетного стола Agile практик, чтобы сформировать такой процесс, где:

1. Нужды и требования проекта выражаются в виде пользовательских историй, помещенных в беклог. В идеале эти истории формируются продукт оунером (в SCRUM) или заказчиком (в экстремальном программировании) совместно с командой.
2. Разработчики дают высокоуровневые оценки на время разработки пользовательских историй.
3. Продукт оунеры группируют пользовательские истории в последовательные релизы (итерации, спринты и т.д.), каждый из которых длится от шести недель до шести месяцев.
4. Продукт оунеры выбирают следующие истории для каждой фазы, начиная с приносящих наибольшую пользу. Выбранные истории должны "вписываться" в заданные временные рамки.
5. К концу каждой фазы команда успевает инкрементально увеличить ценность продукта. Итоговый продукт демонстрируется продукт оунеру и другим стейкхолдерам.
6. Команда сохраняет оценки времени для каждой истории. Они используются в будущем для рассчитывания числа историй, которые можно добавить в следующую фазу.
7. Команда проводит ретроспективные митинги, чтобы проанализировать свою работу в ходе фазы и понять, что можно сделать лучше в следующей фазе.
8. Пофазная разработка длится вплоть до выпуска финальной версии продукта

Конечно, есть и другие общепринятые практики, такие как ежедневные stand-up митинги для синхронизации статусов членов команды и burn-down диаграммы для отображения прогресса разработки, но и приведенных достаточно, чтобы выразить мою мысль: сегодняшний типичный Agile процесс представляет собой разнообразнейшую смесь хороших идей, взятых из различных источников.

Медленные изменения общепринятых практик приводят к проблемам

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

Уменьшение историй облегчает Agile разработку

В среде Agile разработки стало модным ратовать за уменьшение пользовательских историй, и для этого есть много хороших причин. Маленькую историю проще оценивать, что ведет к более точным оценкам и к большей предсказуемости. Маленькими историями проще планировать. С большими историями – пользовательскими историями, которые могут занять у разработчика недели для реализации – сложнее спланировать следующую фазу разработки, особенно когда сама фаза занимает не более пары недель. Кажется, в такую фазу влазит лишь пара историй, а иногда остается место еще на половину истории - но как вы можете разработать только половину истории? Разбиение крупных историй на более мелкие облегчает планирование фаз.

Уменьшение историй усложняет Agile разработку

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

Короткие фазы облегчают Agile разработку

Планирование короткой фазы занимает меньше времени. Изначально взятые из экстремального программирования, фазы (или итерации) должны были длиться по 2-4 недели. Первоначальная концепция Scrum предполагала, что спринт должен длиться один календарный месяц, так что разработку было легче синхронизировать с бизнес месяцами и квартальными циклами. Каждый, кто хоть раз посещал Agile митинги по планированию фаз, знает, что они часто длятся ровно на час больше того времени, что вы готовы вытерпеть. Короткие итерации - например на неделю-две - позволяют планированию проходить быстрее. В наши дни типичная продолжительность Agile фазы сократилась до двух недель. Мы быстрее получаем обратную связь при коротких фазах разработки. В конце Agile фазы у нас есть возможность просмотреть финальную версию продукта и внести соответствующие изменения в продукт беклог. Также мы можем измерить скорость разработки команды, а на ретроспективном митинге можно предложить и воплотить в реальность улучшения процесса. Такие частые возможности оценки продукта по скорости разработки и используемому процессу позволяют быстро реагировать на проблемы и делать Agile собственно Agile'ом.

Короткие фазы усложняют Agile разработку

Короткие фазы перегружают. Проработка деталей пользовательской истории выходит за рамки фазы: Идеальная Agile фаза отличается частым общением между разработчиками, тестировщиками и командой продукт оунера - бизнес аналитиками, UX специалистами и, собственно, представителями бизнеса. Это делается для четкого понимания того, что необходимо создать, и детального описания того, что необходимо проверить при готовности. Короткие фазы оставляют меньше времени для общения. Обычно уточняющие историю и ее прием митинги проводятся за фазу до фазы реализации этой истории. Некоторые практики Scrum начинают задумываться над определением готовности истории к реализации: что именно должно быть сделано для того, чтобы историю можно было начинать реализовывать. Тестирование не вкладывается во временные рамки фазы: при короткой фазе сложно полностью проверить готовность истории. Так часто тестирование не вкладывается в одну фазу и переносится на следующую, что влечет за собой цепочку багов из предыдущей фазы, которые "внезапно" проявляются в текущей фазе. Как результат, эти не вкладывающиеся в одну фазу активности обычно занимают в 3-4 раза больше, чем одна фаза. Фактически, приходится выделять одну фазу на подготовку к истории, одну на разработку, одну на тестирование и еще одну на устранение найденных дефектов. Уровень общения в команде снижается, а параллельно приходит усталость. При уменьшении фаз и члены команды продукт оунера, и тестировщики внезапно оказываются в жестких временных рамках: им надо одновременно чинить баги с прошлой фазы и готовиться к следующей. Они много работают, посещают кучу митингов и, как результат, не могут уделять достаточно времени разработчикам, работающим над текущей фазой. Поскольку они сфокусированы не на текущей фазе, любые вопросы по ней воспринимаются как отвлечение. Взаимодействие в команде снижается, а вместо него приходит напряженность в отношениях. Члены команды перегружены, раздражены и не могут спокойно работать.

Вписывается ли бережливое мышление в Agile?

В течение последних нескольких лет много практиков Agile начали внедрять принципы бережливой разработки в свои Agile методы. Принципы, изначально изложенные Томом и Мери Поппендиками в их книге Lean Software Development , теперь широко используются по всему миру как в чистом виде, так и в комбинации с Agile методами. Недавно я заметил большое количество обсуждений разработки в стиле Канбан - подходе, который нарушает основное правило Agile разработки - наличие временного ограничения на разработку одной фазы. Несмотря на то, что про Канбан говорят и пишут многие, Девид Андерсон одним из первых осваивал эту тематику и до сих пор является евангелистом Канбан.

Канбан в бережливом производстве

Бережливая разработка ПО позаимствовала много терминов из японского языка и из системы производства Toyota в частности. Слово "Канбан" состоит из двух частей: "Кан" означает "визуальный, видимый", а "бан" означает карточку или доску. Представьте себя на производственной линии Тойота. Вы вставляете двери в Приусы. У вас есть стопка из 10 или около того дверей. Вы постепенно вставляете двери в корпуса, уменьшая вашу стопку. Когда вы убираете шестую дверь, оставляя ровно пять дверей, на верхней двери обнаруживается карточка Канбан, на которой написано "установите 10 дверей". Ну, может, надпись немного другая, но смысл такой - вам надо установить еще 10 дверей на эти Приусы. Вы берете эту карточку и бежите с ней к товарищу, который занимается производством дверей и уже ждет вас. Он занимался другими делами, чтобы не скучать, ожидая вас. Что важно, он НЕ делал двери для Приусов. Он берет вашу карточку и начинает делать двери. Вы идете обратно на ваше рабочее место и ровно тогда, когда ваша стопка кончается, "дверной" товарищ приходит с новой стопкой из 10 дверей. Вы знаете, что между пятой и шестой дверями уже лежит следующая Канбан карточка на вставку еще 10 дверей в Приусы. Ну а эти двери пришли как раз вовремя. Весь этот процесс отработал на "ура". Эх, если бы вы занимались производством дверей. У "дверного" товарища, судя по всему, куча свободного времени. Карточки Канбан используются для ограничения количества производимых фабрикой деталей. Тойоте невыгодно производить двери быстрее, чем осуществляется сборка машин. При таком подходе деньги тратятся на избыточные двери и их компоненты. Избыточная работа, осуществляемая в процессе производства, воспринимается как потери в бережливом производстве (да и не в бережливом производстве избыточная работа – это тоже траты). В примере выше (полностью, кстати, выдуманном) у вас никогда не будет больше 15 дверей на установку. ("Муда" – "потери" по-японски. Используйте это слово, чтобы удивить ваших бережливых друзей). Используя Канбан карточки, мы поставили лимит в 15 дверей. В этом аспекте можно провести параллели между Канбан карточками и бумажными деньгами. Как и в денежной системе присутствует четко ограниченное количество напечатанных денег, в системе бережливого производства присутствует четко ограниченное количество деталей, ограниченное Канбан карточками. Если призадуматься, это достаточно простой способ ведения дел. Кори Ладас хорошо разъясняет этот принцип в своих статье и книге.

Разработка с Канбан ограничивает количество незаконченной работы

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

• Отменяется разработка по фазам с четкими временными границами
• Пользовательские истории больше, а их самих меньше
• Оценка (estimation) сводится к минимуму или убирается насовсем
• Внимание переходит со скорости разработки на продолжительность цикла

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

Канбан разработка как она есть

Канбан разработка крутится вокруг визуальной доски, которую мы используем для управления незаконченной работой. (Неудивительно, учитывая перевод слова "Канбан"). В Agile пользовательские истории часто располагают на доске с колонками, представляющими собой стадии, через которые проходит история, например, "разработка" или "тестирование". Канбан доска похожа на эту доску, но при этом добавляет некоторое количество других правил. Эта доска была создана на основе досок, фотографии которых я нашел в Yahoo Основной идеей является то, что истории стартуют с левого края доски и проезжают всю доску слева направо, попутно проходя через те фазы разработки, без которых эти истории нельзя будет назвать завершенными. Завершенные истории, готовые к запуску в продакшн окружении, копятся на правом краю доски. И, поскольку это Канбан доска и мы собираемся ограничивать количество незавершенной работы, мы ограничим количество пользовательских историй, одновременно находящихся на доске. Числа, написанные снизу каждой колонки, представляют собой максимальное количество историй, допустимое в данной конкретной колонке. Этот пример Канбан доски был сделан на уайтборде с помощью стикеров, маркеров и синей изоленты.

Канбан доска - слева направо

1. Goals - цели

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

2. Stories queue - очередь историй

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

3. Стадии разработки истории

Справа от очереди историй расположены колонки со стадиями разработки, через которые должна пройти история, чтобы считаться выполненной. Первая колонка часто используется для стадии прорабатывания истории. В командах разработки Yahoo она помечается как UED - user experience design. История должна находиться в этой колонке, если в данный момент осуществляется прототипирование UI или описание истории расширяется до необходимого для разработки уровня. У вас же может быть отдельная колонка для стадии, когда бизнес аналитики аккумулируют необходимые для разработки доменные знания. Следующая колонка часто используется для собственно разработки, а следующая за ней - для тестирования. Эти колонки не фиксированы. Вы должны обсудить с вашей командой те стадии, через которые проходит история, прежде чем помечаться как "выполненная". В некоторых компаниях отдельные колонки могут выделяться под написание документации или под подготовку инженеров поддержки для выпускаемой функциональности. Колонки - не роли в команде. Пускай часто и совпадает, что в отдельной колонке работают люди одной роли в команде, фокус должен делаться не на этом, а на выполнении истории и на том, что ей необходимо для выполнения. Например, если в вашей компании не используются бизнес-аналитики или дизайнеры пользовательского взаимодействия, используйте первую колонку для совместной проработки историй разработчиками и представителями бизнеса. Здесь же стоит определить критерии "готовности" истории. Просто взять и начать писать код (следующая стадия) - плохой ход, особенно если у вас нет критериев, по которым вы сможете оценивать готовность вашей работы. Каждая стадия разделена на две части: верх используется для историй, находящихся в разработке, а низ - для буфера историй. Когда работа над определенной стадией определенной истории заканчивается, историю перемещают из блока "в процессе" в буфер, где она будет дожидаться перевода на следующую стадию. У последней стадии нет буфера, поскольку эта стадия истории завершается при завершении истории. Когда мы ограничиваем количество невыполненной работы, мы устанавливаем рамки для общего количества историй в стадии, которое включает в себя как текущие истории, так и истории в буфере.

4. Done! - Сделано!

Когда история завершается, она готова к поставке на продакшн.

Истории должны быть "минимальными доставляемыми функциональностями"

Термин "минимальная доставляемая функциональность" (minimal marketable feature - МДФ) был впервые использован в книге Программное обеспечение в числах. Акцент в этой книге ставится на самый маленький объем работы, который можно запустить в продакшн и принести тем самым пользу конечным пользователям. Чтобы стать "минимальной доставляемой функциональностью", функциональность должна быть достаточно велика, чтобы быть полезной. Очевидно, при таком определении МДФ изначально больше тех мелких историй, которым требуется не больше пары дней на реализацию и которые представляют собой основную массу историй в Agile беклогах наших дней. МДФ же может разрабатываться по несколько недель. Однако, здесь важна не продолжительность разработки истории, а то, будет ли она понятной и полезной конечным пользователям. Некоторые личности используют следующий вопрос для определения МДФ: "Упомяну ли я об этой функциональности в блоге моей компании?". Если эта функциональность слишком мала, чтобы упоминать о ней в корпоративном блоге - это не МДФ. Фокус на увеличении ценности выпускаемого продукта - одна из важнейших концепций Канбан разработке. Каждая функциональность должна быть ценна сама по себе.

Ставьте ограничения на невыполненную работу

Чтобы быть бережливыми, мы ограничиваем количество историй, допустимое на данной доске. Для расчета этого количества можно взять такую распространенную формулу: сложите количество ролей в команде каждого человека и разделите полученное число на два. Все роли включают в себя разработчиков, аналитиков, дизайнеров пользовательского взаимодействия, тестировщиков, инженеров развертывания. Например, если в команде 20 членов, мы можем ограничить количество МДФ заданий на доске 10ю. Затем нам надо поставить ограничения на каждую конкретную колонку. Для очереди историй - месте, где истории ждут выполнения, поставьте ограничение в половину ограничения на количество активных историй. Так, если на доске допускается 10 одновременно выполняющихся историй, поставьте ограничение в 5 историй для этой колонки. Для каждой стадии разработки выставляйте ограничение в половину того числа людей, которые могут работать в данной стадии. Например, если у вас 6 разработчиков, то ограничением колонки разработки будет 3. Такие правила размещения историй на Канбан доске заставляют разработчиков работать над историями вместе. Однако я на практике уже убеждался, что такой подход нравится не всем. Я часто видел ограничение на количество историй на шаге разработки, равное не половине, а общему числу разработчиков в команде или даже в полтора раза больше. Конечно, если вы пойдете таким путем, вы увеличите количество историй, одновременно находящихся в разработке – и, как вы можете ожидать, общее время выполнения увеличится. Сумма ограничений каждой отдельной колонки должна совпадать с общим ограничением на количество одновременно разрабатываемых историй на доске. Возможно, вам придется немного поиграть с ограничениями в каждой колонке Канбан доски или даже слегка увеличить общее ограничение на количество историй (хотя это похоже на допечатывание денег каждый раз, когда они у вас кончаются). В примере Канбан доски "канбанами" служат кусочки синей изоленты, которые отмечают, где мы можем крепить очередной стикер с историей. Каждый кусок изоленты в активной или буферной зонах колонок представляет собой место для одной активной истории. Вы можете достичь того же эффекта, просто написав ограничение над каждой колонкой.

Жизнь МДФ истории на Канбан доске

Этот рассказ начинается с очереди МДФ историй, терпеливо ждущих на левой стороне Канбан доски. Они расположены рядом с целями так, что каждый может видеть, что эти МДФ помогают в достижении целей. Дизайнер пользовательского взаимодействия и бизнес аналитик, работая в паре, берут верхнюю историю из очереди и сдвигают все остальные вверх. Вытянутая история помещается в колонку "проработка в процессе". Они определяют необходимых для проработки стейкхолдеров и обсуждают с ними критерии приема готовности истории. Они встречаются с разработчиками, чтобы убедиться, что определенные ранее критерии понятны и достаточны для начала разработки. Все выражают свое согласие. Бизнес аналитик говорит "Значит я помещаю эту историю в буфер". "Нет нужды, мои активные слоты пусты - я сразу помещу историю в них и начну ей заниматься" - говорит разработчик. Использование системы Канбан вовсе не означает, что мы разрабатываем по модели водопада. Поскольку на доске все истории упорядочены слева направо, многие ошибочно считают, что Канбан исключает совместную работу над историей. Заметьте как бизнес аналитики и дизайнеры поработали вместе со стейкхолдерами и разработчиками. Они были ответственны за выполнение взятой истории, но это вовсе не означало, что они должны сделать все сами и не помогать никому с другими историями. В здоровом Канбан процессе есть множество мест, когда члены команды работают вместе. Продолжая работу над историей, мы видим, что она движется по доске слева направо, как только все, от кого зависит работа над историей на определенной стадии, делают все возможное, чтобы история вышла из этой стадии и пошла дальше. Они никогда не перебрасывают историю на следующую стадию, не выполнив своих обязательств. Они знают, что если перенести незавершенную историю в буфер, ответственные за следующую стадию просто не возьмут эту историю и отправят ее на доработку. Такой подход делает взаимодействие между членами команды и полноценное общение критически важными. Передвижение истории в обратном направлении – слева направо – вполне обычная ситуация. Чаще всего такое происходит, когда кто-то из следующей стадии считает, что качество работы предыдущих стадий можно немного улучшить. Проходит время, истории прорабатываются, перемещаются в разработку, а потом и в тестирование. Но вдруг случается маленький затык. Разработчики только что закончили свою историю и, подойдя к Канбан доске, чтобы перенести выполненную историю в буфер своей колонки, они видят, что в их буфере нет мест и колонка тестировщиков тоже забита под завязку. И что теперь? Разработчики идут к тестировщикам. - "Ребят, мы тут реально на всех фронтах загружены со своими историями. Свободные слоты появятся не раньше завтрашнего утра." - "Хммммм", – говорят разработчики, – "А мы можем помочь тестировать?" - "Конечно вы можете!", – говорит тестировщик. - "С вашей помощью мы разгребемся уже к сегодняшнему вечеру". – Тестировщик улыбается, – "Только я не дам вам проверять сделанную вами же историю."

Ограничения выявляют узкие места

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

Ускоряйтесь с помощью "Ускоренных" слотов

Всегда есть срочные запросы или проблемы на продакшне, которые надо решать здесь и сейчас. Над каждой колонкой есть отдельный "ускоренный" слот. Ряд таких слотов образует "скоростную полосу" над нашей Канбан доской. Когда какой-то элемент помещается в "ускоренный" слот, он получает наивысший приоритет для членов команды, работающих в этой колонке. Этот элемент затем переместится в следующую колонку и будет двигаться с наивысшим приоритетом, пока не будет выполнен.

Измеряйте производительность длительностью полного цикла

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

1. Записывайте время появления истории в очереди историй
2. При переходе истории на каждый следующую стадию записывайте время перехода на эту стадию.
3. В итоге, когда история доходит до состояния "завершено", запишите дату завершения истории.

Теперь у вас есть все данные для расчета длительности полного цикла. Разница между временем поступления истории на Канбан доску и временем ее ухода с доски называется длительностью полного цикла, которое включает в себя даже время простоя истории в очереди историй. Для оценивания длительности полного цикла определенной истории можно использовать среднее значение этой же длительности у всех выполненных историй. Рассчитанное время включает в себя время простоя истории – но это именно то, что в себя должно включать время полного цикла. Если вы заметите, что какая-то небольшая история была на Канбан доске более двух недель, вам явно стоит что-то заподозрить. Если вы хоть когда-нибудь стояли в очереди на аттракцион Пиратов Карибского Моря в Диснейленде, вы можете вспомнить дорожные знаки вдоль дороги, на которых написано "Отсюда осталось ждать не более 30 минут!" – ну или что-то похожее. Теперь вы можете записывать ваши собственные оценки времени на Канбан доску. В самом низу очереди историй напишите среднюю продолжительность полного цикла. Здесь я могу сказать "Этой истории осталось ждать 18 дней до выполнения". На вершине очереди историй можете написать соответствующую длительность, что-то наподобие "Этой истории осталось ждать 14 дней до выполнения".

Кому вообще нужна оценка?

Когда вы фокусируетесь на том, насколько быстро вы можете реализовать историю, и у вас есть возможность измерить лишь этот параметр, оценки теряют свой прежний вес. На самом деле, многие практики Канбан полностью отказались от оценивания. Кто-то до сих пор оценивает истории, а потом использует полученные оценки вместе со временем полного цикла. Электронные таблицы в таком случае могут помочь вам рассчитать среднее время полного цикла для всех историй из прошлого, которые получали такую же оценку. Если вы придерживаетесь подобной практики, разместите справа от вашей Канбан доски табличку с соответствиями эстимейтов и времен полного цикла. Эта табличка будет отличным ответом на вопрос о реальной продолжительности разработки, который наверняка зададут стейкхолдеры сразу после получения эстимейтов: "А когда мы увидим это в версии на продакшне?". Если ваши стейкхолдеры похожи на моих, им не хочется знать, когда они получат эту конкретную функциональность, нет. Они хотят знать, когда получат все это. Я обнаружил, что если я помещаю каждую историю в электронную таблицу, задам каждой истории время начала и время конца, то я смогу получить интересную временную статистику. Например, я могу сказать, сколько в среднем историй выполняет команда за определенный отрезок времени. Если я вижу что в прошлом команда справилась с 22 историями за 3 неделями, то в среднем она выполняет 7.3 историй за неделю. Если у меня в беклоге висят около 100 историй, я смогу обоснованно полагать, что общее время разработки будет около 13/14 недель (100/7.3). Это "вчерашняя погода" для системы Канбан - по крайней мере, я рассчитываю ее так. Если я знаю, что за трехнедельный период было 15 рабочих дней и 5 разработчиков работали по 8 часов в день, то мы получаем 75 человеко-дней. Знание этого позволяет мне рассчитать среднее количество человеко-дней на одну историю: около 3.4 (75/22). Это число достаточно близко к Пи, что дает мне полагать, что оно верно ;). Это число, 3.4, называется фактором загрузки в экстремальном программировании.

Циклы оценки, а не временные рамки для разработки

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

Синхронизируйте команду каждый день

Утренний стенд-ап митинг или дневной скрам митинг проходят как обычно, только теперь все стоят вокруг Канбан доски. Вместо обычного митинг ритуала опроса каждого человека "А что ты делал вчера?", "А что ты будешь делать сегодня?", команда сосредотачивается на Канбан доске, прикидывает, какие истории появятся на доске, а какие пропадут с нее, какие проблемы с загруженностью доски и как с ними бороться.

Смотритесь в зеркало каждые несколько недель

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

Показывайте свою работу каждые несколько недель

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

Возвращаемся к Agile идеалам

Возвращение к Agile идеалам мотивирует тех практиков Agile, которые пробуют Канбан подход. Agile манифест описал ценности Agile, но нигде не упоминал о фазах с жесткими временными рамками как способе их достижения. Практики бережливой разработки помогают командам увеличивать пропускную способность Канбан досок. Они не заставляют разработчиков печатать быстрее, они привлекают внимание команды к узким местам, которые замедляют весь процесс, помогают вам заметить их и отреагировать быстрее. Использование Канбан доски визуализирует текущую невыполненную работу, распределенную по всем стадиям разработки, а также показывает вам, когда на кого-то накладывается слишком много работы одновременно. Доска заданий, часто используемая в Agile подходе, также может поможет вам визуализировать выполняемую работу. Но, расширение доски заданий, отделяющее разработку от тестирования или других стадий разработки, помогает мне лучше визуализировать места, где процесс засоряется, т.е. помогает мне находить и устранять проблемы. Установка ограничений на количество историй в каждой стадии разработки и адекватное отношение к этим ограничениям лучше позволяет мне справиться со своими задачами, по сравнению с вариантом, когда в очередную фазу разработку просто вбрасывается большая куча заданий. Но, возможно, это всего лишь моя лень и нежелание бороться с серьезными проблемами. Я уверен, что вы никогда не попадали в ситуацию, когда вы и ваша команда сидели у подножия горы у

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.