Должны ли ошибки рассматриваться как истории или как задачи?

Я использую модифицированную версию Scrum со своими командами в недельных спринтах. Бэклог продукта упорядочен сверху вниз в порядке важности. Команда разработчиков берет элементы с вершины стека и работает над ними.

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

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

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

Я рекомендую командам, которые я тренирую, разделить ошибки на два вида:

• Ошибки/дефекты, возникшие из-за сбоя в ТЕКУЩЕЙ работе (например, история из текущего спринта) — для тех, кого я рекомендую отслеживать как задачи по этой истории и как блокираторы того, чтобы эта история была ВЫПОЛНЕНА/принята.

• Ошибки/дефекты, которые обнаружены, но считаются существующими в течение некоторого времени, возможно, даже уже присутствующими в рабочей среде — рассматривайте их как элементы незавершенной работы, которым необходимо расставить приоритеты. Обычно это решение/политика управления продуктом/владельцем. Конечным результатом МОЖЕТ быть то, что вы исправите их прямо сейчас, но это зависит от приоритета.

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

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

Если ошибка есть в бэклоге продукта, то ее исправление имеет смысл, иначе ее не должно быть в бэклоге. Баг также следует оценить, иначе у вас возникнут трудности с планированием работы и измерением.

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

Для меня это зависит от размера, серьезности и времени обнаружения.

Если она обнаруживается во время тестирования запланированной функции, она возвращается в разработку для повторной работы и обсуждения в схватке.

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

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

Не зацикливайтесь на терминологии — просто убедитесь, что их можно отследить, исправить и учесть.

В чем разница между рассказом и задачей? Или рассказ и эпос? Или баг и история?

По-моему, все работает.

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

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

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

Если вы дадите им очки истории:

• Да : означает, что к ним относятся так же, как к историям, и они помогают повысить точность вашего процесса планирования. Однако это также подразумевает, что они добавляют ценность для бизнеса и являются частью показателя скорости вашей команды, чего им не следует делать.

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

Ошибка сама по себе является ошибкой и должна рассматриваться как задача. Разницы не вижу, можно спринтить с задачами по исправлению ошибок.

Для меня ошибка в реализации обычно является задачей.

Что касается багов в дизайне/архитектуре, то их обычно не так просто исправить, и они обычно заканчиваются историей.

Что-то, что придает большую ценность, — это характеристика или история. Ошибка — это что-то неправильное в завершенной функции/истории.

Чтобы взять пример с Нотча, создателя MineCraft:

У меня есть несколько планов и видений, но мое единственно верное дизайнерское решение — сделать его интересным и доступным. Документа по дизайну нет, но есть два списка; один для ошибок и один для функций, которые я хочу добавить, но думаю, что могу забыть.[ 1 ]

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

С нашей командой мы относимся к ним как к гибридному элементу. При использовании Scrum истории всегда получают баллы, а задачи — никогда. Ошибки не получают значение в баллах, назначенное командой. ОДНАКО, когда мы собираемся зафиксировать наши невыполненные работы в Sprint, нам нужен способ оценки ошибок, верно? В целях планирования и скорости мы оцениваем каждую отдельную ошибку по 2 баллам — хотя некоторые из них намного больше, а некоторые намного меньше, мы обнаружили, что это хорошо работает для целей оценки.

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

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

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

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

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

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