Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?
Или потому что требования были неоднозначно сформулированы, и он их неправильно понял. А может наоборот, в них было так много информации, что потерялся фокус и некоторая часть информации пропала из виду во время разработки.
И в этой ситуации разработчик не является вредителем, который специально ошибся. На практике, если предоставить ему простые, понятные и, главное, — короткие требования — то количество ошибок, которые будут находить тестировщики, устремится к нулю.
Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.
Я считаю, что все такие задачи, заведенные после релиза, и являющиеся следствием плохо проработанной спецификации, — тоже баги. Баги, которые характеризуют качество вашего продукта.
Получается, бизнес-аналитики определяют, какие фичи нужно создать. Разработчики создают их. Тестировщики находят дефекты в работе обоих. Так работает традиционный подход к разработке. Но ведь можно научить этих троих сотрудничать, чтоб делать свою работу лучше и сразу, без дополнительных переделок. И этот способ коммуникации называется 3 Амиго. Также его называют Story Kick Off Huddles или Триада.
3 Амиго — это практика, которая дает всеобщее понимание того, что будет доставлено клиенту. Помогает доносить голос команды, а не переплетение разрозненных мнений.
Данный способ коммуникации внутри команды помогает:
А также, способствует пониманию:
Встреча трёх амиго — это способ совместного мышления, которое устраняет пробелы в понимании бизнес-спецификаций. Она помогает в разработке крутых пользовательских историй.
Цель заключается в том, чтобы делать работу в срок, но при этом планировать не настолько заранее, чтобы детали успевали устаревать.
Название практики не ограничивает нас тремя контекстами, а лишь создаёт минимальные рамки. Чтобы убедиться в том, что в проработке требований учли все технические нюансы, явные и неявные случаи, что спецификация отражает действительную нужду клиента — требуется 3 различных мышления/контекста: бизнеса, разработчика, тестировщика. При этом встреча не ограничивается только этими людьми. В ней участвуют все, кто вовлечены в реализацию требования. Например, если в вашей задаче есть не только web, но и mobile, то нужен дополнительный контекст. То есть тот человек, который будет делать реализацию в мобильном приложении. В наших командах чаще всего во встрече участвуют 4 разработчика (1 ios, 1 android, 1 back, 1 front), тестировщик и бизнес-аналитик.
Представитель бизнеса знает (почти всегда), что он хочет получить в итоге и какое value от этого получит клиент и бизнес. Важно рассказывать об этом команде.
Участвуя во встрече 3 Амиго, бизнес-аналитик делится информацией с участниками, чтобы у всех в команде было одинаковое понимание и ожидание от пользовательской истории. Также только он может ограничить scope приемочных критериев, по которым потом будет происходить приемка.
Разработчик знает, как реализовать требование от бизнеса, какие есть для этого возможности. Как правило, он думает о деталях, которые ему нужно знать, чтобы приступить к реализации. Задавая вопросы, исходя из своего опыта и знания системы, разработчик помогает вскрывать различные нюансы еще на этапе обсуждения требований.
Тестировщик, так же, как и другие члены команды, помогает обогащать требования различными тестовыми случаями. Исходя из своего опыта, он больше и чаще подвергает сомнению любые утверждения, которые озвучивает команда. Поэтому лучше находит крайние случаи, неявные сценарии, задается вопросом, что может пойти не так, чего следует остерегаться.
Я редко встречала процесс разработки, где в явной форме присутствовало тестирование требований. В большинстве случаев, требования начинали изучать на этапе разработки или тестирования, и только тогда вскрывались какие-то нестыковки.
Непротестированная спецификация — это с большой вероятностью неоднозначные, противоречивые, неполные, продублированные и иногда даже устаревшие требования.Это происходит потому, что каждый понимает прочтенное и услышанное по-своему. Отсюда и возникает расхождения в интерпретации.
А если документация большая и подробная, то ее чтение может занять больше времени, чем сам процесс тестирования или разработки.
В нашей бизнес-линии мы решили применять эту практику, когда задачи стали задерживаться в тестировании. Мы выделили 3 основные проблемы:
Вот и выходит, что несмотря на agile разработку, все-равно присутствует этап работы с технической спецификацией. И если не учли какие-то случаи, потому что о них не сказал заказчик, или же сделали не то, что на самом деле он имел в виду, после выхода на прод, в backlog подваливает куча задач по доработке или даже переделке.
Ну и напоследок стоит озвучить и проблему с оценкой.
Сложно оценить задачу, когда ты на самом деле не понимаешь весь объем работы, который предстоит по ней проделать. Какое количество тестов написать, сколько будет возвратов из-за багов или переделок из-за неточностей спецификации? Даже если разработчик даст точную оценку по самому времени разработки, практически никогда вы не угадаете, сколько времени займет тот самый непредсказуемый этап тестирования.
Я рекомендую применять прорабатывать требования, основываясь на пользовательских историях. И в качестве основы брать одну историю и на встрече 3 амиго прорабатывать только ее.
Здесь очень важный момент в том, чтобы требование от бизнеса действительно было сформулировано как пользовательская история. То есть соддержала в себе 3 части, а именно:
Я как <роль>, хочу <действие>, чтобы <мотивация>
Это на самом деле самый популярный шаблон для формирования пользовательских историй и называется Connextra. Есть также и другие шаблоны, но я рекомендую использовать именно этот. А почему, сейчас объясню.
Традиционно есть 2 проблемы при формировании user story:
Это на самом деле влечет проблемы, и я постараюсь на простых примерах объяснить какие.
Но формулирование в вышеописанном формате не является обязательным условием. Я знаю команды, которые проводят встречи в формате 3 Амиго и без user story. А в качестве основы используют ТЗ. В этом случае возникают свои подводные камни, но это был осознанный выбор команды.
Встреча 3 Амиго начинается с подготовки. В рамках подготовке к ней формулируются требования, так чтоб они были понятны всей команде. Эти требования валидируются на готовность к работе.
Валидация включает в себя оценку истории по критериям INVEST. А также качество формулировки самой истории. Тут исключается любая неоднозначность, многословность и при оценке по INVEST, особенное внимание обращается на размер истории. Если команда понимает, что требование представляет из себя epic, то происходит декомпозиция.
После того, как требование прошло этап трансформирования в user story и валидацию со стороны команды (3 амиго), можно приступать к проработке acceptance criteria.
Для начала нужно определиться, а чем же все-таки являются критерии приемки.
Итак, критерии приёмки (acceptance criteria) — это требования от заказчика; спецификация по которой может быть проверена система/user story.
У них есть альтернативное название, conditions of satisfaction — условия удовлетворения ожиданий (автор Майк Кон).
На встречу 3-х Амиго команда уже приходит подготовленная. У них уже имеется провалидированная user story, которая возможно уже даже обладает каким-то набором критериев приемки, которые представитель бизнеса сформулировал самостоятельно.
Во время встречи, задачи участников дополнить/обогатить историю достаточным количеством критериев приемки для ее последующей реализации.
В критериях приемки не должны находиться детали реализации. Фактически, критерии приемки — это бизнес-правила, которым подчиняется прорабатываемая пользовательская история. Детали же реализации фиксируются в приемочных тестах, но после того, как все критерии приемки были сформулированы.
Смешивать детали реализации с критериями приемки не стоит еще хотя бы потому, что при ограниченных сроках, вы как команда всегда можете "выкинуть" какой-то scope критериев, который в ближайший момент не так важны бизнесу. При наличие деталей с технической реализацией в критериях — вы рискуете потерять важную информацию и время, которое уже было потрачено на обсуждение деталей реализации. Ваши детали реализации напрямую зависят от scope критериев, которые вам надо сделать.
Также избегайте последовательного описания сценария с набором шагов (классическая система ведения тест-кейсов). Любое ваше утверждение должно быть атомарным. Лучше использовать описательный стиль ожидаемого поведения создаваемой функции.
Например:
*Когда пользователь заходит в карточку сотрудника, то видит пустые поля ввода.*>
Хорошо декомпозированная US как правило не содержит в себе больше 10 acceptance criteria. Если в процессе обсуждения обнаруживается большое количество acceptance criteria и все они подлежат реализации, то тогда эту историю необходимо декомпозировать на несколько историй с разным пулом acceptance criteria.
Если этого не сделать, то встреча 3 Амиго будет сильно затягиваться.
Оптимальное время для проведения встречи 3-х Амиго — от 30 мин до 1 часа.
Допустимо увеличение в самом начале пути — когда команда только учится общаться и применять эту практику.
Если команда берет в работу большую историю, то маловероятно, что за один сеанс они смогут проработать все критерии и приемочные тесты. Потому что теряется фокус и внимательность. В этом случае нужно разбить сессию на несколько встреч. Но в данном случае есть риск потери контекста, и может понадобиться дополнительное погружение при повторной встрече.
Когда я обучаю команды данной практике, то рекомендую в самом начале их пути пользоваться эвристиками, чтобы сгладить отсутствие опыта. С опытом у команды появляются свои эвристики и чек-листы на что обращать внимание при проработке критериев.
Эвристика USR позволяет рассмотреть критерии на всех уровнях, которые необходимы, чтоб получить максимум информации о том, что хочет заказчик.
Итак,
Важно сначала проработать все критерии группы USER, и затем только переходить на уровень системы. Тут включаются разработчики фронта и бэкенда, и на уровне своих систем могут сформулировать критерии приемки к тому, что должно получиться, чтобы реализовать критерии из группы USER.
Ну и наконец группа RISK. Про нее чаще всего забывают про проработке требований, хотя она не менее важная. Тут рассматриваются различные сложные кейсы, которые возможно вы не будете реализовывать. Но проговорить и принять риски как команда — обязаны.
Рекомендуемый способ формализации требований — примеры использования, в российском IT мы это называем тест-кейсами.
Есть удобный инструмент проработки тест-кейсов на встрече 3-х Амиго, называется example mapping. В этой статье я вкратце затронула его. В следующей статье мы опубликуем подробную информацию по этому инструменту и как он применяется в рамках встречи триады.
Тест-кейсы могут быть реализованны как автоматизированные приемочные тесты к истории. Также, когда вы прорабатываете тест-кейсы, обязательно группируйте их. Разделение тест-кейсов на группы — это способ поделить историю на несколько более маленьких.
В тест-кейсах декомпозиция бизнес-правила происходит ровно на том системном уровне, на котором они и будут реализовываться, а не со стороны пользователя.
Все детали реализации должны находиться в ваших тест-кейсах, чтобы на них происходила ориентация разработчиков в процессе реализации.
Рекомендуется в рамках одной встречи прорабатывать требования только на одну user story. Допускается больше, при условии, это это совсем маленькие истории или они между собой связаны по смыслу.
Так как в спринт вы берете уже готовые к работе истории, то встречу 3 Амиго по истории нужно провести до планирования. Иначе вы рискуете сильно ошибиться с предварительной оценкой. На практике, оценки истории после встречи 3-х Амиго сильно отличаются от изначальных.
Также, имеет смысл добавить в DOD новый пункт как индикатор готовности, что история готова к работе над ней в спринте.
Например, у нас некоторые команды, которые начали применять эту практику, договорились, что на планировании они не будут брать в спринт, если на задачу нет критериев приемки и приемочных тестов.
А на обзоре спринта приемка истории презентуется по критериям приемки.
Но при этом встреча 3 Амиго также вписывается в процесс, если команда работает и не по скраму, а например использует канбан. В этом случае, задача попадает в разработку только после того как прошла через встречу 3 Амиго.
Основным результатом трех амиго являются приемочные тесты, написанные в формате « Дано / Когда / Тогда». На самом деле их написание может занять больше времени чем хотелось бы, поэтому формализовывать все требования на встрече, когда все вместе находятся, не рекомендуется. Обычно разработчик или тестировщик работают над этим вне встречи. И как только у них есть все критерии и тест-кейсы записаны, 3 Амиго кратко просматривают что получилось, чтобы убедиться, что все согласны с тем, что было записано.
Стратегия 3 Amigos может оказать огромное влияние на эффективность всей команды, а также на качество и поддерживаемость ваших проектов, повышая маневренность, гибкость к изменениям.
Вот ещё несколько бонусов:
Наши команды, применяя практику, смогли прийти к уменьшению возвратов задачи из-за неточной спецификации. Задачи бэкенда ребята научились разрабатывать "с первого раза". То есть без багов и сразу на прод.
7 июня, в Инфопространстве на конференции 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
К сожалению, не доступен сервер mySQL