Главное Свежее Вакансии   Проекты
Комментируемое:
384 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

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

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

Краткий ликбез по Waterfall


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


Этапы методологии Waterfall

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

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

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

Семейство Agile-методологий: в чем главная особенность


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

Ценности Agile:

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

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

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


Схема работы по методологии Scrum

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

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

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

Преимущества и недостатки Waterfall и гибких методологий


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


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

ХарактеристикиWaterfallГибкие методологииВ чем подвох
Скоуп и требованияПонятны и меняться не будутМеняются по ходу работыВ Waterfall этап аналитики предполагает полное прояснение всех требований и учет ограничений на ранней стадии проекта. Последующие изменения требований сложнее с т.з. процессов и потребует дополнительных затрат, чтобы исправить реализованный ранее функционал.
Новизна задачиПохожая задача уже решалась заказчиком/исполнителем, продукт не инновационныйДля заказчика/исполнителя это качественно новая задача, либо продукт инновационныйВ новой для себя области гораздо проще упустить что-то важное. Для Waterfall будет сложнее вносить изменения в исходные требования.
Управление требованиямиТребования к проекту в процессе работы не будут значительно менятьсяПланируется применять Customer development (тестирование идеи или прототипа будущего продукта на потенциальных потребителях), тестировать гипотезы на рынке, в процессе проекта управлять приоритетами, опираясь на фокус-группыПо аналогии с первыми пунктами — здесь все упирается в потребность гибко управлять требованиями. Если нет такой потребности — Waterfall ваш вариант.
БюджетЖестко ограниченМожно варьировать в заданных рамкахЕсли в Waterfall все идет по плану, то бюджет и срок проекта можно определить после этапа аналитики по проекту. При этом бюджет первичен, и после завершения аналитики он будет определять срок. То есть последовательность такая: бюджет → аналитика → срок.
СрокЖестко ограничен и определен до этапа аналитикиМожет варьироватьсяОтличительная особенность гибких методологий — результат каждой итерации в виде работающего продукта. После завершения этапа аналитики можно достаточно точно оценить срок завершения Waterfall-проекта.

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

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


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

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

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

1. По ходу проекта появляются задачи, которые не вписываются в рамки исходной постановки задачи, но когда-нибудь в будущем хочется их сделать? Внедряем backlog (журнал оставшейся работы, которую необходимо выполнить команде), куда складываем все такие задачи. Даже если проект управляется по Waterfall, будет удобно вернуться к задачам после завершения проекта.

2. В проекте много рисков? Внедряем матрицу управления рисками — стандартный артефакт Waterfall-проекта. Даже если проект ведем по Agile-фреймворку, можно параллельно использовать практики каскадной модели управления проектом.

3. Исходная постановка задачи простая и понятная, а вот после выхода на рынок планируется кастомизировать продукт под потребности пользователя? Можно реализовать первый этап проекта по Waterfall, а поддержку и развитие вести спринтами, по гибкой методологии управления.

4. Хочется «протестировать» гибкий подход управления проектом, и потом уже решать, какую методологию выбрать? Тогда можно начать с работ по аналитике и документированию: составить список User Stories (отзывы клиентов), приоритизировать их и прояснять последовательно (это вариант работы с backlog задач в гибких методологиях). При этом целиком проект можно вести по Waterfall, и приступить к разработке только после полного завершения работ по аналитике. К тому же, такой подход дает максимальную вовлеченность заказчика на старте проекта, что сильно снижает вероятность ошибки в процессе дальнейших работ по проекту.

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

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

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.