Kanban, Agile, Scrum – что выбрать для управления проектами

Артур Нек

Управляющий партнер Kaiten

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

Когда стоит задуматься об оптимизации или смене привычной в компании системы управления? Тогда, когда меняется внешняя среда (например, становится больше конкурентов), меняются потребности клиентов – уровень привычного обслуживания их уже не устраивает. В общем тогда, когда нужно успевать за темпами стремительно меняющегося рынка. 

Давайте разберемся в современных подходах к управлению проектами и процессами в компании.

Scrum: что это и зачем нужен

Scrum – это самый популярный подход в управлении проектами, он начал развиваться с 1995 года. Основоположники этого метода Кен Швабер и Джефф Сазерленд создали его первоначально для IT-проектов. Но впоследствии оказалось, что он применим для любых других. Scrum представляет собой фреймворк-практику, в рамках которой есть предписанные активности, которые нужно выполнять, и предписанные роли: продукт-оунер, скрам-мастер, команда.

Продукт-оунер – человек, который отвечает за выстраивание приоритетов разработки продуктов. Скрам-мастер – человек, который помогает команде стать самоорганизованной, можно сказать, что это наставник команды. Особенность команды в Scrum в том, что любой ее участник равноценен и владеет полной информацией о продукте: может клиенту рассказать полностью про продукт, а не только про тот сегмент, над которым он работает; получить обратную связь и обсудить ее с командой, участвовать в выработке совместного решения.

Есть в рамках Scrum определенные артефакты: спринт-бэклог, бэклог, инкремент продукта и другие (все их можно посмотреть в Scrum-гайде). То есть это некоторая рамка процесса, который предписывает как нам нужно действовать, причем с определенной частотой – в виде спринтов.

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

Классическое проектное управление

Другая категория инструментов – это классические проектные подходы. Проверенный временем метод – им руководствуются в сфере управления проектами уже десятки лет. И он эффективно работает, когда неопределенность гораздо ниже: когда вы понимаете, какие входные требования, какие ограничения, когда результат более понятен и можно построить план на длительный период. То есть проектные подходы помогают эффективно организовать планирование на длительный период, когда понятен образ результата.

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

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

Agile: что это и зачем нужен

А какое же место занимает в ряду проектных практик Agile? Тут важно понимать, что Agile – как раз совсем не практика, это философия управления проектами. Которая возникла в том числе под влиянием успешного внедрения Scrum.

Как возник Agile?

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

Выделяют 4 ценности:

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

И 12 принципов Agile:

• Потребности клиентов на первом месте.
• Корректировка требований к продукту/проекту в ходе разработки.
• Следование обозначенным дедлайнам.
• Сотрудничество между заказчиком и исполнителем.
• Поддержка и мотивация для всех, кто работает над проектом.
• Эффективное взаимодействие между разработчиками.
• Метрики для измерения прогресса и результатов.
• Придерживаться темпа работы, чтобы не срывать установленные сроки по проекту.
• Уделять внимание как техническим деталям, так и дизайну.
• Налаживание простого и понятного рабочего процесса.
• Коллегиальность принятия решений: не только руководство, но и все участники проекта могут влиять на процесс принятия решений.
• Адаптация к постоянно меняющейся среде и гибкость.

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

То есть нужно понимать, что Scrum – это практический метод, а Agile – культура, базирующаяся на этом и других подобных методах (XP, TDD). То есть нельзя работать по Agile, но можно разделять принципы и ценности Аджайла.

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

Kanban: что это и зачем нужен

Как появился Kanban, и как он соотносится с Agile и Scrum? В 2004 году выходец из компании Microsoft Дэвид Андерсон придумал подход, который бы позволял разгрузить разработчиков от большого количества задач, сделать их работу более комфортной. За основу он взял идеи компании Тойота, объединенные термином «бережливое производство». Но изначально они были придуманы для автомобильного производства с принципом конвейера, а Андерсон попробовал творчески их интерпретировать и переложить на IT-разработку. Так появились Kanban-доски, Kanban-стикеры и другие наборы практик, которые стали называться впоследствии Kanban-методом.

Kanban подходит только для интеллектуальной деятельности, не для производства, где делают что-то руками. Kanban не является фреймворком, как Scrum. Kanban – это «улучшайзер» к процессам. Там есть различные инструменты (их около 150), которые можно применять к любым интеллектуальным процессам, чтобы улучшать их понимание, и клиентский сервис.

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

В Канбане 6 основных категорий:

• визуализация;
• ограничение незавершенной работы;
• петли обратной связи;
• явные правила;
• управление потоком;
• управление изменениями на основании моделей и данных.

Главные условия для применения Kanban-метода: это интеллектуальная деятельность (не когда мы делаем что-то руками) и возможность визуализировать процессы (с помощью карточек, стикеров или графиков работы). При помощи Kanban можно улучшать и Scrum-процессы и методы управления проектами.

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