Блог

Сравнение Agile, Scrum, Kanban в качестве эффективных методов управления проектами

29.04.2019

Вопросы, рассмотренные в материале:

  • Какие существуют популярные системы управления проектами
  • В чем преимущества и недостатки классического метода управления
  • В чем плюсы и минусы Agile, Scrum, Kanban
  • В чем различия между Agile, Scrum, Kanban

Определение терминов управления проектами: Agile, Scrum, Kanban

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

Сравнение Agile, Scrum, Kanban

Нужно составить представление о некоторых терминах, перед тем как заняться сравнением Agile, Scrum, Kanban как самых популярных из существующих подходов к проектному менеджменту.

Базовые термины проектного управления:

  1. Agile: гибкий итеративно-инкрементальный метод проектного менеджмента с динамическим формулированием требований, выполнение которого ведется за счет непрерывного взаимодействия рабочих групп. В последние входят специалисты разных профилей. Если проводить сравнение Agile с другими методами, становится ясно, что его идеи стали основой для множества методик, например, Scrum, Kanban.
  2. Критический путь: непрерывный цикл действий, требующий самого продолжительного срока на его осуществление.
  3. Событийная цепочка процессов (EPC-диаграмма): диаграмма, в которой отображается ход проектов в соответствии с доступностью ресурсов.
  4. Резерв времени: промежуток времени, на который можно задержать старт работ, не влияя на срок сдачи проекта. У критического пути такого резерва нет.
  5. Веха (контрольная точка, milestone): ключевое событие, которое на диаграмме Гантта выглядит как задача, не имеющая продолжительности. Вехой может считаться конец этапа.
  6. Менеджер проекта (руководитель проекта, project manager, PM): управленец группы проекта, он отвечает за планирование, реализацию, закрытие проекта.
  7. Ресурсы: это время, оборудование, материалы, специалисты, пр. – то есть все составляющие, без которых успешная работа не представляется возможной.
  8. Содержание проекта (Scope): описание всех работ, запланированных на время осуществления проекта.
  9. Спринт (Sprint): итерация (рабочий цикл) в Scrum, на которую дается неделя – месяц. За него создается рабочая версия продукта/его элемент, который можно передать заказчику.
  10. «Классическое» или «традиционное» проектное управление: самый распространенный вариант управления проектами, в основе которого лежит «водопадный» (Waterfall)/каскадный цикл, где задача последовательно движется по фазам.

Далее рассмотрим ряд подходов к проектному управлению. Начнем с классического вида – Agile, после чего перейдем к сравнению Scrum и Kanban.

Немного о классическом проектном управлении

Сравнение Agile, Scrum, Kanban

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

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

5 этапов традиционного менеджмента:

Этап 1. Инициация. На совещаниях, собраниях все участники устанавливают требования к проекту. Именно на этом этапе составляется представление о результате работы.

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

Этап 3. Разработка. Во многих случаях этот этап представляет собой часть планирования. Разработка сама по себе обычно свойственна технологической области, так как позволяет выбрать конфигурацию проекта/продукта, способы его создания. Так, если речь идет о сфере информационных технологий, то выбирают язык программирования.

Этап 4. Реализация и тестирование. Осуществляется основная работа по проекту – написание кода, строительство, пр. Для этого используются составленные ранее планы, работа сверяется с выбранными метриками. Во второй части фазы продукт тестируется – проводится сравнение результата с требованиями заказчика и представлением группы на первом этапе. Это позволяет исправить недочеты.

Этап 5. Мониторинг и завершение проекта. На этом шаге можно просто передать результат трудов заказчику либо вести длительное взаимодействие с клиентами по улучшению проекта – все зависит от самого проекта. Если он ведется в сфере клиентского сервиса и ПО, допускается поддержка результатов.

Сравнение Agile, Scrum, Kanban

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

Поскольку такое проектное управление привязано ко времени исполнения задач, проекты осуществляются с использованием инструментов календарно-сетевого планирования. Обычно в ход идет знаменитая диаграмма Гантта, для ее построения и заполнения могут использоваться простые средства, такие как «Excel» и «Smartsheet», или более серьезные программы «Microsoft Project» и «Primavera».

Преимущества и недостатки классического метода управления

  1. Сильные стороны классического проектного менеджмента.
  2. Сегодня принято считать, что водопадный подход устарел, по сравнению с более современными Agile, Scrum, Kanban.Но он продолжает активно использоваться на практике. Сравнение с остальными подходами к управлению проектами позволяет увидеть главный плюс «водопадного» подхода: заказчик и руководство фирмы сразу решают, какой результат нужен в итоге. Раннее включение упрощает работу команды, а реализация проекта становится более стабильной и упорядоченной. Обязательными составляющими «водопадного» метода являются мониторинг показателей, тестирование, что необходимо для реальных проектов различного масштаба.

    Теоретически, при классическом подходе, в сравнении с семейством Agile, минимизируются стрессы, ведь у исполнителей на всех этапах есть запас времени на случай осложнений, рисков. Грамотно осуществленный этап планирования позволяет руководителю представлять, каким объемом ресурсов он будет распоряжаться.

  3. Слабые стороны классического проектного менеджмента.
  4. Главная слабая черта этого подхода – невозможность реагировать на изменения. Руководство «Toyota», создавшей Lean и Kanban, часто критикуют за разработку софта для своей компании на основе этого недостаточно гибкого метода.

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

Альтернативные методы управления: сравнение Agile, Scrum, Kanban

1. Agile.

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

Сравнение Agile, Scrum, Kanban

Избежать подобных трудностей позволяет Agile. Это семейство гибких итеративно-инкрементальных методов проектного управления. Если проводить сравнение с «водопадным» методом, отличие Agile состоит в том, что проект разбивается не на последовательные этапы, а на подпроекты. Именно из последних в дальнейшем складывается ожидаемый результат.

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

Agile стал популярен не так давно, однако сама идея итеративной разработки существует уже долгие годы. Современное название семейство гибких методологий получило в 2001 году, после публикации Манифеста Agile («Agile Manifesto») – он зафиксировал базовые ценности и принципы гибкой разработки ПО. Основными в этом подходе стали командная работа, адаптация, готовность к изменениям.

В чистом виде Agile является не методом управления проектами, а набором идей и принципов их реализации. Все они послужили базой для создания гибких методов или фреймворков (frameworks), таких как Scrum, Kanban, Crystal, пр. Хотя сравнение последних позволяет заметить серьезные отличия между ними, подход к работе остается общим.

Сильные стороны Agile:

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

При работе с Agile нельзя забывать о его основном правиле: «Реакция на перемены важнее следования плану». Быстрая, безболезненная реакция на изменения приводит к тому, что лидеры рынка все чаще делают выбор в пользу более гибких процессов. В отличие от классического подхода, Agile может использоваться для проектов, не имеющих четкого завершения, допустим, для запуска сервиса или блога.

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

Слабые стороны Agile:

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

Работая с Agile, лидер должен проявить знания и упорство, а также от него потребуются серьезные административные ресурсы, вложения. Радует тот факт, что сегодня есть готовые наборы практик, которые упрощают Agile-трансформацию организации. В их число входят Scrum, Kanban и целый ряд других: Crystal, LeSS, SAFe, Nexus.

2. Scrum.

Гибкий фреймворк, появившийся в 1986 году. Считается, что он наиболее структурированный по сравнению со всеми остальными продуктами семейства Agile. Здесь элементы водопадного метода совмещены с гибким подходом к управлению проектами, образуя баланс гибкости и структурированности.

В соответствии с принципами Agile, Scrum делит проект на части, которые заказчик может сразу использовать для получения ценности – они называются заделами продуктов (product backlog). Хотя «задел продукта» является достаточно точным переводом английского термина и используется в профессиональной литературе, на практике его обычно заменяют словом «беклог».

Далее владелец продукта, то есть представитель заказчика в команде, определяет приоритетные составляющие проекта. Самые важные из них должны быть первыми выполнены в спринте – так называют итерации в Scrum, продолжающиеся 2–4 недели. По итогам спринта заказчик получает рабочий инкремент продукта, то есть элементы, которыми уже можно пользоваться. Это может быть сайт с частью функционала или программа, которая уже частично работает.

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

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

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

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

Сравнение Agile, Scrum, Kanban

Структура Scrum состоит из 5 основных встреч:

  • Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): в классическом подходе есть похожий этап, но там он называется этапом планирования. В первый день спринта команда обсуждает, что уже сделано в рамках проекта, что еще нужно предпринять, принимается решение о следующем шаге. Отдельная роль отводится владельцу продукта – в Scrum он устанавливает приоритетные задачи. На первом шаге в Scrum определяют, что получит заказчик после итерации, поэтому данная встреча влияет на ее эффективность.
  • Планирование спринта: владелец сделал свое дело, поэтому сразу после первой встречи команде нужно понять, как она будет идти к цели, что именно будет делать во время итерации. Выбор специалистов среди технологий планирования и оценки ограничивается только одним правилом: инструменты не могут противоречить идеям Scrum.
  • Ежедневные летучки: каждый день, желательно в одно время, команда выделяет четверть часа на то, чтобы обсудить статус задач, состояние проекта. В это время не говорят о вопросах и разногласиях, такие темы прорабатываются лично со Scrum-мастером. Летучка нужна только для обмена информацией, тогда каждый специалист будет в курсе текущего состояния проекта.
  • Подведение итогов спринта: теперь проводится адаптация продукта. Команде нужно представить свое детище всем заинтересованным лицам, ведь только так можно понять, выдерживает ли результат ее работы сравнение с ожиданиями участников, поставленными целями.
  • Ретроспектива спринта: проходит после подведения итогов, но до планирования нового рабочего цикла. На этом этапе важно понять, насколько четко шла работа, какие были проблемы на разных ее этапах. Команда проводит сравнение, чтобы новый спринт оказался более продуктивным.

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

Сильные стороны Scrum:

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

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

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

Слабые стороны Scrum:

Scrum, по сравнению с другими методами из семейства Agile и вне его, выдвигает серьезные требования к команде проекта: она должна быть маленькой (5–9 человек), а у каждого члена команды должно быть более одной компетенции, необходимой в процессе выполнения проекта. Так, разработчику ПО нужны знания в тестировании и бизнес-аналитике. Подобный подход позволяет всем участникам быть задействованными на разных этапах проекта, подменять друг друга при необходимости.

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

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

3. Kanban.

Это детище инженера компании «Toyota» Тайичи Оно (Taiichi Ono), которое увидело свет в 1953 году. При сравнении Kanban с другими методами заметна его схожесть со схемой производства – в нее попадает кусочек металла, а выходит полноценная деталь. Инкремент продукта передается с этапа на этап, а в конце мы получаем готовый к поставке элемент.

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

Сравнение Kanban и Scrum показывает, что первый не столь строг: в нем спринты могут длиться столько, сколько нужно, в нем нет конкретных ролей, единственная точно определенная роль – это владелец продукта. Согласно принципам Kanban, член команды может работать сразу над несколькими задачами, что недопустимо в Scrum. Другое отличие, которое заметно при сравнении Kanban с остальными методами Agile – не регламентируются встречи по статусу проекта, их проводят в удобное время либо вовсе отказываются от этого этапа.

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

Сравнение Agile, Scrum, Kanban

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

  • Карточки: каждая задача в Kanban – отдельная карточка со всеми данными о ней. Это позволяет всегда держать все необходимые сведения под рукой.
  • Ограничение на количество задач на этапе: число карточек жестко регламентируется, поэтому всегда становится заметен «затор», и он сразу устраняется.
  • Непрерывный поток: задачи из беклога попадают в поток в соответствии с их приоритетом, за счет чего работа по Kanban идет непрерывно.
  • Постоянное улучшение (кайзен (kaizen)): концепция постоянного улучшения зародилась в Японии в конце XX века. Она требует постоянного анализа процесса, поиска способов увеличения производительности.

Сильные стороны Kanban:

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

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

Слабые стороны Kanban:

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

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