Что такое agile scrum и kanban
Scrum, Kanban или оба?
Сегодня большинство компаний используют методологию Agile при разработке программного обеспечения. У Agile есть разные системы с похожими принципами и конечными результатами, но они различаются по структуре и подходу к управлению. Какой из них лучше всего подходит для вашего проекта? Это Скрам или Канбан? Или оба?
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
Agile
Scrum
В Scrum есть три роли : Product owner, Scrum Master и команда разработчиков, которые разбивают работу по разработке продукта на небольшие этапы, называемые спринтами. Это временные рамки, состоящие из мероприятий по планированию спринтов, ежедневных схваток, обзоров спринтов и ретроспективных мероприятий спринта, которые проходят каждый спринт. В каждом спринте высокопроизводительная команда Scrum находит инновационные решения сложных проблем, чтобы разработать, выпустить и поддерживать продукт.
Команда Scrum поставляет программное обеспечение постепенно, с пометкой «Готово», чтобы максимизировать обратную связь и повысить эффективность.
Kanban
В Канбане нет конкретных размеров команд или должностей. На доске указаны главные приоритеты каждой команды. В канбан-менеджменте нет временных ограничений. Это дает членам команды свободу работать так интенсивно, как они хотят, чтобы выполнить свою работу. Фактически, свобода дает больше обязанностей. Команды должны организоваться и полагаться на свой опыт, не ожидая присмотра.
Нет необходимости в ограничении задач или мерах контроля. Однако менеджер может измерить среднее время выполнения задач и обсудить это с командами в качестве попытки улучшения. Также он организует доску, на которой записываются все цели, будущие задачи, тесты и выполненные задачи.
Отличия
Рабочие роли и обязанности
В Kanban менеджер является организатором проекта, где команды разработчиков сотрудничают и помогают друг другу независимо от того, над какой стороной проекта они работают. Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.
Планирование и сроки поставки
Планирование времени лучше или нет?
В идеале руководство должно отвечать ожиданиям клиента относительно того, когда будет выпущен продукт. Скрам определенно лучший вариант для доставки вашего продукта в отведенное время. Из-за спринтов Scrum желателен для проектов, в которых клиент и руководство фиксируют прогресс. Отсутствие согласованного расписания в канбане предназначено для более сложных проектов в долгосрочной перспективе, когда работа выполняется точно, а не в спешке.
Производительность и измерение
Канбан ориентирован на достижение индивидуальных целей, записанных на доске Канбан. Прогресс не имеет конкретных мер. Обычно визуализация задач показывает прогресс каждой небольшой команды.
Является ли одна гибкая методология более продуктивной, чем другая? Конечно же нет. Не существует правильного рецепта гибкого управления. Это зависит от потребностей проекта. Просто дайте понять: каковы цели проекта? Какой рабочий процесс лучше всего подходит членам команды? Каков спрос со стороны конечного пользователя?
И Scrum, и Kanban усиливают управление проектом, но по-другому. Так зачем выбирать только один из них? Что, если есть третий метод, сочетающий в себе их лучшие качества?
Scrumban?
Визуализация рабочих элементов из системы Канбан представлена в Scrum. Рабочие элементы Scrum, находящиеся в процессе выполнения, подробно описаны на доске Kanban. Диаграммы применяются для выявления слабых мест и выявления возможностей для улучшения. Следовательно, Scrumban будет иметь растущую прозрачность, где каждый может видеть, что происходит с проектом.
Команда Scrum иногда может прийти к незавершению нескольких задач из-за ограничений по времени. При применении метода планирования Канбан задачи полностью завершаются до перехода в столбец «Готово». Вместо того, чтобы выпускать рабочие элементы раз в 2–3 недели в Sprints, существует постоянная поставка рабочего программного обеспечения. Качество превыше времени. Таким образом, в Scrumban есть улучшения по запросу, чтобы максимизировать поток работы.
Поэтому, не любите Scrum. Самыми важными стали метрики Канбан, а не скорость. Улучшение проекта выявляется внутри каждой команды самостоятельно. Это позволяет более достоверно оценивать прогресс.
Однако в Scrumban структура Sprint по-прежнему присутствует для обратной связи с командами.
Обзоры спринтов используются для анализа результатов каждого рабочего цикла. Далее, как и в Scrum, ежедневные встречи отслеживают непрерывную работу над требованиями.
На этом все. А тех, кто желает подробнее узнать о курсе, познакомиться с преподавателями и почерпнуть еще больше полезной информации, приглашаем на бесплатный демоурок по теме: «Как уточнять статусы задач и подружиться с соседями».
Agile/Scrume/Kanban как выравнивать процессы, максимизировать процессы
Материал подготовлен в рамках обучения Product University, январь, 2021
Для начала определим кто такой менеджер?
Менеджер — это человек производящий и управляющий потоками, для оптимизации производственной деятельности и достижения поставленных целей и результатов.
Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrume, Kanban. Чтобы иметь представления как работать с командой.
Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.
А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.
Подход к проектам по разработке ПО
• Гибкая методология разработки,
• Постоянное формирование требований на основе целевого видения продукта
• Короткие горизонты планирования (1-2 мес.)
• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля
• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Особенность реализации проектов
• Фиксированы срок и стоимость проекта.
• Лучший контроль качества – контроль результата каждой итерации
Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки
Scrum – самая популярная из гибких методологий разработки
Позволяет решать задачи
• с минимальными затратами.
РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.
Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.
ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.
По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.
Как максимизировать и выравнивать процессы?
На самом деле здесь уже все продумано, и придумать велосипед не нужно!
Используется всего четыре артефакта:
Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.
Это краткое описание того, ради чего выполняется данный спринт, цель на спринт помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.
Sprint Burndown Chart
Есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.
Ритуалы в скрам это:
Sprint Planning Meeting (встреча по планированию спринта)
Daily Meeting (ежедневная встреча команды).
Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.
Sprint Review – сдача спринта Product Owner
По завершению каждого спринта команда обязана провести демонстрацию полученного результат.
Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.
Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.
Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Kanban — это метод для разработки продуктов, который помогает наладить текущие процессы и не перегрузить команду. Незавершенные задачи не простаивают и потоком движутся по цепочке создания продукта или его поддержки.
Kanban используют для реализации проектов.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с «передовой» и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.
В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи
Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.
Чем Канбан отличается от Scrum, и причем тут Agile
Когда-то давно Скрам и Канбан органично жили под одним брендом Agile.
Однако, по мере развития Канбан-метода, его создатели поняли, что этот должен базироваться на других принципах, нежели Scrum. Было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно, и надо его из-под «зонтика Agile» вывести
В этих нюансах не так просто разобраться тем, кто впервые интересуется Scrum и Канбан и поэтому мы решили написать эту статью, чтобы расставить все точки над «Ё».
Рассмотрим основные различия между Kanban-методом и фреймворком Scrum с точки зрения смысла, назначения и практики применения этих подходов.
Разница с точки зрения смысла
Scrum — это готовое руководство о том, как организовать итеративно-инкрементальную разработку нового продукта. Есть даже инструкция, которая называется Scrum Guide. Все элементы Scrum взаимосвязаны друг с другом, и при реализации Scrum нельзя выбросить ничего из того, что указано в Scrum Guide.
Kanban-метод похож на ящик с инструментами. Вы можете брать только что-то одно, или все сразу — решать вам. Каждый инструмент приносит свою пользу. Выбор инструмента зависит лишь от вашей готовности его применять. Есть разные степени зрелости применения Канбан-метода, и на каждом уровне организация использует те или иные его элементы и их сочетания.
Разница с точки зрения целей
Scrum изначально создавался, чтобы быстро разработать «то, не знаю что» — какой-то инновационный продукт, подобных которому может еще даже в мире не существует. В этом главная цель и назначение Scrum.
Scrum может быть реализован в отдельных продуктовых подразделениях и не требует обязательного изменения рабочих процессов других подразделений или в компании в целом. Хотя, конечно, работа Scrum-команд менее эффективна в компаниях, где целеполагание, бюджетирование и другие процессы не являются гибкими.
Можно конечно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility
То есть, применение Канбан-метода стратегически нацелено на изменения во всей компании, для обеспечения долгосрочной устойчивости и гибкости на рынке (Business Agility). А главной целью фреймворка Scrum является разработка нового инновационного продукта.
Разница с точки зрения принятия решений
Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.
Поэтому решения о способах применения Канбан-метода и выборе конкретных инструментов принимает именно руководитель подразделения или сервиса. Чтобы выбор был обоснованным, он должен собрать статистику, характеризующую рабочий процесс, и на ее основе принять управленческие решения.
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.
Для ускорения принятия решений и достижения наилучших результатов Scrum делает ставку на командный подход.
Чтобы Scrum заработал, нужно вовлечение всех участников Scrum-команды — Владельца Продукта, Scrum-мастера и Разработчиков.
Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Scrum-командой, а не каким-то одним руководителем или менеджером.
Разница в смысле встреч и способе их проведения
Так как. Scrum делает ставку на командный подход, то все встречи в Scrum рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений.
Каждая встреча Scrum нацелена на одно из двух:
Исходя из этих целей, одна из самых главных компетенций в Scrum — это навык фасилитации встреч. Фасилитация — это умение так организовать обсуждение вопроса группой, чтобы все смогли высказаться, услышать друг друга, выбрать наилучшее решение и остаться в хорошем настроении и в хороших отношениях.
Канбан-метод смотрит на встречи иначе.
Так как основа Канбан-метода — это данные и статистика, то цель встреч заключается в том, чтобы проанализировать собранные данные о рабочем процессе, выделить системные проблемы и принять управленческие решения способах изменения рабочего процесса ради устранения выявленных проблем. Эти решения принимает менеджер сервиса по итогам встречи
На встрече по ревью сервиса поставки все крутится вокруг статистических данных о времени выполнения задач, пропускной способности и статистики по блокерам. Менеджер решает, как поменять рабочий процесс и его визуализацию так, чтобы улучшить статистические показатели.
Каденция по пополнению посвящена вопросу о том, чем стоит загрузить Канбан-систему, с учетом ее возможностей. Менеджер управляет общением с заказчиком предоставляя им данные для обоснованного принятия решения о том, какую работу взять следующей.
По итогу каждой встречи менеджер сервиса получает информацию для дальнейшего улучшения рабочих процессов и принимает управленческие решения
Разница с точки зрения предусловий
Чтобы Scrum начал приносить пользу, нужно сделать многое:
Только при выполнении этого, довольно длинного, списка условий Scrum может дать ожидаемый результат.
Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги:
На этом первом шаге применения Kanban-метода многие компании и останавливаются, но даже это приносит пользу. Такого рода реализацию называют прото-канбан, он позволяет увидеть целостную картину происходящего в подразделении и понять, где кроются системные проблемы.
Вы можете пойти дальше и использовать другие инструменты Kanban-метода: WIP-лимиты, метрики, управление потоком, каденции и т.д. Но можете этого и не делать. Решение полностью за вами. Когда будете готовы к этому, тогда и используйте.
Совместимость Kanban и Scrum
Может создаться впечатление, что Канбан-метод и фреймворк Scrum совершенно несовместимы, но это не так.
Все инструменты Kanban-метода можно применять при работе по Scrum: сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд. Это может быть очень полезно, так как даст Scrum-команде больше возможностей чтобы делать свою работу лучше.
Примеры применимости Scrum и Kanban
Малая команда
Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. Scrum в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.
Канбан-метод будет работать даже для одного человека. Есть понятие «Персональный Канбан», когда, вы ведете свои каждодневные рабочие дела на персональной Канбан-доске. Вам всегда видно, что у вас находится в работе, по каким задачам есть вопросы и блокеры, что в какой стадии завершенности, на что следует обратить внимание.
И хотя у вас может не быть какого-то длинного рабочего процесса для обработки ваших задач, тем не менее, вы получите выгоду от прозрачности, и даже сможете собрать свою персональную статистику о том, какие типы задач занимают у вас больше времени, а какие меньше.
Чисто операционная деятельность
Другой пример, когда нет смысла пытаться применять Scrum — работа операторов call-центра. Потому что Scrum предполагает эксперименты, исследование и терпимость к ошибкам, а работа операторов, как правило, заключается в точном следовании “скрипту” ответов на звонки, с правильной маршрутизацией запроса звонящего. В этой ситуации Scrum ничего не даст, так как все поведение заранее определено и уложено в инструкции, которым просто надо следовать.
С другой стороны, можно собрать рабочую группу по улучшению этого “скрипта”, чтобы он мог охватывать нестандартные ситуации и по-прежнему приносил пользу. Тут появляется поле для исследования и экспериментов, и такая группа вполне может работать по Scrum. Такие примеры вы можете посмотреть в докладе Agile в операционном управлении.
Канбан-метод, при наличии соответствующих инструментов, можно применять и в работе операционистов call-центра. Будут определенные трудности с визуализацией потока входящих звонков, так как частота их поступления весьма велика. Но если это удастся сделать, то у менеджеров call-центра появится возможность собирать данные о статистике обработки запросов от клиентов, и увидеть:
На основе этой информации руководитель call-центра может принять управленческие решения и оптимизировать рабочий процесс.
Scrum и Канбан на масштабе крупной компании
Главные трудности применения любых подходов на большом масштабе, в общем, одинаковы: это координация людей, разрешение зависимостей, обеспечение общего контекста и всеобщей информированности. И какой бы подход мы ни взяли, эти проблемы будут возникать обязательно.
Однако есть и разница.
Scrum, в первую очередь, делает ставку на людей, скорость и качество коммуникации между ними, а так же умение договариваться. Поэтому главные трудности применения Scrum на большом масштабе связаны именно с этими аспектами.
Чтобы их преодолеть, приходится применять фасилитацию на большом масштабе, проводить громоздкие и дорогостоящие встречи (например, Big Room Planning), ради того, чтобы все вовлеченные Scrum-команды успели поговорить, спланировать свою совместную работу и двигаться дальше с общим пониманием целей, задач и контекста.
Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе совместного движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение.
В Large-Scale Scrum (LeSS) кросс-функциональные и кросс-компонентные фиче-команды (feature teams) совместно работают над общим бэклогом продукта, у которого есть один владелец продукта.
Канбан-метод рассматривает все как сервис и поток задач, о котором мы собираем данные, анализируем и принимаем решения. Поэтому на большом масштабе главная задача Канбан-метода — сделать простым сбор данных на всем протяжении производственной цепочки (от момента зарождения идеи в голове бизнеса до момента продажи и поставки продукта клиенту). А это может быть очень длинный путь, который, скорее всего, включает в себя множество отделов, департаментов, подразделений.
Если попытаться “запихнуть” работы всех этих подразделений в одну Канбан-доску и проводить возле нее Канбан-встречи со всеми вовлеченными людьми, то получится сложная и дорогостоящая встреча. Поэтому придумывают разные варианты визуализации потока задач “по частям”, с обязательными встречами по синхронизации между этими частями.
На рисунке показаны разные типы встреч, которые могут присутствовать в Канбан-методе.
Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).
Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев
С другой стороны, на разных уровнях иерархии надо собирать разные данные.
На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.
На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.
На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.
Чтобы связать данные по всем этим уровням между собой, придется создавать иерархию Канбан-досок, которые будут связаны между собой по вертикали, от стратегического уровня до тактического и обратно. Чтобы обеспечить синхронный сбор данных, прозрачность и актуальное состояние Канбан-досок на каждом уровне, нужно будет проводить координационные встречи не только “по горизонтали”, но и “по вертикали”.
Только при этих условиях Канбан-метод на большом масштабе принесет пользу, позволит увидеть заторы, проблемы и затыки на разных уровнях иерархии, и даст возможность улучшить рабочие процессы по всей организации.
Заключение
Если мысленно довести применение обоих подходов до логического конца, когда все аспекты подхода полностью реализованы и решены проблемы масштабирования, то результатом, как мне кажется, будет одно и то же — компании будут быстро реагировать на вызовы рынка, сохраняя свои позиции и обгоняя конкурентов.
По данным исследования Agile в России
Укажите размер своей организации и узнайте, какие результаты у вас наиболее вероятны при использовании Scrum или Kanban.