Ситуация: Спринт в работу, user story в работе, но тут Заказчик направляет Change Request.
Как Вы поступаете в таком случае?
Уважаемые Бизнес Аналитики, предлагаю поделиться своим опытом, best practice и знаниями по теме Change request handling.
На хууууууу....тьху в бэклоооог!
Ситуация: Sprint in progress, user story in progress, но тут Customer asks for Change Request.
Как Вы поступаете в таком случае?
Уважаемые Business Analysts, предлагаю share свой experience, best practices and knowledge по теме Change Request Handling.
Пофіксив.
1. Сразу же предупредить Заказчика, что велосити команды упадет, ведь как минимум нужно будет время на грумминг или на рефайнмент задачи.
2. Дальнейшие действия зависят от того, насколько большой Change request и его нужно обязательно в текущем спринте или можно на следующий оставить.
3. Если в текущий спринт нужно взять — тогда сразу на грумминге убрали из спринта нужное количество задач, чтобы освободить капасити для change request и заказчику четко об этом написали.
На будущее лучше прописать процедуры change management, чтобы заказчик четко понимал, сколько стОит один такой change request
И да, такое допустимо только в исключительных случаях
1. Если импэкт небольшой — сделать внеочередной грумминг, перепланировать спринт, описать риски и заставить ПО подписаться под ними. Добиться от ПО понимания того, что это исключительный случай и это не должно быть даже 1/3 случаев.
2. Если импэкт большой, то имеет смысл прервать спринт и начать новый (если возможно)
3. Если такие инпуты в середине постоянные, то имеет смысл либо отказаться от Скрама в пользу какой-то вариации канбана либо, если уж совсем нимажлива, то на этапе спринта закладывать резерв для исполнения таких запросов.
Если такие инпуты в середине постоянные
Да кто ж тебе скажет, что они навечно. Но такова селяви, что аппетит приходит во время потребления услуг.
На то и глаза скрам-мастеру, чтобы это понять и предпринять меры. Пусть даже и в тайне от ПО.
Хороший скрам-мастер отличается от BDSM-мастера только тем что последний помнит стоп-слово :)
У него даже есть специальная плеть для груминга :)
Вы шо, не аджайл, что ли? Сложно поменять?
*сарказм*
но тут Заказчик
но тут Manager
но тут Architect
но тут ...
7 бед — один PO
> 1 ПО — не скрепно.
Спринт в работу, user story в работе, но тут Заказчик направляет Change Request.
one in, one out
Выставляется отдельная таска, которая груммится в порядке приоритетности и берётся в работу в следующий спринт или(в случае крайней важности) добавляется хотфиксом в текущий спринт, но предупредив заказчика о рисках не донести другую задачу в спринте.
Не использовать скрам) Как будто кроме этого нет методологий)
Зачем сразу правильный ответ спойлером выкидывать? Лишаешь гениальных манагеров полового удовлетворения (включая того что с мёртвой лошадью)
ватерфол жеж
Тег фор-груминг и обсудить на ближайшем груминге. Если не получилось, но очень надо, то можно догрумать на ближайшем планинге.
Правится юзер стори, о изменениях уведомляются разработчики.
Как по другому может быть?
И что дальше? Крылья бабочки создают раскол в параллельной вселенной?
Это в параллельной вселенной. В реале это овертайм в спринте, и тормоза во всех последующих. В том числе по очень важными и срочным допилам.
Vlad Stelmahovsky
Włodzimierz Rożkow
Anna Kalmius
anonymous
Luci
Олексій Пєніє
Luci
Artem Perchyk
Андрій Кузнецов
Андрій Кузнецов
Oksana
Yegor Chumakov
Vlad Stelmahovsky
Леголас Трандуилович
Александр Шевченко
Олексій Пєніє
23 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів