Скрам или Kanban?
Зачастую при построении процессов разработки возникает вопрос: «Что использовать — Scrum или Kanban? Что подойдет нашей команде?» Давайте разбираться, можно ли их вообще сравнивать.
Скрам — это Фреймворк, который на старте задаёт рамки структуры и процессов, которые должны быть в компании. В Скрам входят:
5 обязательных событий: спринт, планирование спринта, дейли скрам, обзор спринта, ретроспектива.
Три роли: Владелец продукта, Скрам мастер и команда разработки.
Артефакты: беклог продукта и спринта беклог, инкремент в конце спринта.
Также — критерии готовности и некоторые ценности и принципы.
Скрам применяется в условиях неопределённости организации работы умственного труда при создании чего то нового.
Kanban — это не подход, не фреймворк, а метод (или инструмент), который можно использовать для улучшения производственной эффективности. Или по другому- набор принципов и практик совершенствования процессов.
Он изначально базируется на принципах Lean, в основе которых лежит устранение потерь в работах. Например, в процессе разработки какие-то задачи могут простаивать, какие-то передаваться между отделами, какие-то быть явно лишними и не совсем актуальными или требовать ресурсов сразу нескольких команд. Kanban — метод, позволяющий визуализировать всю работу и имеющиеся процессы для их постепенного улучшения. Это может быть как на уровне персональных задач, уровне команды, так и на уровне стратегии компании.
Если фреймворк Scrum сразу определяет рамки процесса, то канбан-метод встраивается в любой существующий и позволяет начать с того, что есть сейчас, постепенно его улучшая. Если Скрам работает с неопределенностью, то Канбан можно использовать и для вполне определенных задач, например, для управления проектом, когда необходимо довести до готовности вполне понятные задачи, или для сервисных команд, чтобы упростить получение требований. Тем не менее, Канбан также можно использовать в разработке для создания продукта небольшими кусочками и тестирования его на рынке. Также Скрам требует изменения структуры на старте и создания кроссфункциональных команд, что не обязательно для канбана. Канбан может использоваться для управления работой, которая проходит через разные команды, не обязательно находящиеся вместе.
Канбан-метод базируется на эволюционном развитии процесса, это его основной принцип, который позволяет создать предсказуемый и управляемый поток создания ценности. Условно говоря, — конвейер который функционирует без простоев, задержек и лишней работы.
Как начать использовать Kanban
Визуализировать работу и процесс.
Обычно это делается с помощью Канбан-доски, где изображаются все этапы, через которые проходит работа. Так, количество колонок может быть больше, чем в Scrum, например, колонки «очередь», «выбрано», «анализ», «тестирование» и так далее. Другие рекомендации без визуального представления не будут иметь смысла — чтобы управлять работой, нужно видеть и понимать ее. Суть инструмента — визуализировать процессы нашей работы: как она движется, по каким правилам, какие задачи выполняются, какие застопорились, а по каким ожидается ответ от других департаментов.
Ограничить одновременно выполняемые работы.
Для появления канбан-системы визуально представлять процессы, также важно стремиться к минимизации количества задач, которые одновременно берутся в работу, — такая практика помогает уменьшить время их выполнения и спрогнозировать сроки реализации, понимание которых, несомненно, будет важным для всех стейкхолдеров.
Начать собираться вокруг доски и управлять потоком работы.
Например, можно проводить ежедневные встречи, на которых будет определяться план работы на день, будут рассматриваться «зависшие» задачи и оперативно приниматься решения по их урегулированию. Также, важно смотреть на метрики потока и строить гипотезы об их улучшении. Цель — создать плавный процесс прохождения работы через систему, минимизируя препятствия и потери.
Внедрить понятные правила работы.
Для каждого члена команды работа с канбан должна быть прозрачной. Крайне важно убедиться в том, что все понимают «правила игры». Чтобы избежать недопонимания, необходимо эти правила зафиксировать и визуализировать для общей вовлеченности: например, какие критерии готовности каждого этапа системы, какие задачи являются приоритетными, как определить необходимость пополнения бэклога идей и так далее.
Совершенствовать процессы.
Канбан-метод — это не просто инструмент управления работами. Это метод эволюционных улучшений: с помощью визуализации метрик мы можем отследить несовершенства процессов и на их основе модернизировать функционирование команды. Главная цель канбан-метода — постоянные улучшения на основе метрик и экспериментов.
Как начать использовать Скрам?
Сперва необходимо определить продукт в компании, над которым будет работать команда, далее понять какие системы обслуживания продукт, далее собрать кроссфункциональную команду. Наделить ее всем необходимым, выделить необходимые роли, исключить команду из старой структуры с иерархией. Далее научить команду работать по новому, понимать все компоненты систем, работать сообща.
На практике — сложный и долгий процесс.
Резюмируем
Kanban-метод применим для улучшения любых процессов (и продуктов, и проектов), в том числе при прогнозируемом результате. Создает предсказуемый и управляемый поток создания ценности. Kanban позволяет начать с того, что есть сейчас, и на старте не требует создавать условия для его использования. Возьмите существующий процесс, визуализируйте его и все задачи и начните потихоньку управлять ими. В процессе принимайте решения, что стоит изменить.
Скрам применим для создания чего то нового в условиях неопределённости. Не стоит его использовать для вполне понятных продуктов/ проектов. Процесс внедрения Скрам как правило требует много изменений в компании, чего не требует канбан на старте.
Как получить максимум?
Если вы заняты в сфере разработки и создаете продукт, оптимальным решением для вас будет использовать фреймворк Scrum, усиленный Kanban-методом. Например:
визуализацией всех этапов разработки от Discovery (когда происходит уточнение продуктовой ценности), до Delivery (когда происходит доведение выбранных задач до готовности),
визуализацией стратегических инициатив, крупных задач, которые будут двигаться по доске, а вы будете управлять ими,
ограничением одновременно выполняемой работы на этапах.
внедрением системы метрик времени выполнения.
Рекомендации
Задумывались ли вы для чего разрабатываются ИТ-системы? Или для кого? Кто в них заинтересован? В чем их интерес? Хочу пригласить всех желающих на бесплатный вебинар, где поговорим о том, зачем при разработке ИТ-систем выявлять стейкхолдеров, как их выявлять, чтобы не пропустить важного, главного, для чего предназначена система. Обсудим методы выявления стейкхолдеров, приемы работы с ними. А еще вы узнаете: как выявить сторонников и противников, и всегда ли сторонники — это хорошо, а противники — плохо? Как быстро выудить из сторонника не только цвет кнопки, но и в чем ценность системы для его компании и его самого. А из противника — что нужно изменить/добавить, чтобы повысить востребованность системы. И как найти того стейкхолдера, который как локомотив поможет сделать систему нужной и полезной многим? И кто поможет запустить систему, когда ее разработаем.
