В этой части урока мы рассмотрим, как команда разработки использует Kanban в рамках agile-подхода
Kanban - это гибкая методология управления проектами, которая помогает командам максимально эффективно организовать свой рабочий процесс.
Teamlead Артур: На проекте рассматриваем использование Kanban в дополнение к Scrum. Scrum хорош, но не всегда подходит для всех задач, особенно если требуется более гибкий подход к управлению потоком работ.
Аналитик Тамара: Почему Kanban может быть более предпочтительным для некоторых наших задач, Артур?
Teamlead Артур: В отличие от Scrum, Kanban позволяет нам адаптироваться к изменениям в реальном времени и управлять задачами без жестких временных рамок спринтов, что делает процесс более гибким и непрерывным.
Аналитик Тамара: Понятно, это может действительно помочь на стримах разработки, где приоритеты быстро меняются или требуется непрерывная доставка функционала.
Методология Kanban
Kanban - это методология визуального управления проектами, которая использует доску с карточками для отображения работы команды. Каждая карточка представляет отдельную задачу, а доска разделена на колонки, которые показывают разные стадии процесса выполнения задач. Это помогает команде видеть текущий прогресс и эффективно управлять рабочими процессами.
Хотя методика Kanban зародилась более 50 лет назад, она невероятно популярна среди современных Agile- и DevOps-команд разработчиков. В конце сороковых годов XX века компания «Тойота» начала использовать модель заполнения полок в супермаркетах, чтобы оптимизировать технологический процесс. Супермаркеты выставляют ограниченное количество товаров, которого при этом достаточно для удовлетворения потребительского спроса. Таким образом оптимизируется поток товаров между супермаркетом и потребителем. Если уровень запасов соответствует потребительскому спросу, значительно увеличивается эффективность управления складом, ведь избыточных запасов — которые тоже нужно где-то хранить — становится меньше. При этом супермаркет по-прежнему гарантирует, что нужный потребителю товар всегда есть в наличии.
Компания «Тойота» применила эту систему в своих цехах, чтобы лучше соотнести внушительные складские запасы и реально используемые в производстве материалы. Для отслеживания объемов производства в цехе (и взаимодействия с поставщиками) в режиме реального времени использовалась специальная карточка, или Kanban, которую рабочие передавали между командами. Когда в корзине заканчивались используемые на участке производства материалы, на склад передавали Kanban с указанием необходимого материала, нужного количества и т. д. На складе уже стояла новая корзина с этим материалом: ее отправляли в цех, а складские работники отсылали поставщику свой Kanban. У поставщика корзина с этим материалом тоже была готова, и он отправлял ее на склад. Конечно, в современном мире сообщения передаются совсем не так, как в сороковых, но смысл остается тем же — все основано на процессе «своевременного» производства (JIT).
Kanban подчеркивает непрерывный поток работы, где задачи постоянно перемещаются от начала к завершению. Это позволяет команде фокусироваться на текущих задачах, минимизируя время простоя и повышая производительность.
Главные принципы Kanban:
- Визуализация работы: Отображение всех задач на доске Kanban помогает команде лучше понимать рабочий процесс и видеть общую картину.
- Ограничение количества задач: Установление пределов на количество задач в каждой колонке помогает избежать перегрузки команды и ускоряет выполнение работы.
- Управление потоком: Контроль за тем, как задачи перемещаются по доске, обеспечивает непрерывный и балансированный поток работы.
- Непрерывное улучшение: Регулярный анализ и оптимизация рабочего процесса способствует повышению эффективности команды.
Kanban-доски
Работа kanban-команд строится вокруг kanban-доски, которая используется для визуализации и оптимизации рабочего процесса. Хотя некоторые команды предпочитают реальные доски, виртуальные доски давно стали обязательной функцией любого инструмента agile-разработки ПО: с ними проще отследить процессы, организовать совместную работу и доступ из разных мест.
Доски нужны, чтобы визуализировать работу команды, стандартизировать процесс, а также найти и устранить блокеры и зависимости. И не важно, в какой форме они представлены — в физической или в цифровой. На стандартной Kanban-доске процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако доску можно настроить в соответствии с процессом, принятым в той или иной команде, в зависимости от ее размеров, структуры и целей.
Методология Kanban основана на полной прозрачности работы и обсуждении производительности в режиме реального времени. Поэтому доска Kanban должна стать единственным достоверным источником информации о работе команды.
Kanban-карточки
В переводе с японского Kanban дословно означает «визуальный сигнал». У команд, использующих Kanban, каждая рабочая задача представлена в виде отдельной карточки на доске.
Зачем отображать работу в виде карточки на Kanban-доске? Благодаря такому наглядному представлению членам команды будет проще и удобнее отслеживать жизненный цикл рабочих задач. На Kanban-карточках отображается важная информация о конкретной рабочей задаче, доступная всей команде: имя ответственного за выполнение задачи, краткое описание выполненной работы, оценка необходимого времени и т. д. На виртуальных Kanban-досках в карточки также часто добавляют снимки экрана и другие важные для исполнителя технические детали. Когда все члены команды видят состояние каждой рабочей задачи в любой момент времени, а также всю связанную с ней информацию, повышается концентрация, обеспечивается полная прозрачность, быстрее выявляются блокеры и зависимости.
Kanban vs Scrum
Когда в Scrum команда работает по спринтам, она фокусируется на заранее определенном наборе задач. Но что происходит, если появляется срочная новая задача в середине спринта?
Есть два варианта: отложить эту задачу до следующего спринта или попытаться включить её в текущий. В первом случае заказчик должен будет подождать, что может не устроить его из-за срочности. Во втором случае, беря новую задачу в работу, команда рискует не успеть выполнить запланированные задачи, что приведёт к нарушению графика и возможно неполному инкременту продукта.
В этом контексте Kanban предлагает альтернативное решение. Kanban позволяет команде быть гибкой и адаптироваться к меняющимся приоритетам, не придерживаясь жёсткого плана спринта. Это достигается за счёт визуализации всех задач на доске Kanban и установления ограничений на количество одновременно выполняемых задач. Таким образом, если появляется новая срочная задача, команда может быстро переориентироваться и взять её в работу, не жертвуя другими важными задачами. Это обеспечивает большую гибкость и способность адаптироваться к меняющимся условиям, что является ключевым преимуществом Kanban в динамичной среде разработки.
Сравнение Scrum и Kanban
| Scrum | Kanban | |
|---|---|---|
| График | Регулярные спринты фиксированной продолжительности (например, 2 недели) | Непрерывный процесс |
| Подходы к релизу | В конце каждого спринта после одобрения владельцем продукта | Поставка выполняется непрерывно или на усмотрение команды |
| Роли | Владелец продукта, Scrum-мастер, команда разработчиков | Ролей нет, в некоторых командах работают тренеры по agile |
| Ключевые показатели | Скорость команды | Продолжительность цикла |
| Отношение к изменениям | В ходе спринта команды стремятся избегать изменений в прогнозах спринта: изменения приведут к неверным выводам относительно оценки задач | Изменение может произойти в любой момент |
Некоторые команды объединяют идеалы Scrum и Kanban в Scrumban. Из Scrum берут роли и спринты фиксированной длительности, а из Kanban — ориентацию на время цикла и лимиты незавершенной работы. Но если ваша команда только начинает использовать Agile, мы настоятельно рекомендуем выбрать одну методологию и некоторое время следовать только ей. Поэкспериментировать вы всегда успеете.
Преимущества Kanban
На сегодняшний день Kanban — одна из самых популярных методологий разработки ПО, используемых agile-командами. Kanban предоставляет командам любых размеров ряд дополнительных преимуществ, касающихся планирования задач и обеспечения производительности.
Гибкость планирования
Kanban-команда концентрируется только на текущей работе. По завершении рабочей задачи команда забирает следующую задачу с верха бэклога. Владелец продукта может менять приоритет задач в бэклоге, не мешая работе команды, поскольку изменения происходят за пределами текущих рабочих задач. Если владелец продукта следит, чтобы наверху бэклога были самые важные рабочие задачи, команда разработчиков будет гарантированно поставлять максимально ценный продукт бизнесу. Таким образом, необходимости в спринтах фиксированной длительности, используемых в методике Scrum, просто нет.
Опытные владельцы продуктов обязательно привлекают команду разработчиков к изменениям в бэклоге. Например, если в бэклоге описаны пользовательские истории 1–6, оценка пользовательской истории 6 может быть основана на завершении пользовательских историй 1–5. Во избежание неприятных сюрпризов все изменения лучше согласовывать с командой разработчиков.
Сокращение времени цикла
Продолжительность цикла — ключевой показатель для Kanban-команд. Под продолжительностью цикла понимается время прохождения рабочей задачей жизненного цикла, от начала работы над задачей до ее поставки. Оптимизировав продолжительность цикла, в будущем команда сможет с уверенностью предсказывать срок поставки задач.
Если теми или иными навыками обладает несколько человек, продолжительность цикла сокращается, если же только один — в рабочем процессе появляется узкое место. Именно поэтому команды стремятся делиться знаниями и внедряют такие практики, как проверка кода и наставничество. Благодаря обмену знаниями участники команды могут выполнять разнообразные задачи, что еще больше оптимизирует время цикла. Это также означает, что в случае возникновения узкого места в работе вся команда сможет взяться за него и восстановить нормальное течение процесса. К примеру, тестирование не всегда выполняют только инженеры по тестированию. Разработчики тоже могут поучаствовать.
В методологии Kanban все члены команды отвечают за то, чтобы рабочие процессы протекали без сучка, без задоринки.
Меньше узких мест
Многозадачность убивает эффективность. Чем больше незавершенных задач, тем чаще приходится переключаться между ними, а это сказывается на сроках их завершения. Поэтому ключевой принцип Kanban состоит в ограничении объема незавершенной работы (WIP). Лимиты незавершенной работы позволяют быстро находить в работе команды узкие и проблемные места, вызванные нехваткой внимания, людей или навыков.
К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода можно установить лимит WIP, равный 2. Число может показаться маленьким, но на все есть свои причины: разработчики предпочитают писать собственный код, а не проверять чужой. Низкий лимит стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода. В конечном итоге это сокращает общее время цикла.
Наглядность
Одна из основных ценностей — предельное внимание к повышению эффективности команды с каждой рабочей итерацией. Графики — это визуальное средство, позволяющее командам не останавливаться на достигнутом. Если у всей команды есть доступ к данным, проще заметить (и устранить) узкие места в процессе. Kanban-команды часто используют два общих отчета: графики управления и совокупного потока.
На графике управления отображается продолжительность цикла выполнения каждой задачи, а также скользящее среднее для всей команды.
Подсказка: цель команды — сократить время прохождения задачи по этапам рабочего процесса. Если среднее время цикла на контрольном графике снижается, то команда на верном пути.
На сводной диаграмме процесса отображается количество задач в каждом состоянии. Выявить проблемные места несложно: если число задач увеличивается на одном из этапов, значит, что-то идет не так. Промежуточные состояния, такие как «В работе» или «На проверке», указывают на то, что задача еще не поставлена клиенту. Если таких задач становится все больше и больше, повышается вероятность серьезных конфликтов при интеграции в процессе слияния кода.
Резюме
Kanban в рамках agile позволяет команде разработки эффективно управлять своими проектами, делая работу более организованной и прозрачной. Эта методология помогает ускорить процесс выполнения задач и улучшить координацию внутри команды. Использование Kanban в agile обеспечивает гибкость, позволяя команде быстро адаптироваться к изменениям и оптимизировать свои рабочие процессы. Такой подход способствует не только повышению производительности, но и создает более мотивированную и сфокусированную рабочую среду.