Методика Agile. Настолько ли много отличий?

Часто спрашивают о том, как можно выполнять проекты. Мол, путей много, непонятно как выбрать. Но мы задумались, а так ли это? Насколько разношерстные методики выполнения проектов существуют на текущий момент? Классический «водопад» (каскад), Agile, Scrum, kanban, scrumban и прочие. Как сориентироваться в этом изобилии терминов и принципов? В это статье мы решили раскрыть нашу точку зрения на то, что лежит в основе всего сущего, точнее — проектов.

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

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

Какими методиками управления проектами вы пользовались в своих проектах?

View Results

Загрузка ... Загрузка ...

В более ранних статьях мы говорили о том, что есть всего два типа выполнения проектов — когда план управляет проектом (предикативный, «каскадная» модель) и когда проект управляет планом (адаптивная, «спиральная» модель). В целом, мы не изменили своего мнения. Более того, мы только убедились в этом: все существующие на сегодняшний день методики представляют собой ответвления от указанных подходов. Не так ли?

Но если погрузиться немного дальше, и начать рассуждать о природе гибких методологий Agile, Scrum, kanban — называйте как угодно? Из чего состоит проект по гибким методологиям? Он состоит из спринтов — ограниченных во времени или в объеме работ, которые необходимо достичь в ходе проекта. Да, мы не знаем, какой получим в итоге результат. Но это и не важно!

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

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

А что такое итерация? У каждой итерации есть начало (инициация?), планирование (одноименное название в «водопаде»), выполнение (то же), контроль (мониторинг и контроль), ретроспектива и завершение (завершение). Это проект.

То есть, проект по Agile, по большому счету, представляет собой программу небольших по своей сути проектов. Одно «но» — их содержание формируется динамически.

Неудивительно, что PMI до конца сопротивлялась включению гибких методологий управления проектами в PMBoK. Только в 5-й редакции появилось упоминание об этом.

Тем не менее, вывод очевиден.

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

Есть еще один довод. Это принципы методики Agile, так называемый манифест.

Основные идеи:

  • люди и взаимодействие важнее процессов и инструментов;

  • работающий продукт важнее исчерпывающей документации;

  • сотрудничество с заказчиком важнее согласования условий контракта;

  • готовность к изменениям важнее следования первоначальному плану.

Разберем по порядку.

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

«Работающий продукт важнее исчерпывающей документации». Многие эту идею интерпретируют так, что при таком подходе вообще не требуется ничего документировать. К сожалению, это не так. Как бы то ни было, документирование — естесственный  самый простой способ коммуницирования различных сторон и участников процесса. То есть совсем без документов обойтись невозможно. Но и подход к управлению по методологиям «водопада» не отрицают рационального использования документов. Иными словами, если разработка документа требует больше сил, нежели получаемый от него эффект, то смысла в его разработке нет. Это никоим образом не противоречит идее, а, скорее, подтверждает ее. Если у нас проект не более 1 месяца, постоянно меняющаяся бизнес-среда, то разработка документов по управлению для нас — пустая трата времени.

«Сотрудничество с заказчиком важнее условий контракта». Это, конечно, любимый пункт юристов. И спасает таких «идеологов» только одно — короткое время спринта. То есть вы рискуете не большими суммами денег в случае крупного контракта, а только стоимостью спринта. Наверное, можно себе позволить рискнуть такой суммой. Тогда и документы не нужны в большом объеме. С другой стороны, непонятно, где гарантии качественной проработки проекта и удовлетворенности заказчика? Ответ прост: в StandUp Meeting.

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

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

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

Вам также может быть интересно

Добавить комментарий