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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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