С любезного разрешения Карла Скотланда (Karl Scotland) я публикую здесь перевод его замечательной статьи Kanban, Flow and Cadence и дополню его своими комментариями (будут выделены красным курсивом).

Kanban, Flow and Cadence

Kanban - контроллируемая работа
Flow - эффективная работа
Cadence - надёжная работа

Kanban

Kanban - это механизм управления работой в системе разработки программного обеспечения. Kanban переводится как "visual card" и выглядит как на следующей картинке (это автору написал Кенжи Хиранабе на конференции Agile 2008).

Родоначальником Kanban является Toyota Production System.

Kanban реализует пул-систему для работы точно к указанному сроку (just-in-time).
Пул-система - это система, согласно которой имеется некий пул задач на выбор для разработчиков. Команда тянет (от англ. pull - тянуть) задачи из пула и определяет состав итерации.

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

Это выглядит очень похоже на типичную Agile доску задач (Task Board), в то же время здесь есть ещё один важный элемент, который определяет всю систему Канбан - ограничения. Существует два основных ограничения - лимит очереди и лимит WIP (Work in progress - работа в процессе).

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

В идеале очередь задач должна быть FIFO (First in - first out), хотя это скорее рекомендация, чем строгое правило, так как это не всегда возможно с имеющимися навыками и ресурсами. Ограничивать WIP необходимо для уменьшения многозадачности (одновременного выполнения задач), увеличения производительности и улучшения командной работы.

Уменьшение многозадачности полезно по двум причинам.
1) 20% времени теряется на контекстные переключения между задачами, соответственно, меньше задач означает меньше потерь времени (из книги Gerald Weinberg, Quality Software Management: Systems Thinking)

2) Выполнение задач последовательно даёт результаты быстрее. Как показано на диаграмме внизу, в случае одновременного выполнения A, B и С (сверху), задача A выполняется намного позже и даже С выполняется чуть позже, чем в случае последовательного выполнения (внизу).

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

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

Общее время цикла = Число объектов в процессе / Средняя скорость выполнения

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

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

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

1. Можете ли вы помочь на имеющейся задаче? Займитесь этим.
2. У вас нет подходящих навыков? Найдите это узкое место и работайте над этим.
3. У вас нет подходящих навыков? Возьмите задачу из очереди.
4. Не можете начать ничего в очереди? Есть ли какая-нибудь низко-приоритетная задача, чтобы начать её исследовать?
5. Нет ничего низко-приоритетного? Найдите другую интересную работу. (Здесь конечно имеется в виду "другую интересную задачу", хотя другая работа - это тоже решение :) )

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

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

Размер лимита WIP может зависеть от типа работы и размера команды и должен регулироваться для достижения максимального flow (движения). Один способ - начать с небольшого значения (например, лимит в 1) и увеличивать при необходимости. Другой - начать с большого значения (например, половина размера команды) и уменьшать, пока не достигнута максимальная эффективность.

Результаты использования системы Канбан -
1) можно отказаться от Product Backlog'а, так как единственный интерес представляет ближайшая очередь задач.
2) можно отказаться от ограниченных по времени итераций (спринтов в Scrum), так как задачи берутся по необходимости.
3) можно избавиться от оценки трудозатрат на задачи, так как работа не планируется по итерациям.

Flow

Процесс описывает, как работа в системе может принести максимальную ценность. Как написали Mary и Tom Poppendieck,

“В бережливых (lean) предприятиях, традиционные организационные структуры уступают место новым командно-ориентированным организациям, нацеленным на процесс получения результата, а не на функциональную квалификацию."

Lean придаёт особое значение "One Piece Flow". Это означает движение одной части работы в момент времени между этапами техпроцесса, в отличие от движения целой кучи работ между этапами. One Piece в системе Канбан для разработки ПО может быть реализована как Minimal Marketable Feature (MMF, минимальный маркетинговый набор функциональностей). Как описано в книге M Denne и H Clelan-Huang Software by Numbers:

“Минимальный маркетинговый набор функциональностей - это некоторое количество функциональностей, которое реализует подмножество требований клиента, и которое представляет ценность для клиента будучи выпущенным как независимая сущность”.

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

Карточки с задачами должны быть "рыночными" и обеспечивать следующие результаты:

Table Stakes - эти результаты обеспечивают равенство в конкурентной борьбе, т.е. являются необходимым минимумом в игре.
Differentiators- дифференцируют продукт среди конкурентов и радуют пользователя.
Spoilers – обнуляют выделяющиеся результаты конкурентов и повышают планку равенства.
Cost Reducers – уменьшают цену и увеличивают размер прибыли

Полезная рекомендация - считать MMF рыночным, если есть что написать об этом в блоге продукта.

Карточки с задачами должны быть ясными, поставляемыми и заметными функциями. Описанный Биллом Вейком акроним INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) также может быть полезен применительно к MMF. (Ну и не забываем ещё про критерии SMART для любых задач - Specific, Measurable, Achievable, Result-oriented, Time-bounded)

Маркетинговый элемент MMF, означает что эти функции ценны именно вместе. Типичные User Stories, разбивающие работу на составные части, которые реализуются постепенно, не имеют большой рыночной ценности сами по себе. Важно понимать Ценностный поток MMF (Value Stream), чтобы разрабатывать и поставлять целый MMF как можно быстрее. Ценностный поток описывает шаги, задержки и информацию, необходимую для выполнения продукта, и часто может использоваться для определения шагов на начальных этапах системы Канбан. Я описываю как может быть достигнут продолжительный процесс (Flow) с MMF в статье The Anatomy of an MMF.

Есть несколько приёмов, которые могут помочь наладить отношения между MMF и User Stories для получения выгод от обеих техник. Один из них User Story Mapping, описанный Джеффом Паттоном.

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

Дальнейшее улучшение - использовать двух-рядные Канбаны, один ряд для MMF, и другой для User Stories.

В результате применения концепции Flow акцент ставится на использование больших сфокусированных на ценность MMF, чем маленьких постепенно увеличивающихся Stories.

Cadence

Cadence служит для достижения обязательств и надёжности в системе Канбан. Мне часто задают следующий вопрос:

"Если команда не оценивает и не планирует в фиксированных временных рамках, то как она может надёжно выполнять обязательства?"

Опять цитируя Mary и Tom Poppendieck,

“Регулярный ритм, или ‘сердцебиение’, создает у команды возможность надёжно выпускать рабочее ПО на надёжной скорости. В организации, обеспечивающей регулярный ритм, уже установлены процессы, и она может легко измерять свою производительность.”

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

Пропускная способность = WIP / Время цикла

Пропускная способность позволяет прогнозировать будущую производительность без необходимости указывать, что конкретно должно быть выполнено. Время цикла позволяет установить обязательства, заключая SLA (Service Level Agreement) с заказчиком (см. Kanban Commitment). Если размер работ меняется, от больших новых функций до небольших исправлений и запросов на изменения, может применяться классификация MMF, для определения целого ряда времён цикла (cycle-times). И для пропускной способности и для времени цикла можно построить график и отследить тренд (как для скорости в методике XP) для поощрения команды на дальнейшие улучшения. Диаграмма Cumulative Flow Diagram также делает видимым рабочий процесс в системе и высвечивает узкие места в проекте.

Для долговременного прогнозирования ритм квартального планирования направлен на квартальные цели и задачи. Для MMF могут последовательно выставляться приоритеты, чтобы выполнить эти цели и задачи. Регулярный ритм выпуска продуктов создаст уверенность, что команда будет работать с полной отдачей и производительностью.

Другие ритмы - stand-up митинги, регулярные ретроспективы и Обзоры Операций описаны Дэвидом Андерсоном. Некоторые команды используют Retrospective Kanban, чтобы сигнализировать, когда необходима ретроспектива. Я об этом уже кратко писал в статье Kanban and Retrospectives.

В результате Cadence достигается обязательство и надёжность через измерения, а не планирование.

Итоги:

Kanban система организует рабочий процесс таким образом, что можно избавиться от Product Backlog'а, временных итераций и оценок трудозатрат.
Flow позволяет эффективно производить максимальную ценность для клиента, направлен на создание больших MMF.
Cadence позволяет разъединить вход и выход итерации и достигать обязательства и надёжности через измерения, а не планирование.

Я не смог подобрать подходящий перевод терминам Flow и Cadence, возможно вы сможете - тогда сообщите мне. Далее мой взгляд более понятным языком. )))

Kanban - даёт более гибкий список задач на выполнение, это может быть хорошим плюсом, всё равно заказчик часто хочет добавить функциональность посреди итерации. Но целиком избавиться от ограниченных по времени итераций и оценок по времени не получится. Всё равно есть как минимум одна большая итерация - сделать проект к определённому сроку. И какая-то оценка трудозатрат всё равно должна производиться, чтобы понимать, успеет ли команда сделать желаемую фукнциональность в срок (не делать каждый раз оценку можно только имея представление о производительности команды, об этом говорит Cadence).

Flow или Value Stream - говорит о том, что надо создавать продукт не мелкими, непонятно как разбитыми кусочками, а целыми маркетинговыми наборами функций (MMF), чтобы клиент мог сразу же продавать эту версию продукта. В принципе это логично, и я лишь добавлю, что с клиентом должен быть налажен очень хороший контакт, чтобы всегда иметь от него актуальную информацию о приоритетах.

Cadence говорит о том, что в налаженном темпе работы нужно оценивать производительность команды для определённого размера задач (а если задачи отличаются по размеру, то иметь несколько оценок для различных размеров MMF).
Оценка производительности позволяет брать на себя обязательства и обеспечивать надёжность скорости разработки.

Project Catalyst blog

воскресенье, 23 августа 2009 г.

Лайфхакинг

пятница, 14 августа 2009 г.

Scrum и XP: заметки с передовой

Книги по Agile тематике

пятница, 7 августа 2009 г.

Kanban, Flow and Cadence

Flow

Cadence

среда, 5 августа 2009 г.

Почувствуй себя Scrumy!

Мои ссылки

Мой список блогов

Постоянные читатели

Архив блога

Обо мне

Project Catalyst blog

воскресенье, 23 августа 2009 г.

Лайфхакинг

пятница, 14 августа 2009 г.

Scrum и XP: заметки с передовой

Книги по Agile тематике

пятница, 7 августа 2009 г.

Kanban, Flow and Cadence

Flow

Cadence

среда, 5 августа 2009 г.

Почувствуй себя Scrumy!

Мои ссылки

Мой список блогов

Постоянные читатели

Архив блога

Обо мне

воскресенье, 23 августа 2009 г.

пятница, 14 августа 2009 г.

пятница, 7 августа 2009 г.

среда, 5 августа 2009 г.