Организация процессов разработки по Scrum и Kanban на реальных проектах

За пятнадцать лет в разработке я не видел ни одной команды, которая работала бы строго по учебнику. Реальные проекты всегда требуют адаптации. Бизнесу нужен предсказуемый результат, а не идеальная схема. Поэтому команды смешивают Scrum, Kanban и собственные правила — и это нормально. Главное, чтобы этот микс помогал двигаться вперёд, а не создавал иллюзию порядка. Ниже — разбор того, как выстроить процессы разработки, чтобы команда не тонула в хаосе, а продукт регулярно получал осмысленные обновления.

Почему методология вообще важна

Когда проект перерастает стадию «два разработчика и тимлид», проблемы становятся системными. По моим наблюдениям, в девяти случаях из десяти команды сталкиваются с одним и тем же набором симптомов:

• задачи копятся в бэклоге, о них забывают, а через месяц вспоминают с вопросом «а это ещё актуально?»;
• разработчики заняты с утра до вечера, но по доске видно, что за неделю закрыто две задачи из двадцати;
• сроки срываются не из-за сложного кода, а потому что требования не собрали, зависимости не учли, а приоритеты менялись трижды за спринт;
• бизнес не понимает, что именно будет готово к конкретной дате, и начинает давить на команду в ручном режиме.

Scrum и Kanban не решают эти проблемы автоматически. Но они дают структуру, в которой проблемы становятся видимыми. А видимая проблема — это уже наполовину решённая проблема. Методология здесь — не свод ритуалов, а инструмент для управления ожиданиями, нагрузкой и потоком задач. Если относиться к ней как к набору практик, а не как к религии, польза будет ощутимой.

Scrum и Kanban простыми словами

Scrum

Scrum хорош, когда продукт развивается итерациями и команде нужен ритм. Мы работаем короткими циклами — спринтами, обычно по одной-две недели. В начале спринта команда берёт фиксированный объём задач, в конце показывает результат и проводит ретроспективу. Это дисциплинирует: нельзя бесконечно допиливать фичу, нужно доводить её до состояния «готово» в рамках цикла.

Что даёт Scrum на практике:

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

Scrum особенно полезен, когда есть дорожная карта продукта, несколько заинтересованных сторон и поток новых фич. Он заставляет договариваться о приоритетах до старта, а не в середине спринта.

Kanban

Kanban — это потоковая модель. Задачи двигаются по колонкам визуальной доски без привязки к спринтам. Ключевая идея — ограничить количество задач в работе и ускорить их прохождение через весь процесс. Это не значит, что в Kanban нет планирования — оно просто устроено иначе: через приоритеты и лимиты WIP, а не через фиксацию объёма на период.

Что даёт Kanban:

• меньше контекстных переключений — разработчик не распыляется на десяток задач одновременно;
• гибкость при срочных задачах — горячий баг можно взять в работу сразу, не дожидаясь конца спринта;
• наглядность узких мест — если задачи скапливаются в колонке «Code Review», проблема видна мгновенно;
• удобство для поддержки, доработок и непрерывного потока — там, где нет смысла нарезать искусственные итерации.

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

Когда выбирать Scrum, а когда Kanban

За годы работы я вывел для себя простое правило: Scrum — про обязательства на короткий срок, Kanban — про управляемость без жёстких рамок. Но чтобы выбор был осознанным, полезно посмотреть на типовые ситуации.

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

Как выглядит рабочий процесс в реальном проекте

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

1. Сбор входящих задач

Источники задач в типичном проекте выглядят так:

• бизнес-заказчик — новые фичи и стратегические инициативы;
• аналитика — гипотезы на основе данных;
• баги от пользователей — через саппорт или автоматический мониторинг;
• техдолг — рефакторинг, обновление библиотек, архитектурные улучшения;
• улучшения интерфейса — UX-исследования и обратная связь;
• инфраструктурные задачи — миграции, настройка окружений, CI/CD;
• срочные инциденты — то, что требует немедленной реакции.

Если все эти задачи падают в одну кучу, процесс разваливается за неделю. Разработчики теряются в приоритетах, а бизнес не понимает, почему его фича откладывается ради бага, который «никто не видел». Поэтому входящий поток нужно разделять хотя бы по типам: новая функциональность, баги, техдолг, поддержка, исследования и спайки. Это не бюрократия, а способ сохранить управляемость.

2. Триаж и первичная оценка

Перед тем как задача попадёт в разработку, её нужно проверить на вшивость. Я всегда рекомендую задавать пять вопросов:

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

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

3. Планирование

В Scrum планирование привязано к спринту. В Kanban — к приоритетам и лимитам WIP. Но в обоих случаях хорошее планирование отвечает на три вопроса:

• что делаем — конкретный объём работ;
• зачем делаем — бизнес-ценность или техническая необходимость;
• как поймём, что готово — критерии приёмки.

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

4. Реализация

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

• актуальный статус — не «в работе» третий день без движения, а конкретный этап;
• ответственный — кто именно делает и кто отвечает за результат;
• критерии приёмки — чтобы тестировщик и разработчик говорили на одном языке;
• видимые блокеры — если задача встала, это должно быть видно сразу;
• понятные зависимости — чтобы менеджер мог разрулить конфликты до того, как они станут проблемой.

Именно здесь доска из формальности превращается в инструмент управления. Когда вся команда видит реальное положение дел, снижается потребность в бесконечных статус-митингах.

5. Проверка и приёмка

Без тестирования и приёмки любая методология — иллюзия контроля. Задача может считаться завершённой только когда выполнены все условия:

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

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

Как настроить Scrum на реальном проекте

Базовая схема

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

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

Что важно настроить заранее

Роли

Даже если в команде нет формального Scrum Master, роли должны быть распределены явно. Я не раз видел, как отсутствие явного владельца продукта приводило к тому, что приоритеты назначал самый громкий голос в переговорке. Базовая схема ролей выглядит так:

• владелец продукта отвечает за приоритеты и бизнес-ценность;
• разработчики — за техническую реализацию;
• аналитик или PM — за уточнение требований и коммуникацию;
• тестировщик — за качество и соответствие критериям;
• техлид — за архитектурные решения и технический долг.

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

Бэклог

Бэклог — это не свалка идей из чатов и писем. Это список подготовленных задач, каждая из которых содержит:

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

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

Definition of Done

Без определения «готово» Scrum деградирует за два-три спринта. Команда начинает спорить, считать ли задачу завершённой, если код написан, но не протестирован. Definition of Done должен быть конкретным и проверяемым. Например:

• код вмержен в основную ветку;
• автотесты пройдены успешно;
• ручная проверка выполнена по чек-листу;
• документация обновлена, если изменения затрагивают API или пользовательские сценарии;
• фича доступна на тестовом или продакшн-окружении.

Этот список не должен быть формальным. Если команда не может выполнить какой-то пункт систематически, его нужно либо убрать, либо найти способ обеспечить.

Как настроить Kanban

Kanban особенно полезен, когда команда живёт в режиме постоянного потока задач. Я применял его в проектах поддержки, где баги и доработки приходили ежедневно, а планировать спринты было бессмысленно — через день после планирования прилетал срочный инцидент, и весь план летел к чертям.

Основные принципы

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

Пример колонок на доске

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

• Backlog — задачи, которые ждут своей очереди;
• Ready — подготовленные и приоритизированные задачи;
• In Progress — активная разработка;
• Code Review — проверка кода;
• QA — тестирование;
• Ready for Release — готово к деплою;
• Done — завершено.

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

WIP-лимиты

WIP — это work in progress, задачи в работе. Лимит WIP нужен, чтобы команда не брала слишком много одновременно. Это, пожалуй, самый недооценённый инструмент в Kanban. Пример реалистичных лимитов:

• у разработчика максимум две задачи в работе одновременно;
• у QA — не более трёх задач на проверке;
• в колонке Code Review — не более пяти задач.

Если лимиты превышаются, процесс начинает тормозить. Люди заняты, но поток не движется — задачи зависают на полпути, а cycle time растёт. WIP-лимиты заставляют команду завершать начатое, а не набирать новое.

Scrum, Kanban или гибрид

На практике гибрид часто эффективнее чистой модели. Я пришёл к этому выводу после нескольких лет попыток внедрить «правильный Scrum» в проектах, где одновременно шла продуктовая разработка и поддержка. Чистый Scrum ломался на срочных задачах, чистый Kanban — на необходимости стратегического планирования.

Когда гибрид оправдан

• продуктовая разработка идёт спринтами — новые фичи требуют ритма и предсказуемости;
• поддержка и багфиксы идут потоком — здесь нужна гибкость и быстрая реакция;
• часть команды делает новые фичи, часть — операционные задачи;
• есть срочные запросы, которые нельзя ждать до конца спринта.

Как выглядит гибрид

Рабочая схема, которую я не раз применял:

• продуктовые задачи живут в Scrum-спринтах с фиксированной длиной и планированием;
• срочные и мелкие задачи идут через Kanban-доску с WIP-лимитами;
• общие правила качества и приёмки едины для обоих потоков;
• релизы синхронизируются по общему графику, чтобы не создавать хаос на продакшне.

Такой подход ближе к реальности, чем попытка «внедрить Scrum по учебнику». Он требует дисциплины в разделении потоков, но окупается предсказуемостью.

Типовые ошибки в организации процессов

За годы работы с командами я собрал коллекцию ошибок, которые повторяются с удивительным постоянством. Вот самые частые.

1. Смешивают всё в одну доску

Когда в одном списке лежат баги, фичи, хотфиксы, исследования и административные задачи, приоритеты размываются за день. Команда не понимает, за что хвататься, а менеджер не может объяснить бизнесу, почему фича откладывается. Разделение потоков — не бюрократия, а необходимость.

2. Нет критериев готовности

Без чётких критериев команда начинает спорить на приёмке: «я думал, тестирование — это не моя задача», «баг воспроизводится только на окружении заказчика, значит это не баг». Такие споры съедают время и убивают доверие между разработчиками и тестировщиками.

3. Слишком много задач в работе

Если каждый разработчик берёт по пять-семь задач одновременно, то почти ничего не доходит до конца. Задачи зависают в статусе «в работе» на недели, а cycle time становится неприлично большим. Лучше меньше, но завершённо — это правило работает безотказно.

4. Планирование оторвано от реальности

Классическая ситуация: команда на планировании оптимистично оценивает свою ёмкость, бизнес недооценивает сложность, и в итоге спринт за спринтом срывается. Через пару месяцев такого опыта команда перестаёт верить в планирование как таковое. Решение — опираться на исторические данные, а не на ощущения.

5. Ретроспектива превращается в формальность

Если после спринта команда обсуждает проблемы, но никто не меняет процесс, ретроспектива становится пустой рутиной. Люди перестают говорить честно, потому что знают: всё останется как было. Ретроспектива без action items — это просто встреча ради встречи.

6. Нет владельца приоритетов

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

Что измерять, чтобы понять, что процесс работает

Не стоит измерять всё подряд — метрики ради метрик только отвлекают. Достаточно нескольких практичных показателей, которые дают реальную картину.

Если команда не знает свои базовые метрики, она управляет процессом «на ощущениях». Это нормально только на старте, когда проект ещё маленький. На длинной дистанции без цифр невозможно понять, становится ли команда быстрее или медленнее.

Практический чек-лист запуска процесса

Если выбираете Scrum

• определить длину спринта — начать лучше с двух недель, а потом скорректировать;
• назначить ответственного за приоритеты — владельца продукта;
• описать Definition of Done — конкретно и проверяемо;
• подготовить шаблон задачи — чтобы не тратить время на формат на каждом планировании;
• провести первое планирование — взять заведомо меньше задач, чем кажется возможным;
• зафиксировать формат демо и ретроспективы — кто участвует, сколько длится, что является результатом;
• ограничить объём спринта реальной ёмкостью команды — опираться на данные, а не на оптимизм.

Если выбираете Kanban

• настроить простую доску — начать с пяти-семи колонок;
• описать этапы потока — что означает каждый статус;
• ввести WIP-лимиты — начать с консервативных значений и корректировать по мере накопления статистики;
• договориться о правилах приоритизации — кто и как определяет, что брать в работу следующим;
• сделать критерии входа и выхода для каждой колонки — чтобы задачи не зависали на стыках;
• начать измерять cycle time — хотя бы вручную на первых порах;
• регулярно разбирать узкие места — раз в неделю или две.

Для любого подхода

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

Как понять, что команда действительно стала работать лучше

Хороший процесс заметен не по количеству церемоний, а по результату. Вот признаки, на которые я ориентируюсь:

• меньше незавершённых задач — задачи не зависают в статусе «в работе» на недели;
• меньше авралов — срочные задачи перестают быть нормой;
• понятнее сроки — бизнес получает реалистичные прогнозы, а не обещания;
• быстрее реакции на изменения — команда может перестроиться без паники;
• меньше конфликтов на приёмке — критерии готовности снимают неопределённость;
• бизнес чаще получает предсказуемый результат — и реже приходит с вопросом «когда уже будет готово».

Если же после внедрения Scrum или Kanban команда стала только чаще встречаться, но не стала двигаться быстрее — процесс настроен формально. Такое случается, когда методологию воспринимают как набор ритуалов, а не как инструмент управления потоком.

Что особенно важно для российских команд

В российских проектах я регулярно сталкиваюсь с одними и теми же ограничениями:

• меняющиеся требования со стороны бизнеса — приоритеты могут измениться в середине спринта;
• смешанные команды из in-house и подрядчиков — разная культура разработки и уровень вовлечённости;
• срочные задачи без подготовки — «надо вчера» как стандартный режим работы;
• ограниченные ресурсы на аналитику и QA — часто эти роли совмещаются или отсутствуют;
• сильная зависимость от внешних интеграций — государственные системы, партнёрские API, унаследованные сервисы.

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

Вывод

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

Если процесс можно объяснить за пять минут, если команда понимает, что считать «готово», и если задачи действительно проходят по доске от начала до конца — значит организация разработки работает. Всё остальное — детали, которые можно настраивать по ходу дела.

FAQ

Можно ли использовать Scrum без Scrum Master?

Да, если команда небольшая и роли распределены явно. Но кто-то всё равно должен следить за процессом — фасилитировать встречи, снимать блокеры, защищать команду от внешнего хаоса. Иначе Scrum быстро распадается под давлением срочных задач и меняющихся требований.

Подходит ли Kanban для продуктовой разработки?

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

Что выбрать стартапу?

Чаще всего — облегчённый Scrum или гибрид Scrum + Kanban. Стартапу нужен ритм, чтобы быстро проверять гипотезы, но без лишней бюрократии. Я обычно рекомендую начинать с недельных спринтов и Kanban-доски для срочных задач, а дальше корректировать под реальность.

Как не перегрузить команду?

Ограничить WIP, сократить число одновременно активных задач и планировать от реальной ёмкости, а не от оптимизма. Если команда стабильно не успевает сделать запланированное, проблема не в людях, а в объёме обязательств.

Почему методология не работает после внедрения?

Обычно причина не в Scrum или Kanban, а в том, что нет владельца приоритетов, нет критериев готовности и команда не меняет поведение — только названия статусов. Методология становится фасадом, за которым продолжается хаос. Лечится это только одним способом: честным разбором реальных проблем и готовностью менять процесс.