Почему не все ошибки надо исправлять, чтобы сделать ИТ-продукт лучше

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

А ведь качество конечного продукта в немалой степени зависит от того, как разработчик организовал процесс тестирования, выявления и исправления ошибок, в среде разработчиков известных как «баги» (от англ. 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.

Довольный — значит продуктивный

Для чего всё это нужно компании-разработчику?

• Одна из причин — повышение мотивации разработчиков. Фиксить баги — рутинная и малоприятная работа, которой далеко не все любят заниматься. Реализовывать новые функции намного интереснее, чем исправлять ошибки своих коллег. При этом повышается продуктивность и производительность. Наконец, таким образом можно без ущерба для качества серьёзно сэкономить на содержании тестировщиков, оставив в компании вместо целого отдела одного-двух специалистов.

Для чего это нужно пользователям и бизнес-заказчикам?

• Бизнес развивается, перед ним постоянно встают новые задачи, которые нужно решать с помощью ИТ-продуктов. А если разработчики будут тратить большую часть времени на устранение малозначимых ошибок, а не на совершенствование функциональных возможностей своих творений, они рискуют остаться далеко позади конкурентов. Бизнес же выберет тех, кто движется вперед, держа при этом планку качества на высоком уровне.

Источник