Разумно ли создавать истории для дефектов при использовании Scrum, а история еще не создана?
Допустим, вы работаете над унаследованным кодом, который был написан до того, как ваша компания начала использовать методологию Agile, такую как Scrum.
Теперь предположим, что вы обнаружили ошибку в поле, которую нужно исправить, и никогда не было написано истории для этой функции. Каждый в команде знает, что это за особенность и как она должна себя вести, но просто никакой истории, связанной с ней.
Теперь в текущем спринте вы должны работать над этим дефектом, потому что отдел маркетинга и поддержки устали от решения этой проблемы.
Вы создаете историю в ретроспективе для того, чтобы этот дефект был связан с? Вы помечаете свой дефект как историю и изменяете форматирование так, чтобы оно выглядело как история? Если вы не создаете историю, получаете ли вы очки за дефект? Если вы создаете историю, получаете ли вы очки за исправление дефекта (через очки истории)?
Какой лучший способ справиться с этой ситуацией?
Обновление: допустим, внезапно начался процесс установки, чтобы синий экран системы на 64-битной Windows 7 был установлен, и всегда существовало требование, чтобы приложение устанавливалось на всех платформах Windows. Возможно, новая проблема возникла из-за пакета обновления 1 или чего-то подобного.
5 ответов
Вы создаете историю в ретроспективе для того, чтобы этот дефект был связан с?
Да. Это также заслуживает рассмотрения, чтобы убедиться, что все согласны с этой историей.
Если это безошибочный, но надоедливый интерфейс, то вы действительно модифицируете рабочий процесс, и его нужно запомнить как правильную историю.
Если есть ошибка, то есть модульные тесты, которые должны были найти ошибку (но не сделали). Это не похоже на вашу ситуацию, но часто неполные юнит-тесты не находят ошибку. Продление юнит-тестов (после исправления истории) также очень важно.
Вы помечаете свой дефект как историю и изменяете форматирование так, чтобы оно выглядело как история?
На самом деле, нет. Дефект - это просто дефект, независимо от того, есть история или нет.
Дефекты уходят. Истории нет.
Если вы создаете историю, получаете ли вы очки за исправление дефекта (через очки истории)?
Почему бы и нет?
Редактировать Сюжетная проблема сложна. В идеале, точки отслеживают проделанную работу и созданную ценность. История == усилия == баллы. Но проблемы возникают при обработке повторного использования, выпуска и переделки.
У вас есть несколько не связанных вопросов: усилия, качество и ценность. Точки могут отслеживать один из них. Это не может отследить ни одного из других.
Если вы думаете, что скорость должна отражать усилие, то вы не можете забрать очки из-за ошибок или изменений требований. Он не отслеживает созданное значение и не может быть использован для этого.
Если вы думаете, что скорость должна отслеживать значение, то вы должны убрать очки. Это не отслеживает усилие, потому что работа была сделана, но кредит на это был удален.
Переработка сложная. Ошибки и изменения требований - это то же самое, они переделаны. У вас есть целый спектр кандидатов.
"Простые" ошибки, где реализация неверна, но история "правильна". В идеале это не относится к скорости. Правильно?
Ошибки "Incomplete Story", где реализация верна, но в истории пропущены некоторые важные (и технические) детали. Хм. Кто виноват? Кто за измерение скорости должен быть оштрафован за это?
Что мы измеряем? Усилию? Работа была выполнена. Значение? Значение не было создано.
Ошибки "Неправильная история", где реализация верна, но история была плохой идеей с самого начала, и никто ее не уловил. Это можно назвать "сценарием лжи". Такое случается. В идеале это имеет значение для скорости. Пользователи лгали. Но как вы можете отличить это от любой другой переделки? Что за "правило"?
"Измененная история" ошибки, где реализация правильная, а история была правильной. Но общий контекст изменился, и история должна измениться. Это просто "улучшение" или "адаптация" и похоже на новую работу. За исключением, конечно, это не работа полного усилия, не так ли? Это может быть просто подстройка к существующему коду, так что вы не хотите переоценивать это созданным полным значением.
Что мы измеряем? Усилию? Некоторое было сделано, но не очень. Значение? Значение было создано.
Итог. Очки являются политическим оружием и мало измеряют. Либо усилие или ценность, но не оба. И не хорошо.
В Scrum есть только пользовательские истории. Недостатком, как и функцией, является запрос владельца продукта о внесении некоторых изменений в систему, чтобы повысить ценность бизнеса.
Если о дефекте сообщают после выпуска, это должно войти в отставание как новая история. Это прекрасно, чтобы отслеживать некоторые заметки о деталях дефекта (кто сообщил об этом, окружение и т. Д.). Как история, она должна быть оценена командой до отбора для спринта в ПО.
Если во время спринта сообщается о дефекте, а ПО (и команда) принимает решение о том, что он является низкоуровневым и не приводит к провалу истории, этот дефект возвращается в отставание как новая история для дальнейшего рассмотрения.
В моих командах мы часто обнаруживаем, что пользовательские истории на основе дефектов имеют размер 0,5-1 балла - не всегда, но достаточно часто. Мы обнаружили, что выбор сюжета из 0,5-1 баллов может внести некоторый шум в скорость в спринте, поскольку каждая предполагаемая история строится с некоторой ошибкой оценки. Мы сгруппируем несколько историй, если они очень маленькие, и создадим оценку кластера историй. Мы обнаружили, что иногда из-за совпадения различных исправлений оценка отличается - (5) 1-балльные истории могут в общей сложности составить 3 балла для кластера.
TLDR:
История нужна для того, чтобы зафиксировать требование (как и любое требование) с дефектом, который вы хотите исправить. История нужна для написания теста, чтобы вы знали, когда дефект был исправлен.
Длинная версия:
У вас есть дефект.
Как вы узнаете, какая часть функциональности неисправна?
Дефектная функциональность должна быть задокументирована как требование или иметь какую-то спецификацию; будь то на бумаге, в электронной почте или кому-то в голову.
Так что ИМХО имеет смысл запечатлеть это как историю.
Зачем?
Поскольку вам нужна история, все, что вы делаете, должно быть против истории. Как вы узнаете, когда исправите этот дефект?
Единственный способ узнать это с помощью какого-то теста. Как вы узнаете, когда тест пройден?
Дефект скажет, что вы дадите вам критерий провала теста, но не скажет, когда он должен пройти. Примечание: если у вас есть описание того, что должно произойти в отчете об ошибке, то эта информация может быть записана как [часть] истории и зафиксирована как критерии прохождения теста.
Таким образом, чтобы знать, прошел ли ваш тест, чтобы знать, что часть функциональности больше не является дефектной, нужно иметь требование о том, как этот тест будет пройден, вы должны воспринимать это требование как историю, как и все другие ваши требования.
Есть больше способов сделать это. Я обычно создаю оригинальную историю и ошибку. Я даю исходные 0 баллов за историю, потому что на ней не осталось работы, а оставшаяся работа всегда должна быть в центре внимания баллов, а не "командных баллов".
ИМХО ты не "набираешь" сюжетные очки. Что вы делаете, это есть их во время спринта. Если вы хороший мальчик и съели все это, у вас может быть десерт (больше предметов отставания). Если нет, то вы едите остатки в следующем спринте:-)
Обновление: вы также можете написать только дефект, так как вы действительно не реализовали оригинальную историю в спринте (или в текущем проекте в этом отношении)
Я хотел бы предложить, чтобы все было просто. Я не вижу реальной, ценной разницы между историей и исправлением дефекта. Они оба меняют систему; оба, если они принесут некоторую ценность пользователю из клиента после завершения; у обоих есть стоимость; оба они более важны, чем некоторые истории (и недостатки), и менее важны, чем другие.
Так что, если он ходит, как утка, и крякает, как утка... Я назову это историей пользователя.
Рассматривайте это как любую историю (вы могли бы написать ее как "чтобы иметь возможность сохранить мои высокие результаты, как пользователь Fire Fox, я хочу, чтобы JIRA 234 была исправлена").
Таким образом, ПО может решить, когда бороться с ошибкой, как и любая другая задача.
Надеюсь, это поможет, Ассаф.