Методики SCRUM и KANBAN в разработке цифровых продуктов
Меня зовут Фёдор Гвоздев, я основатель веб агентства Onecommerce. Работаю с командами разработчиков на протяжении десяти лет и знаю, как организовать работу digital проектов. Большая часть моего опыта в работе с различными командами были основаны на системе гибкого управления Agile. Но внедрить Agile недостаточно. Важно применять её непосредственно в самом планировании. В этой статье я расскажу об опыте использования agile-методик Scrum и Kanban в своих проектах.
Agile – это система ценностей, философия, на основе которой были созданы совокупности методов и практик гибкого управления. При работе в рамках её принципов команда становится более слаженной, учится быстро принимать решения и систематизировать рабочие процессы. Всё это достигается за счёт использования специальных инструментов для организации и ведения проектной деятельности.
С момента появления философии она обросла множеством методов для внедрения Agile в работу команды.
Scrum и Kanban – это две самые популярные методики для осуществления принципов идеологии «гибкого управления».Такие компании как Facebook, Amazon, Apple, Netflix и Google давно пользуются ими в сфере разработки.
Оба фреймворка нацелены на улучшение продукта и оптимизацию всех организационных процессов. Однако между ними есть принципиальные отличия.
KANBAN – визуализация задач и непрерывное совершенствование
Методика Kanban основывается на наглядном иллюстрировании всех процессов. Команды такого типа стремятся сократить время выполнения проекта и ограничить незавершенную работу.
Визуализация в Kanban реализуется через главный отличительный инструмент этого фреймворка — Kanban-доску.
Элементы Kanban-доски
Kanban-доска состоит из карточек с задачами и столбцами. Такой тип визуализации помогает просто и понятно систематизировать задачи, а также отслеживать выполнение работы.
- Визуальные сигналы. Первое, что бросается в глаза, смотря на доску — это обилие карточек. Каждая из них вносится командой и обозначает одну задачу. По мере выполнения они продвигаются по столбцам — этапам разработки. Для Agile-команд одна карточка обозначает одну пользовательскую историю – задание на разработку.
Столбцы. Весь рабочий процесс на доске разбит на этапы. Для каждого из которых есть своя колонка с карточками. В составлении и наполнении Kanban-доски нет правил, поэтому свои столбцы, как их количество вы можете определять самостоятельно. Они могут иметь как самые простые значения – «предстоит сделать», «в разработке», «завершено», так и разбивать каждый этап на несколько более детальных.
- Ограничение незавершенной работы (WIP). Ключевой аспект в работе с доской. Для каждого столбца команда устанавливает лимит по карточкам. Например, в столбце «разработка» количество пользовательских историй равно лимиту. Значит команде необходимо приложить максимальные усилия для того, чтобы освободить очередь для перехода других задач в эту колонку.
Точка принятия обязательств — точка начала работы над задачей из бэклога. Важным элементом рядом с доской является уже приоритизированный бэклог. Команда и иные участники проекта выбирают из него задачи по уровню приоритетности и начинают работу над ними.
- Точка поставки продукта — точка завершения работы над проектом. Этот элемент непосредственно относится к крайнему столбцу. Он означает окончание проекта и его сдачу клиенту.
Доску можно вести виртуально или сделать физический вариант, разместив его прямо в офисе. Выбор зависит лишь от удобства для команды.
Принципы Kanban
Метод отличается непрерывностью потока работы и поставки продукта. Эти особенности обеспечиваются за счет визуализации и использования WIP - ограничения незавершенной работы. Команда фокусируется на непрерывности работы, при этом не выполняет больше, чем может. Такой подход обеспечивает поэтапное выполнение и соблюдение приоритизации.
Целью Kanban-команды является сокращение времени прохождения одной карточкой пути от точки принятия обязательств до точки поставки продукта. Всю продуктивность участники проекта направляют на то, чтобы снизить это время до минимума и сохранить качество продукта.
Здесь отсутствуют дедлайны и определённые сроки. Обновления задач происходят по мере готовности. Для выпуска продукта нет необходимости в собрании или оценке.
Так как в этом подходе нет четко регламентированных ролей, любой вправе вносить изменения – продвигать, блокировать или удалять карточки.
Опыт внедрения
В своей работе мы использовали цифровую версию доски, созданную в Trello. Это наиболее удобно нашем в случае, когда в команде часть сотрудников работает удаленно.
На тот момент система Kanban в нашей компании применялась разово для исключительных проектов. Но было принято решение использовать её для всех задач, так как методика показала себя эффективно.
Задачей было – развитие и оптимизация каталога товаров в интернет-магазине. Весь процесс мы разбили на несколько этапов, включающих анализ, создание дизайна и разработку. Визуализировав и приоритизировав задачи, мы смогли добиться высокой скорости выполнения задач. Этапы стали наглядны, а более ранний опыт применения метода Kanban позволил не тратить время на адаптацию команды к новому подходу.
Гибкая система помогала вносить правки сразу и предотвращать более серьёзные последствия.
SCRUM. Искусство создавать рабочие циклы
Scrum – гибкая методология планирования разработки. Весь проект делится на спринты – равные по времени этапы работы. Scrum-команды нацелены на предоставление промежуточного продукта (инкремента) в конце каждого спринта. Готовая часть работы оценивается, корректируется и только после этого команда приступает к новому этапу. На протяжении всего проекта Scrum-мастер отслеживает следовании методологии.
Роли в модели Scrum
В отличие от Kanban, Scrum предусматривает наличие ролей.
- Команда разработчиков – разрабатывают продукт и предоставляют инкременты по окончанию спринта.
- Scrum-мастер – регулирует работу команды, участвует в оценке промежуточного продукта и проводит собрания.
- Владелец продукта – представляет интересы заказчика, помогает команде в приоритизации бэклога и оценке промежуточного продукта.
Однако так как Scrum является частью Agile здесь нет единого центра управления. Следуя философии, в Scrum работает самоорганизация и единая ответственность.
Принципы Scrum
Деление работы на этапы способствует повышению скорости реализации продукта.
Предоставление инкремента в конце каждого спринта позволяет производить поэтапную оценку и избежать внушительной платы за ошибки. Разбитые на части задачи легче выполнить, сотрудники не перегружены и более мотивированы.
Непрерывная коммуникация с владельцем продукта помогает лучше понять ожидания от готового продукта и максимально воплотить их.
Цель работы кросс-функциональной команды – качественный продукт, удовлетворяющий заказчика. Этот показатель и есть главный критерий оценки. Однако в рамках ретроспектив возможно внедрение оценки показателей скорости. Концепция таких встреч позволяет обсуждать ошибки и находить причины снижения эффективности команды.
Инструменты и этапы
Инструментами в модели Scrum являются:
- Инкремент — промежуточный продукт, предоставляемый командой в конце каждого спринта. Без удовлетворительной оценки этого элемента невозможен переход к следующему спринту.
Бэклог продукта — формируется владельцем продукта до начала разработки. На его основе собирается бэклог спринта.
Бэклог спринта — задачи отобранные из бэклога продукта для предстоящего спринта. Формируется владельцем продукта и командой при участии Scrum-мастера.
В рамках спринта есть три основных собрания команды, Scrum-мастера и владельца продукта. Они по содержанию они делятся на:
- Собрания по планированию спринта — отбор задач на один этап.
- Собрания по итогам спринта — оценка инкремента.
- Ретроспективы – встречи команды для обсуждения достижений и неудач за прошедший период после сдачи полностью готового продукта.
Кроме основных встреч регулярными являются ежедневные scrum-совещания. Они не должны занимать более 15-20 минут и направлены на формирование ежедневных целей.
Опыт внедрения
В нашей компании мы начали трансформировать планирование в сторону Agile еще несколько лет назад. Попробовав применить Kanban-доску, увидели, что концепция гибкого управления эффективна в нашей команде.
Нужно было идти дальше. Scrum оказался более сложным инструментом для внедрения.
Мы столкнулись с проблемами:
- Было трудно организовывать регулярные встречи. Сначала не все понимали их смысл. Вместо коротких собраний, нацеленных на оповещение команды о проделанной работе и освещении возникших проблем, на первых этапах собрания перерастали в длинные сессии, с перечислением всего, что и как было сделано, обсуждением новых идей – что делало собрания неэффективными.
- Планирование спринтов также занимало много времени. Грамотно разделить весь проект на равносильные этапы было для нас в новинку.
В течение месяца команда училась работать по новой методике. Scrum-команде понадобилось время, чтобы полностью понять и привыкнуть к своим ролям, задачам и основным принципам.
Scrum помог нам внести ясность в работу коллектива. Сотрудники лучше стали понимать принципы новой концепции, ведь они стали применять их на практике. Команда стала работать эффективнее и быстрее исправлять ошибки.
Scrum или Kanban?
Выбрать более подходящий фреймворк можно только путём проб и ошибок. Стоит попробовать обе модели на практике. Но мы всё же проанализируем эти подходы.
Обе методики соответствуют философии Agile. Добавлять элементы подхода Scrum или Kanban стоит поэтапно и смотреть, что лучше подходит именно вашей команде.
Мы в своей работе совмещаем оба инструмента – используем Kanban и Scrum, в зависимости от команды и проекта.
Пробуйте, внедряйте и совершенствуйте свою работу!