Автор: Эми Стюарт (Amy Stuart)
Оригинал статьи
Перевод: Ольга Алифанова.

Многие компании, занимающиеся разработкой ПО, просто терпят забагованные стейдж-окружения: мало кто считает это большой проблемой. Работая в разработке, вы с шансами сталкивались со стейдж-окружением, которое очень похоже на ваш первый автомобиль. Мы зачастую обещаем все починить, покупая его, но машина остается в том же состоянии годами! Боковое зеркало разбито, моргает задний габарит – но она же ездит! Мы убеждаем себя, что эти мелочи несущественны, а чинить их слишком дорого.

Хочу объяснить, почему эти «мелочи» приведут к большим проблемам в вашей команде разработки. Скорее всего, они уже именно этим и заняты. Я дам вам советы, как убедить компанию выделить ресурсы на исправление корня этих проблем. И, наконец, я расскажу, что можно сделать, чтобы привести ваш стейдж в порядок – и поддерживать этот порядок.

Стейдж-окружения: основные факты и реальное положение дел

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

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

• «Всем привет, я заметил, что эта страница на стейдже не загружается… но на проде все в порядке. Мы знаем об этом? ????»
• «Ох лол, да, ну, оно такое ???? не парься!»

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

Три основных начинающих развиваться проблемы:

• Культура анти-качества
• Повышенный риск багов прода
• Скрытые издержки процессов разработки.

Культура анти-качества

Что такое культура анти-качества?

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

Если культура качества борется за качество в качестве самоцели, то культура анти-качества – ее полная противоположность. Ваша команда медленно, но верно теряет чувствительность к неожиданному поведению стейдж-окружения. Она начинает предполагать (или подозревать), что любое неожиданное поведение – следствие игнорирования окружения, а не реальных проблем. Инженеры привыкают к этим проблемам, научаются их обходить, работают все более и более халатно. Эта культура анти-качества напрямую приводит к усталости от дефектов. Усталость от дефектов возникает, когда мы настолько привыкаем к виду багов, что разрабатываем когнитивные искажения и предполагаем, что не связанные с задачей баги вызваны окружением. В результате меняется наше поведение – с потенциально разрушительными результатами.

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

Представьте себе такие сценарии. Возможно, это происходит в вашей команде прямо сейчас.

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

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

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

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

Как культура анти-качества влияет на QA-инженеров

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

Усталость от дефектов тоже влияет на QA-инженеров. Учитывая, что их основная задача – искать баги, это опасная черта. Остановимся на этом подробнее в следующей части.

QA-инженеры чаще всего пользуются стейдж-окружениями. Именно там прогоняются автотесты и проводится исследовательское тестирование. Если ваша компания не вкладывает средства в то, чтобы убедиться, что QA могут выполнять свои задачи, не сталкиваясь постоянно с проблемами окружения – эти инженеры начнут искать, где трава зеленее. Или (еще один распространенный сценарий) оставшиеся инженеры будут работать с пониженной производительностью, реализуя минимум своего потенциала – они могли бы больше, и это очень грустно.

Повышенный риск багов на проде

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

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

Или инженеры решают, что не будут изучать вопрос, потому что предполагают, что это проблема окружения. В реальности QA угадывают не всегда – оно и понятно! Если у QA-инженера есть дедлайн через час, и стрессующий он сталкивается с тем, что, «скорее всего», проблема окружения – с высоким шансом он пропустит изменение дальше. Или потому, что он уверен, что реальной проблемы нет, или он так устал, что даже не видит тут проблемы. QA-инженеры тоже живые люди.

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

Скрытые издержки процесса разработки

Но их так дорого исправлять…

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

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

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

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

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

Стейдж-окружение нужно исправить. Как продавить это в компании?

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

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

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

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

И тут нужно быть креативными, потому что на этот вопрос так много ответов! Во-первых, если вы осознали, что культура анти-качества поработила вашу команду, в первую очередь надо признать существование проблемы. Используя вышеописанные пункты, попробуйте убедить других членов команды, что эти мелкие баги окружения вызывают цепную реакцию в жизненном цикле вашего приложения. Вдохновите их искать проблемы окружения и не принимать их, как жизненный факт, а выделить им отдельное место для фиксации, так же, как и для багов прода. (Если вы уже это не делаете, немедленно начните фиксировать баги прода!)

Признав проблему, вам нужно понимать, какие баги у вас есть и где именно – вам надо представлять масштаб проблемы. Это нужно для следующего шага – выбора идеального способа с ней разобраться.

Идеальный подход к исправлению багов окружения сильно зависит от конкретной ситуации. Вот несколько идей:

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

И снова призываю вас сделать команду ответственной за это. Если вы можете поставить цель исправить Х% багов окружения в Y спринтах, и эта цель достигнута рядом последовательных спринтов, это цементирует исправление таких багов, как серьезное мероприятие. Эту цель можно отслеживать на церемониях спринта, технических встречах по дорожной карте, или других регулярных инженерных сборищах. Начните говорить об этом!

Советы напоследок

Рекомендую обращаться с инженерами, как с важным акционером, и достичь гарантийных соглашений о багах окружения. Убедитесь, что баги окружения и все связанные с ними внедряемые процессы внятно описаны и задокументированы. Если все сделано правильно, команда будет в курсе багов, если (когда) они появятся.

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

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

Обсудить в форуме