Когда багов создается больше чем решается…

Иногда мне присылают вопросы, достойные ответа в виде статьи. Или хотя бы виньетки или драбла.

– Самое интересное … когда багов создается больше чем решается … что в этом случае советуешь делать? Палкой бить?

Зачем же сразу палкой? Да еще разработчиков. Данная ситуация полностью в компетенции менеджмента. Либо ручного контроля, либо контроля со стороны его величества Регламента.

Можно выделить несколько ситуаций, в которых кто-то находит дефект:
1. На продакшене.
2. Во время проекта разработки нового софта.
3. В процессе сопровождения существующего софта. Софт уже эксплуатируется, и выпускаются новые релизы. При подготовке нового релиза тестировщик находит дефект.

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

Дефекты делятся на:
1. Не правим вообще и живем с ним долго и счастливо. Как с JRA-1330 жили дюжину лет.
2. Правим в рамках отладки фичи. Фичи с этими незакрытыми дефектами не выпускаются.
3. Дефект будет правиться, но не прям сейчас. Выпустим, а потом будет время подчищать долги, вот и поправим.

В Jira это легко организуется следующим образом. Фичи – это задача, иногда эпик с задачами. Дефекты создаются как подзадачи. Можно повесить скрипт, который не даст закрыть фичу, если есть незакрытые дефекты-подзадачи. Решили перевести из второй категории в третью – измените тип. С дефекта-подзадачи на дефект-задачу. Все, дефект не привязан к фиче, релиз выпускаем.
А теперь главное правило работы с дефектами: «Если вы решили править дефект, то время от внесения дефекта в код до исправления должно быть минимально.»
Идеальный вариант – программист получает реестр ошибок через 5 минут после коммита в фиче-бранч. Именно для этого нужны автоматизированные тесты. И начинать автоматизацию с регрессионного тестирования – занятие так себе. Не, если паровоз прицепить позади состава, то двигаться вперед можно. Но плохо-плохо.

Если вы решили править дефект, то время от внесения дефекта в код до исправления должно быть минимально. Пока весь код в памяти. Пока не нужно выгружать из оперативки мозга другую задачу и загружать эту. Кроме того, дальнейшее развитие кода делает внесение любых изменений сложнее. Дороже. В том числе и исправление ошибок. Не, у вас конечно код идеально изолирован и это не про вас. Это про другие, обычные проекты, которые пилят не такие хорошие программисты, как вы, мои читатели.

Второе главное правило работы с дефектами: «Исправление дефекта, который решили править, приоритетней, чем запиливание новой фичи.» Повесьте это правило в кабинете программистов. И в кабинетах заказчиков тоже.

Перейдем к анализу. Перед вами малоизвестная, крайне редко применяемая и крайне полезная диаграмма для анализа потока создания ценности VSM.

W – работа.
M – muda. Потери. Простои в очередях.
W1 – программирование фичи. Точнее внесение дефекта в код.
W2 – нахождение дефекта.
W3 – определение категории: правим немедленно, правим потом, не правим.
W4 – Исправление дефекта.

Как уменьшить время исправления? Довольно простое решение – убрать W3 из производственного потока. Неприятно, да? «Чтобы улучшить производственный поток, нужно устранить из него менеджера и заменить его регламентом». Такова суровая правда науки управления. «Sad but true.»

Далее. После запиливания фичи, тестировщики должны приступать к работе немедленно. Сокращаем m1 до нуля. Для этого тестировщики должны иметь запас по мощности (должны простаивать) 20-25%. «Sad but true.» Или вы занимаетесь субоптимизацией, или вы беспокоитесь об эффективности производственного потока. Если прибыль фирмы важнее чем таймшиты по 40 часов в неделю, то к черту таймшиты!

И наконец. «Исправление дефекта, который решили править, приоритетней, чем запиливание новой фичи.» Получив реестр дефектов, программист должен немедленно или почти немедленно начать их править. Нетленка подождет.

Может показаться, что я не ответил на начальный вопрос. Нет, ответил. Дефект проживший более [года | полугода | квартала] должен автоматически попадать в первую категорию. И закрываться скриптом.

Вот собственно и все. Don’t worry be happy.

PS. Первая публикация в facebook. Там же и обсудить можно.

Источник