замеряете среднюю Velocity команды - за все спринты команды или за определённый интервал времени?
Пример, у меня команда прошла 10 спринтов (4 недели = 1 итерация). Считать ли мне Velocity за все спринты или лучше свежие за последние 3-4 спринта? Как лучше поступить?
Средняя команды Velocity: 427 sp
Пример:
- Июнь (566 sp → 651 sp → 306 sp)
- Июль (587 sp → 972 sp → 479 sp)
- Август (341 sp → 524 sp → 306 sp)
План sp → Реальный объём работы sp → Фактически реализованный sp
Заранее благодарю за ответ!
Мы берём последние 3-4 спринта. Брать больше нет смысла - с тох пор уже слишком многое изменилось, информация, на основе которой тогда выполнялась оценка, сейчас скорее всего, уже сильно устарела.
Для планирования высчитываем ёмкость (capacity) от среднего значения скорости (velocity ) за последние 5 итераций (учитывается только факт - значение sp по таскам закрытым за спринт).
Можно Вас попросить указать пример расчёта?
я правильно понимаю, что вы не планируете на спринт больше capacity?
Зависит от ситуации. Я стараюсь в историю набрать как можно больше кейсов, повлиявших на велосити (отпуска, внезапные больничные, обучения, некачественный рефайнмент, блокеры внешние и внутренние, тех долг и тп). Иногда команда за полгода через все это проходит, иногда быстрее, иногда дольше
Да, завтра напишу вам подробнее.
Да, мы рекомендуем командам при постановке цели и формирования бэклога на спринт не брать больше капасити.
А они берут? (я сейчас не стебусь и не подкалываю, я спрашиваю по делу)
Добрый вечер! параллельный вопрос - каким способом замеряете реальный объем sp? Ретро?
Не совсем понятен вопрос. Условная жира сама всё считает же
SP величина составная.. лихо вы ее складываете. Разве 5 задач по 2 SP будут равны одной на 10 SP? 1 апельсин 🍊 + 1 апельсин 🍊 это = 2 апельсина, а не один большой. Прогнозировать в SP практически не реально. Попробуйте штуки 😊
Чую запах Канбана... :)
Прогноз по SP валиден, это всё таки про доступную капасити команды. Если у нас стабильный поток задач примерно одинакового размера на протяжении последнего времени, прогноз в штуках также валиден. Если поток не стабилен, задачи разного размера и закономерности не прослеживается, то стоит отталкиваться от доступной капасити команды. Что важно здесь сказать, так это то что "большие" задачи содержат в себе больше не определённости, поэтому мы рекомендуем их разбивать на более мелкие.
Да, я поняла. Хороший и правильный вопрос! Ответ: кто-то да, кто-то нет. Насильно не заставляем. Команды сами приходят методом проб и ошибок. Там уже, само собой, зависит от многих факторов: есть ли выделенный или приходящий см (кто может обучить и передать знания в команду), насколько команда или кто в ней готов что-то менять, видит ли команда проблему в ситуации с Гималаями в графиках, давление ПО/ПМ или бизнеса и как команда с ним справляется, et cetera.
я для чего это выяснял. Просто есть следующий риск. Если им жестко ограничить капасити через велосити за 5 спринтов посчитанный как среднее арифметическое, то они возьмут в следующие 5 спринтов меньше SP чем в предыдущие. И когда из статистики уберутся спринты, в которых брали много, то среднее арифметическое по 5 последним спринтам начнет падать и мы будем иметь тренд на плавное, но затухающее снижение velocity, ну и дополнительно мы убиваем амбициозность команды
На мой взгляд некорректно определять капасити команды на основе велосити. Для меня Велосити - это про способность команды ритмично поставлять ценность. Доступную капасити нужно каждый раз определять. Чем на больший период мы пытаемся её определить, тем больше неопределённости, и тем больше реальная доступность не совпадёт с расчитанной.
это все ориентировочные показатели, чтобы брать в итерацию амбициозно и при этом не упороться. Ну и на правах шутки: А в чем измеряется способность команды ритмично поставлять ценность? (я могу поставлять ценность в ритме ча-ча-ча, а могу в ритме бочаты)
Отвечу не в шутку. У некоторых команд есть цель - создавать за спринт инкремент, который можно зарелизить на продуктив. Если на конец спринта у команды много незавершённой работы и так с каждым спринтом, команда начинает испытывать сложности с релизом в конце каждого спринта. (продукт в разобранном, незаконченном виде) Поэтому ответ на твой вопрос - в релизе в конце спринта. Как база. Дополнительный показатель - реализация потенциала спринта. Сколько капасити было доступно на спринт и сколько было превращено в поставку.
согласна, поэтому жестких правил - "планируйте строго по цифрам в отчетах", конечно же нет. Как цифры могут помочь: опираясь на капасити - даем предварительный прогноз для бизнеса (в рамках квартального планирования, рекомендуем до 2 итераций, у нас они по 2 недели, давать более детальный прогноз, далее - по специфике сервиса и определенности среды) при планировании спринта - это ориентир для команды и инструмент для запуска диалога с ПО или друг с другом (классическая ситуация, с которой сталкиваюсь, заходя в новые команды - кол-во задач в бэклоге спринта, превышающий возможности в команды до 4х раз. Например - 124 СП в бэклоге при велосити команды в 24 СП. Постоянно накапливающийся и ездящий из спринта в спринт хвост задач - "потому что это же все надо", приводящий к таким неуправляемым накоплениям) цифры наш помощник. Также хорошо помогает в цифрах показать командам, сколько работы можно было и не делать вообще, а спокойно работать по цели, не бегая в огне от одного тикета до другого, когда у команды мышление пока направлено на коммит на бэклог, и нет созданной культуры целеполагания (тут, конечно, тоже простор для обсуждения - от работы с самой командой и каждым ее участником лично, до того, как устроена сама система, формирующая поведение команды и тп)
такой беклог - это продобл ПО а не команды, надо его дрючить за это
Обсуждают сегодня