Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?
Или потому что требования были неоднозначно сформулированы, и он их неправильно понял. А может наоборот, в них было так много информации, что потерялся фокус и некоторая часть информации пропала из виду во время разработки.
И в этой ситуации разработчик не является вредителем, который специально ошибся. На практике, если предоставить ему простые, понятные и, главное, — короткие требования — то количество ошибок, которые будут находить тестировщики, устремится к нулю.
Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.
Я считаю, что все такие задачи, заведенные после релиза, и являющиеся следствием плохо проработанной спецификации, — тоже баги. Баги, которые характеризуют качество вашего продукта.
Получается, бизнес-аналитики определяют, какие фичи нужно создать. Разработчики создают их. Тестировщики находят дефекты в работе обоих. Так работает традиционный подход к разработке. Но ведь можно научить этих троих сотрудничать, чтоб делать свою работу лучше и сразу, без дополнительных переделок. И этот способ коммуникации называется 3 Амиго. Также его называют Story Kick Off Huddles или Триада.
3 Амиго — это...
3 Амиго — это практика, которая дает всеобщее понимание того, что будет доставлено клиенту. Помогает доносить голос команды, а не переплетение разрозненных мнений.
Данный способ коммуникации внутри команды помогает:
- прийти к общему соглашению относительно ожиданий до начала разработки
- сформировать соглашение о том, как сделать правильную вещь сразу
А также, способствует пониманию:
- какую проблему мы решаем
- какие есть варианты решения
- что нам нужно сделать, чтобы задача была готова
Встреча трёх амиго — это способ совместного мышления, которое устраняет пробелы в понимании бизнес-спецификаций. Она помогает в разработке крутых пользовательских историй.
Цель заключается в том, чтобы делать работу в срок, но при этом планировать не настолько заранее, чтобы детали успевали устаревать.
Почему 3? Кем применяется?
Название практики не ограничивает нас тремя контекстами, а лишь создаёт минимальные рамки. Чтобы убедиться в том, что в проработке требований учли все технические нюансы, явные и неявные случаи, что спецификация отражает действительную нужду клиента — требуется 3 различных мышления/контекста: бизнеса, разработчика, тестировщика. При этом встреча не ограничивается только этими людьми. В ней участвуют все, кто вовлечены в реализацию требования. Например, если в вашей задаче есть не только web, но и mobile, то нужен дополнительный контекст. То есть тот человек, который будет делать реализацию в мобильном приложении. В наших командах чаще всего во встрече участвуют 4 разработчика (1 ios, 1 android, 1 back, 1 front), тестировщик и бизнес-аналитик.
Бизнес-аналитик или PO
Представитель бизнеса знает (почти всегда), что он хочет получить в итоге и какое value от этого получит клиент и бизнес. Важно рассказывать об этом команде.
Участвуя во встрече 3 Амиго, бизнес-аналитик делится информацией с участниками, чтобы у всех в команде было одинаковое понимание и ожидание от пользовательской истории. Также только он может ограничить scope приемочных критериев, по которым потом будет происходить приемка.
Разработчики
Разработчик знает, как реализовать требование от бизнеса, какие есть для этого возможности. Как правило, он думает о деталях, которые ему нужно знать, чтобы приступить к реализации. Задавая вопросы, исходя из своего опыта и знания системы, разработчик помогает вскрывать различные нюансы еще на этапе обсуждения требований.
Тестировщик
Тестировщик, так же, как и другие члены команды, помогает обогащать требования различными тестовыми случаями. Исходя из своего опыта, он больше и чаще подвергает сомнению любые утверждения, которые озвучивает команда. Поэтому лучше находит крайние случаи, неявные сценарии, задается вопросом, что может пойти не так, чего следует остерегаться.
Когда применяется практика?
Я редко встречала процесс разработки, где в явной форме присутствовало тестирование требований. В большинстве случаев, требования начинали изучать на этапе разработки или тестирования, и только тогда вскрывались какие-то нестыковки.
Непротестированная спецификация — это с большой вероятностью неоднозначные, противоречивые, неполные, продублированные и иногда даже устаревшие требования.Это происходит потому, что каждый понимает прочтенное и услышанное по-своему. Отсюда и возникает расхождения в интерпретации.
А если документация большая и подробная, то ее чтение может занять больше времени, чем сам процесс тестирования или разработки.
В нашей бизнес-линии мы решили применять эту практику, когда задачи стали задерживаться в тестировании. Мы выделили 3 основные проблемы:
- На этапе тестирования возникало много возвратов из-за уточнения требований. Это были ощутимые паузы в тестировании и разработке, когда бизнес-аналитик определялся с тем, как должно работать.
- Тестирование задачи задерживалось из-за слишком подробной спецификации. Частыми были кейсы, когда тестировщик мог потратить 3-6 часов только на изучение требований и проработку тест-кейсов, а само тестирование происходило минут за 30. А самым вопиющим был случай, когда к тестированию приступили спустя 2 недели изучения спецификации, настолько она была сложная и подробная.
- Ну и самая распространенная проблема была в том, что при приемочном тестировании находилось много багов. Тех багов, которых можно было бы избежать, если бы о них подумали до разработки.
Вот и выходит, что несмотря на agile разработку, все-равно присутствует этап работы с технической спецификацией. И если не учли какие-то случаи, потому что о них не сказал заказчик, или же сделали не то, что на самом деле он имел в виду, после выхода на прод, в backlog подваливает куча задач по доработке или даже переделке.
Ну и напоследок стоит озвучить и проблему с оценкой.
Сложно оценить задачу, когда ты на самом деле не понимаешь весь объем работы, который предстоит по ней проделать. Какое количество тестов написать, сколько будет возвратов из-за багов или переделок из-за неточностей спецификации? Даже если разработчик даст точную оценку по самому времени разработки, практически никогда вы не угадаете, сколько времени займет тот самый непредсказуемый этап тестирования.
Шаги применения практики для проработки AC
1. Формулируем требования как User Story
Я рекомендую применять прорабатывать требования, основываясь на пользовательских историях. И в качестве основы брать одну историю и на встрече 3 амиго прорабатывать только ее.
Здесь очень важный момент в том, чтобы требование от бизнеса действительно было сформулировано как пользовательская история. То есть соддержала в себе 3 части, а именно:
Я как <роль>, хочу <действие>, чтобы <мотивация>
Это на самом деле самый популярный шаблон для формирования пользовательских историй и называется Connextra. Есть также и другие шаблоны, но я рекомендую использовать именно этот. А почему, сейчас объясню.
Традиционно есть 2 проблемы при формировании user story:
- При записи либо не указывают роль, оставляя действие и мотивацию
- Либо же указывют роль и действие, а мотивацию выкидывают.
Это на самом деле влечет проблемы, и я постараюсь на простых примерах объяснить какие.
- Зная <роль>, вы как члены команды будете лучше понимать границы критериев приемки, которые вам нужно сформировать. Не до конца понимания заинтересованное лицо в этой пользовательской истории, вы можете сделать либо сверх нужного, либо наоборот недоделать какую-то функциональность.
- Пример: команда плохо понимала роль в user story, и при проработке задачи решила, что сделает 3 метода для api: на добавление, редактирование и удаление. А еще на фронте добавят кнопки, которая будет вызывать эти методы. Когда они презентовали свое решение бизнесу — то получили фидбек, что на самом деле их клиент, это конкретный бизнес-аналитик, которому достаточно метода добавления. И удалять и редактировать он не будет. Да и вызвать этот метод он может через postman.
- Команда не понимает мотивацию "роли" для кого они делают пользовательскую историю. Из-за непонимания плохо очерчиваются границы самой user story. И помимо этого, критерии приемки в итоге могут и не решать конечную клиентскую проблему, хотя будут соответствовать тому действию, что озвучено в user story.
- Пример: команда взяла в работу user story, где бизнес-аналитик не мог чётко сформулировать мотивацию. С одной стороны, она была в том, чтобы оставить клиента лояльным и сделать для него улучшение. С другой стороны — сокращение расходов для банка. В этом случае способы реализации и критерии приемки были кардинально разными. Потому что в первом случае, команда фокусировалась на пользовательских критериях приемки. Во втором — команда обращала внимание на то, как сделать максимально простую и быструю реализацию.
Но формулирование в вышеописанном формате не является обязательным условием. Я знаю команды, которые проводят встречи в формате 3 Амиго и без user story. А в качестве основы используют ТЗ. В этом случае возникают свои подводные камни, но это был осознанный выбор команды.
Встреча 3 Амиго начинается с подготовки. В рамках подготовке к ней формулируются требования, так чтоб они были понятны всей команде. Эти требования валидируются на готовность к работе.
Валидация включает в себя оценку истории по критериям INVEST. А также качество формулировки самой истории. Тут исключается любая неоднозначность, многословность и при оценке по INVEST, особенное внимание обращается на размер истории. Если команда понимает, что требование представляет из себя epic, то происходит декомпозиция.
После того, как требование прошло этап трансформирования в user story и валидацию со стороны команды (3 амиго), можно приступать к проработке acceptance criteria.
2. Дополняем acceptance criteria к User Story на встрече 3-х Амиго
Для начала нужно определиться, а чем же все-таки являются критерии приемки.
Итак, критерии приёмки (acceptance criteria) — это требования от заказчика; спецификация по которой может быть проверена система/user story.
У них есть альтернативное название, conditions of satisfaction — условия удовлетворения ожиданий (автор Майк Кон).
На встречу 3-х Амиго команда уже приходит подготовленная. У них уже имеется провалидированная user story, которая возможно уже даже обладает каким-то набором критериев приемки, которые представитель бизнеса сформулировал самостоятельно.
Во время встречи, задачи участников дополнить/обогатить историю достаточным количеством критериев приемки для ее последующей реализации.
В критериях приемки не должны находиться детали реализации. Фактически, критерии приемки — это бизнес-правила, которым подчиняется прорабатываемая пользовательская история. Детали же реализации фиксируются в приемочных тестах, но после того, как все критерии приемки были сформулированы.
Смешивать детали реализации с критериями приемки не стоит еще хотя бы потому, что при ограниченных сроках, вы как команда всегда можете "выкинуть" какой-то scope критериев, который в ближайший момент не так важны бизнесу. При наличие деталей с технической реализацией в критериях — вы рискуете потерять важную информацию и время, которое уже было потрачено на обсуждение деталей реализации. Ваши детали реализации напрямую зависят от scope критериев, которые вам надо сделать.
Также избегайте последовательного описания сценария с набором шагов (классическая система ведения тест-кейсов). Любое ваше утверждение должно быть атомарным. Лучше использовать описательный стиль ожидаемого поведения создаваемой функции.
Например:
*Когда пользователь заходит в карточку сотрудника, то видит пустые поля ввода.*> 3. Выдерживаем тайминг
Хорошо декомпозированная US как правило не содержит в себе больше 10 acceptance criteria. Если в процессе обсуждения обнаруживается большое количество acceptance criteria и все они подлежат реализации, то тогда эту историю необходимо декомпозировать на несколько историй с разным пулом acceptance criteria.
Если этого не сделать, то встреча 3 Амиго будет сильно затягиваться.
Оптимальное время для проведения встречи 3-х Амиго — от 30 мин до 1 часа.
Допустимо увеличение в самом начале пути — когда команда только учится общаться и применять эту практику.
Если команда берет в работу большую историю, то маловероятно, что за один сеанс они смогут проработать все критерии и приемочные тесты. Потому что теряется фокус и внимательность. В этом случае нужно разбить сессию на несколько встреч. Но в данном случае есть риск потери контекста, и может понадобиться дополнительное погружение при повторной встрече.
4. Для полноты проработки критериев применяем эвристику USR
Когда я обучаю команды данной практике, то рекомендую в самом начале их пути пользоваться эвристиками, чтобы сгладить отсутствие опыта. С опытом у команды появляются свои эвристики и чек-листы на что обращать внимание при проработке критериев.
Эвристика USR позволяет рассмотреть критерии на всех уровнях, которые необходимы, чтоб получить максимум информации о том, что хочет заказчик.
Итак,
- USER — Что пользователь хочет сделать с системой?
- SYSTEM — Что должна делать система?
- RISKS — Какие проблемы могут возникнуть?
Важно сначала проработать все критерии группы USER, и затем только переходить на уровень системы. Тут включаются разработчики фронта и бэкенда, и на уровне своих систем могут сформулировать критерии приемки к тому, что должно получиться, чтобы реализовать критерии из группы USER.
Ну и наконец группа RISK. Про нее чаще всего забывают про проработке требований, хотя она не менее важная. Тут рассматриваются различные сложные кейсы, которые возможно вы не будете реализовывать. Но проговорить и принять риски как команда — обязаны.
Способы применения практики для проработки тест-кейсов до разработки
Рекомендуемый способ формализации требований — примеры использования, в российском IT мы это называем тест-кейсами.
Есть удобный инструмент проработки тест-кейсов на встрече 3-х Амиго, называется example mapping. В этой статье я вкратце затронула его. В следующей статье мы опубликуем подробную информацию по этому инструменту и как он применяется в рамках встречи триады.
Тест-кейсы могут быть реализованны как автоматизированные приемочные тесты к истории. Также, когда вы прорабатываете тест-кейсы, обязательно группируйте их. Разделение тест-кейсов на группы — это способ поделить историю на несколько более маленьких.
В тест-кейсах декомпозиция бизнес-правила происходит ровно на том системном уровне, на котором они и будут реализовываться, а не со стороны пользователя.
Все детали реализации должны находиться в ваших тест-кейсах, чтобы на них происходила ориентация разработчиков в процессе реализации.
Как это может выглядеть в общем процессе (когда нужно проводить эту встречу)
Рекомендуется в рамках одной встречи прорабатывать требования только на одну user story. Допускается больше, при условии, это это совсем маленькие истории или они между собой связаны по смыслу.
Так как в спринт вы берете уже готовые к работе истории, то встречу 3 Амиго по истории нужно провести до планирования. Иначе вы рискуете сильно ошибиться с предварительной оценкой. На практике, оценки истории после встречи 3-х Амиго сильно отличаются от изначальных.
Также, имеет смысл добавить в DOD новый пункт как индикатор готовности, что история готова к работе над ней в спринте.
Например, у нас некоторые команды, которые начали применять эту практику, договорились, что на планировании они не будут брать в спринт, если на задачу нет критериев приемки и приемочных тестов.
А на обзоре спринта приемка истории презентуется по критериям приемки.
Но при этом встреча 3 Амиго также вписывается в процесс, если команда работает и не по скраму, а например использует канбан. В этом случае, задача попадает в разработку только после того как прошла через встречу 3 Амиго.
Какой результат на выходе встречи 3 Амиго?
- сценарии/примеры (очевидные ответы)
- уточненные правила/критерии приемки
- новые/декомпозированные истории
- общее понимание проблемной области
- эмпатия (сопереживание, участие)
Основным результатом трех амиго являются приемочные тесты, написанные в формате « Дано / Когда / Тогда». На самом деле их написание может занять больше времени чем хотелось бы, поэтому формализовывать все требования на встрече, когда все вместе находятся, не рекомендуется. Обычно разработчик или тестировщик работают над этим вне встречи. И как только у них есть все критерии и тест-кейсы записаны, 3 Амиго кратко просматривают что получилось, чтобы убедиться, что все согласны с тем, что было записано.
Профит использования практики 3-х Амиго
Стратегия 3 Amigos может оказать огромное влияние на эффективность всей команды, а также на качество и поддерживаемость ваших проектов, повышая маневренность, гибкость к изменениям.
Вот ещё несколько бонусов:
- При планировании не тратим много времени на погружение в смысл истории.
- Выявляет путаницу и недопонимание на ранней стадии, что позволяет ускорить доставку
- Гарантирует, что команда, обсудит необходимый объем работы
- Помогает найти все критерии приемки и другие атрибуты качества
- Разрабатывать по тест-кейсам значительно легче
- Провоцируем разработчиков на покрытие кода тестами
- Быстрее приходим к выводу, что эта фича не нужна
Наши команды, применяя практику, смогли прийти к уменьшению возвратов задачи из-за неточной спецификации. Задачи бэкенда ребята научились разрабатывать "с первого раза". То есть без багов и сразу на прод.
Подводные камни
- Не ограничивайтесь только тремя людьми. Если нужно больше — зовем.
- Не проводите встречу на всю команду. В этой встрече должно быть минимально необходимое количество людей для реализации фичи.
- Не рассматривайте как регулярное собрание — ритуал. Иначе у команды будет негатив от увеличения количества встреч.
Мастер-класс на конференции QualityConf
27-28 мая, в рамках фестиваля РИТ++ на конференции QualityConf я проведу мастер-класс по проработке требований с использованием практики 3 Амиго.
Если вас заинтересовал подход и у вас есть вопросы, вы также можете связаться со мной в telegram @Travieso_nastya.
История подхода
Автор подхода: Джордж Динвидди, 2009 год.
Данный подход он описал в своем интервью и упоминал в ряде статей, ссылки на которые я приложила. Также в качестве дополнительного материала приложила все ссылки на англоязычные ресурсы, по которым я данную практику изучала и училась применять.
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos
