Методологии разработки: Agile, Scrum, Kanban, Waterfall для заказчика

В коммерческих предложениях студий то и дело встречается: «работаем по Agile», «спринты по две недели», «Scrum-команда». Методологии разработки — не жаргон программистов. От них зависит, когда вы увидите первый результат, можно ли менять требования по ходу, как считается бюджет и кто отвечает за то, что продукт получился не таким, как задумывали.

Ниже разберём Waterfall, V-модель, итеративную разработку, Agile, Scrum, Kanban, Scrumban и Lean со стороны заказчика: что подходит сайту-визитке, а что — веб-сервису, что методология меняет в договоре и как отличить гибкость от хаоса.

Что такое методология разработки и почему она влияет на бюджет и сроки

Методология разработки программного обеспечения — набор правил: в каком порядке идут этапы, как фиксируются требования, когда заказчик видит результат и как обрабатываются изменения. По сути, это договорённость о том, как команда управляет неопределённостью.

Для заказчика всё сводится к трём вопросам:

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

Waterfall, V-модель и итеративная разработка: плановые подходы

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

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

В госзакупках и крупных корпорациях каскад часто задан нормативно. Стадии создания автоматизированных систем описывает ГОСТ Р 59793-2021 (заменил ГОСТ 34.601-90), требования к ТЗ — ГОСТ 34.602-2020, для программ — ЕСПД (ТЗ по ГОСТ 19.201-78). Контракт по 44-ФЗ заключается по заранее описанному объекту закупки с твёрдой ценой — это каскадная логика. Подробнее о выборе стандарта — в статье про техническое задание на разработку ПО.

V-модель

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

Итеративная и инкрементная разработка

Промежуточный вариант между каскадом и Agile: продукт делают несколькими циклами «анализ — разработка — тестирование». Инкрементная модель добавляет готовые куски функциональности (каталог, потом корзина, потом личный кабинет), итеративная улучшает весь продукт с каждым витком. На практике их сочетают; сюда же относятся спиральная модель и RUP.

Гибкие методологии разработки: что такое Agile

Agile — не методология в строгом смысле, а набор ценностей и принципов. В 2001 году 17 практиков разработки сформулировали Agile-манифест с четырьмя ценностями:

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

Ключевое слово — «важнее», а не «вместо»: документация, договор и план никуда не деваются. К манифесту прилагаются 12 принципов, среди них — частая поставка работающего продукта (от пары недель до пары месяцев) и ежедневная совместная работа бизнеса и разработчиков. На практике Agile реализуется через фреймворки: Scrum, Kanban, XP (парное программирование, TDD, частые релизы) и их комбинации.

Методология Scrum: роли, спринты, события и артефакты

Scrum — самый распространённый гибкий фреймворк. Его правила описаны в Scrum Guide (актуальная редакция — 2020 года, авторы — Кен Швабер и Джефф Сазерленд).

Роли. Product Owner (владелец продукта) — один человек, не комитет: управляет бэклогом и решает, что делать в первую очередь. В заказной разработке это представитель заказчика или менеджер подрядчика, которому вы делегировали приоритеты. Scrum Master отвечает за то, чтобы процесс работал, и убирает препятствия. Developers — все, кто делает продукт: программисты, тестировщики, дизайнеры, аналитики. Команда целиком — обычно не больше 10 человек.

События.

• Спринт — фиксированный цикл не длиннее месяца; в веб-разработке чаще всего 2 недели.
• Планирование спринта — до 8 часов для месячного спринта (для коротких — меньше), итог — цель спринта.
• Daily Scrum — 15-минутная ежедневная синхронизация разработчиков; заказчику на ней быть не нужно.
• Обзор спринта (Sprint Review) — до 4 часов: команда показывает результат, заказчик даёт обратную связь. По Scrum Guide это рабочая сессия, а не презентация.
• Ретроспектива — до 3 часов: команда разбирает, что улучшить в процессе.

Артефакты. С редакции 2020 года у каждого есть «обязательство»: у бэклога продукта — цель продукта (Product Goal), у бэклога спринта — цель спринта, у инкремента — определение готовности (Definition of Done), то есть формальные критерии, когда задача считается сделанной.

Kanban, Scrumban, Lean и гибридный подход

Kanban пришёл в разработку из производственной системы Toyota. Спринтов нет: задачи идут по доске через колонки «Бэклог → Разработка → Тестирование → Готово». Главный инструмент — WIP-лимиты: ограничение числа задач, одновременно находящихся в колонке. Пока начатое не закончено, новое не берут — так видны узкие места. Полезные заказчику метрики — время цикла и пропускная способность: по ним прогнозируют сроки без оценок в часах. Kanban хорошо подходит для поддержки работающего сайта с потоком доработок и багов разного размера.

Scrumban — гибрид: от Scrum берут регулярные планирования, демо и ретроспективы, от Kanban — доску с WIP-лимитами. Коротко о разнице Scrum и Kanban: Scrum — ритм фиксированных итераций с ролями и обязательным демо, Kanban — непрерывный поток с ограничением незавершённой работы.

Lean (бережливая разработка) переносит в IT принципы бережливого производства: убирать всё, что не создаёт ценности, быстрее получать обратную связь, откладывать необратимые решения. Для стартапов это оформлено в Lean Startup с циклом «сделать — измерить — научиться», отсюда MVP — минимальная версия продукта для проверки гипотезы.

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

Сравнение методологий разработки: сводная таблица

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

Цены и сроки — ориентиры рынка из нашей практики; итог зависит от объёма, дизайна и интеграций.

Если вы заказываете разработку сайта под ключ с понятной структурой, полноценный Scrum с отдельным Scrum-мастером обычно избыточен. А для веб-приложения или сервиса с ролями, личными кабинетами и расчётами короткие итерации и регулярные демо почти обязательны: слишком много решений принимается по ходу.

Методология и договор: как связаны подход и модель оплаты

Каскад естественно ложится на фиксированную цену: объём описан в ТЗ, изменения идут через допсоглашение. Scrum и Kanban лучше сочетаются с оплатой по фактическим часам (Time & Material) с лимитом на период. Гибрид — фиксированная цена этапа и оплата по вехам. Риски каждой схемы и расчёты — в разборе fixed price или time & material.

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

Как заказчику участвовать в гибкой разработке

Каскад позволяет согласовать ТЗ и прийти на приёмку. Гибкий подход без вашего времени не работает.

1. Назначьте одного ответственного с правом решать приоритеты. На небольшом проекте — 3–5 часов в неделю, на сервисе — заметно больше.
2. Держите бэклог в порядке: сверху — важные для бизнеса задачи с критериями приёмки.
3. Приходите на демо и кликайте продукт на тестовом сервере сами — вопрос на демо дешевле правки после релиза.
4. Принимайте по спринтам: промежуточные акты или хотя бы отметки в трекере. Тогда финальная приёмка — проверка целостности, а не поиск ошибок за три месяца.
5. Меняйте приоритеты между спринтами, а не внутри. Если срочное появляется каждый день, вам ближе Kanban.

Инструменты: Jira и российские таск-трекеры в 2026 году

Jira долго была стандартом для Scrum-команд, но Atlassian ушла с российского рынка: с конца 2022 года продление лицензий и подписок для клиентов из России прекращено, аккаунты российских пользователей в облаке блокировались, а серверные версии не поддерживаются с февраля 2024 года. Закладываться на Jira в новом проекте в РФ не стоит: при работе через обходные пути можно в любой момент потерять историю задач.

• Kaiten — канбан-доски и спринты, WIP-лимиты, отчёты по времени цикла.
• Яндекс Трекер — канбан- и Scrum-доски с бэклогом и спринтами, интеграция с сервисами Яндекса.
• YouGile — простой старт, бесплатен для небольших команд.
• Битрикс24 — канбан и Scrum-режим в задачах и проектах, удобно, если компания уже работает в Битрикс24.

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

Формальный Agile и ошибки заказчика

Признаки, что подрядчик делает Agile формально

• Демо без продукта: презентация или скриншоты вместо работающей версии на тестовом сервере.
• Спринты без цели: «сделано 40 задач», но что стало лучше для пользователя — непонятно.
• Бэклог, который видит только подрядчик, и приоритеты расставляет менеджер студии.
• Agile как оправдание: «мы гибкие, поэтому без ТЗ и оценки» — а через три месяца бюджет исчерпан.
• Нет прогноза: через 3–4 спринта команда должна знать свою скорость и называть срок следующего крупного блока.

Типичные ошибки заказчика при выборе методологии

• Требовать фиксированную цену и полную гибкость одновременно. Компромисс — фиксированные этапы.
• Выбрать Scrum и не выделить владельца продукта. Решения зависают, спринты сгорают впустую.
• Писать огромное ТЗ для продукта, который будет меняться. Половина требований устареет к запуску.
• Вести интеграционный проект без тестовой среды. Ошибки обмена с 1С и CRM всплывают на боевых данных.

Итог: чек-лист, как договориться о методологии с подрядчиком

Для небольшого сайта с понятной структурой подойдёт каскад или простой гибрид, для веб-сервиса и MVP — короткие итерации с активным владельцем продукта, для поддержки — Kanban. Большинство заказных проектов разумно вести гибридом: смета на этап, разработка спринтами, приёмка частями.

• Понимаю уровень неопределённости: требования известны или многое будем выяснять по ходу.
• Подрядчик назвал конкретный подход и объяснил его для нашего проекта: этапы, длину итерации, частоту демо.
• Модель оплаты соответствует методологии: фикс на этап, T&M с лимитом или их сочетание.
• В договоре описан порядок изменения требований и их оценки.
• Есть определение готовности и критерии приёмки по этапам.
• С нашей стороны назначен один ответственный с правом решать и временем на проект.
• У нас есть доступ к трекеру и репозиторию с первого дня, трекер доступен из РФ.
• Демо проходят на тестовом сервере, а не в презентации.