Я изучал и читал о Scrum в последние несколько дней, а также читал о планировании спринтов и задачах. Одна проблема, которая пришла мне в голову, - это как бороться с ошибками в Scrum. Хенрик Книберг перечисляет некоторые способы решения этой проблемы в своей очень хорошей книге Scrum and XP from the Trenches :
- Владелец продукта распечатывает наиболее важные элементы Jira, приносит их на собрание по планированию спринта и развешивает на стене вместе с другими историями (тем самым неявно указывая приоритет этих элементов по сравнению с другими историями).
- Владелец продукта создает истории, относящиеся к элементам Jira. Например, «Исправьте наиболее важные ошибки отчетов бэк-офиса, Jira-124, Jira-126 и Jira-180».
- Считается, что исправление ошибок выходит за рамки спринта, т. Е. Команда поддерживает достаточно низкий коэффициент фокусировки (например, 50%), чтобы у них было время для исправления ошибок. Тогда просто предполагается, что команда будет тратить определенное количество времени на каждый спринт, исправляя ошибки, о которых сообщает Jira.
- Поместите отставание продукта в Jira (то есть откажитесь от Excel). Относитесь к ошибкам как к любой другой истории.
Это действительно то, что нужно решать для каждого проекта или есть лучшие решения? Я могу думать о проблемах с каждым из этих подходов. Есть ли гибрид из этих подходов, который работает лучше всего? Как вы справляетесь с этим в своих проектах?
Ответы:
Это очень хороший вопрос, и у меня есть некоторые наблюдения, когда речь идет о различных подходах к этой проблеме.
Решение, которое мы нашли наиболее удовлетворительным, заключалось в том, чтобы помещать одну пользовательскую историю под названием «Тикеты» или «Ошибки» на каждый спринт. Затем такую историю можно разделить либо на низкоуровневые задачи, описывающие конкретную ошибку (если они известны во время планирования), либо на мета-задачи, резервирующие определенное количество часов для общего исправления ошибок. Таким образом, владелец продукта видит процесс, а диаграмма выгорания отражает его прогресс.
Просто не забудьте безжалостно закрывать все «ошибки», которые на самом деле являются новыми функциями, и создавать для них новые элементы журнала. Также убедитесь, что вы исправили все ошибки, о которых сообщалось в текущем спринте, до его завершения, чтобы считать спринт завершенным.
источник
На самом деле, я думаю, что лучше всего будет ответить jpeacock на этот вопрос. Считаете ли вы часы, потраченные на исправление ошибок, до схватки?
Приведу цитату:
источник
Первый шаг - определить, что такое ошибка. Я учу, что ошибка является ошибкой только в том случае, если эта функция не работает в производственной среде, как это было задумано / разработано. Они становятся PBI типа ошибок, которые должны иметь приоритет перед новыми разработками. Отсутствие функциональных возможностей в производственной среде является функцией и становится обычным элементом невыполненной работы продукта. Любой дефектный код, обнаруженный во время спринта, считается неполной работой, и, поскольку вы не переходите к следующей истории, пока текущая не будет завершена; нет необходимости отслеживать эти дефекты в спринте, поскольку команда всегда работает над ошибочным кодом. Наклейки могут быть очень удобными для быстрых напоминаний между товарищами по команде. Исправление неработающего кода всегда имеет приоритет перед написанием нового кода.
Инвентарь - это отходы. Отслеживание ошибок - это инвентарь. Отслеживание ошибок - пустая трата времени.
Если у вас гораздо больше ошибок, чем функций, вам нужно поработать над своими инженерными методами. Это запах того, что что-то еще не так, и отслеживание не является ответом. Копать глубже. На самом деле жуки всегда вонючие. Они не крутые, и если у вас их много, вам нужно найти первопричины, устранить их и перестать сосредотачиваться на отслеживании ошибок.
источник
Действительно, если инвентарь - это отходы, как насчет инвентаря дефектов ...
Вот почему я всегда стараюсь реализовать менталитет « останови линию» с разработкой на основе тестирования и непрерывной интеграцией, чтобы мы находили и исправляли большинство дефектов, а не вносили их в список доработок.
А когда дефекты обнаруживаются, мы их исправляем перед написанием нового кода (истории с ошибками все равно не делаются). Затем мы пытаемся исправить наш процесс, чтобы сделать его более защищенным от ошибок и выявлять дефекты в момент их появления.
источник
Не существует единого решения, подходящего для всех, и каждый проект индивидуален. Ошибки также можно разделить на категории от критически важных до вряд ли стоит исправлять.
Если это не критично для работы системы, я предпочитаю, чтобы ошибки превратились в карточки рассказов. Это делает очевидным приоритет разработки функций и исправления ошибок. В сценарии, когда исправление ошибок считается «вне спринта», исправление ошибок может перейти к исправлению действительно тривиальных ошибок, в то время как действительно важные бизнес-функции не разрабатываются.
Мы прошли через ряд изменений, прежде чем использовать ошибку как сюжетный подход. Попробуйте разные вещи и воспроизведите их на ретро-встречах команд.
источник
В нашем случае (разработка с нуля, 2-3 разработчика) обнаруженные ошибки записываются, четко помечаются как ошибка и в зависимости от их серьезности назначаются на следующую итерацию или оставляются в невыполненном журнале. В случае критических и срочных ошибок они добавляются к текущей итерации.
источник
Я не знаю, почему такая простая вещь, как исправление ошибок, усложняется правилами ... В Scrum очень мало правил, помните? Каждая функция, поддержка, рекомендация или дефект - это проблема невыполненной работы в Scrum, нет никаких различий. Итак, как сказано в руководстве по Scrum: задачи в Sprint никогда не ограничиваются тем, что вы решаете во время собрания по планированию, Daily Scrum помогает людям обсуждать «препятствия» на их пути.
Зачем?
Итак, вы обсуждаете и рационально думаете как команда, хотите ли вы, чтобы дефект, то есть проблема невыполненной работы, перешел в PBI или остался в этом спринте и доставил его ...
источник
Лучший вопрос: как мне перестать создавать ошибки на этапе разработки? см. -> http://bit.ly/UoTa4n
Если вы выявляете и документируете ошибки, вам нужно будет отсортировать и исправить их в будущем. Это приводит к «стабилизационным спринтам», то есть к одному целому спринту только для исправления ошибок. Или вы можете добавить их обратно в очередь и расставить приоритеты как часть будущего спринта. Это также означает, что вы предоставляете и ожидаете подписания и выпуска программного обеспечения с известными ошибками (P3 и P4, также известными как косметические и незначительные).
Это не очень гибко?
источник
Я внес в наш проект идею внедрять короткий спринт с исправлением ошибок каждый третий спринт. Наши текущие спринты - три недели.
Идея заключается в том, что это позволит всем разработчикам сосредоточиться на исправлении ошибок вместе, позволит сосредоточиться только на новых историях в регулярных спринтах и будет постоянно уделять внимание сокращению технического долга.
Исправления ошибок будут сгруппированы в соответствующие истории и распределены по приоритетам. Упор делается не на определение размера перед спринтом, поскольку разработчики изо всех сил стараются определить размер исправлений ошибок, не пытаясь понять природу дефекта.
Кто-нибудь пробовал это или есть отзывы о том, как, по их мнению, это может работать?
Ура, Кевин.
источник