Home

Автор: Михайлов Максим, Scrum Master компании DINS.

Слова благодарности

В тексте я частенько буду срываться на «мы» в знак признательности всем тем людям, кто тащил, поддерживал и сопротивлялся лишь в полсилы. Особая благодарность Диме Кабанову, ведущему менеджеру продукта и автору сценария этой истории.

Проблема, которую мы заслужили

Мы участвуем в разработке продукта с долгой историей и сложной структурой. Продуктом пользуется 400 000 компаний по всему миру. В активную разработку вовлечены тысячи людей на 5 континентах. Разные языки, культуры и часовые пояса.

Баги на проде — неотъемлемая часть продукта. Не то чтобы это достойный повод для хвастовства. Просто данность. Подобную картину можно увидеть в известных продуктах с публично доступными трекерами.

Оставим за скобками критические и блокирующие дефекты — внимания им уделяется достаточно, чтобы не пропустить в релиз или максимально быстро поднять с пола патчом. Поговорим о багах (ни)когда-нибудь. В нашем контексте их приоритет помечают как P2 (Normal) и ниже: P3 (Low), P4 (Trivial). При этом большая часть P2 таки чинится в период стабилизации релиза. Процентов 20 — нет. Добавим несрочные инциденты с прода. И до кучи баги с корнями из прошлых версий, которые находят в процессе разработки.

Достаточная ли эта проблема, чтобы отвлекать разработчиков DINS и читателей Habr? Давайте прикинем. Фичи с объявленной ценностью успешно отправились в прод. Неприятные баги пофикшены. Кому какое дело до мелочей? Пусть пылятся на складе. Так-то оно так, но нет. Есть несколько явлений, которые не дают спокойно спать.

Во-первых, баг взвешенный вчера как P3, назавтра может проснуться как P1 у нового пользователя с крупной подпиской. Хуже всего ситуация сложилась с P2. В трекере это приоритет по умолчанию, читай — используется в любой непонятной ситуации. И он близок в P1, который считается недопустимым в релизе. Но иголки и сено всё ещё перемешаны.

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

Хуже всего картина в динамике. Мониторинг таких багов показал устойчивый рост от релиза к релизу. Что вполне объяснимо — увеличивалась база пользователей, увеличивалось число разработчиков. Но ситуацию с каждым релизом всё сложнее стало называть контролируемой.

Было ещё одно нежелательное явление. Накопившиеся известные баги были разбросаны по разным проектам, а их актуальность не подтверждалась. Если до бага не дошли руки при принятии решения об откладывании фикса, то стоит ли пояснять, сколько времени выделяется на его проверку в дальнейшем?

Итого. Два года назад. На проде 4000 известных багов. Среди 1300 из них — потенциальные кандидаты на патч. С каждым релизом прибывает несколько сотен новых, а чинятся случайным образом пару десятков. Всё больше жалоб от пользователей и всё чаще мы обнаруживаем, что релевантная информация уже имеется в нашей базе. Просто она зафиксирована в (ни)когда-нибудь тикете.

Это уже было в Симпсонах

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

Всё на зеро

Zero bug policy (ZBP). Хотелось бы перевести название подхода как «пишем код без багов, а с багами не пишем». Но на любой продукт без багов найдется пользователь со специфичными вкусами.

Багоноль — это не четко определенный алгоритм действий, а совокупность методов, объединенных общей целью — ноль известных багов в беклоге. Методы можно разделить на 2 группы:

1. всё починить,

2. не баг и был.

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

Вторая группа очень напоминает технику пустого инбокса Максима Дорофеева. Как только становится известно о баге, принимается решение: сейчас или никогда.

Просто и понятно. Почему бы не воспользоваться? Очевидно, из-за минусов, которые в нашем случае перевешивают выгоду.

Починить всё легко, когда «всё» — это «и это всё?». Единственная опечатка в системе и допустил ты её прямо сейчас. А когда «всё» — это «всё, с меня хватит» и количество известных багов перевалило за отметку «тлен», то совет всё починить воспринимается как шутка.

Второе ограничение связано с последствиями явного отказа исправления бага. Такое решение кто-то должен донести до заинтересованных лиц. И в глазах этого человека сохранение надежды, что баг когда-либо починят может казаться более привлекательным, чем прямой отказ.

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

Фиксики

Допустим, вы пока не готовы перейти на ZBP. Накопление багов — неотъемлемая часть ваших процессов, как и починка. Часто баги обозначают в производственной системе как отдельный тип работ. И этот тип часто конфликтует с другим — фичи. Эффективный менеджер с трезубцем в руке как-будто нашептывает: «Раздели. Занимайся фичами, а баги починит кто-то другой.»

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

Всё ради общего благого дела: «позволить лучшим из лучших сфокусироваться на самом важном». Это могло бы звучать как единственный плюс данного подхода, но, увы, при ближайшем рассмотрении ничего хорошего для общей цели метод не сулит.

А вот чем богат подход, так это минусами. И чем дольше вы практикуете его, тем проще вам будет расширить данный список нежелательных явлений:

• выгорание сотрудников;

• отсутствие важной информации, хранящейся в багах, у тех, кто разрабатывает фичи;

• отсутствие важной информации, хранящейся в фичах, у тех, кто чинит баги;

• снижение качества;

• потеря целостности продукта.

Как вы заметили, наш список не такой уж большой. Мы пробовали, нам не понравилось.

Ху из он дьюти тудей?

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

Это первое, что стоит предложить, если перед вашим кабинетом столпились недовольные разработчики с вилами и факелами. Добавим справедливости и возвращаемся к работе.

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

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

Субботник

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

Астрологи объявляют неделю наведения порядка. Всем грабли для разгребания граблей.

Ущерб для бизнеса очевиден — пока все чинят баги, никакие другие типы работ не выполняются. Хочется верить, что на такой шаг идут, только когда другого выхода нет, и ущерб от низкого качества еще сильнее. Совсем хорошо, если из таких прецедентов делают выводы и более не повторяются.

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

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

Наша история

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

Ограничения

Прилаживание не было быстрым. Более того, процесс продолжается по сей день.

Давайте посмотрим какие общие ограничения обуславливают наши действия:

• нет возможности привлечь дополнительных или выделенных людей;

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

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

Пармезан

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

• 4000 багов раскиданы по десяткам Jira-проектов;

• актуальность большинства багов не подтверждена;

• часть баг-репортов содержит минимум информации с расчётом на то, что баг починят моментально;

• сомнительная достоверность выставленного приоритета.

Мы определили все входящие источники, пополняющие данный тип рабочих элементов. Наскребли по сусекам и перемотали через OR изолентой. Получился очень некрасивый JQL.

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

Прежде чем известный баг попадал из закромов в BUG, он валидировался менеджером продукта и упаковывался по-новому. Кроме стандартного описания репорт дополнялся следующей информацией:

• видео воспроизведения;

• тип используемой аккаунтом биллинг-системы;

• конфигурация продукта и бренд;

• локация, в которой воспроизводится баг, — в простейшем исполнении заполнялся как URL соответствующей web-страницы.

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

После фича-фриза продукт, в разработке которого мы принимаем участие, проходит фазу стабилизации. Важной её частью является регрессионное тестирование системы. Такое тестирование выполняется силами отдельной команды QA-специалистов. Из чувства прекрасного по собственной инициативе они и ранее верифицировали часть багов с прода. В основном проверялись те баги, которые ими и были заведены. Но нам не хватало ресурсов проверить весь склад. Стандартный объем без ущерба для основной деятельности — 200-300 верифицированных баг-репортов за цикл.

Мы договорились, что после каждого крупного квартального релиза эта команда как и раньше будет обрабатывать около 200 багов, но те, которые наиболее желательно было перетащить в BUG проект. Если баг при проверке воспроизводился, то отчет дополнялся полезной информацией.

Отношение закрытых к воспроизведенным было 1:2. За полтора года на склад перевезли все баги уровня P2. А еще через полгода — верифицировали 80% всех известных багов. Без изменения схем работы команд, используя текущие правила игры.

Непосредственно в BUG тикеты переводились силами PM. Заодно валидировался приоритет, и проводилась кластеризация по бизнес-областям.

Что в итоге:

• за два года все известные баги прода переведены в единый проект;

• немного подправили процессы, чтобы предотвратить попадание продакшн багов в другие Jira-проекты;

• каждый баг содержит расширенную информацию, что упрощает поиск;

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

Причём тут пармезан?

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

Кукушка

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

Мы не могли просто принести эти баги в команды с просьбой починить. Это нарушило бы один из принципов инициативы — не влиять негативно на текущую схему рабочей нагрузки.

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

Больше всего затрат было на восстановление контекста: мыслительного и технического. Для воспроизведения бага требовались особенные настройки окружения. Приходилось ждать подходящего момента, когда перенастройка не повредит основным задачам. Другой немаловажный аспект — разработчику приходилось выныривать из текущего проекта и погружаться в контекст бага. Очевидно, разница между этими контекстами могла быть большой и во времени (разные релизы) и в пространстве (система большая и сложная, с разными функциональными областями). Всё это в итоге складывалось и в психологический эффект — не было никакого желания браться за починку таких багов.

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

Так возникла Кукушка. Имея упорядоченный склад, мы можем проводить эффективный быстрый поиск. Баги можно сгруппировать по локации, которая по сути представляет собой контекст. Во время очередного релиза команда занимается проектом в определенном контексте. Обеими областями знаний умело оперирует Product Manager (PM).

Когда PM готовит эпик для команды, через поиск релевантные по контексту баги со склада подтягиваются в этот же эпик. PM «подкладывает» баги в запланированную корзину. Отсюда и название — Кукушка.

С командой действует договоренность: запланированная работа в приоритете, но когда есть возможность, берутся подкидыши с прода. Часть из них закрывается как более неактуальные — например, из-за изменившегося дизайна страницы. Часть фиксится, с приемлемым расходом времени.

Что в итоге:

• мы получили трёхкратный прирост закрытых багов с прода;

• мы не изменили отношения между PM и командами разработки;

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

Уборщик (Janitor)

Системный анализ захватил не только область хранения и устранения известных проблем, но и изучение источников пополнения.

Самым крупным поставщиком сырья на ПРОДовольственный склад невостребованных багов были остатки перед выпуском релиза. В момент, когда бизнес считает, что релиз пора выпускать, в работе еще есть баги. Ранее большинство из них возвращали в бездонные беклоги команд разработки. Теперь предстояло перевезти их на склад.

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

Что в итоге:

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

Сегодня я многое понял

Наша история — не быстрая прогулка, а долгое путешествие. Мы многому научились, идя по этому пути. Во-первых, улучшений можно добиться не выходя за рамки действующих правил. Для того чтобы получить значимый результат, не обязательно объявлять громкую кампанию, подключать большие ресурсы. Можно обойтись без резких изменений, а развиваться постепенно. Главное — понимать в какую сторону.

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

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

В-четвертых, в очередной раз убедились что нет серебряных пуль. Лучший вариант — это подбор хорошей практики полезной в своём контексте.

Ниже чуть больше деталей того, что на наш суд получилось, а что нет.. пока нет.

Что получилось

1. Тренд неконтролируемого роста багов общими усилиями удалось зафиксировать на определенном уровне. Этот уровень для P2 багов соответствует примерно половине от прогнозируемой в 2019 году отметке на данный момент. 952 известных P2 бага против ожидаемых 1840. 

2. Получилось не нарушить текущие процессы разработки

3. Получилось выстроить систему менеджмента багов с прода

Что пока не получилось

1. Рассчитывали на убывающий тренд за счёт того, что скорость починки будет выше, чем скорость притока новых известных багов. Сейчас наблюдаем плато.

2. Не получилось полноценно вовлечь представителей бизнеса. Баги на проде воспринимаются как проблемы инжиниринга, как некий долг. Интерес бизнеса резко усиливается, только когда какой-то баг выстреливает, — ущерб от него соизмерим с запросом на создание фичи.

3. Не получилось в достаточной мере визуализировать поток багов. Возможностей Jira не хватает, а google sheets костыли не выглядят надежно. Много ручной работы по администрированию.

4. Всё ещё требуется администрирование системы, она не автономна. Периодически проседают отдельные узлы.

5. Общий интерес менеджмента к проблеме продакшн багов снижается с ростом успехов по их починке. Видимо, есть некоторая планка, ниже которой проблема перестает быть видимой и значимой.

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

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

Полезные ссылки по теме из моей коллекции:

• Всё на зеро

  • Zero Bug Software Development by Sam Hatoum

  • Zero Bug Policy by Kevin Sookocheff

  • 0 Bug Policy by Gal Zellermayer

  • Implement a zero bug policy by Peter Hilton

  • Zero bug policy. A fast way for paying back technical debt. by Roland Flemm

• Фиксики

• Мне не попадалось много статей на эту тему, но если применение данной практики в вашей ситуации оправдано, то постарайтесь сделать жизнь людей комфортнее: 9 Ways to Incentivize Bug-Fix Teams by Bobby Tahir