Как было сказано много раз ранее ( 1 , 2 , 3 ):
«Не оценивайте баги/дефекты».
Я знаю, что в Scrum мы пытаемся свести к минимуму количество дефектов, но время от времени это случается. Исправление таких неоцененных задач может иметь большое влияние на фактическую скорость команды. Интересно, есть ли какая-то процедура или формула, чтобы сделать это видимым для команды и других?
Или просто увеличение количества дефектов (= падение скорости) является признаком того, что мы должны уделять больше внимания нашему контролю качества?
Поскольку мы не оцениваем ошибки, этот вопрос не является дубликатом этого вопроса: отслеживание баллов, потраченных на ошибки во время спринта .
Если вы оцениваете давно работающий проект со скоростью, чтобы получить представление о том, когда будут достигнуты функции или вехи, лучше не оценивать дефекты. Дефекты — это работа, которая должна была быть завершена в других точках уже в прошлом. Если у вас сейчас много дефектов, вероятно, столько же будет и в будущем, что замедлит весь ваш проект. Это даст ложное ощущение скорости, если вы дадите баллы за бесценную работу. Скорость падает, когда у вас есть дефекты или технический долг .
Увеличение количества дефектов или снижение скорости всегда должно приводить к хорошему анализу первопричин во время ретроспективы, чтобы найти способы предотвратить подобные ошибки или улучшить процесс. Если причина действительно в вашем процессе обеспечения качества, вам нужно выяснить это, так как это сильно зависит от ситуации.
Некоторые метрики, которые я люблю использовать, чтобы сигнализировать о проблемах:
Они должны быть довольно стабильными или снижаться/увеличиваться, в зависимости от метрики.
Теперь, исходя из опыта, основная причина большинства дефектов чаще всего заключается не в отсутствии процесса обеспечения качества, а в архитектуре или дизайне, которые имеют множество связанных зависимостей, что затрудняет поддержку и расширение кодовой базы. Часто для него сложно создать тест-автоматизацию и, соответственно, сложно его рефакторить и почистить. Я всегда советую посмотреть первый эпизод « Чистого кода» , чтобы получить представление о распространенных проблемах с кодом.
ппаслер