Вы считаете часы, потраченные на исправления ошибок в схватке?

Ответ 1

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

• Если ошибка легко или быстро исправлена ​​(один лайнер и т.д.), просто исправьте ее.
• Если ошибка не является тривиальной, а не блокирующей, то добавьте ее в отставание.
• Если ошибка является блокировщиком, добавьте задачу (к текущему спринту), чтобы зафиксировать работу, необходимую для ее исправления, и приступить к ее работе. Для этого требуется, чтобы что-то еще было перемещено (от текущего спринта) к отставанию для учета новых часов, потому что ваши общие часы не изменились.

Когда мы добавляем новые задачи с ошибками, мы будем отличать их от запланированных задач, чтобы их было легко увидеть во время обзора спринта. Иногда незапланированная работа заканчивается > 50% нашего спринта, но поскольку мы подталкиваем запланированные предметы к отставанию, мы очень рано знаем, что мы не доставляем этот спринт, который мы планировали.

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

Ответ 2

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

EDIT: Просто понял, что, упоминая "ошибка-backlog", я открываю для "множественных отставаний", что является плохим. Лучшим способом было бы отметить запись в отставании флагом ошибки или просто принять его как любую другую историю в отставании.

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

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

РЕДАКТИРОВАТЬ: Реализовать что-то еще - иногда работа в команде по схватке не всегда защитит вас от реальности необходимости поддерживать другие приложения, поддержку и т.д. Хотя это действительно отстой и делает всю идею о том, чтобы быть в команде с одно отставание и фокус действительно не работают, реальность часто заключается в том, что вам необходимо зарезервировать фиксированное количество часов в неделю для поддержки/поддержки. Не поощряйте это, но если это реальность, попробуйте и назначьте одного человека (при ротации (он) он не станет печальным) каждую неделю фиксированное количество часов, посвященных указанной роли поддержки. Таким образом, вы знаете, чего ожидать, поскольку скорость относительно - это будет как-то похоже на меньшее влияние на спринты.

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Не ставьте оценки на ошибки, вместо этого попробуйте добавить это время к оценкам для модульного/функционального тестирования против функций, над которыми вы работаете.

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