Комментарии 9
Очень интересно читать подобные успешные(или не всегда) истории, приятно видеть, что иногда бизнесу реально донести важность таких активностей.
Отдельный респект за кукушку, у нас было что-то похожее, но делалось не слишком осознанно и централизованно.
Поделюсь и своей историей ZBP с предыдущего проекта -
Начальство начальства пришло с идеей уменьшения кол-ва багов и дало добро на уменьшение скорости разработки новых фич (ситуация из ряда фантастики, конечно, но речь про внутренние сервисы и про большое кол-во претензий к ним)
После анализа всех очередей в трекере нашли порядка 1200 багов, каждый был воспроизведён\закрыт и прошёл обсуждение с менеджерами относительно баг/не баг и приоритета. На всё про всё ушло примерно 4 недели и на выходе получилось порядка 900 багов.
Каждый месяц была примерная цель уменьшать общее кол-во багов на 10% (включая новые), которую мы успешно профакапили, но примерно за 6 месяцев сократили кол-во в половину.
Важную часть сыграл не только фикс багов, но и разбор всех новых проблем по пятницам, где мы нашли в процессах дыры (например, сделали адекватный код фриз за сутки до релиза)
Чем закончилась история, к сожалению, не знаю, т.к. самовыпнулся на мороз :)
Как по мне - лучше нормализовать и улучшить процессы(затащить на проект код ревью, юнит тесты, автотесты) тем самым предупреждая появление новых багов на проде, нежели фиксить P3 и P4, которые в один прекрасный момент просто уйдут с редизайном.
Как по мне - лучше нормализовать и улучшить процессы (затащить на проект код ревью, юнит тесты, автотесты)
Абсолютно верно, если нет авто-тестов, CI/CD, ревью кода - то баги можно чинить бесконечно - они будут постоянно появляться вновь.
На мой взгляд, каждую задачу с багой, помимо самой ошибки, нужно завершать примечанием, что нужно сделать, чтобы подобная ошибка больше не позникала.
Раз в месяц такие примечания агрегировать, собираться командой и думать, как улучшить процессы разработки.
Круто, особенно понравился метод Кукушки)
Еще можно классическую штуку - рост приоритета со временем. То есть каждый например месяц или там каждые 5 спринтов приоритет бага поднимается. И глядишь через полгода он либо станет критикалом и пофиксится либо закроется как неактуальный.
Для визуализации можно тянуть данные через Jira API и обрабатывать их в условном QlikView, это связка неплохо себя показала, когда нам нужно было отслеживать эффективность линии поддержки по нескольким срезам.
Надоели продукты и услуги, заполонившие всё вокруг, выполненные в стиле «сойдет и так».
Шестой подвиг Геракла: как мы расчистили прод от багов