Привет, Хабр! Я являюсь тестировщиком компании TravelLine. Мы разрабатываем единую систему для гостиничного предприятия, которая помогает отелям, санаториям и другим средствам размещения автоматизировать свои бизнес-процессы. В этой краткой статье (я бы назвал её отзывом на инструмент) я не буду рассказывать о концепции встреч в формате “3 Амиго”, хочу лишь поделиться личным опытом внедрения таких сессий в процесс разработки требований в одной из своих команд.
В нашей небольшой, но амбициозной команде процесс работы над новой фичей был четко структурирован. Он был рожден из необходимости быстро и качественно доставлять ценность, а начинался он с фундамента — технического задания (ТЗ), которое наш проектный менеджер (ПМ), в виду отсутствия в команде системного аналитика, кропотливо готовил, аккумулируя все пожелания бизнеса и превращая их в план действий. Этот документ был отправной точкой для всех членов команды.
Наш воркфлоу выглядел следующим образом:
Подготовка ТЗ. (этап 1)
Параллельная работа экспертов → Тестировщик анализировал требования на полноту и тестопригодность, разработчик оценивал техническую реализацию, дизайнер начинал разработку пользовательского интерфейса, а технический писатель готовил тексты. (этапы 2-3)
Первая синхронизация (Демо макетов) → Вся команда собиралась, чтобы обсудить визуальную часть, технические нюансы и зависимости. (этап 4)
Финальное согласование → После правок (если таковые были) макеты утверждали. (этап 5)
Планирование работ. (этап 6)
Несмотря на четкость схемы, мой опыт и наблюдения как тестировщика выявили в ней системный риск. Ключевая проблема была заложена в самом принципе параллельной работы.
Получив ТЗ, три ключевых участника — разработчик, тестировщик и дизайнер — начинали работать независимо, по сути, в информационном вакууме друг относительно друга, а ведь у каждого из нас — свой профессиональный бэкграунд, свой фокус внимания и свои ментальные модели. В результате одно и то же требование могло быть интерпретировано совершенно по-разному.
Отсутствие коммуникации на этом раннем этапе лишало нас возможности обмениваться критически важными мнениями и знаниями. Мы двигались по параллельным дорогам, и к моменту первой общей встречи (этап 4 — демо макетов) наши интерпретации уже успевали “закостенеть”, что приводило к переделкам, потере темпа и, что главное, к риску создать нерабочий продукт.
Стало очевидно, что нам не хватает точки ранней синхронизации — момента, где мы не просто получаем задачу, а совместно погружаемся в её контекст, делясь своими профессиональными взглядами до того, как каждый пойдет своим маршрутом.
Именно так у меня родилась идея внедрить в наш отлаженный процесс короткие, но, как мне казалось, крайне эффективные сессии в формате “Три Амиго”.
Цель была не в том, чтобы критиковать чью-то работу или ломать существующий порядок, а в том, чтобы усилить его, добавив слой коллективного интеллекта.
Как мы выстроили свою работу над формированием требований в формате “Три 4 Амиго”:
Начальная формулировка требований: ПМ собирает и документирует основные требования, основываясь на потребностях бизнеса и пользователей.
Сессия "3 Амиго": ПМ, разработчик, тестировщик и дизайнер собираются вместе, чтобы обсудить эти требования. Цель — убедиться, что все стороны понимают их одинаково и выявить потенциальные проблемы или неясности. Это также хорошее время для обсуждения возможных технических решений и тестовых сценариев.
Уточнение и детализация требований: на основе обсуждений в рамках "Три Амиго" требования могут быть уточнены и дополнены, чтобы учесть все выявленные аспекты.
Я отвечал за фасилитацию встреч и документирование принятых решений в Confluence, обеспечивая единый источник правды для всех участников.
Что на самом деле изменилось?
Если посмотреть на процесс с высоты, может показаться, что мы просто добавили еще одну встречу. Но суть глубже. Мы не отменили параллельную работу — мы подняли её на новый уровень. Раньше три эксперта работали рядом, но не вместе. Мы выполняли этапы параллельно, но в информационном вакууме, как три независимых конвейера. Теперь же мы объединили эти этапы в одну интенсивную сессию коллаборации. Вместо того чтобы неделю идти параллельными курсами, чтобы потом обнаружить расхождение в 100 километр��в, мы за 30 минут совместного обсуждения сверяем наши карты и намечаем один общий маршрут.
А был ли эффект? Измеряем успех
Внедряя любую новую практику, важно понимать, работает ли она. Я оценивал успех “3 Амиго” по двум ключевым параметрам: количество багов в процессе тестирования фичи и их критичность, а также субъективное ощущение команды.
Статистика по багам для разрабатываемой фичи была следующая:
Low - 4 шт.
Normal - 3 шт.
Medium - 2 шт.
High - 4 шт.
Вряд ли это можно считать “непреложными” количественными метриками для прямого измерения эффективности, но качественные метрики (субъективное ощущение команды) показали, что внедрение сессий в формате 3 Амиго продемонстрировало положительные результаты. По результатам опроса участников, получены исключительно положительные отзывы, подтверждающие ценность совместного обсуждения требований на ранних этапах. Отсутствие блокирующих багов на этапе тестирования фичи считаю значимым успехом, что свидетельствует о снижении рисков и повышении качества разрабатываемого продукта.
отсутствие блокеров + положительный отзыв = успех
В отличие от Git, где можно "откатить" изменения до коммита “начало разработки фичи” и переделать функциональность по-другому, человеческая жизнь не позволяет вернуться назад и изменить уже принятые нами решения. Например, нельзя пересмотреть этап проработки требований и не проводить встречи "Трех Амиго". А было бы интересно сравнить, как разработка одной и той же фичи прошла бы с этими встречами и без них, чтобы увидеть разницу в подходах.
Нужно ли это вашей команде?
Сессии в формате “3 Амиго” это лишь инструмент, который может сработать в вашей команде, а может лишь усложнить вам жизнь. Конкретно в моем случае данный опыт оказался положительным. Подобные встречи еще полезны и тем, что можно узнать много нового о разрабатываемой фиче, а ведь то, что мы узнаём сегодня, отразится в более мощных тестах завтра.*
*Джеймс Бах, Джем Кейнер, Бретт Петтикорд “Тестирование программного обеспечения: контекстно-ориентированный подход.”
