Чем agile отличается от скрама канбана и других фреймворков и методов
Обновлено: 06.07.2024
Все, кто работали и работают в сфере ИТ, хоть раз слышали про Agile, а еще про Scrum и Kanban. Сейчас практически любая компания хочет быть хоть немножечко аджайл, и это хорошо, когда есть выбор, но что именно подойдет вам? Чтобы окончательно не запутаться в этих понятиях и знать, в чем их преимущества, в этой статье мы предлагаем вам более детально ознакомиться с Agile и его основными фреймворками: Scrum и Kanban.
Что же такое Agile?
- Вся работа над проектом разделяется на короткие циклы (итерации) и ведется поэтапно;
- В конце каждой итерации заказчик получает готовый минимально работающий продукт или его часть, которую уже можно использовать;
- В течение всего рабочего процесса команда сотрудничает с заказчиком;
- Любые изменения в проекте приветствуются и быстро интегрируются в работу.
В отличие от других подходов вроде Waterfall, где можно выполнять задачи только если они были запланированы ранее, с Agile команда сможет легко подстраиваться под новые требования и факторы. Особенно это актуально для крупных проектов, где стейкхолдеры постоянно хотят что-то поменять.
Scrum
Термин Scrum пришел из регби. Он означает особую фигуру, в которую собираются игроки перед началом матча, и выглядит это примерно так:
Фигура Scrum в регби
В бизнес среде слово Scrum у многих людей ассоциируется с ежедневными короткими собраниями команды в начале дня для обсуждения проделанной работы и планирования следующих задач.
Kanban
Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски.
Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды.
Наши авторы
Профессионалы, работающие с Sony, NASA, Сбербанк, МТС, Nokia и многими другими компаниями. Спикеры на конференциях, авторы статьей
Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.
Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.
Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
К отдельным agile-подходам относятся scrum и kanban.
Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.
Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.
Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Примеры употребления
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
(Из перевода колонки Forbes на Rusbase)
Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)
Когда-то давно Скрам и Канбан органично жили под одним брендом Agile.
Однако, по мере развития Канбан-метода, его создатели поняли, что их подход должен основываться на принципах, отличных от того, чем руководствовались создатели Scrum. Также было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно.
Примерно в 2015-2017 годах создателями Канбан-метода было принято решение развивать концепцию Business Agility — в противовес понятию Agile. И с этого момента Канбан-метод начал позиционировать себя как альтернатива Agile-подходам.
Рассмотрим основные различия между Kanban-методом и фреймворком Scrum с точки зрения смысла, назначения и практики применения этих подходов.
Разница с точки зрения смысла
Scrum — это готовое руководство к тому, как организовать итеративно-инкрементальную разработку нового продукта. Есть даже инструкция, которая называется Scrum Guide. Все элементы Scrum взаимосвязаны друг с другом, и поэтому при реализации Scrum нельзя выбросить ничего из того, что указано в Scrum Guide.
Kanban-метод похож на ящик с инструментами. Вы можете брать только что-то одно, или все сразу — решать вам. Каждый инструмент приносит свою пользу. Выбор инструмента зависит лишь от вашей готовности его применять. Есть разные степени зрелости применения Канбан-метода, и на каждом уровне организация использует те или иные его элементы.
Разница с точки зрения целей
Scrum изначально создавался, чтобы быстро разработать «то, не знаю что» — какой-то инновационный продукт, подобных которому может еще даже в мире не существует. В этом главная цель и назначение Scrum.
Scrum может быть реализован в конкретных продуктовых подразделениях и не требует обязательного изменения рабочих процессов других подразделений или в компании в целом. Хотя, конечно, работа Scrum-команд менее эффективна в компаниях, где целеполагание, бюджетирование и другие процессы не являются гибкими.
Kanban-метод ставит своей конечной целью дать компаниям возможность быстро реагировать на изменения рынка. Он делает это за счет такого построения рабочих процессов, которое позволит быстро перестраиваться под новые реалии, гибко перебалансируя ресурсы, приоритеты, загрузку и т.д. Для этого требуется использовать целостный взгляд на компанию, чтобы увидеть, где именно кроются препятствия и заторы.
Можно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility
То есть, применение Канбан-метода стратегически нацелено на изменения во всей компании, для обеспечения долгосрочной устойчивости и гибкости на рынке. А главным фокусом Скрама является разработка продукта.
Разница с точки зрения принятия решений
Прежде всего, Kanban-метод — это инструмент менеджмента, т.е. предназначен для руководителей.
Поэтому решения о способах применения Канбан-метода и о выборе инструментов принимает именно руководитель подразделения или сервиса. Чтобы выбор был обоснованным, собирается статистика, характеризующая рабочий процесс.
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.
Для ускорения принятия решений и достижения наилучших результатов Scrum использует командный подход. Поэтому, чтобы Scrum заработал, нужно вовлечение всех участников Scrum-команды — Владельца Продукта, Scrum-мастера и Разработчиков.
Управленческие решения принимаются совместно всей Scrum-командой, а не каким-то одним руководителем или менеджером.
Разница в проведении и смысле встреч
Scrum делает ставку на командный подход.
Поэтому все встречи в Scrum рассчитаны на активное вовлечение всех участников команды и на коллективное принятие решений.
Каждая встреча Scrum нацелена на одно из двух:
- или на координацию движения команды (ежедневные митинги, планирование, обзор спринта),
- или на развитие командного взаимодействия, опыта и навыков самой команды (ретроспектива).
Поэтому одна из самых главных компетенций в Scrum — это навык фасилитации встреч. Фасилитация — это умение так организовать обсуждение вопроса группой, чтобы все смогли высказаться, услышать друг друга, выбрать наилучшее решение и остаться в хорошем настроении и в хороших отношениях.
Канбан-метод смотрит на встречи иначе.
Так как основа Канбан-метода — это данные и статистика, то цель встреч заключается в том, чтобы проанализировать данные о рабочем процессе, выделить системные проблемы и их возможные причины. По итогам этих встреч менеджер сервиса может принять управленческие решения, которые улучшат рабочий процесс.
Например, на ежедневном митинге возле Канбан-доски собираются данные о блокерах, трудностях, ожиданиях, которые препятствуют свободному движению потока задач.
На встрече по ревью сервиса поставки все крутится вокруг статистических данных о времени выполнения задач, пропускной способности и статистики по блокерам.
Каденция по пополнению посвящена вопросу о том, чем стоит загрузить Канбан-систему, с учетом ее возможностей. И так далее.
По итогу каждой встречи менеджер сервиса получает информацию для дальнейшего улучшения рабочих процессов
Разница с точки зрения предусловий
Чтобы Scrum начал приносить пользу, нужно сделать следующее.
- Выделить Владельца продукта — специального представителя бизнеса, который:
- будет наделен полномочиями для самостоятельного принятия решений о том, как должен выглядеть продукт,
- и, в то же время, будет тесно взаимодействовать с командой разработки.
Только при выполнении этого, довольно длинного, списка условий Scrum может дать ожидаемый результат.
Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера и сделать первый шаг:
- визуализировать рабочий процесс по вашему сервису;
- сделать соответствующую Kanban-доску;
- разместить на ней все текущие работы;
- проанализировать положение вещей и принять управленческие решения.
На этом первом шаге применения Kanban многие компании и останавливаются, но даже это приносит пользу. Такого рода реализацию называют прото-канбан, он позволяет увидеть целостную картину происходящего в подразделении и понять, где кроются системные проблемы.
Вы можете пойти дальше и использовать другие инструменты Kanban-метода: WIP-лимиты, метрики, управление потоком, каденции и т.д. Но можете этого и не делать. Решение полностью за вами. Когда будете готовы к этому, тогда и используйте.
Совместимость Kanban и Scrum
Может создаться впечатление, что Канбан-метод и Scrum совершенно несовместимы, но это не так.
Все инструменты Kanban-метода можно применять при работе по Scrum: сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд. Это может быть очень полезно, так как даст Scrum-команде больше возможностей чтобы делать свою работу лучше.
Примеры, когда Scrum неприменим
Малая команда
Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. 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) совместно работают над общим бэклогом продукта, у которого есть один владелец продукта.]()
LeSS — Scrum на больших масштабахВ Large-Scale Scrum (LeSS) кросс-функциональные и кросс-компонентные фиче-команды (feature teams) совместно работают над общим бэклогом продукта, у которого есть один владелец продукта.
Канбан-метод рассматривает все как сервис и поток задач, о котором мы собираем данные, анализируем и принимаем решения. Поэтому на большом масштабе главная задача Канбан-метода — сделать простым сбор данных на всем протяжении производственной цепочки (от момента зарождения идеи в голове бизнеса до момента продажи и поставки продукта клиенту). А это может быть очень длинный путь, который, скорее всего, включает в себя множество отделов, департаментов, подразделений.
Если попытаться “запихнуть” работы всех этих подразделений в одну Канбан-доску и проводить возле нее Канбан-встречи со всеми вовлеченными людьми, то получится сложная и дорогостоящая встреча. Поэтому придумывают разные варианты визуализации потока задач “по частям”, с обязательными встречами по синхронизации между этими частями.
![Канбан каденции]()
На рисунке показаны разные типы встреч, которые могут присутствовать в Канбан-методе.
Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).
Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев
С другой стороны, на разных уровнях иерархии надо собирать разные данные.
На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.
На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.
На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.
Чтобы связать данные по всем этим уровням между собой, придется создавать иерархию Канбан-досок, которые будут связаны между собой по вертикали, от стратегического уровня до тактического и обратно. Чтобы обеспечить синхронный сбор данных, прозрачность и актуальное состояние Канбан-досок на каждом уровне, нужно будет проводить координационные встречи не только “по горизонтали”, но и “по вертикали”.
Только при этих условиях Канбан-метод на большом масштабе принесет пользу, позволит увидеть заторы, проблемы и затыки на разных уровнях иерархии, и даст возможность улучшить рабочие процессы по всей организации.
Заключение
Как видим, фреймворк Scrum и Канбан-метод строятся на совершенно разных принципах, фокусируются на разных аспектах рабочей деятельности и предназначены для разных целей. Но при этом, инструменты Канбан-метода можно применять при работе по Scrum .
Если мысленно довести применение обоих подходов до логического конца, когда все аспекты подхода полностью реализованы и решены проблемы масштабирования, то результатом, как мне кажется, будет одно и то же — компании будут быстро реагировать на вызовы рынка, сохраняя свои позиции и обгоняя конкурентов.
![Укажите размер своей организации и узнайте, какие результаты у вас наиболее вероятны при использовании Scrum или Kanban.]()
Сравнение выгод от Scrum и КанбанПо данным исследования Agile в России
Укажите размер своей организации и узнайте, какие результаты у вас наиболее вероятны при использовании Scrum или Kanban.
Agile / Waterfall / Kanban / Scrum: назначение инструментов,подходы и принципы работы с ними
Разработка любого продукта подразумевает четкое планирование операций, разработку средств и методов решения рабочих задач. Существует несколько подходов к этому процессу, которые призваны помочь команде повысить качество результата, снизить издержки, расходы и риски. Методологии Agile, Scrum, Waterfall, Kanban сегодня должен иметь в своем арсенале каждый менеджер проекта.
Agile
Agile – что это за методика, получившая в современном продакт-менеджменте особую популярность? Под этим термином подразумевается гибкая методология при разработке продукта. Чаще всего она применяется в IT-технологиях небольшими группами специалистов, занятых однородной творческой работой. Этот метод отличается итерационным характером разработки, непосредственным взаимодействием разработчиков друг с другом и клиентом, гибким подходом к принятию решений. Его следует рассматривать скорее как систему ценностей, а не четких практик. К принципам Agile относятся следующие приоритеты:
- людей и коммуникации между ними над процессами и инструментами;
- работающего продукта над исчерпывающей документацией;
- взаимодействия с клиентом над заранее согласованным ТЗ (контрактом);
- готовности к изменениям над строгим соблюдением плана.
Waterfall
Данная модель используется в продакт-менеджменте с 70-х годов прошлого века. Другое ее название – каскадная или водопадная разработка, в основе которой лежит принцип последовательного и четкого соблюдения заранее разработанного плана. При таком подходе каждый шаг предварительно продуман и зафиксирован, поэтому обычно он применяется в тех проектах, где влияние непредусмотренных факторов минимально или отсутствует вовсе. Типичная схема каскадной разработки выглядит следующим образом: аналитика – проектирование – разработка – тестирование – эксплуатация и поддержка. В общем виде методологию Waterfall можно описать в следующих принципах:
- разработка осуществляется в точном соответствии с заранее составленным ТЗ;
- работа выполняется последовательно, без пропущенных и неоконченных этапов;
- при внесении клиентом новых требований после согласования проекта полностью переделывается ТЗ;
- разработка представляет собой непрерывный и общий процесс без итераций;
- выявление и исправление ошибок осуществляется только на стадии тестирования;
- разработчики не взаимодействуют с клиентом после составления и согласования ТЗ.
Kanban
Эта методология впервые была применена фирмой «Тойота», ее название переводится с японского как «доска объявлений». Она родилась из практики вывешивания мастерами участков перечней выполняемых работ. В основу данной системы положен принцип «точно в срок», заключающийся в организованном выполнении производственных операций в назначенное время. Методология Kanban применяется главным образом в небольших коллективах, она позволяет равномерно распределить обязанности между сотрудниками и сделать процесс разработки максимально прозрачным. Основные принципы такой системы:
- опора на имеющиеся методы разработки и стимулирование дополнительных изменений в них;
- предварительная договоренность о важных изменениях, поощрение небольших и эволюционных перемен в производственных процессах;
- четкое соблюдение и уважение существующих ролей и обязанностей, но с поощрением инициативы каждого разработчика.
Scrum
Основой для этой системы стали принципы, которыми руководствуются военные отряды и команды в регби. Разница между Scrum и Agile заключается в том, что первое – это конкретная методология, а вторая – система базовых ценностей. Процесс разработки при данном подходе разбивается на спринты – короткие периоды, в течение которых разработчики должны создать готовую часть (инкремент) продукта и продемонстрировать его клиенту на специальном совещании, чтобы получить обратную связь. Scrum-технология сводится к следующим принципам:
- заказчик должен получить готовый работающий продукт в максимально короткие сроки;
- разработка строится на активном взаимодействии членов команды, каждый из которых стремится к общей цели;
- заказчик и пользователи являются неотъемлемой частью команды и активно участвуют в работе;
- тестирование осуществляется в конце каждого спринта (итерации) для более гибкой и оперативной коррекции ошибок.
Все перечисленные методологии сегодня продолжают активно использоваться в управлении проектами. Квалифицированный продакт-менеджер должен знать, зачем нужна каждая из них, и четко понимать, чем отличается Scrum от Kanban, где применить гибкую Agile-методику и твердую Waterfall-систему.
Читайте также:
