фиче + есть еще СА. Если это брать в спринт, то написание кода и тестирование как бдуто будут ждать конца спринта когда им мб придет задача, а мб и не придет.
По поводу оценки того придет задача в разработку или нет это понятно - оценка задач командой. Но вот БА и СА не могут на 100% делать аналитику параллельно, а уж тем более парарллельно с написанием кода.
ЧТо делать в такой ситуации?
Была в роли БА внутри скрам-команды. Мы всегда готовили стори вперед на спринт, максимум два. Стартовали условно со sprint 0, когда команда готовила инфраструктуру, допустим, а мы - беклог с бизнес-сторями. И дальше шли по стандартной каденции и скрам церемониям. Задачи аналитика не трекались на общей доске и не были частью спринта.
Если оставаться в рамках Скрама, то уменьшать размер задач, чтобы все можно было сделать за спринт. Альтернатива - делать вытягивающую систему, где БА и СА работают, как отдельная команда. И «варят» столько требований сколько нужно чтобы команда разработки не простаивала. И «не варят», когда команде работы хватит на два ближайших спринта. Остальное время помогают команде разработке. ВП при этом управляет беклогом для БА и СА, а также тем что получилось на выходе работы БА и СА.
Спасибо, буду разбираться. Пока вижу что первый подход в моей ситуации труднодостежим, а второй вариант плох из-за того что аналитикам придется много переключаться между контекстами + не понятно как управлять их бэклогом. А такой вопрос, такие вопросы или моменты разбираются на курсах по скраму. Понимаю что это не задача скрама, но сейчас курсы могут быть адаптированны под разные ситуации.
В чем тогда ценность спринтов?
Дим, у вас контекст не заточен под скрам и вы его не хотите поменять так, чтобы скрам стал возможен
Практически каждый кейс который мне встречается с композицией ба/са/апстрим очень криво кладется на скрам. Прям беда.
Можете поделиться как пуступали в таких случаях?
Определить что для для заказчика главное \ что имеет ценность. Посмотреть на текущие проблемы и оценить связаны ли они с тем что "главное" для заказчика. Если проблемы не про главное и это для заказчика имеет меньшую ценность чем главное, то с этим можно ничего не делать. Если проблемы связаны с главным, то вместе с заказчиком разбирать альтернативы как это можно починить, привлекая экспертизу (чтобы не предумывать свой собственный велосипед, а использовать бенчмарк).
Обсуждают сегодня