Size: a a a

2017 November 29

АК

Алексей Козлов in SOFTER
Да, как то так. Можно ещё доску придумать двумерную отдельно
источник

АК

Алексей Козлов in SOFTER
источник

АК

Алексей Козлов in SOFTER
типа такой
источник

АК

Алексей Козлов in SOFTER
а задачи по перемещению стикеров на ней влево или вниз - в общий бэклог
источник

VA

Vasilii Artemev in SOFTER
Такая таблица хорошо помогает избежать типичной ошибки новичка, когда адресуют только impact или только probability )
источник

АП

Андрей Павленко in SOFTER
Да техник много (impact mapping тот же), просто в дизайне Скрама они не перечислены. Чем хотите, тем и пользуйтесь. Но делать отдельный бэклог я бы не стал, лучше всё-таки как-то приаттачить риски к соответствующим элементам бэклога. Риски же явно так или иначе связаны с продуктом, так зачем их далеко прятать?
источник

NK

Natalia Kosinova in SOFTER
Ⓢⓔⓡⓖ
А вы завтра будете на митапе? Может расскажете, минут 10 для этого найдём ?
у вас завтра митап, я о дате не знала((( не смогу завтра.... но в следующие разы могу что нибудь рассказать)))
источник

VA

Vasilii Artemev in SOFTER
А что делать с рисками связанными с архитектурой и тех. долгом, если они сквозные для фич продукта?
И процессными рисками?
источник

АК

Алексей Козлов in SOFTER
Можно отдельно вести реестр рисков. А бэклог с задачами общий: детализировать риск, провести превентивные мероприятия, составить план реагирования и т.д.
источник

VA

Vasilii Artemev in SOFTER
Да, отдельный реестр мне кажется правильным. Называть его бэклогом или нет уже не так важно )
источник

Ⓢⓔⓡⓖ in SOFTER
Vasilii Artemev
Да, отдельный реестр мне кажется правильным. Называть его бэклогом или нет уже не так важно )
Расскажешь завтра минут на 15 про риски и скрам?
источник

АП

Андрей Павленко in SOFTER
Vasilii Artemev
А что делать с рисками связанными с архитектурой и тех. долгом, если они сквозные для фич продукта?
И процессными рисками?
Ну так если они сквозные для продукта, они тем более в бэклоге продукта должны лежать
источник

АП

Андрей Павленко in SOFTER
Я против лишних сущностей, потому что они неоправданно увеличивают сложность системы и растут риски уже самого рабочего процесса 🙂
источник

Ⓢⓔⓡⓖ in SOFTER
Андрей Павленко
Я против лишних сущностей, потому что они неоправданно увеличивают сложность системы и растут риски уже самого рабочего процесса 🙂
Против того, чтобы признать их существование и хотя бы зарегистрировать их как сущность ?😉
источник

Ⓢⓔⓡⓖ in SOFTER
Кстати одна из стратегий (не лучшая) управления рисками - игнорирование
источник

VA

Vasilii Artemev in SOFTER
Мне больше нравится название "accept", чем "ingore". Действительно, в некоторых случаях вполне оправданно просто принимать риск как есть и ничего с ним не делать
источник

АП

Андрей Павленко in SOFTER
Ну нет конечно, если единственный вариант признать риски - хранить их в отдельной сущности, то пусть хоть так :)
источник

АП

Андрей Павленко in SOFTER
Просто два беклога - фич и рисков - мне лично нравятся меньше, чем 1 общий, но как сказано выше - если команда готова только к варианту 2 бэклогов, пусть так и будет
источник

VA

Vasilii Artemev in SOFTER
В терминах скрам гайда тут скорее вопрос в ownership и responsibility. Бэклог продукта это ответственность владельца продукта. Если он же ответственный за риски, то можно в 1 бэклоге хранить. Если риски отдать скрам мастеру или создать отдельную роль, то нужна отдельная сущность для рисков
источник

VA

Vasilii Artemev in SOFTER
Ⓢⓔⓡⓖ
Расскажешь завтра минут на 15 про риски и скрам?
Я пока не уверен успею ли завтра к 7 освободиться
источник