Багтрэкинг, работа с ним или без него
Из ленты: 255 ступеней
Не исключительно мое мнение:
“Основное назначение трекера — дать возможность руководителю работ управлять реестром работ по проекту. Реестр задач на исправление багов, подмножество реестра работ по проекту.”
Рекомендуемая последовательность:
- Внедряем процесс ведения реестра.
- Внедряем процесс управления реестром.
- Внедряем процессы создания развернутых описаний элементов реестра.
Обычно пытаются внедрять процессы в обратном порядке. С известным заранее результатом. Еще одним удивительным феноменом является иногда встречающееся нежелание руководителей заниматься управлением. Поэтому шаг “2″ иногда внедряется со скрипом. Лесть, уговоры, убеждение — все должно идти в ход. Потому что если нет управления реестром, то нет управления в целом. И неважно, что это — проект по созданию системы или процесс сопровождения. Да, модели управления отличаются, но управление должно быть.
“Если руководитель на регулярной основе не занимается управлением реестра, то с управлением проблемы”. И, очень вероятно, бактрекер не нужен. Если вы не собираетесь делать шаг “2″, то зачем вам шаг “1″!?
Кстати. “Внедрение процесса управления реестром” дает огромный эффект. Вполне может получиться, проект по разработке системы удастся сделать в 1.5 — 2 (это не только моя оценка) раза быстрее.