Толпа, как обработать ошибки в спринте и как к [закрытым] ошибкам временной оценки

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

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

Например, мы знаем, что можем выполнить 20 очков истории за неделю, исходя из предыдущих спринтов. Разработка этих 20 пунктов может быть завершена в течение 2 дней, однако затем проводится тестирование и исправление ошибок. Мы не оцениваем ошибки разработчиков, так как каждая новая история должна иметь оценку, которая приблизительно включает время исправления ошибок. Живые ошибки должны быть исследованы перед оценкой, тогда должна быть возможность точно оценить.

Как насчет их оценки на основе среднего времени, затраченного на исправление более ранних ошибок?

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

Оцените их в неделях, а не в часах.

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

«Трудно делать прогнозы, особенно в отношении будущего»

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

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

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

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

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

One approach that has worked for me is not to have bugs in the first place :)

The way this works is that when a bug is found, fixing it takes priority over story implementation. New features can only be added once the already existing functionality works 100%.

Of course we classify bugs. This stop-the-production-line approach is only applied to critical bugs. Less than critical bugs get treated as feature enhancement stories, estimated and planned in upcoming sprints as any other stories.

Time allocation for critical bug fixing eventually gets reflected in your team velocity.

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

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

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

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

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

вы также можете рассмотреть возможность выделения "контингента" для исправления ошибок во время спринта (10-20% времени коммиттера), чем использовать способ Kanban для их устранения. Это означает, что вы можете поговорить с Владельцем продукта и объяснить ему, что расходы на исправление ошибок находятся под контролем (поскольку контингент - это ваш таймбокс), который будет эмпирически корректироваться на каждой новой итерации, основываясь на том, что команда чувствует, что качество продукта будет таким, каким он будет. Целью, конечно же, является сокращение времени и содействие прозрачности. Владелец продукта может помочь в расстановке приоритетов для Блога ошибок, ставя на первое место наиболее ценные ошибки - обычно это значение "Сохранить" - так что, вероятно, самый высокий приоритет будет исправлен... чем выше, тем лучше.

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

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