Руководство по Kanban для Scrum Teams - AWS

Руководство по Kanban для Scrum TeamsЯнварь2021

Разработано и поддерживается Scrum.org, Daniel Vacanti, and Yuval Yeret

© 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

Содержание Для чего это руководство 3

Отношение к Руководству по Scrum 3

Определение Kanban 3

Kanban и теория Scrum 3

Поток и эмпиризм 3

Основные метрики Потока 4

Закон Литтла – ключ к управлению потоком 4

Практики Kanban 4

Определение потока работ 5

Визуализация потока работ – Kanban доска 5

Ограничение Незавершенной работы (WIP) 6

Активное управление незавершенными рабочими элементами 6

Ожидаемый уровень обслуживания 6

Инспекция и адаптация Определения потока работ 7

События Scrum c точки зрения потока 7

Sprint Planning 8

Daily Scrum 8

Sprint Review 8

Sprint Retrospective. 8

Increment 9

Заключение 9

История и благодарности 9






3

Для чего это руководство

Рассматривая систему как поток, Kanban‐метод может дополнить и улучшить фреймворк Scrum и

его реализацию. Команды могут применять практики Kanban как в самом начале использования

Scrum, так и по мере накопления опыта.

Руководство по Kanban для Scrum Teams ‐ это результат сотрудничества между членами

сообщества Scrum.org и лидерами сообщества Kanban. Они вместе стоят за созданием

Руководства по Kanban для Scrum Teams. По их общему мнению совместное применение Kanban и

Scrum будет полезно практикующим специалистам в области профессиональной разработки

продуктов.

Отношение к Руководству по Scrum

Настоящее руководство не заменяет и не обесценивает какую‐либо часть Руководства по Scrum.

Оно предназначено для улучшения и расширения практик Scrum. В этом Руководстве

предполагается, что читатель управляет процессом, используя фреймворк Scrum. Таким образом,

Руководство по Scrum применяется в полном объеме.

Определение Kanban

Kanban (сущ.): стратегия оптимизации потока ценности внутри процесса, который использует

вытягивающую систему с ограничением незавершенной работы и визуализацией.

Kanban и теория Scrum

Поток и эмпиризм

Центральное место в определении Kanban занимает концепция потока (flow). Поток‐ это

движение ценности через систему разработки продукта. Kanban оптимизирует поток за счет

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

Оптимизация потока в контексте Scrum требует определения того, что такое поток в Scrum. Scrum

основан на эмпирической теории управления процессами или эмпиризме. Ключом к

эмпирическому управлению процессом является частота цикла прозрачности, инспекции и

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

Когда практики Kanban применяются к Scrum, они фокусируют внимание на улучшении потока

через цикл обратной связи; оптимизации прозрачности и частоты инспекции и адаптации как для

продукта, так и для процесса.






4

Основные метрики Потока

Когда Scrum Teams используют Kanban, им надо отслеживать четыре основных метрики потока:

● Незавершенную работу (WIP): количество рабочих элементов, работа над которыми

начата, но ещё не завершена. Команда может использовать метрику WIP, чтобы

обеспечить прозрачность своего прогресса в сокращении WIP и улучшении своего потока.

Обратите внимание, что существует разница между метрикой WIP и правилами, которые

Scrum Team использует для ограничения WIP.

● Время цикла: время, прошедшее между началом и завершением работы над рабочим

элементом.

● Возраст рабочего элемента: время между моментом, когда рабочий элемент попал в

систему, и текущим временем. Это относится только к тем элементам, которые еще не

завершены.

● Пропускную способность: количество рабочих элементов, завершенных за единицу

времени.

Закон Литтла – ключ к управлению потоком

В основе теории управления потоком лежит закон Литтла:

Среднее время цикла Среднее количество незавершенной работы

Средняя пропускная способность

Закон Литтла говорит, что для процесса с известной пропускной способностью, чем больше

элементов находятся в работе в каждый момент времени (в среднем), тем больше времени (в

среднем) нужно на их завершение.

Если время цикла слишком большое, то первое, что следует рассмотреть Скрам‐командам ‐ это

возможность уменьшения WIP. Большинство прочих элементов Канбана основаны на взаимосвязи

между незавершенной работой и временем цикла.

Также из закона Литтла следует, что теория потока опирается на эмпиризм, а метрики потока и

данные используются для достижения прозрачности исторических данных о потоке и

последующего использования их в экспериментах по инспекции и адаптации.

Практики Kanban Следующие четыре практики помогут Scrum Team оптимизировать поток:

● Визуализация потока работ (Workflow)






5

● Ограничение Незавершенной работы (WIP)

● Активное управление незавершенными рабочими элементами

● Инспекция и адаптация командного Определения потока работ

Определение потока работ

Четыре практики Kanban поддерживаются Определением потока работ Scrum Team. Определение

потока работ ‐ это явно выраженное понимание членами Scrum Team того, какие правила они

используют для следования практикам Канбан. Такое общее понимание повышает прозрачность и

поддерживает самоуправление.

При этом содержание Определения потока работ может выходить за рамки Sprint и Sprint Backlog.

Например, Определение потока работ Scrum Team может охватывать поток внутри или за рамками

Sprint.

Ответственными за создание и изменение Определения потока работ являются соответствующие

роли Scrum Team как описано в Руководстве по Scrum. Никто за пределами Scrum Team не может

указывать Scrum Team как определять свой поток работ.

Визуализация потока работ – Kanban доска

Визуализация с помощью Kanban доски является способом, с помощью которого Scrum Team делает

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

своевременному обсуждению необходимых вопросов и способствовать раннему выявлению

возможностей для улучшения.

Визуализация должна включать следующее:

● Явно определённые точки, в которых Scrum Team начинает и заканчивает работу.

● Определение рабочих элементов ‐ отдельных единиц ценности (ценность для

стейкхолдеров, ценность в получении знания, ценность в улучшении процесса),

проходящих через Scrum Team (вероятнее всего, это элементы Product Backlog (PBIs)).

● Определение потока работ говорит о том, что рабочие элементы проходят от начала до

конца (между которыми должно быть хотя бы одно активное состояние).

● Явные правила о том, как именно работа проходит через каждое состояние (могут включать

элементы из определения готовности Scrum Team и правила вытягивания рабочих

элементов из одного этапа работы в другой).

● Правила ограничения Незавершенной работы (WIP).






6

Ограничение Незавершенной работы (WIP)

Незавершенная работа (WIP) ‐ это рабочие элементы, которые Scrum Team начала, но еще не

закончила.

Scrum Team, применяющая Kanban, должна явно ограничивать количество незавершенных рабочих

элементов. Scrum Team может явно ограничить WIP по своему усмотрению, но при этом должна

следовать установленному ограничению.

Основной эффект ограничения WIP в том, что оно создает вытягивающую систему. Вытягивающей

называется система, при которой команда начинает работу (то есть “вытягивает”следующий

рабочий элемент) только тогда, когда ясно, что у нее есть для этого возможность. Когда WIP

становится ниже установленного ограничения, это становится сигналом к началу новой работы.

Нужно отметить, что такой подход отличается от выталкивающей системы, которая требует, чтобы

работа начиналась сразу по запросу.

Ограничение WIP способствует потоку и улучшает самоуправление, фокус, приверженность и

сотрудничество в Scrum Team.

Активное управление незавершенными рабочими элементами

Использование ограничения WIP является обязательным для обеспечения непрерывности потока,

но в отрыве от остальных практик не является достаточным. Третья практика для установления

непрерывного потока ‐ это активное управление незавершенными рабочими элементами. Такое

управление, осуществляемое Scrum Team в рамках Спринта, может проявляться, например, в том,

что члены Scrum Team будут:

● следить за тем, чтобы рабочие элементы втягивались в Поток работ примерно с той же

скоростью, с которой они покидают его;

● убеждаться, что рабочие элементы не простаивают без необходимости;

● быстро реагировать на заблокированные или ожидающие в очереди рабочие элементы, а

также на те элементы, которые превышают ожидаемое Время цикла Scrum Team (смотри

Ожидаемый уровень обслуживания).

Ожидаемый уровень обслуживания

Ожидаемый уровень обслуживания (service level expectation ‐ SLE) используется для

прогнозирования времени, которое потребуется рабочему элементу, чтобы пройти от начала до

завершения в рамках Потока работ Scrum Team. Scrum Team использует свой SLE для выявления

проблем потока и для инспекции и адаптации в случае несоответствия уровня обслуживания

ожиданиям.






7

SLE состоит из двух частей: диапазон времени в днях и соответствующая ему вероятность

(например, 85% рабочих элементов должны быть завершены за восемь дней или быстрее). SLE

должен основываться на исторических данных о Времени цикла Scrum Team, после его расчета

Scrum Team должна сделать его открытым и доступным. Если исторических данных для расчета

Времени цикла нет, Scrum Team должна сделать наилучшее предположение, и затем

инспектировать и адаптировать SLE как только появится достаточно исторических данных для его

правильного расчета.

Инспекция и адаптация Определения потока работ

Scrum Team использует существующие события Scrum для инспекции и адаптации Определения

потока работ, тем самым способствуя эмпиризму и оптимизируя поставляемую ценность.

Scrum Team может адаптировать следующие элементы Определения потока работ:

‐ правила визуализации ‐ например, этапы Потока работ рабочих элементов, либо меняя

текущий Поток работ, либо добавляя прозрачности там, где команде необходима

инспекция и адаптация;

‐ правила работы ‐ эти правила могут быть непосредственно направлены на работу с

препятствиями в работе. Например, огромный эффект могут оказать регулировка WIP‐

лимитов и Ожидаемых уровней обслуживания (SLEs) или изменение размера партии (как

часто рабочие элементы вытягиваются из одного этапа работы в другой).

События Scrum c точки зрения потока

Канбан в контексте Scrum не порождает новых событий в дополнение к описанным в Руководстве

по Scrum. В то же время, подход к событиям Scrum с точки зрения потока и использование

потоковых метрик усиливает лежащий в основе Scrum эмпирический подход.

Sprint

Дополнителняющие практики Kanban не отменяют необходимости Sprint в Scrum. Sprint и его

события предоставляют возможность для инспекции и адаптации как продукта, так и процесса.

Распространённое заблуждение состоит в том, что команды могут поставлять ценность только один

раз за спринт. На самом деле, Scrum Team должна поставлять ценность по крайней мере один раз

за Sprint. Команды, практикующие Scrum с Kanban, совместно инспектируют и адаптируют

Определение потока работ и метрики потока, используя для улучшения Sprint и события Sprint как

циклы обратной связи.

Практики Kanban могут помочь Scrum Team улучшить поток и создать среду, в которой решения

принимаются в течение Sprint точно‐в‐срок на основе инспекции и адаптации. В такой среде для






8

оптимизации ценности, поставляемой за 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 о том, над чем работать

дальше?

● Нарушили ли мы WIP‐лимит? И что мы можем сделать, чтобы закончить незавершенную

работу?

Sprint Review

Событие Sprint Review описано в Руководстве по Scrum. Инспекция метрик потока во время Sprint

Review может инициировать дополнительные обсуждения прогресса в направлении Product Goal,

а сведения о пропускной способности могут дать дополнительную информацию для Product Owner

при обсуждении вероятных дат поставки.

Sprint Retrospective.

Sprint Retrospective с ориентацией на поток добавляет инспекцию метрик потока и аналитики для

поддержки решения о том, какие именно улучшения Scrum Team может внести в свои процессы.






9

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‐практики оптимизации потока предоставляют Scrum Team дополнительные возможности

для инспекции правильных вещей в правильное время, и на основе этой инспекции

адаптироваться по мере необходимости. Гиперфокус Kanban на прозрачности, визуализации и

потоке максимизирует обратную связь, эмпиризм и в конечном итоге ‐ поставку ценности.

История и благодарности

Применение Kanban в контексте креативного интеллектуального труда берет начало в 2006 году в

одной из команд Corbis ‐ компании из Сиэтла, которая работает в сфере лицензирования СМИ. Эти






10

практики быстро распространились внутри большого и разнообразного международного

сообщества, которое все эти годы продолжает улучшать и развивать этот подход.

Это руководство было разработано совместно Scrum.org, его Сообществом профессиональных

тренеров, Стивом Портером, Ювалем Йеретом и Даниэлем Ваканти.

Особая благодарность Glaudia Califano, Louis‐Philippe Carignan, Charles Bradley, Jose Casal, Andy

Hiles, Jesse Houwing и Julia Wester за их вклад. Мы также выражаем благодарность всем

практикам, которые в прошлом внесли свой вклад в то, чтобы Kanban стал жизнеспособной и

успешной стратегией lean‐agile.

Команда переводчиков

Это руководство было переведено с оригинальной английской версии командой переводчиков.

Состав команды:

Гирин Андрей, [email protected], facebook.com/andreigirin

Глинка Виктор, [email protected], https://www.facebook.com/vic.glinka

Господчиков Сергей [email protected], https://www.facebook.com/s.gospodchikov/

Зегнитц Наталия [email protected], https://www.facebook.com/natalia.segnitz/

Ларченко Игорь [email protected], https://www.facebook.com/igor.l.larchenko

Макаркин Сергей, [email protected], https://www.facebook.com/s.b.makarkin/

Румянцев Михаил, [email protected], https://www.facebook.com/mikhail.rumyantsev/

Вязанкин Михаил, [email protected], https://www.facebook.com/m.vyazankin

Руководство по Kanban для Scrum Teams - AWS

Documents

Transcript of Руководство по Kanban для Scrum Teams - AWS