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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Если вы хотите разработать корпоративный инструмент, то больше подойдет Waterfall.
• Если хотите выводить новый продукт на рынок, лучше использовать Scrum.
• Если у вас проекты по технической поддержке — отличным вариантом станет Kanban.