Как лучше всего интегрировать исправление ошибок в процесс Scrum? [закрыто]

Я изучал и читал о Scrum в последние несколько дней, а также читал о планировании спринтов и задачах. Одна проблема, которая пришла мне в голову, - это как бороться с ошибками в Scrum. Хенрик Книберг перечисляет некоторые способы решения этой проблемы в своей очень хорошей книге Scrum and XP from the Trenches :

1. Владелец продукта распечатывает наиболее важные элементы Jira, приносит их на собрание по планированию спринта и развешивает на стене вместе с другими историями (тем самым неявно указывая приоритет этих элементов по сравнению с другими историями).
2. Владелец продукта создает истории, относящиеся к элементам Jira. Например, «Исправьте наиболее важные ошибки отчетов бэк-офиса, Jira-124, Jira-126 и Jira-180».
3. Считается, что исправление ошибок выходит за рамки спринта, т. Е. Команда поддерживает достаточно низкий коэффициент фокусировки (например, 50%), чтобы у них было время для исправления ошибок. Тогда просто предполагается, что команда будет тратить определенное количество времени на каждый спринт, исправляя ошибки, о которых сообщает Jira.
4. Поместите отставание продукта в Jira (то есть откажитесь от Excel). Относитесь к ошибкам как к любой другой истории.

Это действительно то, что нужно решать для каждого проекта или есть лучшие решения? Я могу думать о проблемах с каждым из этих подходов. Есть ли гибрид из этих подходов, который работает лучше всего? Как вы справляетесь с этим в своих проектах?

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

1. Одинаковое рассмотрение всех ошибок с помощью элементов невыполненной работы может показаться хорошей идеей в теории (работа отслеживается в одном месте), но на практике не работает. Ошибки обычно низкоуровневые и более многочисленные, поэтому, если вы создадите индивидуальную пользовательскую историю для каждой ошибки, то «настоящие» истории скоро будут скрыты.
2. Явное время в каждом спринте, зарезервированное для исправлений, нормально, если сделано так, чтобы это было видно владельцу продукта. Ошибки следует упоминать во время ежедневной схватки, а обсуждение исправленных ошибок должно происходить во время обзора спринта. В противном случае product owner не будет знать, что происходит в проекте.
3. Помещение всего бэклога в инструмент отслеживания ошибок приводит к тому же набору проблем, что и в 1. Более того, большинство трекеров ошибок не разработаны с учетом Scrum, и их использование для этой цели может быть болезненным.

Решение, которое мы нашли наиболее удовлетворительным, заключалось в том, чтобы помещать одну пользовательскую историю под названием «Тикеты» или «Ошибки» на каждый спринт. Затем такую ​​историю можно разделить либо на низкоуровневые задачи, описывающие конкретную ошибку (если они известны во время планирования), либо на мета-задачи, резервирующие определенное количество часов для общего исправления ошибок. Таким образом, владелец продукта видит процесс, а диаграмма выгорания отражает его прогресс.

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

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

Приведу цитату:

• Если ошибку легко / быстро исправить (один лайнер и т. Д.), Просто исправьте ее.
• Если ошибка нетривиальная и не блокировщик, то добавьте ее в бэклог.
• Если ошибка является блокировщиком, добавьте задачу (к текущему спринту), чтобы зафиксировать работу, необходимую для ее исправления, и начните работать над ней. Это требует, чтобы что-то еще было перемещено (из текущего спринта) в очередь, чтобы учесть новые часы, потому что общее количество доступных часов не изменилось.

Первый шаг - определить, что такое ошибка. Я учу, что ошибка является ошибкой только в том случае, если эта функция не работает в производственной среде, как это было задумано / разработано. Они становятся PBI типа ошибок, которые должны иметь приоритет перед новыми разработками. Отсутствие функциональных возможностей в производственной среде является функцией и становится обычным элементом невыполненной работы продукта. Любой дефектный код, обнаруженный во время спринта, считается неполной работой, и, поскольку вы не переходите к следующей истории, пока текущая не будет завершена; нет необходимости отслеживать эти дефекты в спринте, поскольку команда всегда работает над ошибочным кодом. Наклейки могут быть очень удобными для быстрых напоминаний между товарищами по команде. Исправление неработающего кода всегда имеет приоритет перед написанием нового кода.

Инвентарь - это отходы. Отслеживание ошибок - это инвентарь. Отслеживание ошибок - пустая трата времени.

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

Если у вас гораздо больше ошибок, чем функций, вам нужно поработать над своими инженерными методами. Это запах того, что что-то еще не так, и отслеживание не является ответом. Копать глубже. На самом деле жуки всегда вонючие. Они не крутые, и если у вас их много, вам нужно найти первопричины, устранить их и перестать сосредотачиваться на отслеживании ошибок.

Не отслеживайте дефекты в списке, найдите их и исправьте - Мэри Поппендик

Действительно, если инвентарь - это отходы, как насчет инвентаря дефектов ...

Вот почему я всегда стараюсь реализовать менталитет « останови линию» с разработкой на основе тестирования и непрерывной интеграцией, чтобы мы находили и исправляли большинство дефектов, а не вносили их в список доработок.

А когда дефекты обнаруживаются, мы их исправляем перед написанием нового кода (истории с ошибками все равно не делаются). Затем мы пытаемся исправить наш процесс, чтобы сделать его более защищенным от ошибок и выявлять дефекты в момент их появления.

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

Если это не критично для работы системы, я предпочитаю, чтобы ошибки превратились в карточки рассказов. Это делает очевидным приоритет разработки функций и исправления ошибок. В сценарии, когда исправление ошибок считается «вне спринта», исправление ошибок может перейти к исправлению действительно тривиальных ошибок, в то время как действительно важные бизнес-функции не разрабатываются.

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

В нашем случае (разработка с нуля, 2-3 разработчика) обнаруженные ошибки записываются, четко помечаются как ошибка и в зависимости от их серьезности назначаются на следующую итерацию или оставляются в невыполненном журнале. В случае критических и срочных ошибок они добавляются к текущей итерации.

Я не знаю, почему такая простая вещь, как исправление ошибок, усложняется правилами ... В Scrum очень мало правил, помните? Каждая функция, поддержка, рекомендация или дефект - это проблема невыполненной работы в Scrum, нет никаких различий. Итак, как сказано в руководстве по Scrum: задачи в Sprint никогда не ограничиваются тем, что вы решаете во время собрания по планированию, Daily Scrum помогает людям обсуждать «препятствия» на их пути.

Зачем?

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

Лучший вопрос: как мне перестать создавать ошибки на этапе разработки? см. -> http://bit.ly/UoTa4n

Если вы выявляете и документируете ошибки, вам нужно будет отсортировать и исправить их в будущем. Это приводит к «стабилизационным спринтам», то есть к одному целому спринту только для исправления ошибок. Или вы можете добавить их обратно в очередь и расставить приоритеты как часть будущего спринта. Это также означает, что вы предоставляете и ожидаете подписания и выпуска программного обеспечения с известными ошибками (P3 и P4, также известными как косметические и незначительные).

Это не очень гибко?

Я внес в наш проект идею внедрять короткий спринт с исправлением ошибок каждый третий спринт. Наши текущие спринты - три недели.

Идея заключается в том, что это позволит всем разработчикам сосредоточиться на исправлении ошибок вместе, позволит сосредоточиться только на новых историях в регулярных спринтах и ​​будет постоянно уделять внимание сокращению технического долга.

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

Кто-нибудь пробовал это или есть отзывы о том, как, по их мнению, это может работать?

Ура, Кевин.