Agile, Scrum, Kanban - в последние годы эти термины переживают пик популярности. Все больше руководителей стало интересоваться "гибкими" методологиями управления проектами и их особенностями.
Чтобы не запутаться.
Scrum и Kanban - это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile. Сам Agile (agile software development, от agile - проворный) - это семейство "гибких" подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или Agile-методологиями.
Смысл Agile сформулирован в Agile-манифесте разработки ПО: "Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану".
1Н73ЛЛ3К7 370 6ПО6ОБНОС7Ь 4Д4П71PОВ47Ь6Я K 13M3H3H1ЯМ. 67ИВЗН ХОК1НГ.
К отдельным Agile-подходам относятся Scrum и Kanban. Scrum и Kanban - это гибкие методологии, работающие в Agile фреймворке.
По мере развития Kanban-метода, его создатели поняли, что он должен базироваться на других принципах, нежели Scrum. Было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно, и надо его из-под "зонтика Agile" вывести.
Примерно в 2015-2017 годах создателями Kanban-метода было принято решение развивать концепцию Business Agility — в противовес понятию Agile. И с этого момента Kanban-метод начал позиционировать себя как альтернатива Agile-подходам, а не их часть.
Разница с точки зрения смысла.
Scrum — это готовое руководство о том, как организовать итеративно-инкрементальную разработку нового продукта. Есть даже инструкция, которая называется Scrum Guide. Все элементы Scrum взаимосвязаны друг с другом, и при реализации Scrum нельзя выбросить ничего из того, что указано в Scrum Guide.
Kanban-метод похож на ящик с инструментами. Вы можете брать только что-то одно, или все сразу — решать вам. Каждый инструмент приносит свою пользу. Выбор инструмента зависит лишь от вашей готовности его применять. Есть разные степени зрелости применения Kanban-метода, и на каждом уровне организация использует те или иные его элементы и их сочетания.
Разница с точки зрения целей.
Scrum изначально создавался, чтобы быстро разработать "то, не знаю что" — какой-то инновационный продукт, подобных которому, может, еще даже в мире не существует. В этом главная цель и назначение Scrum. Scrum может быть реализован в отдельных продуктовых подразделениях и не требует обязательного изменения рабочих процессов других подразделений или в компании в целом. Главной целью фреймворка Scrum является разработка нового инновационного продукта.
Kanban-метод ставит своей конечной целью дать возможность целым компаниям быстро реагировать на изменения рынка — это и есть Business Agility. Kanban-метод делает это за счет такого построения рабочих процессов, которое позволяет быстро перестраиваться под новые реалии, гибко перебалансируя ресурсы, приоритеты, загрузку и т.д. Чтобы этого достичь требуется использовать целостный взгляд на компанию, для того, чтобы увидеть, где именно кроются препятствия и заторы, не позволяющие работать быстро и гибко. Применение Kanban-метода стратегически нацелено на изменения во всей компании, для обеспечения долгосрочной устойчивости и гибкости на рынке (Business Agility).
Разница с точки зрения принятия решений.
Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей. Поэтому решения о способах применения Kanban-метода и выборе конкретных инструментов принимает именно руководитель подразделения. Чтобы выбор был обоснованным, он должен собрать статистику, характеризующую рабочий процесс, и на ее основе принять управленческие решения.
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов. Для ускорения принятия решений и достижения наилучших результатов Scrum делает ставку на командный подход. Чтобы Scrum заработал, нужно вовлечение всех участников Scrum-команды — Владельца Продукта, Scrum-мастера и Разработчиков. Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Scrum-командой, а не каким-то одним руководителем или менеджером.
Разница в смысле встреч и способе их проведения.
Так как Scrum делает ставку на командный подход, то все встречи в Scrum рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений. Каждая встреча Scrum нацелена на одно из двух:
- или на координацию движения команды (ежедневные митинги, планирование, обзор спринта),
- или на развитие командного взаимодействия, опыта или навыков Scrum-команды (ретроспектива).
Исходя из этих целей, одна из самых главных компетенций в Scrum — это навык фасилитации встреч. Фасилитация — это умение так организовать обсуждение вопроса группой, чтобы все смогли высказаться, услышать друг друга, выбрать наилучшее решение и остаться в хорошем настроении и в хороших отношениях.
Канбан-метод смотрит на встречи иначе.
Так как основа Канбан-метода — это данные и статистика, то цель встреч заключается в том, чтобы проанализировать собранные данные о рабочем процессе, выделить системные проблемы и принять управленческие решения о способах изменения рабочего процесса ради устранения выявленных проблем. Эти решения принимает менеджер сервиса по итогам встречи.
Например, на ежедневном митинге возле Канбан-доски собираются данные о блокерах, трудностях, ожиданиях, которые препятствуют свободному движению потока задач, и менеджер решает как перераспределить ресурсы, чтобы обеспечить завершение задач, которые ближе всего к завершению.
Разница с точки зрения предусловий.
Чтобы Scrum начал приносить пользу, нужно сделать многое:
— Выделить Владельца продукта — специального представителя бизнеса, который:
- будет наделен полномочиями для самостоятельного принятия решений о том, как должен выглядеть продукт,
- несет ответственность за наполнение продукта действительно ценным для клиента функционалом,
- будет тесно взаимодействовать с командой разработки.
— Выделить на 100% всех необходимых специалистов в кросс-функциональную Scrum-команду, и договориться с их линейными руководителями, что теперь задачи этим специалистам может ставить только Владелец Продукта.
— Выделить Scrum-мастера, который будет заниматься развитием самоорганизации в Scrum-команде.
— При необходимости — поменять регламенты, чтобы Scrum-команда могла поставлять результат короткими итерациями (1-4 недели).
— При необходимости — выделить Scrum-команде свой контур инфраструктуры, чтобы они могли самостоятельно делать end-to-end разработку.
— Обучить основам работы по Scrum всех участников Scrum-команды, заказчиков и все окружение, в котором работает Scrum-команда.
Только при выполнении этого, довольно длинного, списка условий Scrum может дать ожидаемый результат.
Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги:
— визуализировать рабочий процесс по вашему сервису;
— сделать соответствующую Kanban-доску;
— разместить на ней все текущие работы;
— проанализировать положение вещей и принять управленческие решения.
На этом первом шаге применения Kanban-метода многие компании и останавливаются, но даже это приносит пользу. Такого рода реализацию называют прото-канбан, он позволяет увидеть целостную картину происходящего в подразделении и понять, где кроются системные проблемы.
Совместимость Kanban и Scrum.
Может создаться впечатление, что Kanban-метод и фреймворк Scrum совершенно несовместимы, но это не так. Все инструменты Kanban-метода можно применять при работе по Scrum: сбор метрик, ограничение одновременно выполняемой работы, визуализация и т.д. Это может быть очень полезно, так как даст Scrum-команде больше возможностей чтобы делать свою работу лучше.
Примеры применимости Scrum и Kanban.
Малая команда.
Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. Scrum в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.
Канбан-метод будет работать даже для одного человека. Есть понятие "Персональный Канбан", когда, вы ведете свои каждодневные рабочие дела на персональной Канбан-доске. Вам всегда видно, что у вас находится в работе, по каким задачам есть вопросы и блокеры, что в какой стадии завершенности, на что следует обратить внимание.
И хотя у вас может не быть какого-то длинного рабочего процесса для обработки ваших задач, тем не менее, вы получите выгоду от прозрачности, и даже сможете собрать свою персональную статистику о том, какие типы задач занимают у вас больше времени, а какие меньше.
Операционная деятельность.
Другой пример, когда нет смысла пытаться применять Scrum — работа операторов call-центра. Потому что Scrum предполагает эксперименты, исследование и терпимость к ошибкам, а работа операторов, как правило, заключается в точном следовании "скрипту" ответов на звонки, с правильной маршрутизацией запроса звонящего. В этой ситуации Scrum ничего не даст, так как все поведение заранее определено и уложено в инструкции, которым просто надо следовать.
С другой стороны, можно собрать рабочую группу по улучшению этого "скрипта", чтобы он мог охватывать нестандартные ситуации и по-прежнему приносил пользу. Тут появляется поле для исследования и экспериментов, и такая группа вполне может работать по Scrum.
Канбан-метод, при наличии соответствующих инструментов, можно применять и в работе операционистов call-центра. Будут определенные трудности с визуализацией потока входящих звонков, так как частота их поступления весьма велика. Но если это удастся сделать, то у менеджеров call-центра появится возможность собирать данные о статистике обработки запросов от клиентов, и увидеть:
— на каких запросах чаще всего возникают трудности, задержки, затруднения;
— на что нужно обратить внимание, чтобы обеспечить бесперебойное обслуживание потока звонков.
На основе этой информации руководитель call-центра может принять управленческие решения и оптимизировать рабочий процесс.
Scrum и Канбан на масштабе крупной компании.
Главные трудности применения любых подходов на большом масштабе, в общем, одинаковы: это координация людей, разрешение зависимостей, обеспечение общего контекста и всеобщей информированности. И какой бы подход мы ни взяли, эти проблемы будут возникать обязательно. Однако есть и разница.
Scrum, в первую очередь, делает ставку на людей, скорость и качество коммуникации между ними, а также умение договариваться. Поэтому главные трудности применения Scrum на большом масштабе связаны именно с этими аспектами.
Чтобы их преодолеть, приходится применять фасилитацию на большом масштабе, проводить громоздкие и дорогостоящие встречи, ради того, чтобы все вовлеченные Scrum-команды успели поговорить, спланировать свою совместную работу и двигаться дальше с общим пониманием целей, задач и контекста.
Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе совместного движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение.
Канбан-метод рассматривает все как сервис и поток задач, о котором мы собираем данные, анализируем и принимаем решения. Поэтому на большом масштабе главная задача Канбан-метода — сделать простым сбор данных на всем протяжении производственной цепочки (от момента зарождения идеи в голове бизнеса до момента продажи и поставки продукта клиенту). А это может быть очень длинный путь, который, скорее всего, включает в себя множество отделов, департаментов, подразделений.
Если попытаться "запихнуть" работы всех этих подразделений в одну Канбан-доску и проводить возле нее Канбан-встречи со всеми вовлеченными людьми, то получится сложная и дорогостоящая встреча. Поэтому придумывают разные варианты визуализации потока задач "по частям", с обязательными встречами по синхронизации между этими частями.
Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг). Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев.
С другой стороны, на разных уровнях иерархии надо собирать разные данные.
На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.
На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.
На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.
Только при этих условиях Канбан-метод на большом масштабе принесет пользу, позволит увидеть заторы, проблемы и затыки на разных уровнях иерархии, и даст возможность улучшить рабочие процессы по всей организации.
People think focus means saying "yes" to the thing you've got to focus on. But that's not what it means at all. It means saying "no" to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things we have done.
Innovation is saying "no" to 1,000 things. Steve Jobs.
Фреймворк Scrum и Канбан-метод строятся на совершенно разных принципах, фокусируются на разных аспектах рабочей деятельности и предназначены для разных целей. Но при этом, инструменты Канбан-метода можно применять при работе по Scrum.
Если мысленно довести применение обоих подходов до логического конца, когда все аспекты подхода полностью реализованы и решены проблемы масштабирования, то результатом, как мне кажется, будет одно и то же — компании будут быстро реагировать на вызовы рынка, сохраняя свои позиции и обгоняя конкурентов.
feat. ScrumTrek.
