Когда для продуктовой разработки собирается команда, метрики планирования которой никто раньше не отслеживал, внезапно оказывается, что команда планировать‑то и не умеет.
Как с этим бороться и что можно сделать, я хочу разобрать на примере своей команды.
Сейчас я RTE (Release Train Engineer) в IT‑центре Summit Group, а когда началась эта история, я была скрам‑мастером одной из команд, работающих по Scaled Agile Framework (SAFe).
Наши команды делают цифровые продукты для финансового бизнеса, в каждой есть разработчики, аналитики и тестировщики. Сама я не люблю внедрять методологии целиком просто потому, что так написано в книге, мне интереснее пробовать по частям и смотреть, что из этого реально работает.
Какую метрику мы рассмотрим — авторский фокус‑фактор (ФФ). Почему авторский? В нашей компании мы считаем его немного по‑другому, чем принято. Обычно ФФ показывает, какая доля времени команды уходит на задачи спринта, а у нас ФФ = выполненные задачи / запланированные задачи, считаем в стори поинтах (SP). Берем во внимание, что результат 100% — это тоже не лучший результат, ведь это значит, что команда могла бы сделать и больше. «Золотой» результат входит в диапазон 80–95%.
Дано: разработчики разных платформ, тестировщик, аналитики. Все эти люди раньше работали только в своих отделах и направлениях, и никто не знал о том, как работать в мультиплатформенной команде. Если раньше в задаче участвовали несколько разработчиков, то фичи могли делаться месяцами, а разработчики взаимодействовали в комментариях к задаче и на редких встречах по синхронизации.
Как было
Если посмотреть на график, то кажется, что средний ФФ 73% уже неплохо, но обратите внимание, что всего два спринта из 15 попали в «золотой» результат, а спринты с 24% и 25% оказались полностью провальными. Таким образом, мы с нашим продакт овнером были как на пороховой бочке, не понимая, когда команда справится со спринтом. А ведь у нас были обязательства перед руководителями, а уверенности в будущем спринте не было. При этом было видно, что ребята стараются, работают много, но что‑то нас постоянно стопорило.
Теперь посмотрим, какая размерность была в задачах:
Размер задачи | Задач | Доля задач | Объем, SP | Доля объема |
1 SP и меньше | 45 | 27% | 44 | 12% |
2 SP | 62 | 38% | 124 | 34% |
3 SP | 45 | 27% | 135 | 37% |
5 SP | 13 | 8% | 65 | 18% |
Самым частым размером задачи у нас были 2 SP — это 38% всех задач. Еще треть задач оценивалась в 3 и 5 SP, и вот на них уходило больше половины объема спринта. А задач по 1 SP было всего 27%.
Эксперимент с XP
В этот период мы с другими скрам‑мастерами начали изучать, что же такое экстремальное программирование (XP). Прочитав соответствующий раздел в книге «Постигая Agile», мы решили попробовать его применить. Кто‑то из скрамов взял полную методику для внедрения, а я решила взять только часть про декомпозицию задач. Не могу сказать, что взяла изначальную методику и полностью ее применила, скорее она меня подтолкнула к идее, что декомпозиция поможет команде лучше планировать.
Я собрала презентацию по материалам книги (тогда еще все презентации приходилось собирать вручную) и устроила отдельную встречу. Мне было интересно узнать, как ребята на это смотрят. Чтобы постараться сократить сопротивление команды, я сначала рассказала про всю методику XP, а в конце торжественно предложила взять только один артефакт. На старте я не была уверена, что это решит нашу проблему, это был чистой воды эксперимент. С этого момента мы договорились брать в спринт только задачи размером 1 SP. Это было в начале 2024 года.
«Это нельзя декомпозировать»
Каждое планирование спринта для нас было как каторга, ребята не знали, как можно декомпозировать задачи. Фразу «Это нельзя декомпозировать» я слышала чаще, чем «Здравствуйте, коллеги» на встречах. Приходилось преодолевать это сопротивление и вместе находить пути декомпозиции.
У меня был опыт работы только с одной платформой разработки, а разработчики у нас были на трех разных платформах. И когда на планировании спринта ребята с платформ, с которыми я не работала, говорили, что задачу нельзя декомпозировать, помочь им было сложно. Тут меня выручало то, что я просто предлагала абсолютно рандомные варианты декомпозиции: «а давай вот так и так сделаем» — что приходило в голову по смыслу задачи. И зачастую ребята, пытаясь опровергнуть мои предположения, доходили до правильного ответа сами.
Конечно, все мы люди, и когда в очередной трехтысячный раз я слышала «это нельзя декомпозировать», хотелось опустить руки и сказать: «Да, окей». Но раз я уже взялась за этот эксперимент, нужно было иметь смелость довести его до конца, и каждый раз я возвращалась к одному и тому же: «Хорошо, давай посмотрим, как мы это можем декомпозировать».
От спринта к спринту наши дела становились лучше, и команда начала сбавлять обороты по сопротивлению. Мне было важно, чтобы изменения в процессах держались не только на ощущениях команды, но и на цифрах. Поэтому эксперимент мы оценивали по тому, насколько предсказуемыми стали спринты, а не только по тому, удобнее ли стало планировать. Ребята и сами видели, что мы начали закрывать спринты, а я еще делилась с ними результатами по фокус‑фактору. И цифры подтверждали, что мы на правильном пути.
Как это выглядело на практике
Покажу на примере интеграции с Telegram. Клиент привязывает свой Telegram в личном кабинете или в приложении, а мы потом присылаем ему через бота уведомления и сообщения.
Раньше такая функция приходила в спринт одной задачей:
Было | SP | Факт |
Чат‑бот в Telegram (анализ) | 3 | 55 ч |
На нее в итоге ушло 55 часов, это почти неделя работы одного человека. Если к концу спринта такая задача не закрывалась, команда‑то понимала, какой объем по ней уже сделан, но все мы находимся под властью отчетов, а в отчетах вообще не было видно, что мы как‑то продвинулись за спринт.
После перехода эту же функцию мы разбили вот так:
Как мы разбили задачу: 15 задач вместо одной
Стало | SP |
ТЗ на чат‑бота | 3 |
Правки ТЗ | 1 |
Описание архитектуры отправки сообщений через Telegram | 1 |
Раздел подключения Telegram в личном кабинете | 1 |
Подключение бота в личном кабинете | 1 |
Отображение ошибок на странице подключения | 1 |
Предложение привязать Telegram на шагах оформления займа | 1 |
Перепривязка Telegram‑аккаунта (сайт) | 1 |
Сохранение никнейма клиента во внутренней системе | 1 |
Передача никнейма во внутреннюю систему, часть 1 | 0,5 |
Передача никнейма во внутреннюю систему, часть 2 | 1 |
Сохранение никнейма на бэкенде | 0,5 |
Таблица для хранения Telegram‑контактов | 1 |
Чат‑бот в мобильном приложении | 1 |
Рассылка акций через бота | 1 |
Получилось 15 небольших задач, и 14 из них закрылись в том же спринте, в котором их взяли в работу. Теперь прогресс по задачам был виден в отчетах каждый спринт. Делили по‑разному — где‑то по пользовательским историям, где‑то по платформам, а тестирование и вывод в прод почти всегда выносили отдельной задачей. Поначалу не все удавалось раздробить — поэтому ТЗ в таблице еще на 3 SP.
Также хочу подчеркнуть, что в течение всего времени существования команды состав менялся с грустной регулярностью, а домены, над которыми работала команда, тоже менялись. Когда наше планирование стабильно дотянулось до золотого стандарта, мы отменили обязательное правило оценки в 1 SP. Но и без этого правила команде было проще делить задачи именно так. А когда приходили новые участники, то мы проходили с ними этот путь снова.
Что получилось
После перехода картина поменялась. За первые 15 спринтов средний фокус‑фактор вырос с 73% до 87%, и самое приятное — пропали провальные спринты, самый низкий был 75%. В «золотой» диапазон попали 12 спринтов из 15, а до этого было всего два. У продакт овнера наконец появилась уверенность в планировании, каждый спринт перестал быть для него лотереей — сделаем мы в этом спринте 20% задач или все 100%.
Размер задачи | Доля задач до | Доля задач после | Доля объема до | Доля объема после |
1 SP и меньше | 27% | 78% | 12% | 60% |
2 SP | 38% | 18% | 34% | 28% |
3 SP | 27% | 5% | 37% | 11% |
5 SP | 8% | меньше 1% | 18% | 1% |
По размеру задач тоже все поменялось: теперь 78% задач были по 1 SP, а задачи на 3 и 5 SP почти пропали. При этом объем работы за 15 спринтов остался примерно таким же, около 360 SP, просто задач стало 285 вместо 165.
Мне было важно проверить, что это не разовый эффект. Я посмотрела последние 15 спринтов, с марта по октябрь 2026 года: средний фокус‑фактор 88%, самый низкий спринт 77%. А если брать все 65 спринтов после перехода, а это уже около двух с половиной лет, то в среднем выходит 89% и ни одного спринта ниже 75%.
Декомпозиция была не единственным экспериментом в нашей команде скрам‑мастеров. Мы пробовали разработку через тестирование (TDD), но отказались. Вместе с архитектором масштабно внедряли предметно‑ориентированное проектирование (DDD), меняли процесс оценки задач. А когда в других командах нашего SAFe случались перестановки или собирались новые команды, и я видела в отчетах похожую проблему, я советовала им провести такой же эксперимент и рассказывала, как это получилось у нас.
Вывод
Понять, что правило стало привычкой, было просто: на планировании ребята сами начали говорить «так, давайте эту задачу декомпозируем», «давайте разделим эти 3 SP на 1 SP и 2 SP». Теперь они делят задачи для своего удобства, а не для меня, чтобы я их не доставала. Если в команду приходят новые участники, они тоже принимают это без проблем — почти все они раньше не работали в кроссплатформенных командах и в этот момент открыты к изменениям. А для меня лично изменилось понимание спринта: по ходу видно, куда мы идем и какие могут возникнуть сложности, и можно что‑то сделать сейчас, а не увидеть в конце, что спринт провален.
У нас декомпозиция сработала: спринты стали предсказуемыми, и это держится уже больше двух лет. Но, конечно, декомпозиция — это не какая‑то серебряная пуля. Это лишь элемент, который помогает улучшить предсказуемость спринта для команды. Если в команде страдает вообще командная работа, работа с задачами, если есть какие‑то патологические проблемы, то просто разбиение задач с этим, естественно, не поможет, и это тоже важно понимать.
Для меня эта история про то, что процессы необязательно менять сразу и целиком. Можно попробовать что‑то небольшое на одной команде, посмотреть на результат и решить, оставлять или нет. Что‑то не приживается, а что‑то, как декомпозиция, потом переходит и в другие команды.
Если у вас в команде похожая ситуация, попробуйте начать с одного правила: в спринт берем только задачи по 1 SP. Первое время будет сопротивление и много «это нельзя декомпозировать», на планировании придется тратить больше времени, но это определенно того стоит.
