Zero bug policy что это
Zero Bug Policy. Нет багов — нет проблем?
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Что же это такое?
Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:
«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».
При этом не надо впадать в крайности: вообще не заводить ошибки или править все подряд. Важно выработать для себя критерии качества для фич, которые вы готовы отдавать пользователям и считать задачу выполненной после исправления всех важных ошибок.
Преимущества политики
Звучит здорово, но ведь возможны и побочные эффекты.
А ещё всегда остается фактор страха.
«Вот мы закроем ошибку, а вдруг настанет светлое будущее, когда найдется время на исправление»?
Очень маловероятно, что у вас появится лишнее время. Это как хранение старого барахла на балконе: вы не теряете надежду что-то из этих вещей использовать, но, скорее всего, это не произойдет никогда.
Вот мы закроем ошибку, а пользователь увидит ее в проде.
Расстроенный пользователь напишет в саппорт, который в свою очередь сообщит вам. Надо будет пересмотреть приоритет этой ошибки и повторно принять решение, исправлять ее или нет.
Реализация
Самое сложное — начать. Для этого надо найти время, ресурсы, желание (нужное подчеркнуть), чтобы перелопатить весь бэклог древних ошибок и принять радикальное решение об исправлении или закрытии.
Затем собраться с силами и исправить «выжившие» после чистки ошибки.
И начать жить по новым правилам.
Начать делить баги на две категории:
Если вы находите баг при тестировании новой фичи, то надо сразу принять решение:
А если находится баг на проде/при регрешне, то надо принять решение, как поступить.
Для определения приоритета бага мы используем матрицу, которая объединяет в себе критичность бага в рамках конкретной команды и частоту возникновения.
Другие детали
Профит от использования такого подхода скорее всего будет незначительный, если вы дополнительно не станете менять процессы и подходы в разработке и тестировании.
Что позволит уменьшить количество багов при разработке новой фичи?
Метрики
Чтобы не делать выводы на своих ощущениях, мы следим за метриками по ZBP (я очень люблю Tableau и использую его для построения отчетов). Это позволяет отслеживать прогресс в динамике и подсвечивать возникающие проблемы.
Результаты
Какие же результаты работы по ZBP у нас?
Мы живем в реальном мире, и в чистом виде использовать политику не получилось.
Кто-то столкнулся с проблемой легаси и невозможностью в ограниченный срок исправлять некоторые баги. У кого-то был накопленный годами бэклог, к нему просто страшно было подступиться и они не торопились начинать этот процесс.
Но в целом многим командам удалось разобрать свои бэклоги и поставить определенную планку на количество открытых багов. Команды стали лучше оценивать баги и быстрее принимать решения о необходимости исправления.
Zero Bug Policy. Нет багов — нет проблем?
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Что же это такое?
Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:
«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».
При этом не надо впадать в крайности: вообще не заводить ошибки или править все подряд. Важно выработать для себя критерии качества для фич, которые вы готовы отдавать пользователям и считать задачу выполненной после исправления всех важных ошибок.
Преимущества политики
Звучит здорово, но ведь возможны и побочные эффекты.
А ещё всегда остается фактор страха.
«Вот мы закроем ошибку, а вдруг настанет светлое будущее, когда найдется время на исправление»?
Очень маловероятно, что у вас появится лишнее время. Это как хранение старого барахла на балконе: вы не теряете надежду что-то из этих вещей использовать, но, скорее всего, это не произойдет никогда.
Вот мы закроем ошибку, а пользователь увидит ее в проде.
Расстроенный пользователь напишет в саппорт, который в свою очередь сообщит вам. Надо будет пересмотреть приоритет этой ошибки и повторно принять решение, исправлять ее или нет.
Реализация
Самое сложное — начать. Для этого надо найти время, ресурсы, желание (нужное подчеркнуть), чтобы перелопатить весь бэклог древних ошибок и принять радикальное решение об исправлении или закрытии.
Затем собраться с силами и исправить «выжившие» после чистки ошибки.
И начать жить по новым правилам.
Начать делить баги на две категории:
Если вы находите баг при тестировании новой фичи, то надо сразу принять решение:
А если находится баг на проде/при регрешне, то надо принять решение, как поступить.
Для определения приоритета бага мы используем матрицу, которая объединяет в себе критичность бага в рамках конкретной команды и частоту возникновения.
Другие детали
Профит от использования такого подхода скорее всего будет незначительный, если вы дополнительно не станете менять процессы и подходы в разработке и тестировании.
Что позволит уменьшить количество багов при разработке новой фичи?
Метрики
Чтобы не делать выводы на своих ощущениях, мы следим за метриками по ZBP (я очень люблю Tableau и использую его для построения отчетов). Это позволяет отслеживать прогресс в динамике и подсвечивать возникающие проблемы.
Результаты
Какие же результаты работы по ZBP у нас?
Мы живем в реальном мире, и в чистом виде использовать политику не получилось.
Кто-то столкнулся с проблемой легаси и невозможностью в ограниченный срок исправлять некоторые баги. У кого-то был накопленный годами бэклог, к нему просто страшно было подступиться и они не торопились начинать этот процесс.
Но в целом многим командам удалось разобрать свои бэклоги и поставить определенную планку на количество открытых багов. Команды стали лучше оценивать баги и быстрее принимать решения о необходимости исправления.
# Работа с багами
# Описание
Это процесс наполнения, приоритизации и разбора багов. Процесс позволяет сделать работу с багами понятной и прозрачной для команды.
# Почему ветка важна?
Баги в системе – это неправильное поведение системы. Слишком большое число критичных багов приводит к сильной деградации системы и в конечном счёте отражается на продуктовых метриках.
Что процесс даёт для разных ролей. Для лида: Контроль за состоянием системы. По динамике наполнения и разбора багов можно делать выводы как о проблемах в продукте, так и о работе команды разработчиков.
Для продукта и пользователей:
# Что будет, если её не делать?
# На кого может быть делегирована?
На старших QA-специалистов в команде или компании. На Scrum-мастеров, продактов.
# Примеры поведения
# Примеры плохого поведения
# Примеры хорошего поведения
# Способы прокачки
# Практика
У любой системы работы с багами есть несколько составляющих:
Конфигурации могут быть разными и отличаться в зависимости от структуры команд. Например, в случае с матричной структурой компании, за систему сбора багов и наполнение отвечает отдел QA. Разбор может проходить за счёт периодического разбора багов силами разработчиков. Бывают интересные варианты с багодельней
, когда баги разбираются в формате хакатона с элементами геймификации.
# Zero Bug Policy
Основная критика многих стандартных подходов с наполнением и периодическим разбором багов в том, что он всё равно пухнет. Обычно так происходит из-за того, что создание новых фичей видится более перспективным для продактов, чем разбор старых багов. Просто выкидывать баги в силу специфики работы тестировщикам тоже не хочется. В итоге бэклог багов превращается в «антресоль», куда баги попадают, но из которой уже не достаются.
Идея Zero Bug Policy в том, что баги не хранить. Фактически предлагается баги раскладывать на две группы:
Опять же, это не означает, что мы снижаем планку качества. Мы признаем, что в нашем продукте есть сколько-то багов и это нормально.
Критика данного метода основывается на следующем:
Zero Bug Policy. Нет багов — нет проблем?
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Что же это такое?
Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:
«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».
При этом не надо впадать в крайности: вообще не заводить ошибки или править все подряд. Важно выработать для себя критерии качества для фич, которые вы готовы отдавать пользователям и считать задачу выполненной после исправления всех важных ошибок.
Преимущества политики
Звучит здорово, но ведь возможны и побочные эффекты.
А ещё всегда остается фактор страха.
«Вот мы закроем ошибку, а вдруг настанет светлое будущее, когда найдется время на исправление»?
Очень маловероятно, что у вас появится лишнее время. Это как хранение старого барахла на балконе: вы не теряете надежду что-то из этих вещей использовать, но, скорее всего, это не произойдет никогда.
Вот мы закроем ошибку, а пользователь увидит ее в проде.
Расстроенный пользователь напишет в саппорт, который в свою очередь сообщит вам. Надо будет пересмотреть приоритет этой ошибки и повторно принять решение, исправлять ее или нет.
Самое сложное — начать. Для этого надо найти время, ресурсы, желание (нужное подчеркнуть), чтобы перелопатить весь бэклог древних ошибок и принять радикальное решение об исправлении или закрытии.
Затем собраться с силами и исправить «выжившие» после чистки ошибки.
И начать жить по новым правилам.
Начать делить баги на две категории:
Если вы находите баг при тестировании новой фичи, то надо сразу принять решение:
А если находится баг на проде/при регрешне, то надо принять решение, как поступить.
Для определения приоритета бага мы используем матрицу, которая объединяет в себе критичность бага в рамках конкретной команды и частоту возникновения.
Другие детали
Профит от использования такого подхода скорее всего будет незначительный, если вы дополнительно не станете менять процессы и подходы в разработке и тестировании.
Что позволит уменьшить количество багов при разработке новой фичи?
Метрики
Чтобы не делать выводы на своих ощущениях, мы следим за метриками по ZBP (я очень люблю Tableau и использую его для построения отчетов). Это позволяет отслеживать прогресс в динамике и подсвечивать возникающие проблемы.
Результаты
Какие же результаты работы по ZBP у нас?
Мы живем в реальном мире, и в чистом виде использовать политику не получилось.
Кто-то столкнулся с проблемой легаси и невозможностью в ограниченный срок исправлять некоторые баги. У кого-то был накопленный годами бэклог, к нему просто страшно было подступиться и они не торопились начинать этот процесс.
Но в целом многим командам удалось разобрать свои бэклоги и поставить определенную планку на количество открытых багов. Команды стали лучше оценивать баги и быстрее принимать решения о необходимости исправления.
Почему не все ошибки надо исправлять, чтобы сделать ИТ-продукт лучше
Покупая ИТ-продукт для решения тех или иных корпоративных задач, бизнес-заказчики чаще всего задумываются о его стоимости, функциональности, удобстве, интеграционных возможностях и т.д. О таких не столь очевидных вопросах, как качество и уровень технической поддержки, думают уже во вторую очередь.
А ведь качество конечного продукта в немалой степени зависит от того, как разработчик организовал процесс тестирования, выявления и исправления ошибок, в среде разработчиков известных как «баги» (от англ. bug — клоп, любое насекомое, вирус, жаргонное слово, обычно обозначающее ошибку в программе). Этим вопросом задаются совсем уже единичные бизнес-заказчики.
Мы хотим вам рассказать о том, как разработчики выявляют и исправляют баги, подходят к тестированию. В основе одного из подходов лежит политика Zero Bug Policy. Спойлер! Мы расскажем, на что на самом деле тратят время разработчики и почему они не исправляют все баги.
У семи нянек
Существует известная шутка, посвященная анонсу нового релиза «Оптимизирована работа приложения, исправлены ошибки, добавлены новые». На самом деле, исправление ошибок и добавление новых — это вечный процесс, старые баги исправляются, но новых возникает не меньше.
Особенно это заметно, когда над программным продуктом, над одной кодовой базой трудится большое число разработчиков или даже несколько проектных команд. Очень сложно синхронизировать их усилия и получать на выходе полностью свободный от ошибок код. К примеру, одна команда сохранила изменения в master-ветке, то есть в главной версии кода в репозитории (хранилище). В свою очередь, другая команда сталкивается с огромным количеством конфликтов и пытается их исправить. В итоге, все это уходит в релиз, то есть в финальную версию продукта, пригодную для обычных пользователей, и здесь всплывает просто неимоверное количество багов. А это чревато потерей денег, клиентов и, самое главное, — угрозой для репутации разработчика.
Так что же делать в этой ситуации? Можно бросить все силы и ресурсы на исправление ошибок, но как тогда заниматься развитием продукта, совершенствовать имеющиеся и добавлять новые функции?
С глаз долой, из бэклога вон
В одной большой ИТ-компании как раз возникла подобная проблема. Благодаря рекомендации одного из работавших в компании специалистов, было решено применить подход Zero Bug Policy. К сожалению, на русском языке о нем написано пока немного.
Суть его состоит в следующем. Когда тестировщики или пользователи обнаруживают какой-либо баг в продукте и сообщают об этом разработчикам, последние принимают решение о том, будет ли эта ошибка исправляться, либо она не влияет на работоспособность продукта, и поэтому ее исправление может быть отложено на будущее, либо вовсе исключено из бэклога (списка задач). Такому багу присваивается статус Won’t Fix (“не исправить”), после чего он навсегда исчезает из поля зрения разработчиков. В некоторых случаях баги с этим статусом помещают в самый конец бэклога. Это означает, что у разработчиков «дойдут руки» до их исправления только тогда, когда будут решены все остальные задачи.
Но вернемся к уже упомянутой ИТ-компании. Ее сотрудники проанализировали весь список обнаруженных багов и провели сортировку найденных проблем. Почти половину ошибок было решено исправить в течение ближайшего времени, а большей половине присвоили статус Won’t Fix. Вся эта работа заняла примерно два месяца, после чего в компании решили взять на вооружение Zero Bug Policy уже на постоянной основе. На сегодняшний день у этой компании в бэклоге размещено не более 10 открытых задач. Это позволяет сосредоточиться на реализации новых функций.
Знатоки багов
Как происходит сортировка багов? Кто принимает решение о том, что одна ошибка критична и ее нужно исправлять, а с другой можно и дальше спокойно жить, либо отложить ее исправление на потом?
Расскажем, как этот процесс организован при использовании концепции гибкого управления проектами (Agile). Всем известно, что Agile включает в себя несколько методик. Мы в качестве примера возьмем одну из них, а именно SCRUM, поскольку она чаще всего используется в мире разработки программного обеспечения.
Владелец продукта или Scrum Product Owner — один из ключевых участников проектной команды. Именно он представляет интересы конечных пользователей и прилагает все усилия к тому, чтобы максимизировать ценность продукта. Он также от начала и до конца несет ответственность за бэклог продукта. В сортировке багов принимает участие вся команда разработчиков, однако последнее слово всегда за Product Owner. Он определяет, какая ошибка будет исправлена, а какая помечена как Won’t Fix.
На самом деле, все решают деньги. К примеру, если исправление бага не принесло бы компании никакой финансовой отдачи, но при этом отняло бы много времени и ресурсов, такому багу лучше присвоить статус Won’t Fix и отложить его исправление до лучших времен. Фактически, «владелец продукта» отвечает за приоритизацию и за статус найденных ошибок.
Иными словами, «скелеты в шкафу» есть у всех. Но если они не оказывают никакого влияния на работоспособность продукта, не затрудняют действия пользователя, не препятствуют интеграционным процессам, их вполне можно проигнорировать.
Критерии отбора
Такие «незначительные» баги есть в продуктах любого разработчика.
К примеру, в администраторском интерфейсе системы управления сайтом невозможно ввести слишком длинное название раздела, статьи и т.д. Разработчики решают этот баг не исправлять. Ведь исправление требует времени, привлечения ресурсов, а можно просто взять и сократить название до определенного количества символов. Достаточно просто предупредить пользователя, что названия длиннее 30 символов не поддерживаются.
Кнопка немного не того цвета, элементы интерфейса, расположенные на два пикселя левее, чем требуется — все это ошибки, не влияющие ни на юзабилити, ни на работоспособность приложения. Поэтому их потенциально можно отнести к Won’t Fix.
Критичные баги — это прежде всего те, с которыми обращается множество клиентов, которые ведут или могут привести к тому, что клиенты потеряют деньги из-за недоработок программистов. Все это определяет Product Owner, который обязан знать продукт как свои пять пальцев, причем не просто разбираться в его функциональных возможностях, но и понимать, как бизнес-клиенты его используют, какие сценарии применения существуют в той или иной компании.
Коллективный разум
Zero Bug Policy часто связывают с Соглашением об уровне обслуживания (SLA). Обычно у разработчиков есть несколько линий технической поддержки.
Первая получает от пользователя сообщение об ошибке и собирает все необходимые данные для ее воспроизведения и анализа, а затем всю эту информацию передает на вторую линию. Специалисты второй линии воспроизводят эту ошибку на рабочих станциях или серверах, на которых установлена та же версия продукта, что и у пользователя. Если ошибка воспроизводится, как заявляет пользователь, то информация о ней попадает уже в активный спринт, то есть список задач для разработчиков.
У первой и второй линии техподдержки, а также у разработчиков имеется SLA. Чем критичнее баг, тем жестче нормы SLA по его исправлению. Существует и общее SLA по устранению ошибок: от обращения клиента до попадания исправленного кода в продакшн. Решение о том, присваивать ли багу статус Won’t Fix или не присваивать, принимает вторая линия технической поддержки. Однако ее вердикт не окончательный. В первую очередь, ее сотрудники руководствуются принципами и правилами текущего спринта. Кроме того, происходит сбор ожиданий от разработчиков, от клиентов, от департамента развития бизнеса.
Если при учете всех этих факторов возникнет спорная ситуация, то последнее слово окажется именно за второй линией саппорта и, разумеется, Product Owner.
Довольный — значит продуктивный
Для чего все это нужно компании-разработчику? Одна из причин — повышение мотивации разработчиков. Фиксить баги — рутинная и малоприятная работа, которой далеко не все любят заниматься. Реализовывать новые функции намного интереснее, чем исправлять ошибки своих коллег. При этом повышается продуктивность и производительность. Наконец, таким образом можно без ущерба для качества серьезно сэкономить на содержании тестировщиков, оставив в компании вместо целого отдела одного-двух специалистов.
Для чего это нужно пользователям и бизнес-заказчикам? Бизнес развивается, перед ним постоянно встают новые задачи, которые нужно решать с помощью ИТ-продуктов. А если разработчики будут тратить большую часть времени на устранение малозначимых ошибок, а не на совершенствование функциональных возможностей своих творений, они рискуют остаться далеко позади конкурентов. Бизнес же выберет тех, кто движется вперед, держа при этом планку качества на высоком уровне.
На этом все. Подробнее о компании «Эквио» можно узнать на их официальном сайте.
А на сайте компании Otus вы можете ознакомиться с нашими курсами и посетить интересующие вас бесплатные вебинары.