What impressed you the most during the previous sprint?

К ретро готовишься?

If you wake up in the moringn and get a magic wand that can change one thing in your current process, what will you change?

К интервью

Ты все время контракты ищешь?

Ты сам на себя работаешь?

В основном на жену и двоих детей :)

они как к скраму относятся? )

они как к скраму относятся? )

разделочная )

Этих шесть!

(И не надо сразу становиться в стойку, я имею ввиду неитеративный процесс с рабочими центрами и WIP лимитами)

Если ты про ресторан - то... Да :)

Ого го кто то приглашает в ресьоран 😀

Ох устал я там на все ходить)

Хотя с учетом "бэклога багов" подозреваю, что не это имелось ввиду, совсем не это :)

Пробуем сделать фокус группы и ближе общаться командами с пользователями. Пока решили, что интервью будет делать РО вместе с ними. А команды уже пользоваться на PBR и при разработке.

Т.е. Решили чтобы маркетологи и РО проводили интервью, а потом уже переработанные ответы на РВR? Привет)

Может это своеобразная имплементация zero bug policy была? https://medium.com/qualityfaster/the-zero-bug-policy-b0bd987be684

А где здесь связь с отдельным бэклогом? В статье про это ни слова нет...

Ссылка была для пояснения zero bug policy только. Моя мысль в том, что, возможно, так коряво идею имплементировали (=своеобразная имплементация)

Ну во-первых, не имплементировали, т.к. я не дал:) Во-вторых, в той ситуации, которая была, там не было ничего из этой статьи - ни разделения багов по категориям, ни решения не заниматься ничем другим пока не будут пофикшены критические баги, ничего такого.

Денис @dennoid - Ты меня спрашивал про идеи для апробации по итогу тренинга LeSS Practitioner. Как то звезды сошлись и мы вместе c бизнесом пробуем взаимодействовать в таком вот ключе. Толчок из тренинга, ну и созрели мы для такого эксперимента. Надеюсь все получится.

Ок, понял. Но ведь у этого "тренера" в чем-то была цель, вероятно... Есть идеи чего он хотел добиться?

Вероятно отдельный бэклог багов может хорошо показать существенные проблемы продукта (и процессов). Это созвучно zero bug policy.

Точнее не самому zero bug policy, а моменту, когда решили на него перелезть.

Не было такого момента и такого решения:)

Отдельный бэклог можно было сделать, просто нажав фильтр "баги" в Jira. Проблема была в том, что организацию не устраивало качество продукта и количество багов, и когда я пришёл в команду и спросил, как они работают с багами, как их отслеживают (потому что этой инфы нигде не было, если надо взять какой-то баг, то это обсуждалось на Ежедневном Стэндапе или вообще приватно, нигде не фиксировалось, и о том что баг пофикшен, зачастую узнавалось случайно в следующем спринте, когда оказывалось, что части багов в бэклоге уже по факту нет, а они там формально висят, т.к. СМ особо не парится про бэклог и ведёт свой какой-то excel-файл, где отмечает то что считает нужным), "СМ" ответил, что посоветуется с коучами из Калифорнии, и потом сказал, что коучи из Калифорнии считают что всё ок, баги не нужны в бэклоге (ни Продукта, ни Спринта) и если сильно хочется, то можно сделать отдельный бэклог для багов. Поэтому нет, те коучи ничего путного СМу не советовали.

Расскажешь потом, что получается. Мы тоже после тренинга хотим затащить гугл аналитику в команды для шаринга компетенций

Отдельный бэклог можно было сделать, просто нажав фильтр "баги" в Jira. Проблема была в том, что организацию не устраивало качество продукта и количество багов, и когда я пришёл в команду и спросил, как они работают с багами, как их отслеживают (потому что этой инфы нигде не было, если надо взять какой-то баг, то это обсуждалось на Ежедневном Стэндапе или вообще приватно, нигде не фиксировалось, и о том что баг пофикшен, зачастую узнавалось случайно в следующем спринте, когда оказывалось, что части багов в бэклоге уже по факту нет, а они там формально висят, т.к. СМ особо не парится про бэклог и ведёт свой какой-то excel-файл, где отмечает то что считает нужным), "СМ" ответил, что посоветуется с коучами из Калифорнии, и потом сказал, что коучи из Калифорнии считают что всё ок, баги не нужны в бэклоге (ни Продукта, ни Спринта) и если сильно хочется, то можно сделать отдельный бэклог для багов. Поэтому нет, те коучи ничего путного СМу не советовали.

Отдельный бэклог можно было сделать, просто нажав фильтр "баги" в Jira. Проблема была в том, что организацию не устраивало качество продукта и количество багов, и когда я пришёл в команду и спросил, как они работают с багами, как их отслеживают (потому что этой инфы нигде не было, если надо взять какой-то баг, то это обсуждалось на Ежедневном Стэндапе или вообще приватно, нигде не фиксировалось, и о том что баг пофикшен, зачастую узнавалось случайно в следующем спринте, когда оказывалось, что части багов в бэклоге уже по факту нет, а они там формально висят, т.к. СМ особо не парится про бэклог и ведёт свой какой-то excel-файл, где отмечает то что считает нужным), "СМ" ответил, что посоветуется с коучами из Калифорнии, и потом сказал, что коучи из Калифорнии считают что всё ок, баги не нужны в бэклоге (ни Продукта, ни Спринта) и если сильно хочется, то можно сделать отдельный бэклог для багов. Поэтому нет, те коучи ничего путного СМу не советовали.

Кстати, я не так давно вопрос с приоритетами с «кручами из калифорнии» обсуждал. Я слышал точку зрения, что если баг по сложности фикса имеет возможность получить эстимейт, то он никак не может быть low impact.

а если это "там все понятно, но надо солидно архитектуру править"?