Классический подход к управлению проектами часто называют океан озеро водопад

Agile и «водопад». Сравнение подходов

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

Что такое agile?

Гибкая разработка впервые упоминается в опубликованной в 1970 г. статье Уильяма Ройса о создании больших программных систем. Четыре ее фундаментальных ценности и 12 принципов были сформулированы позднее в «Манифесте Agile». Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Каждый цикл нацелен на непрерывное улучшение разработки продукта или сервиса.

Agile предусматривает итеративный и ориентированный на пользователей подход к разработке программного обеспечения и включает несколько стадий. Первая — планирование. Она предполагает совместную работу заказчиков и исполнителей над концептуализацией, определением, приоритезацией, распределением ресурсов и бюджетированием проекта. Вторая стадия — проектирование, в ходе которой заинтересованные стороны определяют, как должен выглядеть продукт и какие необходимые элементы он должен содержать. Далее идет собственно разработка, в ходе которой команда разработки создает продукты короткими итерациями, называемые «спринтами». Тестирование призвано выяснить, соответствует ли продукт требованиям. При выявлении недостатков он возвращается на стадию разработки для устранения проблем перед повторным тестированием. Этот цикл продолжается пока продукт не станет соответствовать спецификациям. Главная особенность подхода agile – постоянная обратная связь между разработчиками, тестировшиками и заказчиком, позволяющая улучшать продукт понемногу, но непрерывно.

Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Фото: ru.depositphotos.com

Для того, чтобы команда разработки была способна работать в agile, она, по мнению Мойры Александер (Moira Alexander), должна соответствовать ряду критериев. Команды гибкой разработки должны уметь фокусироваться на запросах пользователей, адаптироваться к изменениям и быть способными работать «под давлением». От участников команды требуются развитые навыки командной работы и сильное чувство ответственности не только перед командой, но и перед заказчиком.

Что такое «водопад»?

Каскадная методология, или «водопад», также используется при разработке продуктов, но процесс разработки носит линейный характер и выполняется в предопределенной последовательности от начала до завершения проекта и предоставления результатов. Этапы «водопадной» разработки схожи с вышеописанными этапами agile-разработки. Также есть этап сбора и анализа требований; этап проектирования, на котором определяется, как должен выглядеть продукт и какие необходимые элементы он должен содержать. После разработки продукта идет его тестирование и приемо-сдаточные испытания для определения соответствия предопределенным требованиям. Выявленные недостатки и ошибки устраняются перед поставкой продукта. Потом следует представление заказчику финальной версии продукта (в соответствие со спецификациями). После чего он передается клиенту, дальнейшая поддержка и доработка возможна за дополнительную плату (если какой-то ее объем не был внесен в договор).

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

Agile или «водопад»: за и против

Оба метода разработки имеют свои достоинства и недостатки. Основные из них Мойра Александер свела в таблицу.

Достоинства и недостатки «гибкого» и «традиционного» подходов к разработке

Источник

Waterfall или Agile: как выбрать методологию управления проектом?

Привет! Я — Алиса Корнева — менеджер проектов в компании Azoft. Занимаюсь управлением проектов больше 8 лет. По моему опыту, выбор методологии управления проектом часто лидирует в списке холиварных вопросов клиента и команды. В этой статье поделюсь с вами своими мыслями на эту тему, без купюр и фаворитизма.

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

Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:

Получается, план такой:

  • Установили и прояснили требования заказчика и согласовали их с командой;
  • Подготовили весь дизайн проекта;
  • Разработали программное обеспечение целиком по заданным технологиям;
  • Протестировали проект на наличие багов;
  • И только после всех предыдущих, последовательных этапов —запустили в эксплуатацию.

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

Agile (гибкие) – это семейство методологий, объединенных ценностями и принципами Agile-манифеста.

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

Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.

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

Жизненный цикл проекта в этом случае – это набор итераций, каждая из которых включает в себя мини-версию разработки проекта командами по методу Waterfall.

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

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

Читайте также:  Санаторий изумруд озеро кисегач

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

Характеристики проектов, подходящих под разные методологии можно обозначить так:

Скоуп и требования-

Waterfall — понятны и меняться не будут;

Гибкие методологии — меняются по ходу работы;

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

Waterfall — похожая задача уже решалась заказчиком/исполнителем, продукт не инновационный;
Гибкие методологии — для заказчика/исполнителя это качественно новая задача, либо продукт инновационный;
В чем подвох — в новой для себя области гораздо проще упустить что-то важное. Для Waterfall будет сложнее вносить изменения в исходные требования.

Waterfall — требования к проекту в процессе работы не будут значительно меняться;

Гибкие методологии — планируется применять Customer development (тестирование идеи или прототипа будущего продукта на потенциальных потребителях), тестировать гипотезы на рынке, в процессе проекта управлять приоритетами, опираясь на фокус-группы;

В чем подвох — по аналогии с первыми пунктами – здесь все упирается в потребность гибко управлять требованиями. Если нет такой потребности – Waterfall ваш вариант.

Waterfall — жестко ограничен;

Гибкие методологии — можно варьировать в заданных рамках;

В чем подвох — если в Waterfall все идет по плану, то бюджет и срок проекта можно определить после этапа аналитики по проекту. При этом бюджет первичен, и после завершения аналитики он будет определять срок. То есть последовательность такая: бюджет -> аналитика -> срок.

Waterfall — жестко ограничен и определен до этапа аналитики;

Гибкие методологии — может варьироваться;

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

Если проект характеризуется признаками только из одной колонки – можно смело выбирать соответствующую методологию проекта и не греть голову. Но что, если все сложнее (как и бывает в большинстве случаев)? Тогда на помощь приходят гибридные методологии управления проектами! Мы уже писали про свой опыт работы с ними на примере разработки портала «Спасибо от Сбербанка. Путешествия». Советуем ознакомиться, чтобы узнать подробнее когда и зачем их применять.

Большинство проектов Azoft управляются с помощью гибридной, индивидуально подобранной под проект методологии.

Для нас важно, чтобы инструменты управления использовались не «для галочки», и не потому, что это декларировано в PMBook, а для того, чтобы решить задачи проекта.

Объясняем, когда и как внедрить практики из разных методологий, чтобы в результате собрать актуальный для вашего проекта «гибрид»:

  • По ходу проекта появляются задачи, которые не вписываются в рамки исходной постановки задачи, но когда-нибудь в будущем хочется их сделать? Внедряем backlog (журнал оставшейся работы, которую необходимо выполнить команде), куда складываем все такие задачи. Даже если проект управляется по Waterfall, будет удобно вернуться к задачам после завершения проекта.
  • В проекте много рисков? Внедряем матрицу управления рисками – стандартный артефакт Waterfall-проекта. Даже если проект ведем по Agile-фреймворку, можно параллельно использовать практики каскадной модели управления проектом.
  • Исходная постановка задачи простая и понятная, а вот после выхода на рынок планируется кастомизировать продукт под потребности пользователя? Можно реализовать первый этап проекта по Waterfall, а поддержку и развитие вести спринтами, по гибкой методологии управления.
  • Выбрали Waterfall, но при этом заказчику важно оставаться включенным в процесс и регулярно проводить ревью результатов работы? Добавляем плановые демонстрации (промежуточные отчеты), как в Scrum.
  • Хочется «протестировать» гибкий подход управления проектом, и потом уже решать, какую методологию выбрать? Тогда можно начать с работ по аналитике и документированию: составить список User Stories, приоритизировать их и прояснять последовательно (это вариант работы с backlog задач в гибких методологиях). При этом целиком проект можно вести по Waterfall, и приступить к разработке только после полного завершения работ по аналитике. К тому же, такой подход дает максимальную вовлеченность заказчика на старте проекта, что сильно снижает вероятность ошибки в процессе дальнейших работ по проекту.

Как сделать подходящий к проекту гибрид:

  1. Сначала придется выбрать исходный фреймворк управления проектами, который будем менять. Сверяемся с данной выше табличкой и личным опытом, либо выбираем фреймворк, с которым команда/заказчик работали раньше.
  2. Определяем «слабые места» фреймворка применительно к текущему проекту. Что именно хочется улучшить в управлении? Какие важные области оказались не покрытыми? Здесь еще можно вернуться на шаг назад и выбрать другую методологию.
  3. Решаем проблемы выбранного фреймворка с помощью других фреймворков. Адаптируем их к текущей ситуации.
  4. Рассказываем про все изменения стандартных процессов команде, а также фиксируем их в общем доступе. Если процессы будут для членов команды новыми, они смогут освежить их в памяти в любой момент.
  5. По ходу проекта периодически возвращаемся к формату управления процессами и сверяемся с целями: достигаются ли они за счет выбранных инструментов? Появились ли новые потребности? Возможно, предыдущие условия стали неактуальными? Эволюция фреймворка управления проектом – это непрерывный процесс, работа с которым поможет реализовать проект эффективнее.

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

Читайте также:  Базы отдыха на исетском озере

Источник

Методологии управления проектами: водопад, эджайл

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

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

Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).

В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.

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

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

Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:

  • Купить саженец
  • Выкопать яму
  • Поставить в нее саженец
  • Присыпать землей
  • Полить дерево

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

Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:

  • Написать техническое задание
  • Нарисовать дизайн
  • Сверстать дизайн
  • Закодить
  • Протестировать
  • Запустить проект

Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.

“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.

Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.

Этапы производства (представим, что каждый этап занимает ровно спринт):

  • Построить коробку со стенами и потолком
  • Построить крышу и закатать стены штукатуркой
  • Поставить двери и окна в дом
  • Провести электричество, воду, канализацию
  • Постелить ламинат, поклеить обои
  • Завезти мебель и телевизор
  • Впустить кота

Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.

Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.

Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.

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

Читайте также:  Детские отели на озерах

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

В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.

Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.

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

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

Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.

Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.

Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.

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

Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).

Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.

“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.

«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.

“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.

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

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

Источник

Поделиться с друзьями
Байкал24