Agile канбан что это

Kanban: что это, как работает и причем тут Agile

Если проект состоит из множества этапов и задействует большую команду, нужны упорядочить его и сделать наглядным. Для этого компании внедряют работу по Agile и методологию Kanban. Эти современные техники позволяют быстро создавать и совершенствовать продукт. Расскажем об управлении проектами по Kanban, а также про Agile и Scrum — наиболее близкие к нему методологии.

Что такое Kanban

Kanban — инструмент управления проектами с этапами работы и подвижными карточками.

• Этапы. Вертикальные сегменты, которые называют так же, как обязательные шаги рабочего процесса. Обычно это «На очереди» (или «бэклог» — список всех требований, пожеланий условий), «Запланировано» (будущие задачи), «В работе» (то, чем специалисты заняты сейчас), «Проверка», «Готово». Компания может добавлять собственные этапы или исключать ненужные. Каждая задача проходит путь от бэклога до последней колонки.
• Карточки. В них оформляют каждую задачу. Помимо формулировки задания, добавляют сроки, исполнителей, описание процесса и деталей работы, прикрепляют полезные материалы. Сотрудники вносят в карточки сведения о проделанной работе, пишут комментарии, оставляют сообщения другим членам команды.

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

Помимо организации системной работы по Agile, Kanban помогает:

• Создать воронку продаж. Колонки будут этапами, а карточки — заявками клиентов.
• Равномерно нагружать членов команды. Благодаря доске понятно, кто из сотрудников перерабатывает, а кому работы можно и прибавить.
• Контролировать выполнение задач. Легко отследить, на какой стадии находится поручение.
• Выявить перегруженные этапы. Затем выяснить, в чем причина медленной работы, и принять меры.
• Найти и устранить другие проблемы. Например, недопонимание между сотрудниками, которые работают над одной задачей.

Чем Kanban отличается от Scrum

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

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

Kanban — это, скорее, набор инструментов, а не четкое руководство. Вы можете сформулировать собственные этапы работы, например, добавить несколько стадий проверки продукта — тестировщиками, продакт-менеджером, CEO компании.

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

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

Менеджмент и взаимодействие

Scrum невозможен без командной работы. Каждый специалист вовлечен на 100% и несет ответственность за общий результат. Управленческие решения принимают все: владелец продукта, разработчики, Scrum-мастер.

Для Kanban чувство локтя не обязательно — его часто используют руководители как «вертикальный» метод управления. Именно они выбирают конкретные инструменты, назначают задачи, отслеживают их выполнение и отвечают за результат. Командная работа, преемственность и взаимопомощь важны, но техника подойдет и для коллективов с четкой иерархией.

Команда проекта ежедневно встречается на коротком 15-минутном стендапе, известном как скрам или дейли. На нем команда вместе планирует и обсуждает свою работу. Важно, чтобы встречи были не только продуктивными, но и позитивными — они задают настроение на весь рабочий день. Каждый участник должен делиться хорошими новостями.

В Kanban и Agile основная цель встреч — выявление проблем. Специалисты анализируют сложившуюся ситуацию, принимают решения, а руководители — внедряют изменения в рабочем процессе. Ежедневные совещания не обязательны, как и мероприятия по сплочению команды.

Представьте: однажды руководитель отдела торговли обнаруживает, что на этапе «В процессе» замедлилось движение телефонных продаж. Он собирает сотрудников, выясняет причины «затора», интересуется пожеланиями специалистов и принимает решение. Допустим, дело в слабой подготовке менеджеров. Тогда руководитель привлекает более опытных наставников, поручает им пересмотреть скрипты и обучить коллег. Затем он следит, улучшается ли ситуация на доске после внедрения изменений.

Отличие	Scrum	Kanban
Суть метода	четкая схема работы	адаптивность под разные бизнес-процессы
Цели	быстрое создание продукта	работа в нестабильных условиях
Управление	для команд с равными правами, обязанностями и ответственностью	для всех вариантов менеджмента
Встречи	обязательны каждый день	обязательны только, если возникают проблемы

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

Преимущества Kanban в разработке и управлении проектами

Из различий между Agile, Scrum и Kanban очевидны преимущества последней методологии. Перечислим некоторые из них.

Гибкость планирования. Руководитель проекта ведет бэклог, а забота команды — текущие задачи и дедлайны.

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

Сокращение цикла. Это один из принципов работы в Kanban. Каждая задача имеет свой жизненный цикл — от начала до конца выполнения. Команда может менять его к лучшему: помогать коллегам «расшивать» узкие места, где скапливается много карточек, развивать многозадачность, обмениваться знаниями, укладываться в сроки, пробовать новые инструменты.

Меньше узких мест. Скопление задач, долгие и сложные цепочки согласования, увольнение ведущего специалиста, недостаточно квалифицированная работа сотрудников — все это замедляет процессы и бьет по их качеству. Kanban позволяет избегать таких ситуаций: своевременно находить проблемные места и устранять их.

Пример. Программист, перед тем как отдать свой код на проверку, участвует в тестировании чужого. Это помогает ему увидеть неочевидные ошибки и устранить их в своей работе. Программист чувствует собственную выгоду: гораздо проще исправить недочеты сразу, чем потом возвращаться к задаче, бросив другие обязанности.

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

Непрерывная поставка. Это регулярная сдача клиенту результата работы. Kanban создает своего рода конвейер, который помогает быстро и эффективно получать работающий продукт. А постоянная оптимизация процесса — отказ от бессмысленных этапов, ротация специалистов, перераспределение задач — позволяет в считанные недели создавать, совершенствовать и внедрять решения.

Как можно применить Kanban вне сферы разработки программного обеспечения

Рассмотрим пример того, как использовать методологию в продажах. Kanban покажет более впечатляющие результаты, если интегрировать его в CRM-систему. Некоторые решения позволяют настроить доску прямо в рабочем интерфейсе.

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

Каждый из них — этап, который проходят новые и постоянные клиенты компании.

• «Регистрация»;
• «Оценка сделки»;
• «Переговоры»;
• «Подписание договора»;

Заявку каждого нового клиента оформляют в виде отдельной карточки — для этого в CRM есть кнопка «Добавить». В задаче указывают источник, который привел клиента, его контакты, подробности заказа, данные ответственного менеджера.

С переходом лида на новый этап карточку перемещают по воронке. Бывает так, что некоторые шаги можно пропустить. Например, если вы сразу согласовали с B2B-покупателем стоимость контракта, отработка возражений не потребуется.

Если клиент сорвался, его карточку отправляют в специальный раздел, например, «Проигранные сделки». Создайте внутри него этапы «Аналитика» и «Обсуждение», чтобы понять, почему продажа сорвалась, выяснить причину неудачи и поделиться опытом с коллегами.

Создание Kanban-доски в CRM полезно тем, что специалисты работают в едином интерфейсе с разными уровнями доступа и полномочиями. Кроме того, система хранит всю историю сделок — если клиент обратится повторно, вести его по воронке будет проще.

Попробуйте CRM Битрикс24

CRM возьмет под контроль все каналы коммуникаций с клиентами и автоматизирует продажи в вашем бизнесе.

Еще один пример — запуск рекламной кампании. Здесь можно включить доску Kanban в управление проектами по Agile. Это будет выглядеть так:

1. Директор маркетингового отдела и ключевые специалисты отбирают площадки для продвижения и команду.
2. Руководство настраивает этапы на канбан-доске — от создания креатива до запуска, тестирования и анализа.
3. Каждый канал продвижения оформляют в виде отдельной карточки, например «Объявление в соцсети», «Реклама у блогера», «Телереклама». Чтобы различать задачи, для рекламных площадок используют разные цвета.
4. На каждый этап и каждую задачу выделяют определенное время. Например, создание и согласование креатива будет занимать неделю, запуск — три дня, наблюдение и анализ результатов — месяц.
5. Специалисты приступают к выполнению задач. Дизайнеры готовят объявления, SMM-менеджеры — посты для социальных сетей, операторы и монтажеры — ролики для видеохостингов.
6. Руководители наблюдают за выполнением задач и следят, чтобы на доске не образовывалось узких мест.

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

Частые вопросы

Что такое Kanban и как он отличается от других Agile-методологий?

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

Как и Agile, Kanban — гибкая разработка. Методология позволяет возвращаться к предыдущим этапам, дорабатывать продукт на основе обратной связи, менять приоритеты задач в бэклоге.

Главное отличие Kanban от методологий Agile и Scrum — в универсальности. Техника подойдет и для команд с четкой иерархией, и для тех, где все сотрудники равны. Kanban дополняет Scrum.

Как создать доску Kanban и какие элементы в нее включить?

Пространство для работы может быть электронным (планировщики задач, системы управления проектами, CRM) или материальным (пробковая или магнитная доска). Обязательные элементы — этапы и задачи. Первые оформляют в виде вертикальных или горизонтальных сегментов на доске, дают им соответствующие названия.

Каждую задачу оформляют в отдельную карточку. В ней указывают название, описание, ответственных лиц, сроки, инструменты. А в электронных досках внутри карточки можно обсудить детали и прикрепить полезные материалы.

Как часто следует проводить совещания и обзоры, работая по доске Kanban?

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

Как можно интегрировать Kanban с другими Agile-методологиями, такими как Scrum?

Достаточно внедрить доску и обучить сотрудников работать с ней. Оформите в Kanban этапы в соответствии с шагами разработки и перенесите все задачи на карточки. Вовлекайте сотрудников постепенно. Сначала обучите ключевых специалистов, затем — рядовых. Показывайте им разные функции: это поможет использовать все возможности доски. Например, прислать оповещение преемнику или добавить в карточку полезный материал.

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

Что в итоге

• Kanban, как и Agile и Scrum позволяет организовать гибкую разработку продукта и сократить время выполнения задач.
• Наглядность — главная ценность Kanban-доски. Она показывает рабочий процесс как систему взаимосвязанных шагов и помогает отследить статус каждой задачи.
• Методы Agile, Kanban и Scrum можно внедрить с помощью специализированного программного обеспечения (планировщика, CRM) или обычной доски. Главное — точно определить этапы работы и своевременно менять статус задач.
• Kanban позволяет быстро выявлять слабые места в рабочем процессе — скопление задач на том или ином этапе, пропущенные сроки. Это называется управлением потоком.
• Метод Kanban применяют в IT, рекламе, продажах и в других digital-проектах. Если грамотно подберете инструмент, получите все необходимое для успешной работы команды.

Agile канбан что это

Комментарии

Популярные По порядку
Не удалось загрузить комментарии.

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

�� ТОП-14 российских аналогов Jira и систем управления проектов

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

Бесплатные книги по управлению проектами для новичков и профи

Подборка бесплатных книг по управлению проектами в разных сферах деятельности. Учебники для новичков, пособия для профессионалов и мировые шедевры.

Как найти ментора в IT-сфере и откуда начать поиски?

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

Waterfall, Agile, Scrum или Kanban — в чем разница?

Бэтмен или супермен? Agile или Waterfall? Scrum или Kanban? Три вопроса, о которых люди могут спорить часами. Мы не являемся экспертами в области супергероев, но поможем вам разобраться с базовыми терминами методик управления проектами. В статье расскажем, что скрывается за перечисленными понятиями и какой подход лучше выбрать для своего бизнеса.

Что нужно знать о методологиях разработки

Методология — набор методов и принципов, подкрепленных теорией.

На сегодняшний день существует множество методов для управления разработкой проекта, но самыми популярными подходами в разработке считаются Waterfall и Agile.

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

Ниже расскажем о плюсах и минусах как Waterfall, так и Agile.

Методология водопада

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

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

Еще один принцип каскадного метода разработки — подробная документация. Перед началом работы команда обсуждает каждый аспект будущего продукта и фиксирует все важные моменты (от требований к проекту до расставления дедлайнов).

Классическая водопадная модель состоит из 5 этапов:

1. Сбор требований к продукту и оформление их в техническое задание. На этом этапе подробно прописывают план работы, распределяют роли в команде, закладывают время на проект и риски.
2. Проектирование. Здесь прописываются функции и фишки продукта, к примеру, логика и архитектура сайта. После под выбранную концепцию подбирают инструменты: язык программирования, методы и т.д.
3. Разработка. Этап, на котором сотрудники разрабатывают продукт или пишут код в строгом соответствии ТЗ, макетам и требованиями — и ни шагу в сторону. Этот этап занимает большую часть проекта.
4. Тестирование. Здесь команда проверяет продукт на соответствие ТЗ и баги, чтобы исправить всё до релиза.
5. Поддержка. Продукт выпускают и поддерживают его работоспособность на рынке. Разработчики собирают обратную связь от клиентов и улучшают продукт, например, добавляя новые функции.

Какие плюсы есть у подхода

Каскадный метод хорошо подходит для крупных проектов, в которых важно точное планирование и четкое следование ТЗ. Например, при строительстве дома нельзя вносить изменения в проект каждую неделю. Чтобы дом не рухнул, нужно следовать изначальному плану. Также Waterfall подойдет проекту, потому что:

• Естьопределенность в сроках и бюджете. Стоимость продукта и сроки сдачи проекта рассчитаны и утверждены в самом начале и не меняются в процессе.
• В доступе у сотрудников естьнесколько инструкций и правил по всему процессу — изобретать велосипед не нужно.
• Waterfall хорошо дисциплинирует сотрудников, благодаря составленному плану, пошаговой последовательности и строгому менеджменту.
• Гибкость на ранних этапах. Можно легко вносить изменения до этапа разработки.
• Метод устойчив к обновлению кадров. Благодаря четкому планированию и документации можно быстро погружать новых сотрудников в проект.

Чем плох Waterfall

Каскадный подход может не подойти вашему проекту, потому что:

• Есть зависимость команд друг от друга. Если одна из команд не успеет выполнить работу к поставленному дедлайну, то это отразится не только на работе их коллег, но и на релизе будущего продукта.
• Тестирование — один из последних этапов разработки. Ошибку разработчика можно заметить слишком поздно. А откатиться к прошлому этапу для ее исправления сложно и дорого.
• Чаще всего финальный продукт не ориентирован на клиента и заказчика, т.к. их полностью изолируют от процесса разработки.
• Низкая вовлеченность в команде. Сотрудники меньше вовлечены в командный проект, потому что каждый работает сугубо над своими задачами, общаясь с коллегами по минимуму.
• Нет самоуправления. Из-за того, что все работают по оговоренному регламенту и определенным инструкциям, нельзя проявлять инициативу и изменять рабочий процесс.

Методология Agile

Agile — целое семейство гибких методологий управления проектами. Философию Agile характеризуют гибкость, скорость и прозрачность рабочих процессов.

В отличие от метода Waterfall с «вытекающими» друг из друга этапами и жестким планированием, Agile-подход хорошо реагирует на изменения. Так как вся работа над задачами ведется параллельно саморганизованными командами, доработки и правки ошибок можно вносить на ходу.

Документация не так важна в Agile, как в каскадном подходе. Но это не значит, что «работать по Agile = работать без документов». В таких командах тоже есть документация, но основной упор делается на работающий продукт.

Управление проектами в Agile разделяют на этапы и устанавливают сроки к задачам. Это делает работу над продуктом наглядной и прозрачной, что хорошо сказывается на общей продуктивности команды.

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

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

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

Преимущества Agile

Начнем с плюсов. Благодаря Agile-методологии:

• Команда открыта к изменениям. Из-за гибкости, можно быстро реагировать на изменения и вносить их, чтобы создать полезный продукт для клиента.
• Снижается вероятность провала, потому что тестирование и сбор обратной связи от заказчика проходят после каждого спринта.
• Увеличивается вовлеченность команды. Благодаря постоянному взаимодействию сотрудников и отсутствию микроменеджмента, каждый участник видит свое влияние на проект.
• Сокращается рутинная работа в духе скрупулезного ведения документов, в которых фиксируется каждый шаг. На первом месте всегда будет работающий продукт.
• Улучшается коммуникация между сотрудниками. Прозрачные рабочие процессы и общение на равных, где ценен каждый голос, — это философия работы всей команды.

Недостатки подхода

Некоторые разработчики не в восторге от Agile, потому что:

• Нет четкого плана для проекта. Заказчик может вносить новые требования к продукту в ходе разработки, и финальный продукт может сильно отличаться от того, что было запланировано вначале.
• Нужна постоянная коммуникация. Некоторым сотрудникам комфортнее работать в одиночку и отчитываться перед руководством после завершения проекта. У заказчика же может просто не быть времени, сил или желания постоянно давать комментарии и общаться с командой.
• Сложное погружение новых сотрудников. Из-за того, что команда работает небольшими итерациями, нового коллегу придется погружать в несколько прошедших периодов — это огромный объем информации.
• Проделанная работа может пропасть. Согласно Agile, если продукт потеряет ценность для клиента, команда должна изменить цель проекта. В этом случае почти вся проделанная работа может кануть в лету. Этот момент может тяжело даться сотрудникам и «добить» их мотивацию.

Waterfall vs Agile

Выбирайте Waterfall, если

Выбирайте Agile, если

Заказчик знает, чего хочет. И у него есть проработанная концепция, которую точно не нужно менять

Команда готова адаптировать продукт под меняющиеся требования клиента

Разрабатывается сложный продукт, у которого есть четкая последовательность разработки

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

Заказчик планирует отдать ТЗ проекта разработчикам и не хочет участвовать в каждом этапе проекта

Заказчик хочет активно участвовать в жизни проекта: посещать встречи и давать комментарии

Команда уже создавала аналогичный продукт, а значит вся работа поставлена на поток

Сотрудники работают над новым продуктом, из-за чего приходится тестировать новые гипотезы и пробовать новые методы в работе

Что нужно знать об Agile-методиках

Kanban и Scrum — это методики Agile, они имеют сходства:

1. Команды Scrum и Kanban — самоорганизованные и кросс-функциональные.
2. Оба подхода визуализируют работу с помощью досок: виртуальных или реальных.
3. Обратная связь о проделанной работе очень ценна. С ее помощью сотрудники могут быстро адаптироваться к изменяющимся бизнес-требованиям.
4. Всем участникам команды нужно работать вместе: обсуждать продукт, решать проблемы и обмениваться опытом.
5. Благодаря прозрачным рабочим процессам, команды постоянно совершенствуются.
6. Задачи берутся в работу в зависимости от их приоритета, который определяется ценностью продукта для клиентов и бизнеса.

Scrum

Scrum — фреймворк для Agile-управления проектами. Каждый проект разбивается на небольшие итерации продолжительностью от 1 до 4 недель — спринты. Если спринт уже начат, то в него не должно вноситься изменений — не получится добавить новые задачи в текущий спринт.

Стандартная Agile-команда включает в себя:

• владельца продукта — посредника между клиентов и командой;
• скрам-мастера — специалиста, помогающего выстроить коммуникацию на встречах и работать согласно ценностям Agile;
• команды разработчиков — группы специалистов, отвечающих за реализацию ТЗ.

Для улучшения рабочего процесса, каждый этап спринта сопровождается встречами:

• планирование,
• daily-встречи,
• обзор и тестирование,
• ретроспективы.

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

Подробнее о Scrum читайте в этой статье.

Kanban

Kanban — это способ управления рабочим процессом, основанный на визуализации целей, задач и прогресса.

Если Scrum-команда разбивает проекты по времени, то команда, которая работает по Kanban-методу, разбивает проекты на этапы рабочего процесса с помощью канбан-доски.

Каждый столбец такой доски представляет этапы работы, которые проходит задача на пути к завершению. Например:

• «В плане»,
• «В работе»,
• «Готово».

Каждая рабочая задача — это карточка на доске, которая постепенно перемещается слева направо. К примеру, можно визуализировать на доске ключевые этапы разработки сайта: «В очереди», «Проектирование», «Дизайн», «Верстка», «Тестирование» и «Готово».

Как правило в работу берется ограниченное количество одновременно выполняемых задач. Делают это с помощью WIP-лимитов. Суть в том, чтобы не брать в работу новые задачи, пока начатные не будут завершены. Удивительно, но чем меньше задач одновременно находится в работе, тем больше команда сможет выполнить.

Итого

Каждый подход к управлению проектами имеет сильные стороны, которые лучше всего подходят для различных ситуаций:

1. Waterfall подойдет для проекта с четким требованиями, а жесткая структура позволит сократить количество совещаний, необходимых во время выполнения.
2. Agile подойдет для проектов, ориентированных в первую очередь на клиента с многими переменными или меняющимися условиями.

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

Фреймворк Scrum подойдет для проектов и команд, которые:

• Работают в условиях неопределенности и создают новый продукт, экспериментируя в разработке.
• Хотят чаще и быстрее выпускать продукт или его новые версии.
• Заинтересованы в сборе обратной связи от клиентов и хотят постоянно корректировать продукт.
• Не привязывают запуск продукта к конкретной дате.

Kanban-метод подойдет для команд, которые хотят:

• Визуализировать рабочие процессы.
• Анализировать проделанную работу и точнее прогнозировать результат.
• Распределить роли в команде и грамотно регулировать нагрузку как на каждого сотрудника, так и на команду в целом.
• Найти узкие места в рабочем процессе и избавиться от буксующих задач.

Подробнее о двух популярных фреймворках и их преимуществах мы рассказали здесь.

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

Внутри Kaiten есть все необходимые инструменты для работы по Agile, Scrum и Kanban

Похожее

Управление

Как и чем мотивировать сотрудников? HR-эксперт рассказывает про новые тренды нематериальной мотивации

Разберем особенности и примеры материальной и нематериальной мотивации сотрудников и расскажем, какие тенденции в системе мотивации ждать в следующем году

Irina Filyakina 21 дек. 2023 г. • 5 min read

Управление

Управление этапами проекта: как сделать работу прозрачной на всех стадиях

Рассказываем, как при помощи Kaiten контролировать жизненный цикл проектов и помогать команде вовремя закрывать задачи

Дарья Литвинова 19 дек. 2023 г. • 7 min read

Управление

Стили руководства: управляем командой осознанно

Разбираемся в основных стилях руководства: как выбрать подходящий для создания нужной атмосферы в коллективе и эффективного управления командой

Дарья Литвинова 6 дек. 2023 г. • 7 min read

Новое

Kaiten в 2024: куда мы пришли и что будет дальше

Привет, на связи команда Кайтен! Хотим рассказать о значимых событиях уходящего года и поделиться планами на 2024 — как будет развиваться сервис, и какие новые функции появятся в скором времени.

Дарья Лебедева 22 дек. 2023 г. • 4 min read

Как и чем мотивировать сотрудников? HR-эксперт рассказывает про новые тренды нематериальной мотивации

Разберем особенности и примеры материальной и нематериальной мотивации сотрудников и расскажем, какие тенденции в системе мотивации ждать в следующем году

Irina Filyakina 21 дек. 2023 г. • 5 min read

Управление этапами проекта: как сделать работу прозрачной на всех стадиях

Рассказываем, как при помощи Kaiten контролировать жизненный цикл проектов и помогать команде вовремя закрывать задачи

Чем Канбан отличается от Scrum, и причем тут Agile

Когда-то давно Скрам и Канбан органично жили под одним брендом Agile.
Однако, по мере развития Канбан-метода, его создатели поняли, что он должен базироваться на других принципах, нежели Scrum. Было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно, и надо его из-под «зонтика Agile» вывести

Примерно в 2015-2017 годах создателями Канбан-метода было принято решение развивать концепцию Business Agility — в противовес понятию Agile. И с этого момента Канбан-метод начал позиционировать себя как альтернатива Agile-подходам , а не их часть

В этих нюансах не так просто разобраться тем, кто впервые интересуется Scrum и Канбан и поэтому мы решили написать эту статью, чтобы расставить все точки над «Ё».

Рассмотрим основные различия между Kanban-методом и фреймворком Scrum с точки зрения смысла, назначения и практики применения этих подходов.

Разница с точки зрения смысла

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

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

Разница с точки зрения целей

Scrum изначально создавался, чтобы быстро разработать «то, не знаю что» — какой-то инновационный продукт, подобных которому может еще даже в мире не существует. В этом главная цель и назначение Scrum.

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

Kanban-метод ставит своей конечной целью дать возможность целым компаниям быстро реагировать на изменения рынка — это и есть Business Agility. Канбан-метод делает это за счет такого построения рабочих процессов, которое позволяет быстро перестраиваться под новые реалии, гибко перебалансируя ресурсы, приоритеты, загрузку и т.д. Чтобы этого достичь требуется использовать целостный взгляд на компанию, для того, чтобы увидеть, где именно кроются препятствия и заторы , не позволяющие работать быстро и гибко.

Можно конечно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility

То есть, применение Канбан-метода стратегически нацелено на изменения во всей компании, для обеспечения долгосрочной устойчивости и гибкости на рынке (Business Agility). А главной целью фреймворка Scrum является разработка нового инновационного продукта.

Разница с точки зрения принятия решений

Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.

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

Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.

Для ускорения принятия решений и достижения наилучших результатов 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 и 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-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение.

  

  LeSS — Scrum на больших масштабах

  В Large-Scale Scrum (LeSS) кросс-функциональные и кросс-компонентные фиче-команды (feature teams) совместно работают над общим бэклогом продукта, у которого есть один владелец продукта.

  Канбан-метод рассматривает все как сервис и поток задач, о котором мы собираем данные, анализируем и принимаем решения. Поэтому на большом масштабе главная задача Канбан-метода — сделать простым сбор данных на всем протяжении производственной цепочки (от момента зарождения идеи в голове бизнеса до момента продажи и поставки продукта клиенту). А это может быть очень длинный путь, который, скорее всего, включает в себя множество отделов, департаментов, подразделений.

  Если попытаться “запихнуть” работы всех этих подразделений в одну Канбан-доску и проводить возле нее Канбан-встречи со всеми вовлеченными людьми, то получится сложная и дорогостоящая встреча. Поэтому придумывают разные варианты визуализации потока задач “по частям”, с обязательными встречами по синхронизации между этими частями.

  

  На рисунке показаны разные типы встреч, которые могут присутствовать в Канбан-методе.

  Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).

  Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев

  С другой стороны, на разных уровнях иерархии надо собирать разные данные.

  На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

  На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.

  На низовом уровне — отслеживать работу конкретного отдела (команды, рабочей группы) над конкретными задачами, входящими в проект.

  Чтобы связать данные по всем этим уровням между собой, придется создавать иерархию Канбан-досок, которые будут связаны между собой по вертикали, от стратегического уровня до тактического и обратно. Чтобы обеспечить синхронный сбор данных, прозрачность и актуальное состояние Канбан-досок на каждом уровне, нужно будет проводить координационные встречи не только “по горизонтали”, но и “по вертикали”.

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

  Заключение

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

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

  

  Сравнение выгод от Scrum и Канбан

  По данным исследования Agile в России

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

  Похожие публикации:

  1. Windows admin center что это
  2. Как добавить спрайт в unity 2d
  3. Как поставить кавычки елочки на клавиатуре
  4. Как сохранить песню из ватсап на телефон