Здравствуйте, Михаил Смирнов , Вы писали:

МС>Статья:
МС>Управление ошибками на практике

Автор(ы): Михаил Смирнов
Дата: 06.12.2006
В этой статье я расскажу о своем опыте внедрения формализованного процесса управления ошибками.
Основная задача статьи – показать важность организации такого процесса и дать начинающим руководителям разработки набор рекомендаций по его построению.

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

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

-3- Невозможно системно подойти к иправлению дефектов и анализу причин их появления, что может приводить "лечению симптоматики" или "прикручиванию костылей"

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

-5- Невозможно прогнозировать уровень качества реализации опираясь на количественные метрики, такие как Defects/KSLOC

-6- Невозможно оцень эффективность выполнения процесса тестирования

-7- Наверное, можно и дальше продолжить...



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