мы на прошлой работе тоже не оценивали баги в sp.. точнее оценивали только старые добрые, техдолговые

В прошлом спринте команда захотела попробовать не оценивать баги, кстати. Я хмыкнул, но раз команда хочет, почему бы нет, благо спринты недельные.

Я в целом вообще против практики хранения багов в бэклоге. НО пока команда учится - пусть будет.

мы раньше использовали Rally (aka CA Agile Central), там по другому инструмент не настроить

Я в целом вообще против практики хранения багов в бэклоге. НО пока команда учится - пусть будет.

В этом спринте к практике оценки багов решили вернуться

А почему?

Потому что баги надо фиксить, а не оценивать :) Если без лозунгов - в корректном workflow баг всегда идет топовым приоритетом и ты не можешь делать НИЧЕГО, пока баг существует.

пока ты фиксишь ВСЕ баги, в вилларибо уже выпустят новый продукт и захватят весь рынок. Тем более, что все баги зафиксить не получится примерно никогда.

пока ты фиксишь ВСЕ баги, в вилларибо уже выпустят новый продукт и захватят весь рынок. Тем более, что все баги зафиксить не получится примерно никогда.

Потому что чтобы использовать мой подход, надо не пускать "забагованные" фичи из спринта в Done. А для этого надо много всего прочего сделать, от клевого TDD и CD, до неклевой teas management бюрократии :)

Кстати, TDD не про отсутствие багов.

Потому что чтобы использовать мой подход, надо не пускать "забагованные" фичи из спринта в Done. А для этого надо много всего прочего сделать, от клевого TDD и CD, до неклевой teas management бюрократии :)

А что в такой схеме делать с багами, не связанными напрямую с разрабатываемыми историями в спринте? Ну то есть он, конечно, связан =) но обнаружить баг в рамках спринта ты не можешь и он всплывает через неделю, месяц или в день релиза =)

А если таких багов много? Они занимают весь топ беклога?

Это позволяет больше знать про свой продукт и быстрее реагировать - это да

То это плохо и печально и надо идти к PO и предупреждать его о том, что следующий спринт, а то и несколько будут посвящены багфиксу. А так как в реальности такая уйня невозможна - то вот искать всякие стратегии, чтобы технический долг не накапливать, а баги фиксить.

У этого пайплайна две фундаментальные прблемы: 1 ДОРОГО пиздец как 2 никто ни..уя не умеет его делать.

Не соглашусь. Я бы исходил из позиции ценности. Ценность бага (его фикса) в общем случае более очевидна, потому что есть прямой эффект от такой работы - мы знаем кого и как наш баг аффектит и насколько это серьёзно. Но я бы воздержался от безусловного награждения багов наивысшим приоритетом в сравнении с фичами. Вполне себе допустим ситуация когда сегодня ценнее будет выпустить в прод новую фичу с приложенным листом known issues

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

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

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

С этим соглашусь. Но в моей практике нулевая терпимость в таком контексте предъявляется не ко всем багам, а только к тем, что вскрываются в рамках спринта.

Второй день тема об управлении Беклогом Продукта и командами. Согласен с Pavel , что это сложно при больших объемах команд и что они в итоге как то перестанут коррелировать с единым управлением одного Беклога и одного РО. И вот что я подумал: да, - бывает. Но это не означает, что другое не возможно. Да есть Фреймворки и их scaled варианты. И безусловно каждый из них как может подойти компании/продукту/команде - так и не подойти. Я всегда ориентируюсь на эмпиризм, мне близко в LeSS максимизация responsibility на команды. Конечно же только состоявшаяся, самоорганизованная, уполномоченная, ответственная, кроссфункциональная команда может справиться с доставкой ценности, качественным готовым к поставке продуктом. Итого: такой она может стать только находясь в соответствующей среде, и эта среда должна поддерживаться владельцами/ТОР компании, создаваться и совершенствоваться агентами Изменений. Очень часто многие применяют механический Скрам, не понимая философию. Механика применения относится и к любому из фреймворков - особенно если их расценивать просто как каркасы с набором правил/ролей/мероприятий/артефактов. Мне кажется было бы здорово обсуждать те или иные практики, способы, Фреймворки с точки зрения Ценностей и Философии и как лакмусом проверять соответствуют ли они прозрачности/инспекции/адаптации, эмпиризму, ценностям Скрама, Agile манифесту.... Каждому подойдёт свой подход... в крайнем случае - НЕТ :)

Обсуждать было бы здорово, к согласию придти не получится. особенно если начать обсужать LeSS vs SAFe :)

А про возможно-ли другое - наверное возможно, умные дяди и тети рано или поздно что-то придумают. Но пока - увы. Empirical evidence говорит о том, что бывают две ситуации: раздельными бэклогами уже управляют и раздельными бэклогами еще не управляют :)

Потому что нет согласия в рядах аджайлистов :)

Скажем честно, аджайл и про ЗАЧЕМ и ПоЧЕМУ мало говорит. Вообще очень такой молчаливый аджайл. Ажаль :)

но надо, чтобы 1. окружение разработки ВСЕГДА 100% матчилось с продакшеном 2. в командах не использовались feature branches 3. команды освоили близкий к single item flow

Эм.. Вот первый пункт я бы сказал очень редко выполним.