АК
Да, как то так. Можно ещё доску придумать двумерную отдельно
Size: a a a
2017 November 29
АК
АК
типа такой
АК
а задачи по перемещению стикеров на ней влево или вниз - в общий бэклог
VA
Такая таблица хорошо помогает избежать типичной ошибки новичка, когда адресуют только impact или только probability )
АП
Да техник много (impact mapping тот же), просто в дизайне Скрама они не перечислены. Чем хотите, тем и пользуйтесь. Но делать отдельный бэклог я бы не стал, лучше всё-таки как-то приаттачить риски к соответствующим элементам бэклога. Риски же явно так или иначе связаны с продуктом, так зачем их далеко прятать?
NK
А вы завтра будете на митапе? Может расскажете, минут 10 для этого найдём ?
у вас завтра митап, я о дате не знала((( не смогу завтра.... но в следующие разы могу что нибудь рассказать)))
VA
А что делать с рисками связанными с архитектурой и тех. долгом, если они сквозные для фич продукта?
И процессными рисками?
И процессными рисками?
АК
Можно отдельно вести реестр рисков. А бэклог с задачами общий: детализировать риск, провести превентивные мероприятия, составить план реагирования и т.д.
VA
Да, отдельный реестр мне кажется правильным. Называть его бэклогом или нет уже не так важно )
Ⓢ
Да, отдельный реестр мне кажется правильным. Называть его бэклогом или нет уже не так важно )
Расскажешь завтра минут на 15 про риски и скрам?
АП
А что делать с рисками связанными с архитектурой и тех. долгом, если они сквозные для фич продукта?
И процессными рисками?
И процессными рисками?
Ну так если они сквозные для продукта, они тем более в бэклоге продукта должны лежать
АП
Я против лишних сущностей, потому что они неоправданно увеличивают сложность системы и растут риски уже самого рабочего процесса 🙂
Ⓢ
Я против лишних сущностей, потому что они неоправданно увеличивают сложность системы и растут риски уже самого рабочего процесса 🙂
Против того, чтобы признать их существование и хотя бы зарегистрировать их как сущность ?😉
VA
Мне больше нравится название "accept", чем "ingore". Действительно, в некоторых случаях вполне оправданно просто принимать риск как есть и ничего с ним не делать
АП
Ну нет конечно, если единственный вариант признать риски - хранить их в отдельной сущности, то пусть хоть так :)
АП
Просто два беклога - фич и рисков - мне лично нравятся меньше, чем 1 общий, но как сказано выше - если команда готова только к варианту 2 бэклогов, пусть так и будет
VA
В терминах скрам гайда тут скорее вопрос в ownership и responsibility. Бэклог продукта это ответственность владельца продукта. Если он же ответственный за риски, то можно в 1 бэклоге хранить. Если риски отдать скрам мастеру или создать отдельную роль, то нужна отдельная сущность для рисков
VA
Расскажешь завтра минут на 15 про риски и скрам?
Я пока не уверен успею ли завтра к 7 освободиться