Comments 3
В описании управления изменениями (CR, то, сё...) не увидел описания этапов рассмотрения вариантов решения с оценкой по деньгам, времени, ресурсам, рискам (+ принятие решения владельцем продукта). Обходитесь без этого?
Сейчас, при описании ролей(!) аналитиков: бизнес-, системный- (как фронт-, бек-разработчики), системный аналитик, обычно, не собирает бизнес-требования. У вас не так или роли(!) перемешаны?
На сегодня команда достигла зрелости
В смысле зрелости ИТ-компаний? Какой по-Вашему уровень?
В описании управления изменениями (CR, то, сё...) не увидел описания этапов рассмотрения вариантов решения с оценкой по деньгам, времени, ресурсам, рискам (+ принятие решения владельцем продукта). Обходитесь без этого?
Команда работает с задачами, которые уже прошли оценку PO. При планировании PL ориентируется на приоритет у задачи, оценки команды по задачам и считает временные затраты на инкремент. В результате формируется бэклог задач на инкремент.
Сейчас, при описании ролей(!) аналитиков: бизнес-, системный- (как фронт-, бек-разработчики), системный аналитик, обычно, не собирает бизнес-требования. У вас не так или роли(!) перемешаны?
В нашей команде мы тесно взаимодействуем с бизнесом, при написании CR мы уточняем требования и детализируем задачу. В команде развит t-shape.
Как мы делаем клиентский сервис