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

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что Agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

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

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

«Боишься — не делай, делаешь — не бойся» (Нэнси Уиллер).

Однажды мне предложили пойти единственным тестировщиком в новую хипстерскую команду, которая могла выстраивать свои процессы, настраивать CI/CD и инструменты как ей угодно, используя самые современные фреймворки. Кто бы мог от такого отказаться? 

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

Мы понимали, что проблема бутылочного горлышка — чисто процессная, но тогда ещё не знали, что подходы к её решению называются 3 Amigo и Shift Left Testing.

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

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

Мы стали вместе обсуждать тестовые сценарии и фиксировать ожидания от разработки (англ. Acceptance Criteria, далее — AC) на этапе дизайна. Это принесло больше всего профита. Команда до сих пор использует эти подходы и даже некоторое время жила без тестировщика.

Моя роль стала шире: я принимал участие в продуктовых решениях, тестировал требования, дизайн и архитектуру. Благодаря тому, что разработчики автоматизировали CI/CD на некоторых этапах, я начал делать финальное ревью кода, мёрджить пул-реквесты и толкать их по пайплайну до прода. Также проводил smoke-тестирование и занимался всем процессом релиза, таким образом сэкономив кучу драгоценного времени разработчиков.

Наша команда сделала качественный скачок от паттерна «Я — роль, я — разработчик, а ты — тестировщик, иди и тыкай мою сборку» к более продуктивному майндсету «Я — часть команды. Что я могу сделать, чтобы наш продукт с оговорённым качеством попал к клиенту как можно быстрее?». Так мы начали взращивать ту самую Agile-культуру, которая упрощает работу с неопределённостью на входе и предоставляет хорошие возможности для развития команды.

В любой ли команде работают Agile-практики?

Не факт.

«Тебе не должно нравиться что-то только потому, что тебе так сказали» (Джонатан Байерс)

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

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

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

Под такое понимание очень подходит определение Agile-команды:

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

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

Если бы разработчик с внутренним паттерном «Я — разработчик, ты — тестировщик» посмотрел на то, что делает разработчик в Agile-команде, то он удивился бы и сказал, что тестировщик — полный бездельник. Но когда есть прозрачные коммуникации в команде, ему был бы абсолютно виден и понятен процесс целиком и задачи каждого члена команды.

Какую пользу приносят Agile-практики

«Просто иногда люди на самом деле не говорят то, что думают. Но когда вы фиксируете этот момент, это говорит о большем» (Одиннадцатая).

• Наборы практик Shift Left Testing и 3 Амиго позволяют команде объединять контексты своей экспертизы на самых ранних этапах разработки задач и отдавать на выходе более качественные продукты. Количество возвратов задач на доработку становится минимальным, что сильно уменьшает Time To Market и увеличивает пропускную способность команды. Например, мы свели количество возвратов на этапе приёмки фактически к нулю, а пропускная способность возросла до 2.5 раз.

• Фиксирование своих ожиданий в чек-листе AC позволяет помнить о договорённостях и синхронизировать ожидания от задач/фичей, всегда держать их под рукой в той же таске в Jira, что тоже уменьшает количество инструментов, используемых разработчиками, делая их счастливыми и продуктивными.

• Понимание и ежедневное употребление использование этих подходов даёт время и возможности на развитие смежных навыков, то есть T-shape каждого члена команды, что наиболее характерно описывает понятие комплементарности.

• Проговаривание ожиданий друг от друга и будущих функциональностей продукта, равно как проговаривание своих обязанностей и текущих задач (не обязательно даже на утреннем синке) отлично развивает командное доверие и возможные пути для T-Shape и понимания, как и в какой роли каждый член команды может дополнить остальных.

Всё это очень сильно коррелирует с базовыми понятиями Agile и Scrum, такими как «Прозрачность» и «Предсказуемость». А также активно помогает развитию осознанности ребят в команде и того самого майндсета «Я — член команды, что я могу сделать…».

Но каждый раз, когда я прихожу в новую команду, то вижу, что это не работает. Приходится заново подробно рассказывать о самом подходе, деталях и инструментах. И обычная ответная реакция «А что, так можно было?». Более продвинутые ребята говорят «Это очевидно, но почему мы до сих пор так не делаем?». Вопрос может быть задан как относительно всех процессов хорошего командного взаимодействия в целом, так и относительно более углублённых практик 3 Амиго, создания артефактов DoD, DoR, Acceptance Criteria или даже просто конечного фиксирования ваших договорённостей, что чаще всего пропускается, и так далее.

О влиянии и важности культуры в компании

«Наклеив пластырь, рану не залечишь» (Джим Хоппер).

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

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

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

И это у нескольких моих команд получилось. Я использовал их как примеры success story, на которых мы сняли метрики, сравнили с другими командами и били в первую очередь на количество возвратов на этапе приёмки задач.

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

Сопротивление: как работать с возражениями, когда внедряешь Agile-практики

«Мы обсудим это позже. По утрам лишь кофе и медитации» (Мюррей Бауман)

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

Сопротивление разработчиков

Один из самых частых вопросов, которые я слышал от разработчиков, сводился к общему: «То есть я, разработчик, который стоит дороже тестировщика, должен заниматься тестированием. А что будешь делать ты как тестировщик?». С этим вопросом я, конечно, прошёл много кругов ада и часто возвращался к исходной точке в попытках донести важную мысль о культуре взаимодействия внутри команды. И упирался всё равно в это.

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

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

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

А за качество и результат ответственна вся команда.

Сопротивление владельца продукта

На своём пути я встречал такие команды, в которых разработчик и тестировщик отродясь друг с другом даже не разговаривали, а задачку на тестирование фичи заводили отдельно от задачи на разработку, при этом полностью теряя контекст. От таких команд после рассказа о практиках 3 Амиго и фиксирования АС, чаще всего и слышишь вопрос «А что, так можно было?».

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

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

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

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

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

Сопротивление соседних команд

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

Чтобы это вылечить, достаточно просто позвать смежные команды на встречи в формате 3 Амиго и так же составлять и фиксировать ожидания друг от друга. Правда, весомым пунктом будет ещё и исполнение этих договорённостей, но это тема для отдельного разговора.

Инсайты, которые помогут меньше наступать на грабли

«Ничто не вернётся к тому, что было. На самом деле, нет. Но станет лучше. Со временем» (Стив Харрингтон).

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

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

• Продавать best practices нужно только с учётом контекста того, кому вы продаёте.

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

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

• Грустный для меня инсайт: Agile можно взрастить только там, где есть заинтересованные в нём люди. Культуру внедрить административно невозможно, если её ценности не разделяются топ-менеджментом компании.

  Можно сделать Agile без правил, и он будет работать и приносить плоды. Но можно и внедрить только правила, без следования ценностям самой культуры Agile. И это не принесёт ни капли пользы. А ещё всегда будут люди, искренне считающие, что «все ваши скрамы — это просто игрушки для взрослых, навеянные модой».

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

• При оценке реальных проблем и контекста конкретной команды не стесняйтесь оперировать низкоуровневыми  Аgile-понятиями (те самые «Прозрачность, Предсказуемость, Прогнозируемость»). Никто вас не осудит, зато так вы быстрей докопаетесь до сути. Всегда пытайтесь увидеть, на каком уровне могут быть проблемы в коммуникациях, фиксировании договорённостей или проведении PBR.

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

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

Заключение

«Друзья не лгут» (Майк Уиллер).

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

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

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

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