Методики SCRUM и KANBAN в разработке цифровых продуктов

Меня зовут Фёдор Гвоздев, я основатель веб агентства Onecommerce. Работаю с командами разработчиков на протяжении десяти лет и знаю, как организовать работу digital проектов. Большая часть моего опыта в работе с различными командами были основаны на системе гибкого управления Agile. Но внедрить Agile недостаточно. Важно применять её непосредственно в самом планировании. В этой статье я расскажу об опыте использования agile-методик Scrum и Kanban в своих проектах.

Agile – это система ценностей, философия, на основе которой были созданы совокупности методов и практик гибкого управления. При работе в рамках её принципов команда становится более слаженной, учится быстро принимать решения и систематизировать рабочие процессы. Всё это достигается за счёт использования специальных инструментов для организации и ведения проектной деятельности.

С момента появления философии она обросла множеством методов для внедрения Agile в работу команды.

Scrum и Kanban – это две самые популярные методики для осуществления принципов идеологии «гибкого управления».Такие компании как Facebook, Amazon, Apple, Netflix и Google давно пользуются ими в сфере разработки.

Оба фреймворка нацелены на улучшение продукта и оптимизацию всех организационных процессов. Однако между ними есть принципиальные отличия.

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

Визуализация в Kanban реализуется через главный отличительный инструмент этого фреймворка — Kanban-доску.

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

• Визуальные сигналы. Первое, что бросается в глаза, смотря на доску — это обилие карточек. Каждая из них вносится командой и обозначает одну задачу. По мере выполнения они продвигаются по столбцам — этапам разработки. Для Agile-команд одна карточка обозначает одну пользовательскую историю – задание на разработку.

• Столбцы. Весь рабочий процесс на доске разбит на этапы. Для каждого из которых есть своя колонка с карточками. В составлении и наполнении Kanban-доски нет правил, поэтому свои столбцы, как их количество вы можете определять самостоятельно. Они могут иметь как самые простые значения – «предстоит сделать», «в разработке», «завершено», так и разбивать каждый этап на несколько более детальных.

• Ограничение незавершенной работы (WIP). Ключевой аспект в работе с доской. Для каждого столбца команда устанавливает лимит по карточкам. Например, в столбце «разработка» количество пользовательских историй равно лимиту. Значит команде необходимо приложить максимальные усилия для того, чтобы освободить очередь для перехода других задач в эту колонку.

• Точка принятия обязательств — точка начала работы над задачей из бэклога. Важным элементом рядом с доской является уже приоритизированный бэклог. Команда и иные участники проекта выбирают из него задачи по уровню приоритетности и начинают работу над ними.

• Точка поставки продукта — точка завершения работы над проектом. Этот элемент непосредственно относится к крайнему столбцу. Он означает окончание проекта и его сдачу клиенту.

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

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

Целью Kanban-команды является сокращение времени прохождения одной карточкой пути от точки принятия обязательств до точки поставки продукта. Всю продуктивность участники проекта направляют на то, чтобы снизить это время до минимума и сохранить качество продукта.

Здесь отсутствуют дедлайны и определённые сроки. Обновления задач происходят по мере готовности. Для выпуска продукта нет необходимости в собрании или оценке.

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

В своей работе мы использовали цифровую версию доски, созданную в Trello. Это наиболее удобно нашем в случае, когда в команде часть сотрудников работает удаленно.

На тот момент система Kanban в нашей компании применялась разово для исключительных проектов. Но было принято решение использовать её для всех задач, так как методика показала себя эффективно.

Задачей было – развитие и оптимизация каталога товаров в интернет-магазине. Весь процесс мы разбили на несколько этапов, включающих анализ, создание дизайна и разработку. Визуализировав и приоритизировав задачи, мы смогли добиться высокой скорости выполнения задач. Этапы стали наглядны, а более ранний опыт применения метода Kanban позволил не тратить время на адаптацию команды к новому подходу.

Гибкая система помогала вносить правки сразу и предотвращать более серьёзные последствия.

Scrum – гибкая методология планирования разработки. Весь проект делится на спринты – равные по времени этапы работы. Scrum-команды нацелены на предоставление промежуточного продукта (инкремента) в конце каждого спринта. Готовая часть работы оценивается, корректируется и только после этого команда приступает к новому этапу. На протяжении всего проекта Scrum-мастер отслеживает следовании методологии.

В отличие от Kanban, Scrum предусматривает наличие ролей.

• Команда разработчиков – разрабатывают продукт и предоставляют инкременты по окончанию спринта.
• Scrum-мастер – регулирует работу команды, участвует в оценке промежуточного продукта и проводит собрания.
  
• Владелец продукта – представляет интересы заказчика, помогает команде в приоритизации бэклога и оценке промежуточного продукта.
  

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

Деление работы на этапы способствует повышению скорости реализации продукта.

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

Непрерывная коммуникация с владельцем продукта помогает лучше понять ожидания от готового продукта и максимально воплотить их.

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

Инструментами в модели Scrum являются:

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

• Бэклог продукта — формируется владельцем продукта до начала разработки. На его основе собирается бэклог спринта.

• Бэклог спринта — задачи отобранные из бэклога продукта для предстоящего спринта. Формируется владельцем продукта и командой при участии Scrum-мастера.

В рамках спринта есть три основных собрания команды, Scrum-мастера и владельца продукта. Они по содержанию они делятся на:

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

Кроме основных встреч регулярными являются ежедневные scrum-совещания. Они не должны занимать более 15-20 минут и направлены на формирование ежедневных целей.

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

Нужно было идти дальше. Scrum оказался более сложным инструментом для внедрения.

Мы столкнулись с проблемами:

• Было трудно организовывать регулярные встречи. Сначала не все понимали их смысл. Вместо коротких собраний, нацеленных на оповещение команды о проделанной работе и освещении возникших проблем, на первых этапах собрания перерастали в длинные сессии, с перечислением всего, что и как было сделано, обсуждением новых идей – что делало собрания неэффективными.
• Планирование спринтов также занимало много времени. Грамотно разделить весь проект на равносильные этапы было для нас в новинку.
  

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

Scrum помог нам внести ясность в работу коллектива. Сотрудники лучше стали понимать принципы новой концепции, ведь они стали применять их на практике. Команда стала работать эффективнее и быстрее исправлять ошибки.

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

Обе методики соответствуют философии Agile. Добавлять элементы подхода Scrum или Kanban стоит поэтапно и смотреть, что лучше подходит именно вашей команде.

Мы в своей работе совмещаем оба инструмента – используем Kanban и Scrum, в зависимости от команды и проекта.

Пробуйте, внедряйте и совершенствуйте свою работу!