Работа с ошибками в Scrum через GreenHopper

Question

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

Я читал различные руководства Scrum, документацию Greenhopper и начал реализацию процесса Scrum в нашей команде. После некоторых исправлений и изменений он в основном хорош, но одна вещь не позволяет мне хорошо спать: ошибок.

Different решения proposed от developers, но я все еще не могу найти свой путь здесь.

В нашем рабочем процессе любой вопрос живет в 4-х состояниях: Open -> В Testing -> Решено -> Закрытое

Когда разработчик доволен своим кодом, который он ставит вопрос к В Testing и автоматически присваивается лидеру QA. QA проверяет проблему и, если все ok вопрос будет Решено. Если не - Открыть еще раз. В разрешенном состоянии проверка кода выполняется, и если код является безопасным, оптимальным и соответствует разработанной структуре, выпуск становится Закрыт. Если разработчик что-то сделал не правильный - Открыть еще раз.

Хитрость здесь повторное открытие эмиссионного (рассказ), потому что в то же время ошибок достаются, что земля в продукт накопившихся - не спринт задела, и из-за Scrum-полосная разработчик может» t работа над проблемами, которые не находятся в отсталости, но в то же время история не может быть закрыта, потому что код глючит или плохо написан.

Итак, вопрос в том, должен ли быть закрыт сюжет, даже если у него есть некоторые ошибки, связанные с ним, и эти ошибки планируется зафиксировать в дальнейших спринтах?

Или история не может быть закрыта, пока все связанные ошибки не будут исправлены, что означает, что если спринт закончен, но не все ошибки исправлены для истории, история остается открытой, исключена из завершенного спринта и перемещена в следующую спринт, так что сюжетные точки не сожжены в законченном спринте?

Answer 1

Имея подобную ситуацию, одна из ключевых вещей, которые мы обнаружили, отсутствовала (или была недостаточной) из наших историй, была четко определенной (и согласованной) «Определение совершенной» (DoD). Если у вас есть хорошо определенные «сделанные» критерии, тогда, когда история завершена (встречается с DoD), тогда она завершена, конечно, трюк становится тем, как определить хорошее определение, которое не слишком расплывчато, обеспечивает хорошее качество, все соглашаются и на самом деле выполнимо. Для меня это не одно из упражнений, мы постоянно пересматриваем его в каждой ретроспективе, чтобы убедиться, что они все еще актуальны и вносили изменения по мере необходимости. Для идей по настройке хорошего DoD попробуйте Google, есть много хороших упражнений, которые команды могут сделать для его определения (например, this one).

Что касается ошибок, которые проскальзывают, сделайте это, я бы сказал, что они должны быть возвращены обратно в отставание продукта и иметь приоритет в соответствии с нормальным. Ошибки, возникающие во время спринта, связанные с работой спринта, должны быть исправлены в спринте (избегайте администрирования/документации!).Помните, что многие ошибки (или все большее количество ошибок) обычно означают, что есть проблема с качеством, может быть, есть большая проблема для решения (слишком много давления, чтобы закончить, возможно?).

Подводя итог, взгляните на получение надежного DoD (что поощряет качество по количеству) и постоянно улучшайте его, замедляйте и делайте меньше, а не более «с ошибками», и когда появляются ошибки, возвращайте их обратно в отставание продукта и привлечение ПО, чтобы как можно скорее определить приоритет.

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

Надеюсь, это поможет?