25% от каждого билета мы отправляем в фонд Car4Life
24 мая, 2018 | 2253 | 5.0  5.0

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

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

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

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

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

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

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

Немного о досках и карточках Kanban и Scrum

Доска — это один из основных инструментов Kanban- и Scrum-разработки. Она помогает планировать задачи, устанавливать ограничения, делает проект прозрачнее в силу наглядности.

Доски бывают физические и виртуальные. Физическая доска Kanban (на рисунке ниже) вешается на стену, для создания виртуальных используются планировщики задач. Самые популярные — Trello и JIRA, но есть также более узкоспециализированные инструменты Kanban, которые могут лучше подходить под задачи вашей конкретной команды: Hygger, MeisterTask, Asana, Favro, Paymo, Kanbachi, Blossom, Breeze, Taiga, ZenHub, ProofHub, LeanKit. Разбираемся в Scrum и Kanban

Что такое карточки Kanban?

Карточки — это физические или виртуальные стикеры, на которых прописываются задачи, чаще всего в форме пользовательских историй с описанием, весом (в стори поинтах) и приоритетом.

Принцип работы с доской таков:

  • на доску добавляют столбцы, визуализирующие этап, на котором находится задача (“Концепция”, “Дизайн”, “Разработка”, “Тестирование”, “Релиз” или другие);
  • в столбцы вклеивают (или вносят онлайн) карточки Kanban. Когда задача переходит из одного этапа в другой, карточку переносят в другой столбец.

Все просто. Благодаря доске с карточками Kanban с первого взгляда понятно, каковы успехи команды в этом спринте.

Применение канбана в скраме

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

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

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

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

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

Следующий шаг после визуализации потока — применение канбан-системы. На практике это — ограничение допустимого количества незавершенной работы.

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

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

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

С этим им поможет грамотное применение acceptance test-driven development (дословно — разработка через приёмочное тестирование, ATDD), уменьшение размера и количества элементов бэклога в спринте, а также взаимное обучение. Со временем, когда команда разовьет еще большие способности, можно будет устанавливать ей новые неудобные пределы незавершенной работы и добиваться еще большей результативности. Ограничение Work in Process — эффективный способ усилить сотрудничество в команде.

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

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

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

Можно использовать кумулятивные диаграммы потока — они станут неплохим дополнением бернап-чартов. Скрам-команда может также искать возможности уменьшить время поступления работы в продакшен. Скрам регламентирует разработку в пределах спринта. Намеченная работа должна быть готова до конца спринта, но при работе еще и над потоком команда ищет пути выпускать работу сразу по готовности. В Руководстве по скраму не сказано, что обязательно нужно ожидать завершения спринта. Похожая точка зрения изложена в статье об обзоре спринта на Scrum.org.

psk3

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

Чем прозрачнее процесс, тем больше уверенности. Канбан помогает скрам-командам добавить прозрачности не только в работу, но и в сам процесс. Когда участники и участницы команд четко понимают процесс, им проще саморганизовываться (примеры использования канбан + скрам вы найдете в книге Дэвида Марке 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

Тренинг

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

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

Статьи

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

Книги

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

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