Основные моменты для задач по исправлению ошибок: Подходит ли это для Scrum?

Мне просто интересно, должны ли мы присваивать исторические баллы задачам по исправлению ошибок или нет. JIRA, наши проблемы отслеживания программного обеспечения, не имеет поле точки история для Bug вопросов типа (это только история с и Эпическая s).

Должны ли мы добавить тип проблемы Ошибка к применимым типам проблемы поля Story Points ? Каковы плюсы и минусы? Будет ли это подходящим для Scrum?

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

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

С точки зрения бизнеса, исправления и функции также действительно одинаковы: либо вы делаете это (сценарий B), либо нет (сценарий A); к обоим сценариям привязаны затраты и выгоды, и порядочный бизнесмен просто взвесит их и сделает все, что принесет им больше прибыли (в долгосрочной или краткосрочной перспективе, в зависимости от стратегии бизнеса).

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

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

Вы не должны давать очки за исправление ошибки. Примите во внимание тот факт, что ошибка возникает из истории, где разработчики уже заработали очки для завершения истории. Он не должен снова получать баллы там, где он на самом деле не должен был заработать очки для начала.

Исправление ошибки должно отрицательно влиять на скорость. В противном случае падение качества в конечном итоге будет вознаграждено с неизменной или даже повышенной скоростью!

Возможно, полезная ссылка:

http://www.infoq.com/news/2011/01/story-points-to-bugs

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

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

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

Я бы рекомендовал рассматривать ошибку как пользовательскую историю и присваивать ей несколько баллов. Я не обязательно записывал бы это в формате «Как X, я хочу Y, чтобы Z», как это часто бывает в пользовательских историях - я бы написал это больше как «Как X, когда IY, Z происходит, но Z '- ожидаемое поведение ".

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

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

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

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

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

В нашей команде мы экспериментировали с некоторыми методами оценки ошибок:

1. Оценка совершенно неизвестных ошибок
2. Только оценки ошибок, которые уже были проанализированы
3. Выделение времени для исправления ошибок, а не для оценки ошибок, но вместо этого ранжируйте их исключительно исходя из ценности бизнеса

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

Основанный на методе 2 оценки отношения 90/10 (анализ к исправлению ошибок) действительно означал, что мы должны были планировать анализ, который не охватывался планированием спринта (мы узнали из варианта 1, но не имели реального решения) как продолжить с проанализированными ошибками). В результате анализ ошибок не был выполнен, поскольку спринт был сосредоточен на запланированных элементах. Команда не успела сосредоточиться на ошибках из отставания. Так что в конце концов они тоже не сделали.

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

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

Так что это зависит от того, подходят ли вам исторические моменты. Сначала я бы попытался оценить ошибки, используя баллы истории. Если это не сработает, попробуйте мой вариант 3. Это заставило нашу (более 30 спринтскую) команду снова сосредоточиться на старых ошибках, которые имеют большую ценность для бизнеса. Это также освободило нас от попыток доставить то, что команда просто не может оценить. Это охватывало неизвестное, что приблизило нас к реальности, а также сделало наши спринты снова успешными , предоставляя большую часть (основанную на соотношении количества ошибок к истории) деловой ценности за счет исправления ошибок. Соотношение, которое мы использовали недавно, было 50/50.

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

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

Другими словами, зачем даже отслеживать ошибки? Так что в конце дня вы знаете, сколько «работы» проделал каждый участник? Прекрати это! Плохой менеджер! :) Измеряй команду, а не игрока. Поощрите команду управлять собой, если один человек не тянет их вес. Гораздо эффективнее. Выполнение сюжетных пунктов не должно улучшать самочувствие человека, но команда в целом должна чувствовать себя лучше, когда они делают свои обязательства в конце спринта. В спорте цель хороша для команды или человека? Если человек играет за себя, команда проигрывает в долгосрочной перспективе.

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

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

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

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

Создание бюджета может быть сделано несколькими способами для исправления ошибок. Вот некоторые идеи, которые я эффективно использовал:

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

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

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

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

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

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

Исправленные ошибки, какими бы важными они ни были, не приводят бизнес к новым областям и новым клиентам (косвенно и, возможно, в конечном итоге, да, но не сразу, что измеряет руководство).

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

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

Я использую Pivotal Tracker (у меня есть только JIRA, Trak, Trello и другие), а Pivotal Tracker также не зарабатывает баллы за рутинную работу или ошибки. Это сделано по тем же причинам, что и выше, которые делают это верным и в JIRA, как вы видите себя.