Скрам+Канбан: основы / Скрам и Аджайл Блог 2018

Скрам+Канбан: основы

Скрам+Канбан: основы

 

Недавно Scrum.org опубликовала руководство по Скраму с Канбаном и объявила о запуске сертификации PSK — Professional Scrum with Kanban. На блоге организации появилась серия постов о нововведении от Стива Портера (эксперта Scrum.org и бывшего Владельца Продукта в TeamPulse) и Юваля Ерета (опытного практика Скрама с Канбаном и одного из консультантов AgileSparks, известной нашим подписчикам по выступлениям Одеда Тамира). Приводим несколько важных выдержек из Q&A Юваля и базового руководства по Канбану для Скрам команд, а также список статей, которые рекомендует на эту тему Scrum.org.

Ценности и базовые принципы Канбана

Канбан — это метод, в основе которого лежит система вытягивания (pull system) производства, то есть ограничение на количество незавершенной работы  (work-in-process). Проще говоря, ней все устроено так, чтобы застоявшиеся задачи легко было увидеть и распределить более выгодно для команды. Это позволяет выявлять операционные проблемы и мотивировать сотрудников к улучшениям.  

 

Практикующие Канбан придерживаются нескольких ключевых принципов:

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

 

Если вы уже используете Скрам и хотите добавить некоторые Канбан-практики, эти принципы вам очень пригодятся. Практики Канбана помогают направить эмпирический процесс инспекции и адаптации. При этом они не требуют замены ролей, встреч и артефактов, принятых в Руководстве по Скраму.

Практики Канбана применительно к Скраму

1. Визуализировать (работу, распорядок, риски)

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

 

Помимо этого, для Скрам команды важно следить за продвижением элементов Бэклога Продукта: от создания идеи через ее уточнение, анализ, разработку дизайна, написание кода, тестирование до выпуска — иначе говоря, отслеживать весь путь до “готового”. В Канбане это называют потоком ценности (value stream). То есть важно визуализировать не только Бэклог Спринта (отдельные задачи), но и все продвижение работы на входе и выходе из спринта (элементы Бэклога Продукта) — с последним проблемы у многих команд.

 

Скрам+Канбан: основы

 

2. Ограничивать незавершенную работу (Work in Process)

Следующий шаг после визуализации потока — введение Канбан-системы. На практике это значит ограничить Work in Process, что в контексте Скрама значит ограничивать объем элементов Бэклога Продукта в разные моменты времени. Конечно, команды и так берутся за ограниченное количество задач за спринт. Но можно пойти еще дальше и заложить ограничения по количеству элементов Бэклога на разных этапах внутри одного спринта. Это поможет команде работать еще более сфокусированно и слаженно.

 

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

 

Пределы WIP должны быть достаточно низкими, чтобы создавать некоторое неудобство — они должны подталкивать людей за пределы того, что для них привычно и комфортно. Этим неудобством нужно управлять таким образом,чтобы команды улучшали свои политики и процессы и тем самым уменьшали дискомфорт из-за пределов WIP. Они могут делать это, улучшая практики разработки, используя техники наподобии acceptance test-driven development («разработка через приёмочное тестирование», ATDD), уменьшая размер и количество элементов Бэклога в работе, тренируя другу друга или выполняя другие подобные действия. Со временем, когда команда разовьет еще большие способности, можно устанавливать ей новые неудобные пределы WIP и добиваться еще большей результативности.  Ограничение WIP — эффективный способ усилить сотрудичество в команде.

Скрам+Канбан: основы

3. Управлять потоком

Освоив Канбан-систему с ее пределами WIP, начинайте приводить ее в движение и управлять потоком. Команде нужно отслеживать время цикла элементов Бэклога Продукта, чтобы понимать, что еще можно улучшить. Время цикла — это время, которое проходит, пока элемент передвигается между двумя этапами потока ценности на Канбан-доске. Команда постоянно отслеживает устаревание или застой элементов (например, на Ежедневном Скраме), находит проблемные элементы Бэклога и пытается их продвинуть дальше. Так команда остается сфокусированной на отлаженном рабочем потоке.

 

Можно использовать кумулятивные диаграммы потока — они станут неплохим дополнением бернап-чартов. Скрам команда может также искать возможности уменьшить время поступления работы в продакшен. Скрам регламентирует разработку в пределах спринта — намеченная работа должна быть готова до конца спринта — но при работе еще и над потоком команда ищет пути выпускать работу, как только та готова. В Руководстве по Скраму не сказано, что обязательно нужно ожидать завершения спринта. Похожая точка зрения изложена в  https://www.scrum.org/resources/blog/sprint-review-not-phase-gate.

 

psk3

4. Работать над прозрачностью процесса

Чем более прозрачен процесс, тем больше уверенности. Канбан помогает Скрам командам добавить прозрачности не только в работу, но и в сам процесс. Когда участники_цы команд четко понимают процесс, им проще саморганизовываться (смотрите об этом в книге Дэвмда Марке, David Marquet, Turn the Ship Around! — подход этого автора к лидерству описан здесь).

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

Определение “готового” в Скраме — прекрасный пример прозрачной политики. Сам фреймворк тоже прозрачен: Руководство по Скраму можно считать прозрачно изложенной политикой, которую воплощает Скрам команда. В Канбане команды добавляют и другие политики: предел WIP для каждой линии потока и каждого человека, классы сервисной политики, правила визуализации и обработки затруднений, приоретизация задач.

5. Использовать петли обратной связи

Для обратной связи Скрам команды используют Планирование Спринта, Ежедневный Скрам, Обзор Спринта и Ретроспективу Спринта.

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

Скрам+Канбан: основы

6. Повышать качество через сотрудничество и эксперимент (с научными методами и моделями)

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

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

В этом процессе могут помочь фреймворки вроде A3 / Toyota Kata. Изучите также модели типа  Reinertsen’s principles of product development flow — они (порой с неожиданной точки зрения) раскрывают взаимодействие объема, вариативности и частоты работы, команд, WIP и времени цикла.

 

Скрам+Канбан: основы

Резюме о Канбан-практиках

Здесь описаны главные принципы Канбана и те практики, которые можно применить в контексте Скрама. Большинство из них — более специализированное дополнение к контексту Скрама. Этих улучшений Канбан НЕ требует. Вожможно, вы добьетесь описанных позитивных результатов, применяя Канбан со Скрамом, но этого может и не случиться. Стоит помнить, что Канбан — метод, а не методология.

 

В Руководство по Скраму с Канбаном также не включены такие Канбан-практики, как Classes of Service, Cost of Delay и Flow Efficiency (хотя они упоминаются в курсе Scrum.org): по мнению авторов руководства, они не входят в минимально необходимый Скрам-командам набор практик. Часть их может оказаться более полезной в контексте Скрама, часть — менее, но применять их или нет — решение каждой отдельной команды, когда она уже разберется с основами, изложенными в Руководстве.

Дополнительные вопросы

Можно ли Скрам+Канбан считать примением Канбан-метода?

По мнению Юваля Ерета, одно очень близко к другому, если за основу взята работа по Скраму (в этом контексте читайте пост Юваля 2012 года). Точкой отсчета можно считать ситуацию, в которой команда уже использует Скрам, то есть мы проявляем уважение к уже принятым процессам и ролям Скрама и просто улучшаем эмпирический процесс.

 

Есть утверждение, что ограничение work in process — не эволюционное, а резкое, революционное изменение. Юваль считает, что это и вправду не самый простой переход, но его все еще стоит считать эволюционным по сравнению с изменением структур, ролей и потоков процесса. Профессиональной Скрам команде в любом случае будет легче ограничивать WIP, чем многим другим.

Можно ли это считать Скрамбаном?

Это зависит от того, как определить Скрамбан. Некоторые практики определяют Скрамбан как “способ помочь командам перейти от Скрама к Канбану”. В таком случае Скрам+Канбан — конечно, не то же самое, что Скрамбан.

Другое определение (принятое и Ювалем) такое: Скрамбан — это способ применять принципы Лина и Канбана в процессе Скрама, кардинально не изменяя этот процесс. Такое определение близко к Скраму+Канбану.

Скрамбан можно видеть и как просто сочетание Скрама и Канбана независимо от того, с чего вы начали. И это именно то, что описывает Руководство по Канбану для Скрам команд.

Когда стоит добавить Канбан к Скраму?

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

Когда Канбан не стоит применять со Скрамом?

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

 

Скрам и Канбан

Источники, рекомендуемые Scrum.org

Курс

Материалы для курса

Материалы блогов

Статьи

  • Q&A-сессия с СЕО Scrum.org Дейвом Вестом о применении Скрама с Канбаном
  • Новость о новом курсе Scrum.org

Видео и подкасты

  • Вебинар “Скрам и Канбан: улучшайте команды и избавляйтесь от мифов” (на английском) — слайды к нему
  • Подкаст Стива Портера на английском

Книги

Другие ресурсы

 

Переведено и адаптировано командой BrainRain по материалам:

A Kanban Primer for Scrum Teams

Understanding the Kanban for Scrum Teams Guide

Suggested Reading: Professional Scrum with Kanban

 

ЧИТАЙТЕ ДРУГИЕ СТАТЬИ НАШЕГО БЛОГА

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости