Что такое техника «3 амиго»?
Техника «3 амиго» (также известная как Story Kick Off Huddles, или «Триада») — это способ коммуникации, в котором обычно участвуют три роли: аналитик (или продукт-оунер — тот, кто понимает, что нужно бизнесу), разработчик и тестировщик. Они вместе проходят по задаче, задают вопросы, обсуждают сценарии, ограничения и проверяют, все ли понимают ее одинаково. За счет этого многие проблемы и неясности всплывают сразу, а не в процессе разработки.
Почему престади не может полностью выполнять аналитик?
Действительно, классический флоу выглядит так: задача сначала проходит этап аналитики, затем уходит в разработку и только потом попадает в тестирование. В этом месте возникает логичный вопрос: зачем разработчику и QA подключаться раньше, если есть аналитик, который уже всё описал? Дело в том, что они не делают работу аналитика, а привносят свой взгляд: разработчик сразу видит ограничения и сложность реализации, а тестировщик — потенциальные проблемы, сценарии и крайние случаи, которые сложно предусмотреть в одиночку.
Бизнес-аналитик или продукт-оунер (в командах, где аналитика нет) может не осознавать сложности реализации, да и системный аналитик даже при хорошем техническом бэкграунде мог ранее не сталкиваться с подобной задачей.
Плюс в какой-то момент у аналитика может замылиться взгляд: он слишком глубоко погружается в один сценарий и перестает замечать альтернативные варианты поведения системы. Срабатывает простой человеческий фактор — и детали ускользают от внимания. Вместо ревью со стороны бизнес-заказчика, который просто добавляет новые требования, участники с иными ролями могут посмотреть на задачу с других углов зрения. Если двум (или более) членам команды нужно работать вместе, они добьются наибольшей эффективности, если разделят проект на небольшие этапы и будут выполнять их по возможности параллельно.
Пример
Приведу показательный пример: в одной из систем права пользователя обновлялись без перелогина — доступ к разделам можно было выдавать и отзывать прямо во время активной сессии. На тестировании QA решил отдельно проверить сценарий со сменой роли «на лету», и оказалось, что после отзыва доступа интерфейс еще какое-то время продолжал показывать данные из раздела, хотя бэкенд уже возвращал 403 на запросы.
Проблема была в клиентском кеше: после изменения роли состояние на фронтенде не обновлялось сразу, и часть данных оставалась в памяти до обновления страницы или повторного запроса. В итоге получалось, что операции уже запрещены, но пользователь всё еще видит данные, которые видеть не должен. Эту проблему обнаружили уже на готовой системе, когда начали проверять сценарии смены ролей. На этапе требований такой кейс никто отдельно не учитывал, потому что проблема возникала именно на стыке фронтенд-состояния, кеширования и жизненного цикла сессии. После этого пришлось пересматривать механизм обновления прав: добавили принудительную инвалидацию кеша и обновление пользовательского состояния сразу после смены роли, чтобы исключить подобные сценарии.
При этом такой кейс вполне можно было поднять заранее на обсуждении. Например, тестировщик мог бы еще на этапе требований задать вопрос: «Что происходит с уже загруженными данными и активной сессией пользователя после смены роли? Обновляются ли права сразу или только после перезахода?» Разработчик же мог бы заранее обратить внимание на клиентский кеш и lifecycle пользовательского состояния. Возможно, одно совместное обсуждение позволило бы участникам посмотреть на сценарий с разных сторон и заметить этот риск еще до реализации.
Обязательно на встрече должно быть 3 человека?
Число три выбрано, чтобы показать, что в процессе обсуждения должны участвовать представители трех разных ролей. Один участник приходит с требованием или бизнес-запросом. Другой отвечает за реализацию и техническое решение. Третий оценивает, насколько решение проверяемо и какие риски или неоднозначности могут возникнуть. Иногда эту роль описывают как «протестующую», но такая формулировка кажется не совсем удачной. Участник команды не выражает недовольство ради спора, а помогает критически проверить решение, чтобы команда могла достичь общей цели без скрытых проблем и недопонимания. Можно еще сказать, что роль QA в этой коммуникации — искать скрытые допущения, пограничные случаи и несоответствия, задавать «неудобные» вопросы: «А что, если… ?», «Что еще может пойти не так?», «Какие крайние случаи?»
На самом деле в технике «3 амиго» нет жесткого ограничения на конкретные должности. Помимо классических ролей аналитика, разработчика и тестировщика, в обсуждении может участвовать любой специалист, который влияет на решение или зависит от его последствий. Это может быть UX-дизайнер, дата-архитектор, DevOps-инженер, специалист по безопасности, support-команда или представитель смежного продукта. В зависимости от своей роли другие эксперты в этой области могут внести ценный вклад, заметить ограничения, риски или сценарии, которые не видны остальной команде. Например, UX-дизайнер может заранее обратить внимание на неоднозначное пользовательское поведение, а дата-архитектор — предупредить, что предлагаемое изменение создаст проблемы с консистентностью данных или затронет другие сервисы.
На практике многие edge-кейсы появляются только тогда, когда на одну и ту же задачу смотрят с разных сторон. Ценность техники как раз не в фиксированном наборе ролей, а в сочетании разных точек зрения вокруг одной задачи.
Кстати, технику «3 амиго» используют не только в разработке ПО. Ее можно встретить в диджитал-маркетинге, дизайне, креативных командах, инженерных проектах и в целом в любых процессах, где несколько специалистов совместно работают над общим результатом для клиента.
В чём ключевая роль тестировщика, почему аналитик не может обсудить задачу только с разработчиком?
В классическом спринте тестировщик нередко работает сразу над несколькими задачами или даже проектами одновременно, поэтому ему приходится распределять нагрузку между разными потоками работы. Пока функциональность находится в разработке, QA часто не может полноценно подключиться к задаче и вынужден ждать готовой сборки или завершения основной части реализации.
Из-за этого активная фаза тестирования во многих командах смещается ближе к концу спринта, когда сроки уже начинают поджимать. Если в этот момент находятся дефекты или выясняется, что отдельные сценарии вообще не были учтены, задача возвращается на доработку. Причиной могут быть не только баги в реализации, но и неполнота самих требований или пропущенные пользовательские кейсы.
Раннее подключение тестировщика к обсуждению фичи меняет эту динамику. QA начинает понимать сценарии еще до начала разработки и может заранее подготовить тестовые кейсы, продумать пограничные условия и уточнить неоднозначности в требованиях. Кроме того, при постепенной готовности функционала тестировщик может проверять отдельные части системы, не дожидаясь полного завершения всей задачи.
Такой подход к разработке еще называют Shift-left testing, при котором тестирование начинается не после завершения разработки, а как можно раньше — на этапе обсуждения требований и проектирования решения. QA подключается к процессу заранее, участвует в проработке задач, помогает выявлять риски и неоднозначности до появления кода. За счет этого проблемы обнаруживаются раньше, а значит, исправляются быстрее, дешевле и с меньшим влиянием на сроки разработки. Сдвиг влево, по сути, означает, что QA-инженеры начинают тестирование в самом начале цикла разработки и проверка проводится на протяжении всего SDLC (Software Development Life Cycle — жизненного цикла разработки ПО) .
Цель состоит в том, чтобы предотвращать появление дефектов и снижать риски, а не устранять множество ошибок и критических проблем после завершения разработки. Общеизвестно, что дефекты обходятся проекту дешевле, если их выявляют на ранних этапах.
Пример
На таких встречах тестировщик может подсветить много неочевидных сценариев, которые редко попадают в первоначальное описание задачи. Например:
- обработку нестандартных ответов внешних сервисов;
- сценарии с частично успешными операциями;
- проблемы в retry-механизмах, которые проявляются только под нагрузкой;
- переполненные и некорректные граничные значения;
- повторное выполнение одной и той же операции;
- необходимость дедупликации и защиты от повторной обработки событий;
- потерю данных при падении процесса посередине операции;
- проблемы консистентности между несколькими системами;
- кейсы, где ограничения реализованы только на фронтенде, но отсутствуют на бэкенде;
- сценарии с параллельными запросами и конкурентным изменением данных.
Именно такие вещи чаще всего становятся источником сложных продовых багов, хотя на уровне User Story задача может выглядеть полностью понятной и корректно описанной.
Какова роль разработчика?
Вклад разработчиков, которым предстоит непосредственная реализация фичи, состоит в том, что они лучше понимают ограничения, сложности, которые могут возникнуть в процессе разработки, и сразу предлагают альтернативы. Так, на уровне бизнес-требований задача может выглядеть прямолинейно: реализовать «поиск по всем данным пользователя», но разработчик сразу подсветит, что данные лежат в разных сервисах, часть хранится в legacy-системе, а единого индекса нет. И получается, что «простой поиск» либо превращается в тяжелый federated query (подход, при котором один запрос собирает данные сразу из нескольких разных источников), либо требует отдельного search-индекса и пайплайна синхронизации.
Если поставить четкое ТЗ разработчику — грубо говоря, сказать, что делать, он с большей долей вероятности будет следовать инструкциям, насколько это возможно.
Вовлечение разработчиков в написание сценария дает им возможность участвовать в обсуждении того, что именно будет создано. Это меняет восприятие задачи: она перестает выглядеть как формальное ТЗ, которое нужно просто реализовать.
Разработчики начинают лучше понимать ценность функциональности для бизнеса, заказчика или конечного пользователя. За счет этого они становятся не только исполнителями, но и полноценными участниками процесса принятия решений и проектирования.
Пример
Хороший пример, где встреча по технике «3 амиго» могла бы заранее предотвратить проблему, — работа со статусами заказа. В одной из задач пользователь мог отменить заказ, пока тот не перешел в статус «Подтвержден». Бизнес-правила были описаны, основной сценарий согласован, задача ушла в разработку — проблема обнаружилась позже, во время тестирования. Уже после реализации, в ходе проработки тестовых сценариев, отдельно проверили поведение системы при параллельных запросах: что произойдет, если отмена заказа и смена статуса произойдут почти одновременно? Например, пользователь нажимает кнопку отмены ровно в тот момент, когда бэкенд-процесс переводит заказ в статус «Подтвержден».
В результате обнаружился сценарий, когда система могла обработать оба действия одновременно и перевести заказ в неконсистентное состояние. Из-за этого задачу пришлось возвращать в разработку и добавлять дополнительные проверки, чтобы только одна операция могла успешно изменить статус заказа.
Подобные сценарии редко лежат на поверхности в первоначальной User Story, но именно такие вопросы часто появляются во время совместного обсуждения, когда тестировщик начинает думать о пограничных случаях, а разработчик — о поведении системы при конкурентных операциях. Если бы этот кейс обсудили заранее на встрече, часть проблемы можно было бы предусмотреть еще до начала реализации.
А минусы будут?
У техники «3 амиго» есть и вполне реальные минусы. Во-первых, встречи легко могут превратиться в формальность для галочки: люди собрались, пробежались по User Story и разошлись, хотя реальные сценарии и риски никто толком не обсудил. Во-вторых, без нормальной подготовки такие обсуждения быстро начинают расползаться: команда уходит в архитектурные споры, детали реализации или попытки заранее предусмотреть вообще всё. В какой-то момент вместо синхронизации получается еще один длинный митинг. Плюс есть вполне практический вопрос стоимости времени: если собирать несколько человек даже на небольшие задачи, команда довольно быстро начнет воспринимать это как дополнительную процессную нагрузку.
Вместо заключения
Мне кажется важным отметить еще одну вещь, которая особенно заметна в недавно сформированных командах или при смене проекта. У каждого участника уже есть свой опыт, свои привычные процессы и свое понимание того, что считается «достаточно хорошо описанной задачей». Для одной команды нормой может быть подробная спецификация с контрактами, примерами ошибок и описанием всех сценариев, а для другой — несколько верхнеуровневых требований, после которых детали определяются уже в процессе реализации. И здесь проблема не в том, что кто-то работает «правильно» или «неправильно», — просто ожидания изначально разные. В этом плане техника «3 амиго» помогает команде заранее синхронизироваться: проговорить уровень детализации, подход к проработке задач, зоны ответственности и избежать ситуаций, когда расхождение в ожиданиях выясняется уже посреди спринта, с переделками и потерей времени.
