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

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

Что же такое Agile и Scrum?

С английского agile переводится как «гибкий». То есть Agile означает гибкие методологии выполнения проектов. Мы говорили об этом ранее, поэтому открытием для вас это не должно быть. Но почему гибкие? И почему классические подходы к управлению проектами не гибкие?

waterfallДля начала рассмотрим, что же такое классический подход к управлению проектами. В профессиональной среде он называется «водопад» (waterfall). Это связано с тем, что выглядит он как водопад. Посмотрите на картинку слева, на ней отчетливо видны ступеньки. При определенной доле воображения можно увидеть воду, которая стекает по этим ступенькам на манер водопада.

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

  • Представляем себе то, что должно получиться в результате: автомобиль D-класса с автоматической коробкой передач, кожаным салоном, расходом топлива не более 14 л/100 км и стоимостью владения не больше 15 руб/км
  • Спланируем нашу работу
  • Начнем подбирать модель, изучая сайты производителей и интернет-площадки
  • Выберем несколько моделей, которые подходят для нас и попробуем поездить на них, протестируем, изучим особенности моделей и опыт эксплуатации другими людьми
  • Сделаем выборку, короткий список, с которым будем работать более детально: изучим, пообщаемся с владельцами или менеджерами продаж, узнаем особенности, договариваемся о покупке, заключаем договор
  • Вносим оплату и ожидаем поступления автомобиля
  • Забираем автомобиль, оформляем документы
  • Наслаждаемся поездками на своем новом автомобиле

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

agileЧем же отличается методология выполнения проектов по адаптивному жизненному циклу. Именно так в PMBoK называется Agile.

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

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

В-третьих, как правило, подобные подходы довольно сильно бюрократизированы. В данном случае бюрократия используется как средство коммуникации: внутри проектной команды, между проектной командой и заказчиком, между заказчиком и спонсором и так далее. До 70% времени уходит на документирование. А потребитель не видит прототипа, которые уже близко похож на ожидаемый результат.

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

Итак, решая эти задачи, нам необходимо выработать систему выполнения проектами, которая бы:

  1. Как можно раньше показывала потребителю первый прототип
  2. Передавала потребителю продукт как можно раньше
  3. Снизила бюрократию
  4. Сократила время выполнения проекта

В наше время бизнес-проектов крайне важно было найти такую технологию. И ее нашли. Именно этим пунктам удовлетворяет Agile. Но в чем же ее смысл?

Главный принцип Agile — итеративность. Проект выполняется итерациями. Каждая итерация — это небольшой, от 1 недели до 4, проект. Со своим открытием, планированием, выполнением, мониторингом и контролем и закрытием. При этом на каждой итерации потребитель получает результат, который может использовать. Возможно, он будет неполноценный. Возможно, в нем будут ошибки. Но заказчик и потребитель смогут своевременно дать обратную связь по нему и скорректировать его разработку. При этом они смогут пользоваться полученным результатом.

Давайте посмотрим, как это может выглядеть с примером о покупке автомобиля как примером проекта.

  1. Мы решили купить автомобиль. Условия — те же.
  2. Находим несколько вариантов (любых, подходящих изначальным требованиям)
  3. Едем и смотрим варианты, смотрим, подходит или нет
  4. Если не нашли решения (результат), уточняем требования и возвращаемся к п.2

И так до тех пор, пока не найдем нужный вариант. Мы можем найти нужный вариант на 1-й итерации, а можем не найти и на 100-й. Таким образом, правильно применяя эту технологию, можно обеспечить наиболее быстрый эффект для бизнеса. Главное — следовать технологиям. Описание технологии можно найти довольно просто в интернете, поэтому раскрывать в рамках этой статьи мы не будем.

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

  • Ограничено количество участников проектной команды, что ограничивает скорость; в противном случае затраты на коммуникации будут расти в геометрической прогрессии и удельный вес работ по обмену информацией станет превышать полезную работу
  • Чем больше людей участвует со стороны заказчика (например, отделов компании), тем сложнее выявлять противоречия, также как в предыдущем случае растет удельная доля затрат на коммуникации, а также тем больше противоречий; чем больше противоречий в разработке продукта, тем больше вероятность появления задач изменения ключевой архитектуры; это приводит к тому, что продукт перерабатывается много раз, то есть появляется большое количество работы, которая не ведет к созданию ценности
  • Оценить срок выполнения работ (как контролировать проект через контрольные события — читайте здесь) практически невозможно; точно оценить влияние конкретных факторов на конечный результат практически не представляется возможным; соответственно, сформировать конкретный бюджет также очень сложно

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

Бизнес чаще всего ориентирован именно на такой подход. Даже стандарт системы менеджмента качества ISO 9001:2015 во многом ориентирован на такой подход. В этом и кроется основной парадокс проектов: заказчик пытается перевести работу к этой технологии, при этом бюджет и срок, как правило, фиксированы. И разрешение этого конфликта интересов крайне редко завершается в пользу проекта. Поэтому мы еще раз обращаем ваше внимание на необходимость принятия взвешенного решения о применении конкретного подхода к проекту.

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

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

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