Яндекс.Метрика
Услуги Портфолио Контакты БлогНовости +7 (800) 511‑32‑27 Обсудить проект
Статьи

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

3 ноября 2021·3 мин чтения

Обновлено:

Екатерина Полякова
Автор материалаЕкатерина ПоляковаПроджект-менеджер, YuSMP Group
Профиль автора
Как выбрать методологию управления проектами

Вы решили создать свой продукт: уже выбрали команду, оформили идеи и готовы начинать разработку. Но прежде важно решить еще один вопрос — как будет организован процесс работы над проектом.

Раньше все проекты велись по единой методологии Waterfall, она известна с 1970 года, когда Уинстон Уокер Ройс придумал и описал её. Позже появились гибкие подходы Scrum и Kanban. Все три методологии успешно применяем на практике в YuSMP Group, и эта статья о том, как мы ведем проекты не в каноническом виде, а в условиях аутсорсинга, где менеджер проектов полностью управляет процессами.

Waterfall 

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

Структура разработки по Waterfall:

  • аналитика и дизайн;
  • разработка;
  • тестирование;
  • публикация или выпуск; 
  • поддержка.

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

Главный недостаток водопадной модели в том, что нельзя вносить изменения в уже закрытые этапы. Например, если сделана аналитика и дизайн и начата разработка — исправления уже невозможны.

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

Метод WaterFall больше подходит для разработки внутренних корпоративных продуктов, где нет необходимости выводить приложение или другую систему в постоянно изменяющуюся среду бизнеса.

По методологии WaterFall велся наш единственный проект по автоматизации сети аптек, кейс можно посмотреть здесь.

Scrum

Scrum — разновидность гибкой методологии Agile, о которой уже рассказывали в нашем блоге.

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

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

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

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

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

Kanban

Kanban — это непрерывный выпуск задач, начиная от попадания на доску в статус «на выполнение» до полной готовности.

Главный инструмент — доска; менеджер проектов управляет приоритетами задач и ограничениями в столбцах. Ключевое ограничение — WIP-лимит (Work In Progress): максимальное число задач, которое может одновременно находиться в каждой колонке. Без WIP-лимитов доска превращается в неуправляемый список, а команда постоянно переключается между контекстами.

Типичные столбцы Kanban-доски: Backlog → To Do → In Progress → Review → Done. Задачи двигаются только вперёд — без спринтов и дедлайнов спринта.

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

Другие подходы: Lean, SAFe, Shape Up

Помимо «большой тройки», в IT применяют и другие методологии.

Lean — принцип устранить всё, что не создаёт ценность для клиента. Берёт корни из Toyota Production System: минимум незавершённой работы, максимум потока. В разработке это означает короткие циклы и немедленное устранение блокеров как главный приоритет.

SAFe (Scaled Agile Framework) нужен, когда над одним продуктом работают несколько Scrum-команд и нужно синхронизировать релизы. Вводит Program Increment (PI) — 8–12-недельные суперспринты с общим планированием. Актуален при 4+ командах; для малых проектов избыточен.

Shape Up — подход Basecamp с фиксированным «аппетитом» 6 недель на фичу и без бэклога. Команды сами решают, как реализовать задачу в рамках задания. Популярен у продуктовых компаний с автономными командами, но редко применяется в аутсорсинге.

Какой подход выбрать

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

КритерийWaterfallScrumKanban
Гибкость измененийНизкая — этапы закрытыВысокая — корректировка после спринтаВысокая — в любой момент
Ритм работыЛинейные этапыСпринты 1–4 нед (у нас — 1 нед)Непрерывный поток
Лучше всего дляКорп. системы, фикс. бюджетНовые продукты, стартапыТехподдержка, багфикс
Главный рискТребования устаревают к релизуScope creep без сильного POПерегрузка без WIP-лимитов

На практике методологии нередко комбинируют: Scrumban (гибрид Scrum и Kanban) удобен, когда проект одновременно развивает новые фичи и ведёт постоянную техподдержку.

Частые вопросы о методологиях управления проектами

В чём главное отличие Waterfall от Agile?

В Waterfall каждый этап закрывается до начала следующего — вернуться к уже сданной аналитике нельзя. В Agile-методологиях (Scrum, Kanban) работа итеративна: команда может уточнять требования по ходу, реагировать на обратную связь клиента после каждого спринта или релиза.

Какую методологию выбрать для стартапа?

Для стартапов оптимален Scrum: короткие спринты позволяют быстро проверять гипотезы и разворачиваться. Waterfall несёт риск — к дате релиза рынок может уйти вперёд. Если команда маленькая (до 3–4 человек) и задачи разнородны, подойдёт и Kanban.

Можно ли совмещать Scrum и Kanban?

Да — такой гибрид называют Scrumban. Команда работает спринтами, но ведёт Kanban-доску с WIP-лимитами. Это удобно, когда проект сочетает разработку новых фич и постоянную техподдержку.

Что такое SAFe и когда он нужен?

SAFe (Scaled Agile Framework) — масштабированный Agile для крупных программ, где над продуктом работают несколько команд. Вводит Program Increment (PI) — 8–12-недельные суперспринты с общим планированием. Актуален при 4+ командах; малым проектам избыточен.

Нужен ли менеджер проекта при Kanban?

В Kanban нет роли Scrum Master или Product Owner в строгом смысле, но нужен человек, управляющий приоритетами доски и WIP-лимитами. В заказной разработке эту роль обычно берёт менеджер проектов или тимлид.

Услуги мобильной разработки
Узнайте цену

Нужна команда под ваш проект?

Соберём выделенную команду нужного стека — оценка за 2 дня, бесплатно.

Обсудить команду