Когда для продуктовой разработки собирается команда, метрики планирования которой никто раньше не отслеживал, внезапно оказывается, что команда планировать‑то и не умеет.
Как с этим бороться и что можно сделать, я хочу разобрать на примере своей команды.
Сейчас я RTE (Release Train Engineer) в IT‑центре Summit Group, а когда началась эта история, я была скрам‑мастером одной из команд, работающих по Scaled Agile Framework (SAFe).
Наши команды делают цифровые продукты для финансового бизнеса, в каждой есть разработчики, аналитики и тестировщики. Сама я не люблю внедрять методологии целиком просто потому, что так написано в книге, мне интереснее пробовать по частям и смотреть, что из этого реально работает.
Какую метрику мы рассмотрим — авторский фокус‑фактор (ФФ). Почему авторский? В нашей компании мы считаем его немного по‑другому, чем принято. Обычно ФФ показывает, какая доля времени команды уходит на задачи спринта, а у нас ФФ = выполненные задачи / запланированные задачи, считаем в стори поинтах (SP). Берем во внимание, что результат 100% — это тоже не лучший результат, ведь это значит, что команда могла бы сделать и больше. «Золотой» результат входит в диапазон 80–95%.
Дано: разработчики разных платформ, тестировщик, аналитики. Все эти люди раньше работали только в своих отделах и направлениях, и никто не знал о том, как работать в мультиплатформенной команде. Если раньше в задаче участвовали несколько разработчиков, то фичи могли делаться месяцами, а разработчики взаимодействовали в комментариях к задаче и на редких встречах по синхронизации.
Как было
Фокус‑фактор команды с июля 2023 по февраль 2024: в среднем 73%, но разброс от 24% до 100%
Если посмотреть на график, то кажется, что средний ФФ 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 спринтов после перехода на задачи по 1 SP: в среднем 87%, ни одного спринта ниже 75%
После перехода картина поменялась. За первые 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. Первое время будет сопротивление и много «это нельзя декомпозировать», на планировании придется тратить больше времени, но это определенно того стоит.
Источник: habr.com