Разработка без багов — не миф. Так и должно быть. Примените этот подход уже сегодня.

Простой вопрос, вызывающий споры: "Как работать с багами"? Можно ли полностью избавиться от багов? Должны ли мы к этому стремиться?

Мой опыт говорит: достичь состояния Ноль Багов проще, чем вы думаете.

Пример из жизни

Вспоминаю свою работу в BBC в Лондоне.

Я только что подключился к проекту как тренер по гибкому управлению разработкой. Первые две недели я внимательно наблюдал за динамикой работы команды из 22 человек.

У команды не получалось работать стабильно. Я посмотрел историю их спринтов. В одних они набирали много очков продуктивности, в других — ноль.

Я наблюдал, как команда постоянно работает над "маленькими замечаниями" в ущерб важной работе. Владелец продукта и заинтересованные лица были разочарованы отсутствием долгожданных обновлений. Разработчики показывали пальцем друг на друга.

Мне стало очевидно, что все эти "маленькие замечания" были багами трех типов. В редких случаях это были дефекты реализации. Но чаще баги были результатом некорректных или отсутствующих спецификаций.

Разработчики исправляли любые баги. Часто в срочном порядке — поскольку начальство было недовольно, или потребители не могли пользоваться системой.

Я также заметил, что хронически большое число багов стало восприниматься командой как норма.

После наблюдений я применил подход Ноль Багов.

В течение одного спринта мы перешли на новый режим. В следующие 2 спринта продуктивность увеличилась на несколько баллов. После еще 4 спринтов продуктивность стабилизировалась.

Авралов стало меньше. Продукт стал лучше. Команда стала счастливее и воспряла духом.

Как работает эта магия вуду? Расскажу подробно, почему и как применить эту систему очень просто.

Как разрабатывать ПО без багов.

Менеджмент классифицирует все задачи. Команда выполняет задачи в установленном порядке.

Есть четыре типа задач:

• Критичные проблемы
• Баги
• Фичи
• Улучшения

Рассмотрим их на примере магазина.

Критичная проблема: магазин горит.

Если не потушить пожар, вы потеряете магазин!

Критерий: потребители не могут пользоваться продуктом; деньги или время тратятся с недопустимой скоростью.

Решение: бросьте всю текущую работу и решите проблему немедленно.

Баг: трубы протекают.

Если не устранить протечки, вода зальет товар и испортит его. Это замедлит развитие бизнеса.

Критерий: система работает не так как ожидается, но потребители могут ею пользоваться; теряеются деньги или время, но в краткосрочной перспективе это допустимо.

Решение: сперва доделайте текущую задачу, затем устраните баг.

Фича: товар или сотрудник.

Товары и сотрудники необходимы, чтобы вести бизнес.

Критерий: еще не реализованные функции.

Решение: приоретизируйте и реализовывайте по порядку.

Улучшение: чистый магазин.

Довольные чистым магазином потребители заходят чаще.

Критерий: улучшение функций системы.

Решение: приоретизируйте и реализовывайте согласно приоритетам.

Других правил нет! Я же говорил, это просто.

Почему это работает

Концепция критичных проблем давно известна. Во многих командах такие проблемы называют P1. Когда вы видите пожар, вы тушите его.

Суть подхода в том, что вы всегда сначала исправляете все баги, и только потом делаете фичи и улучшения. В этой системе нет багов с приоритетами P2 или P3. Это бинарная система.

Баг либо есть, либо его нет. Баг — это проблема, которую надо решить в первую очередь. Если это не так — это не баг.

Намного чаще задачи будут классифицированы как фичи или улучшения. Приоретизируйте их и делайте по порядку.

Классифицировать задачи вам поможет картинка:

Классификация багов

Три вида багов, о которых я писал выше и в статье "Предотвращая появление багов":

• Дефекты реализации
• Некорретные спецификации
• Отсутствующие спецификации

Можно классифицировать их как критичные проблемы или переклассифицировать в фичи или улучшения.

Ниже — мои любимые правила переклассификации багов.

Можем ли мы жить с этим дефектом реализации?

Шрифт должен быть встроен в приложение, но скачивается каждый раз при его запуске.

Переклассифицируем как улучшение.

Мы теряем деньги или можем потерять их из-за некорректной спецификации?

В спецификации написано считать клики. Но следить надо за расходами.

Это критичная проблема.

Отсутствие спецификации подразумевает новые функции?

Пользователи не могут редактировать свой профиль и делиться им через социальные сети.

Переклассифицируем как фичу.

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

Строго следуя этим правилам, вы автоматически улучшаете дисциплину в команде.

Стандарты качества

При классификации багов, фич и улучшений вы опираетесь на негласные стандарты качества. Например, владелец продукта акцентирует внимание на оформлении: не принимает любые визуальные огрехи и классифицирует их как баги. Последовательное применение правил классификации неявно формирует стандарты качества.

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

Как применить этот подход уже сегодня

Классифицируйте все задачи, пользуясь описанными выше правилами.

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

Разработчики не будут ждать, пока вы классифицируете все задачи. Они начнут разбираться с багами сразу же, как только появится несколько задач данного класса.

Разработчики работают над исправлениями до полного устранения багов. НИКАКИХ ИСКЛЮЧЕНИЙ! Если нарушить это правило, подход перестанет работать. Это правило мотивирует менеджера по продукту корректно классифицировать и приоретизировать задачи.

Не позволяйте всем подряд классифицировать задачи как "баги" — получится бардак. Пусть все создают задачи, но не классифицируют их.

Классифицировать задачи должен менеджер по продукту. Возможно другие члены команды тоже захотят классифицировать задачи. В этом случае установите четкие правила и следите за порядком.

Наглядное изображение процесса работы:

Критичные проблемы решаем сразу → текущие задачи доделываем до конца → фиксим баги → делаем задачи из очереди.

Если критичных проблем или багов несколько, можете приоретизировать их, чтобы легче пережить кризис.

Команда должна постоянно и следовать правилам классификации и приоретизации. При таком подходе разработку будет идти быстро и в соответствии со стандартами качества.

Не замедлит ли это работу?

Ровно наоборот, и описанный выше случай в BBC это доказывает.

Представьте: вы едете по левой полосе скоростного шоссе. Внезапно вы вспомнили о повороте направо. Скорость 150 км/ч, и быстро перестроиться в правый ряд опасно. Вы ускоряетесь до 180 км/ч в надежде, что не пропустите следующий поворот и не попадете в пробку.

Другой вариант: вы едете со скоростью 120 км/ч. Когда вы вспомнили о повороте, еще есть время притормозить и вовремя свернуть.

В каком случае вы доедете быстрее? В каком случае больше шансов попасть в аварию и не доехать?

Подход Ноль Багов работает так же. Разработка замедляется не более чем нужно, тогда когда это нужно.

Увеличение скорости разработки может быть незаметно день ото дня, но будет очевидным в долгосрочной перспективе.

Не верьте мне на слово. Попробуйте применить этот подход на практике, замерьте результаты и убедитесь сами.

Это не новая концепция

Я был весьма горд, что придумал всё это сам.

Как выяснилось, идея не нова. Как и другие забытые мудрости "старой школы", она известна с конца 60-х!

В истинном подходе "Ноль Дефектов" нет неважных элементов. Филипп Кросби, 1926-2001

Филипп Кросби — легендарный эксперт по качеству. Ввел понятие "Ноль Дефектов" когда работал в компании Martin (сейчас известна как Lockheed Martin). Утверждалось, что "государственный аудит показал сокращение дефектов оборудования на 54%". Подход "Ноль Дефектов" был использован в космической отрасли в 60-х, и в производстве автомобилей в 90-х.

У разработки ПО и промышленного производства много общего. Популярный метод гибкого управления Канбан зародился на фабрике Toyota. Ноль Дефектов — другой вдохновляющий пример того, чему мы можем и должны научиться у промышленников.

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

Итоги

Баги в программах будут всегда. Писать программы без багов — невозможно.

"Ноль Багов" не означает код, в котором нет ни одного бага; это стремление устранить все известные баги.

Лучше всего итоги данной статьи подведет легендарный эксперт по качеству Эдвардс Деминг (1900-1993):

Качество создается не проверками, а улучшением производственного процесса. Уильям Деминг, 1900-1993

Сражайтесь за качество, как ниндзя!

Узнайте больше о практиках улучшения с помощью "Quality Faster". Этот цифровой продукт поможет вам улучшить качество и процессы на всех уровнях разработки, во всей команде.

Мы начинаем обучение с основных принципов поставки качественного и ценного ПО. На основе этих принципов вы создадите стратегию и процессы тестирования. Вы увидите работающие примеры на основе Node.JS, React, Chimp JS, Mocha, Meteor, и других технологий.

Кликните здесь, чтобы приобрести книгу и стать Ниндзя Качества!

Также подпишитесь на меня в Medium и Twitter. Пишите в комментариях о своих мыслях и идеях.

Я и дальше буду помогать вам быстрее поставлять ПО высокого качества.

Сэм.

Автор:

Источник