«Три Аміго» — це техніка колаборативного уточнення беклогу, яка використовується в гнучкій розробці продуктів для уточнення користувацьких історій та забезпечення спільного розуміння історій або вимог серед усіх членів команди.
Хоча «Три Аміго» не є офіційною концепцією в Agile, цей термін відноситься до трьох ролей або компетенцій Agile, які беруть участь у співпраці. Хоча склад учасників не є фіксованим, для нас це зазвичай:
- Бізнес-аналітик або власник продукту.
- Розробник.
- Тестувальник
Звичайно, ми не завжди дотримуємося цього, оскільки іноді нам може знадобитися залучити інших членів команди, таких як UX-дизайнер, архітектор рішень тощо. Зазвичай ми зустрічаємося під час сесії планування спринту, щоб переглянути користувацькі історії та забезпечити розуміння між усіма членами команди. Ми також зустрічаємося під час огляду спринту, щоб переконатися, що користувацькі історії були успішно виконані.
Якщо вам цікаво — так, це практично те саме, що стартові зустрічі по сторі або Тріада. Якщо ви вже це робите і це працює для вашої команди, то, мабуть, немає потреби заглиблюватися в цю тему.
Як працює «Три Аміго»?
Ось кроки, які ми використовуємо, коли «Три Аміго» є частиною нашого робочого процесу:
Визначте Трьох Аміго: Спочатку вам необхідно узгодити ролі осіб, які братимуть участь у співпраці. Це не обов’язково має бути фіксованим.
Заплануйте зустріч «Трьох Аміго»: Потім ми призначаємо фіксований час для зустрічі «Трьох друзів» з метою обговорення користувацьких історій або вимог.
Підготуйте користувацькі історії: як бізнес-аналітик, разом із продакт оунером, ми підготуємо користувацькі історії до наради.
Зустріч «Три Аміго»: Під час зустрічі ми переглядаємо користувацькі історії та ставимо уточнюючі запитання. Ми також обговорюємо можливі проблеми, які можуть виникнути в процесі розробки.
Подальші дії: Після наради (або під час неї) продакт оунер або я оновимо користувацькі історії з будь-якими змінами чи уточненнями, які були зроблені під час наради.
Зустріч Трьох Аміго
Нижче наведено детальні кроки для наших зустрічей «три аміго». Послідовність подій не є фіксованою, тому ви можете змінювати її відповідно до потреб вашого проєкту та команди:
- Як бізнес-аналітик, я зазвичай представляю учасникам сесії користувацькі історії разом із будь-якими проєктними документами.
- Потім учасники переглядають вимоги та надають відгуки, які згодом будуть враховані бізнес-аналітиком. Тут виявляються неоднозначності та прогалини, які мені потрібно уточнити або передати бізнесу.
- Після того як команда достатньо переглянула та зрозуміла історію, я позначаю її як «Готово».
- Потім тестувальник представляє свої тест-кейси для перегляду та надання відгуків усіма учасниками. На цьому етапі команда також прагне узгодити тест-кейси з критеріями приймання, щоб забезпечити належне покриття бізнес-вимог. Тут також можуть бути визначені граничні випадки.
- Далі розробник або розробники піднімають та обговорюють питання архітектури та проектування, якщо такі є.
- Наступним кроком є виявлення всіх залежностей та передумов, які можуть вплинути на вимоги. Для їх дослідження створюються завдання для виконання.
- Залежності визначаються, а завдання для виконання створюються та призначаються відповідному члену команди. Аналогічно, завдання для передумов також створюються та призначаються.
Залежності визначено, а завдання створено та призначено відповідним членам команди. Так само створено та призначено завдання для попередніх вимог.
Як «Троє Аміго» допомогли мені в моїй роботі:
Спільне розуміння: техніка «Три Аміго» допомагає забезпечити спільне розуміння користувацьких історій або вимог усіма членами команди.
Покращена комунікація: техніка «Три Аміго» заохочує співпрацю між продакт оунером, бізнес-аналітиком, розробником і тестувальником, що може покращити комунікацію та зменшити кількість непорозумінь.
Підвищення ефективності: техніка «Три Аміго» може допомогти зменшити обсяг повторної роботи та підвищити ефективність завдяки виявленню потенційних проблем на ранніх етапах процесу розробки.
Деякі проблеми, які я спостерігав із «Трьома аміго»:
Витратний за часом: Техніка «Три Аміго» може бути витратною за часом, особливо якщо є велика кількість користувацьких історій для розгляду.
Обмежена перспектива: Техніка «Три Аміго» спирається на точку зору продакт оунера, розробника та тестувальника. Інші точки зору, наприклад, кінцевих користувачів, можуть залишатися поза увагою.
Обмежена гнучкість: техніка «Три Аміго» може бути менш гнучкою порівняно з іншими методами співпраці, оскільки вона вимагає участі певного набору ролей.
Інші способи перегляду історій
Як бізнес-аналітик, що працює у сфері розробки продукту, ми не зобов’язані використовувати техніку «Три Аміго» для перегляду користувацьких історій із розробниками. «Три Аміго» — це лише одна з технік, яку можна використовувати для забезпечення спільного розуміння вимог усіма учасниками.
Наша основна відповідальність полягає в тому, щоб забезпечити точне відображення потреб зацікавлених сторін у користувацьких історіях і відповідність їх критеріям прийнятності. Досягти цієї мети можна за допомогою різноманітних інших технік, і вам слід обирати ту техніку, яка найкраще відповідає потребам вашої команди та проєкту, над яким ви працюєте.
Однак я іноді знаходив це дуже корисним для забезпечення спільного розуміння користувацьких історій командою. Це може допомогти виявити потенційні проблеми на ранніх етапах процесу розробки та знизити ризик непорозумінь.
Чи справді мені потрібно використовувати «Трьох Аміго»?
Якщо ви вирішите використовувати техніку «Три Аміго», вам слід працювати з командою розробників, щоб переконатися, що кожен розуміє мету техніки, а також ролі та обов’язки кожного члена команди. Також слід бути готовими скоригувати техніку або використовувати альтернативні підходи, якщо вона не працює ефективно для вашої команди. Як і більшість аспектів гнучкого підходу до роботи, ключовим є збереження гнучкості та адаптація вашого підходу за потреби, щоб досягти найкращих результатів для вашої команди та вашого проєкту.
Техніка «Три Аміго» — це лише один із підходів до перегляду користувацьких історій разом з розробниками. Існують інші техніки, які можна використовувати для досягнення тієї ж мети, і найкращий підхід залежатиме від потреб вашої команди та конкретного проєкту, над яким ви працюєте.
Ось кілька альтернативних технік і заходів, які можуть виявитися корисними для уточнення історій та забезпечення спільного розуміння:
Огляд спринту: Під час огляду спринту продакт оунер або бізнес-аналітик представляє завершені користувацькі історії команді розробників. Команда може ставити запитання та надавати відгуки щодо користувацьких історій, що допомагає виявити будь-які проблеми або непорозуміння.
Розробка на основі приймальних тестів (ATDD): У підході ATDD продакт оунер або Бізнес-аналітик співпрацює з командою розробників для створення автоматизованих приймальних тестів на основі користувацьких історій. Команда розробників потім пише код, який відповідає вимогам приймальних тестів. Цей підхід може допомогти забезпечити відповідність коду вимогам користувацьких історій.
Розробка на основі поведінки (BDD): У BDD продакт оунер або Бізнес-аналітик і команда розробників співпрацюють для створення користувацьких історій, які включають конкретні приклади того, як користувач взаємодіє з програмним забезпеченням. Потім команда розробників пише код, який відповідає цим прикладам. Такий підхід може допомогти забезпечити відповідність коду вимогам користувацьких історій та його роботу відповідно до очікувань.
Зрештою, найкращий підхід до перегляду користувацьких історій з розробниками залежатиме від потреб вашої команди та конкретного проєкту, над яким ви працюєте. Важливо бути гнучким і готовим випробовувати різні підходи, поки не знайдете той, який найкраще підходить для вашої команди.
Обі Нвокеді
Оригінальна стаття — BA techniques — The Three Amigos від Obi Nwokedi, переклад та ревью — Іван Вільчавський. Зображення з оригінальної статті.