Академический Документы
Профессиональный Документы
Культура Документы
Kanban
для Scrum Teams
Январь 2021
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
2
Для чего это руководство
Рассматривая систему как поток, Kanban‐метод может дополнить и улучшить фреймворк Scrum и
его реализацию. Команды могут применять практики Kanban как в самом начале использования
Scrum, так и по мере накопления опыта.
Руководство по Kanban для Scrum Teams ‐ это результат сотрудничества между членами
сообщества Scrum.org и лидерами сообщества Kanban. Они вместе стоят за созданием
Руководства по Kanban для Scrum Teams. По их общему мнению совместное применение Kanban и
Scrum будет полезно практикующим специалистам в области профессиональной разработки
продуктов.
Определение Kanban
Kanban (сущ.): стратегия оптимизации потока ценности внутри процесса, который использует
вытягивающую систему с ограничением незавершенной работы и визуализацией.
Оптимизация потока в контексте Scrum требует определения того, что такое поток в Scrum. Scrum
основан на эмпирической теории управления процессами или эмпиризме. Ключом к
эмпирическому управлению процессом является частота цикла прозрачности, инспекции и
адаптации, которую мы также можем описать как Время цикла через цикл обратной связи.
Когда практики Kanban применяются к Scrum, они фокусируют внимание на улучшении потока
через цикл обратной связи; оптимизации прозрачности и частоты инспекции и адаптации как для
продукта, так и для процесса.
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
3
Основные метрики Потока
Когда Scrum Teams используют Kanban, им надо отслеживать четыре основных метрики потока:
● Время цикла: время, прошедшее между началом и завершением работы над рабочим
элементом.
● Возраст рабочего элемента: время между моментом, когда рабочий элемент попал в
систему, и текущим временем. Это относится только к тем элементам, которые еще не
завершены.
Закон Литтла говорит, что для процесса с известной пропускной способностью, чем больше
элементов находятся в работе в каждый момент времени (в среднем), тем больше времени (в
среднем) нужно на их завершение.
Если время цикла слишком большое, то первое, что следует рассмотреть Скрам‐командам ‐ это
возможность уменьшения WIP. Большинство прочих элементов Канбана основаны на взаимосвязи
между незавершенной работой и временем цикла.
Также из закона Литтла следует, что теория потока опирается на эмпиризм, а метрики потока и
данные используются для достижения прозрачности исторических данных о потоке и
последующего использования их в экспериментах по инспекции и адаптации.
Практики Kanban
Следующие четыре практики помогут Scrum Team оптимизировать поток:
● Визуализация потока работ (Workflow)
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
4
● Ограничение Незавершенной работы (WIP)
● Активное управление незавершенными рабочими элементами
● Инспекция и адаптация командного Определения потока работ
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
5
Ограничение Незавершенной работы (WIP)
Незавершенная работа (WIP) ‐ это рабочие элементы, которые Scrum Team начала, но еще не
закончила.
Scrum Team, применяющая Kanban, должна явно ограничивать количество незавершенных рабочих
элементов. Scrum Team может явно ограничить WIP по своему усмотрению, но при этом должна
следовать установленному ограничению.
Основной эффект ограничения WIP в том, что оно создает вытягивающую систему. Вытягивающей
называется система, при которой команда начинает работу (то есть “вытягивает”следующий
рабочий элемент) только тогда, когда ясно, что у нее есть для этого возможность. Когда WIP
становится ниже установленного ограничения, это становится сигналом к началу новой работы.
Нужно отметить, что такой подход отличается от выталкивающей системы, которая требует, чтобы
работа начиналась сразу по запросу.
Ограничение WIP способствует потоку и улучшает самоуправление, фокус, приверженность и
сотрудничество в Scrum Team.
● следить за тем, чтобы рабочие элементы втягивались в Поток работ примерно с той же
скоростью, с которой они покидают его;
● убеждаться, что рабочие элементы не простаивают без необходимости;
● быстро реагировать на заблокированные или ожидающие в очереди рабочие элементы, а
также на те элементы, которые превышают ожидаемое Время цикла Scrum Team (смотри
Ожидаемый уровень обслуживания).
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
6
SLE состоит из двух частей: диапазон времени в днях и соответствующая ему вероятность
(например, 85% рабочих элементов должны быть завершены за восемь дней или быстрее). SLE
должен основываться на исторических данных о Времени цикла Scrum Team, после его расчета
Scrum Team должна сделать его открытым и доступным. Если исторических данных для расчета
Времени цикла нет, Scrum Team должна сделать наилучшее предположение, и затем
инспектировать и адаптировать SLE как только появится достаточно исторических данных для его
правильного расчета.
Sprint
Дополнителняющие практики Kanban не отменяют необходимости Sprint в Scrum. Sprint и его
события предоставляют возможность для инспекции и адаптации как продукта, так и процесса.
Распространённое заблуждение состоит в том, что команды могут поставлять ценность только один
раз за спринт. На самом деле, Scrum Team должна поставлять ценность по крайней мере один раз
за Sprint. Команды, практикующие Scrum с Kanban, совместно инспектируют и адаптируют
Определение потока работ и метрики потока, используя для улучшения Sprint и события Sprint как
циклы обратной связи.
Практики Kanban могут помочь Scrum Team улучшить поток и создать среду, в которой решения
принимаются в течение Sprint точно‐в‐срок на основе инспекции и адаптации. В такой среде для
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
7
оптимизации ценности, поставляемой за Sprint, Scrum Team полагается на Sprint Goal и тесное
сотрудничество внутри Scrum Team.
Sprint Planning
Встреча Sprint Planning с ориентацией на поток опирается на метрики потока для поддержки
создания Sprint Backlog. Обзор исторических данных о пропускной способности может помочь
Scrum Team понять свою ёмкость на следующий Sprint.
Daily Scrum
Daily Scrum с ориентацией на поток фокусирует внимание Разработчиков на поддержании
стабильного потока. Цель Daily Scrum остаётся той же, как и в Руководстве по Scrum, при этом сама
встреча проводится перед Kanban доской и фокусируется на нарушениях потока и на поиске путей
исправления этого силами самих разработчиков.
Во время Daily Scrum с ориентацией на поток полезно обращать внимание на следующее:
● Какие рабочие элементы заблокированы и что можно сделать, чтобы их разблокировать?
● Какая работа течёт медленнее, чем планировалось? Каков возраст незавершенных рабочих
элементов? Какие рабочие элементы уже нарушили SLE или близки к тому, чтобы его
нарушить, и что может сделать Scrum Team, чтобы такая работа была завершена?
● Есть ли факторы, которые могут повлиять на нашу возможность закончить работу сегодня,
но отсутствуют на доске?
● Узнали ли мы что‐то новое, что может изменить планы Scrum Team о том, над чем работать
дальше?
Sprint Review
Событие Sprint Review описано в Руководстве по Scrum. Инспекция метрик потока во время Sprint
Review может инициировать дополнительные обсуждения прогресса в направлении Product Goal,
а сведения о пропускной способности могут дать дополнительную информацию для Product Owner
при обсуждении вероятных дат поставки.
Sprint Retrospective.
Sprint Retrospective с ориентацией на поток добавляет инспекцию метрик потока и аналитики для
поддержки решения о том, какие именно улучшения Scrum Team может внести в свои процессы.
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
8
Scrum Team, использующая Kanban, также анализирует Определение потока работ для его
оптимизации потока в следующем Sprint. Для визуализации незавершенной работы и
приблизительных средних времени цикла и пропускной способности может быть полезна
накопительная диаграмма потока (Cumulative Flow Diagram ‐ CFD).
В дополнение к Sprint Retrospective Scrum Team следует постоянно искать возможности для
инспекции и адаптации, используя их в момент появления по ходу Sprint.
Аналогичным образом, Scrum Team может в любой момент внести изменения в свое Определение
Потока. Поскольку эти изменения могут иметь значимое влияние на производительность Scrum
Team, изменения, сделанные в рамках ритма, задаваемого Sprint Retrospective, уменьшают
сложность процессов и улучшают сфокусированность, приверженность и прозрачность.
Increment
Scrum требует от команды создания (как минимум) имеющего ценность и пригодного к
использованию Increment каждый Sprint. Чтобы обеспечить быстрые циклы обратной связи для
инспекции и адаптации эмпиризм Scrum побуждает создавать несколько Increment за время Sprint.
Kanban помогает более явно управлять потоком через такие циклы обратной связи и позволяет
Scrum Team выявить узкие места, ограничения и препятствия, что делает поставку ценности более
быстрой и более непрерывной.
Заключение
Scrum ‐ это не процесс или техника. Это фреймворк, в рамках которого люди могут решать
сложные адаптивные проблемы, продуктивно и творчески создавая продукты максимально
возможной ценности. Как указывает Руководство по Scrum, он хорошо работает как контейнер для
других техник, методологий и практик.
История и благодарности
Применение Kanban в контексте креативного интеллектуального труда берет начало в 2006 году в
одной из команд Corbis ‐ компании из Сиэтла, которая работает в сфере лицензирования СМИ. Эти
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
9
практики быстро распространились внутри большого и разнообразного международного
сообщества, которое все эти годы продолжает улучшать и развивать этот подход.
Особая благодарность Glaudia Califano, Louis‐Philippe Carignan, Charles Bradley, Jose Casal, Andy
Hiles, Jesse Houwing и Julia Wester за их вклад. Мы также выражаем благодарность всем
практикам, которые в прошлом внесли свой вклад в то, чтобы Kanban стал жизнеспособной и
успешной стратегией lean‐agile.
Команда переводчиков
Это руководство было переведено с оригинальной английской версии командой переводчиков.
Состав команды:
© 2021 Scrum.org. Offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Kanban Guide for Scrum Teams, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐
Alike license of Creative Commons.
10