Вы решили создать свой продукт: уже выбрали команду, оформили идеи и готовы начинать разработку. Но прежде важно решить ещё один вопрос — как будет организован процесс работы над проектом. От выбора методологии зависят сроки, бюджет и то, насколько быстро команда сможет реагировать на изменения.
В 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 недель на фичу и без бэклога. Команды сами решают, как реализовать задачу в рамках задания. Популярен у продуктовых компаний с автономными командами, но редко применяется в аутсорсинге.
Как выбрать методологию: 5 критериев
Прежде чем сравнивать таблицы, полезно честно ответить на пять вопросов о своём проекте — они определяют выбор точнее, чем абстрактные плюсы и минусы методологий.
Размер и опыт команды
Команда до 3–4 человек с разнородными задачами — Kanban: меньше формальностей, проще управлять единым потоком без деления на роли. Команда 5–9 человек, работающая только над одним продуктом, — Scrum: спринты дисциплинируют, а роли Product Owner и Scrum-мастера распределяются естественно. Если над продуктом одновременно работают 4+ Scrum-команды — нужна синхронизация через SAFe.
Определённость требований
Если ТЗ зафиксировано и заказчик не планирует его менять — внедрение учётной системы, миграция на новую платформу, — подходит Waterfall: этапы закрываются последовательно, а фикс-прайс предсказуем. Если требования будут уточняться по ходу — новый продукт, эксперимент с рынком, — Scrum или Kanban дают возможность скорректировать бэклог после спринта или в любой момент.
Вовлечённость заказчика
Scrum требует регулярного участия заказчика: приёмка спринта, уточнение приоритетов бэклога, ретроспективы. Если заказчик готов выделять 2–3 часа в неделю — модель работает. Если контакт эпизодический, раз в месяц или квартал, — надёжнее Waterfall с чёткими вехами и приёмкой по этапам.
Отрасль и регуляторные требования
Проекты с обязательной документацией и аудитом — медицина, банки, госсектор, работа с персональными данными по 152-ФЗ — тяготеют к Waterfall или гибриду Waterfall+Scrum: часть этапов (аналитика, безопасность) фиксируется формально, а разработка внутри спринтов идёт гибко. Продуктовым командам без строгих регуляторных требований подходит чистый Agile.
Сроки и бюджет
Фикс-прайс с жёстким дедлайном — Waterfall: бюджет и график известны заранее, риски заложены в оценку на старте. Time & Material с гибким скоупом — Scrum или Kanban: оплата по факту выполненной работы, приоритеты меняются без пересчёта контракта.
Какой подход выбрать
Опыт работы на разных проектах показал, в каких ситуациях та или иная методология сработает лучше всего:
| Критерий | Waterfall | Scrum | Kanban |
|---|---|---|---|
| Гибкость изменений | Низкая — этапы закрыты | Высокая — корректировка после спринта | Высокая — в любой момент |
| Ритм работы | Линейные этапы | Спринты 1–4 нед (у нас — 1 нед) | Непрерывный поток |
| Лучше всего для | Корп. системы, фикс. бюджет | Новые продукты, стартапы | Техподдержка, багфикс |
| Главный риск | Требования устаревают к релизу | Scope creep без сильного PO | Перегрузка без WIP-лимитов |
На практике методологии нередко комбинируют: Scrumban (гибрид Scrum и Kanban) удобен, когда проект одновременно развивает новые фичи и ведёт постоянную техподдержку.
Как внедрить методологию: 4 шага
Смена методологии — не разовое решение, а процесс, который стоит тестировать постепенно. В YuSMP Group для нового проекта или перехода на другую методологию проходим четыре шага.
- Диагностика (1 неделя). Оцениваем проект по пяти критериям выше: размер команды, определённость требований, вовлечённость заказчика, отрасль и бюджет — и предварительно выбираем методологию.
- Пилотный этап. Тестируем методологию на одном модуле или первом спринте, а не на всём проекте сразу — так дешевле развернуться, если модель не подошла.
- Настройка инструментов. Заводим доску под методологию: бэклог и спринты для Scrum, WIP-лимиты по колонкам для Kanban, диаграмму Ганта и вехи для Waterfall. Чаще всего используем Jira независимо от методологии — меняется только конфигурация досок.
- Ретроспектива. Через 2–4 недели сверяем: методология ускоряет работу команды или добавляет бюрократии. При необходимости переходим на гибрид — например, Scrumban.
Что меняется в 2026 году: ИИ и распределённые команды
Две тенденции сейчас влияют на выбор методологии сильнее, чем ещё три года назад.
ИИ-инструменты ускоряют отдельные этапы, но не отменяют методологию. Генерация кода и автотесты сокращают долю рутины в спринте, но не снимают потребность в приоритизации бэклога и ретроспективах — команда просто успевает больше задач за тот же спринт. Мы закладываем это в планирование: спринт длиной в неделю остаётся неделей, но объём работы в него помещается больше.
Распределённые команды делают асинхронные методологии удобнее синхронных. Kanban и Scrumban легче переносятся на команды в разных часовых поясах, чем классический Scrum с ежедневными синхронными стендапами: доска и WIP-лимиты работают без совпадения рабочих часов, а стендап можно заменить асинхронным апдейтом в трекере задач.
Частые вопросы о методологиях управления проектами
В чём главное отличие 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-лимитами. В заказной разработке эту роль обычно берёт менеджер проектов или тимлид.
Какие инструменты нужны для методологии?
Для Scrum и Kanban подходят Jira, Trello или YouGile — важны бэклог и WIP-лимиты, а не конкретный сервис. Для Waterfall обычно достаточно диаграммы Ганта и общего трекера задач. В YuSMP Group большинство проектов ведём в Jira независимо от методологии — меняется только настройка досок.
Как понять, что методологию пора менять?
Сигналы для смены: команда систематически не укладывается в спринт — Scrum перегружен, стоит попробовать Kanban; задачи в Kanban зависают без сроков — не хватает дисциплины спринтов Scrum; в Waterfall заказчик всё чаще просит правки в уже закрытых этапах — переходите на Scrumban. Новую модель стоит тестировать на одном модуле, а не на всём проекте сразу.
Нужна команда под ваш проект?
Соберём выделенную команду нужного стека — оценка за 2 дня, бесплатно.
