Шаринг экспертизы

Подводные камни

Критерии приёмки

Все понимают зачем задача?

Фиксировать вопросы/замечания в процессе

Диалог, а не презентация

Кто будет заниматься?

main trainer - область

На дейлике

Тестирование документации - практика

чатик 3 амиго ~3amigo

Бизнес-аналитики определяют, какие фичи нужно создать. Разработчики создают их. Тестировщики находят дефекты в работе обоих. Так работает традиционный подход к разработке. Но ведь можно научить этих троих сотрудничать, чтоб делать свою работу лучше и сразу, без дополнительных переделок. И этот способ коммуникации называется 3 Амиго. Также его называют Story Kick Off Huddles или Триада.

3 Амиго — это практика, которая дает всеобщее понимание того, что будет доставлено клиенту. Помогает доносить голос команды, а не переплетение разрозненных мнений.

Данный способ коммуникации внутри команды помогает:

• прийти к общему соглашению относительно ожиданий до начала разработки

• сформировать соглашение о том, как сделать правильную вещь сразу

А также, способствует пониманию:

• какую проблему мы решаем

• какие есть варианты решения

• что нам нужно сделать, чтобы задача была готова

Бизнес-аналитик или Product Owner

Представитель бизнеса знает (почти всегда), что он хочет получить в итоге и какое value от этого получит клиент и бизнес. Важно рассказывать об этом команде.

Участвуя во встрече 3 Амиго, бизнес-аналитик делится информацией с участниками, чтобы у всех в команде было одинаковое понимание и ожидание от пользовательской истории. Также только он может ограничить scope приемочных критериев, по которым потом будет происходить приемка.

Разработчики

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

Тестировщик

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

Встреча

На встречу 3-х Амиго команда уже приходит подготовленная. У них уже имеется провалидированная user story

Так как в спринт вы берете уже готовые к работе истории, то встречу 3 Амиго по истории нужно провести до планирования.

В критериях приемки не должны находиться детали реализации.

Оптимальное время для проведения встречи 3-х Амиго — от 30 мин до 1 часа.

По очереди проработка:

1. USER — Что пользователь хочет сделать с системой?

2. SYSTEM — Что должна делать система?

3. RISKS — Какие проблемы могут возникнуть?

Все комментарии и вопросы, которые возникают при проверке требований фиксировать письменно и добиваться, чтобы были даны ответы и требования были исправлены так, чтобы они не вызывали комментариев или вопросов.

Какой результат на выходе встречи 3 Амиго?

• сценарии/примеры (очевидные ответы)

• уточненные правила/критерии приемки

• новые/декомпозированные истории

• общее понимание проблемной области

• эмпатия (сопереживание, участие)

Вот ещё несколько бонусов:

• При планировании не тратим много времени на погружение в смысл истории.

• Выявляет путаницу и недопонимание на ранней стадии, что позволяет ускорить доставку

• Гарантирует, что команда, обсудит необходимый объем работы

• Помогает найти все критерии приемки и другие атрибуты качества

• Разрабатывать по тест-кейсам значительно легче

• Провоцируем разработчиков на покрытие кода тестами

• Быстрее приходим к выводу, что эта фича не нужна

Подводные камни

• Не ограничивайтесь только тремя людьми.

• Не проводите встречу на всю команду.

• Не регулярное собрание — это не ритуал.