Меня зовут Никита Пимошенко. Сейчас я IT-Head департамента General Development в Quadcode, а до этого три года был тимлидом команды Billing API . Я успел поработать в ряде интересных проектов, но самым большим своим достижением на данный момент считаю налаживание процессов в моей Billing-команде. Статья — именно об этом. Расскажу о наших проблемах во взаимодействии между разработчиками и QA-инженерами и том, как мы эти проблемы решали.  

Чего мы хотим

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

Процесс продуктовой разработки в Quadcode

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

Весь процесс можно формально разделить на три блока: 

1. Разработка. 

2. Тестирование. 

3. Верификация, когда функционал уже на проде. 

Релизным менеджментом у нас занимаются разработчики: деплой в прод идёт со стороны разработки автоматизированными средствами Jenkins. 

Если взглянуть на схему, то кажется, что мы видим чёткий вход в тестирование на шаге ready to test, где задачка переходит QA-инженерам. Долгое время так и было, но этот процесс породил ряд проблем. 

Проблемы взаимодействия QA и разработки

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

Как мы уже отметили, ключевая цель процесса разработки — делать качественный продукт для пользователей. Когда мы чётко разделяем границы ответственности, разработчики заняты на своём участке работы, а QA-инженеры — на своём. И здесь может произойти следующее. Разработчик подумает: «Окей, я сейчас напишу таску, пройду code review, отправлю её в QA. Дальше дождусь ответов и задеплою, если всё клёво, а если что-то не клёво, буду править. Но после этапа разработки мои полномочия всё». А у QA-инженера может сложиться ощущение: «Я сейчас забираю задачу с ready to test, работаю над ней и откидываю обратно в разработку». 

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

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

Например, у нас были регламенты, написанные за пару лет до внедрения свежих. Они содержали неактуальные данные по процессам, также там описывался flow работы с предыдущим TMS, с которого мы перешли на новое хранилище тестовых артефактов. В регламентах не хватало актуальных описаний новых инструментов тестирования и требований к тестовой документации. Это осложняло онбординг новых специалистов и вводило в заблуждение текущих. Держать в голове все нюансы большого проекта сложно — я бы даже сказал, невозможно, — и тут спасает актуальная документация.

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

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

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

Спринт хорош тогда, когда команда готова принять на себя обязательства по его закрытию и выполнению. А команда готова, когда она понимает, какие ресурсы у неё есть и сколько их потребуется для закрытия спринта. Чем прозрачнее процесс, тем трезвее команда оценивает риски и более готова их принять и/или смягчить.

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

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

Общие группы проблем. Если суммировать наши проблемы, то они подразделялись на две группы: 

1. Эмпатические.

2. Эмпирические. 

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

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

В 2020 году мы приступили к оптимизации процесса. Тогда у нас ещё не было ясной картины внедрения — просто было понимание, что мы хотим меняться.

Решение проблем

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

Зафиксированные договорённости. Кажется, что все прекрасно знают, что разработка и QA — это части одного процесса. Но пока вы не зафиксировали эту договорённость на бумаге, не собрали всю команду, не пообщались и не произвели изменений изнутри, это знание, к сожалению, не всегда работает. Понимать команда всё понимает, но паттерны поведения остаются старыми. 

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

Прийти к единому пониманию помогает Scrum retro — встреча, на которую выносятся плюсы и дельты команды, и где принимаются договоренности о том, как с этим работать. Ключевой момент здесь в том, что новые договорённости не всегда легко приживаются, и нужно мониторить изменения. В среднем нужны 2-3 спринта, чтобы новые ритуалы стали привычкой. 

Но бывают и более сложные ситуации. Например, если изменений требует квартальное планирование. Чтобы успешно внедрить и сделать традицией изменения, которые затрагивают процессы периодичностью в 3 месяца, может уйти до года. Да, внедрить обновлённый процесс можно прямо на следующем ритуале, но вот традиция зарождается с повторением. Это усложняет приземление изменений в процессах, рассчитанных на долгий цикл периода.

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

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

Чтобы проверить получившиеся регламенты, можно пригласить ребят из другой команды почитать их. В идеале коллеги должны понять, как что работает, и подсветить неочевидные изнутри пробелы. Цель — сделать так, чтобы человек со стороны мог прочитать регламент и сказать: «Окей, мне всё понятно». 

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

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

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

Поэтому дальше, когда задача после разработки переходит в QA, многие хэппи-кейсы уже будут пройдены в тестовом окружении. Между основными задачами тестировщиков на этапе ready to test и задачами в состоянии написания кода приоритет отдаётся первым. Поэтому сценарий работает, когда QA-инженеры не перегружены общей очередью на тестирование и у них есть возможность подключаться на code review.  

Это упрощает коммуникацию: QA-инженер может обратиться к разработчику на моменте in progress, задать вопросы или прояснить определённые моменты, которые он нашёл в задаче. Для разработчика это тоже удобно: когда он решает задачу, у него уже есть понимание потенциальных проблемных мест, на которые следует обратить внимание. 

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

Бонус такого процесса в том, что он сохраняет контекст. Мы работаем с потоком задач. Разработчик берёт таски, потом передаёт их в тестирование. Пока QA-инженер тестирует эти задачи, разработчик берёт следующую задачу из пула. Ключевой проблемой пинг-понга является именно изменение контекста, потому много времени тратится, чтобы выйти из своей текущей задачи и вернуться в контекст той, которую ты делал неделю назад. Именно поэтому и QA-инженер и разработчик должны работать совместно на протяжении всего жизненного цикла задачи.

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

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

До и после: как изменился процесс

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

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