Меню

Принцип 3 Amigo в Agile: BA, розробник та QA Three Amigos

3 amigo principle agile

Спробуйте Наш Інструмент Для Усунення Проблем

Вступ до принципу 3 Amigo:

засоби автоматизації тестування веб-додатків

Раніше в серії Scrum ми познайомили вас з концепцією приведення самодостатність членів Scrum Team стимулювати культуру, що приносить ділову цінність, не вимагаючи допомоги з боку зовнішнього світу.

Нещодавно я приєднався до проекту клієнта, де я працював майстром Scrum. Працюючи в декількох проектах на основі Scrum, я зміг поєднати методологію із способами роботи Клієнта.

Однак через певний проміжок часу навколо вимоги розуміння було виявлено багато невизначеності.

Кожен член команди Scrum має власну версію розуміння вимог!

3 принципу друга

Що ви дізнаєтесь:

Огляд

Що станеться, якщо розробники та QA мають дві різні точки зору на одну і ту ж вимогу?

Очевидним шляхом у цьому випадку буде те, що Розробники розроблять Інкремент, враховуючи свою перспективу, тоді як тестувальники тестують його, пам’ятаючи про свою власну перспективу.

Ці дві перспективи, як правило, створюють прогалину, і тоді проблеми вирішуються лише до кінця Спринту. Ще гіршим випадком буде, якщо не залишиться часу для вирішення цих питань у рамках Sprint, який приземлить нас у ситуації, коли ми додамо додаткові елементи до відставання товару.

Для того, щоб вирішити вищезазначене твердження про проблему, ми придумали рішення щодо проведення більше обговорень вимог серед членів групи для аналізу та обговорення вимог у цілому. І отже, ідея Принципу трьох аміго з’явилася на світ.

Перш ніж переходити до Принципу трьох аміго, давайте спочатку обговоримо одну з Практик швидкого тестування, Тестування першої розробки (TFD) та те, як це пов'язано з трьома аміго.

Тест першої розробки (TFD)

Як випливає з назви, Test First Development - це практика, коли тестові кейси пишуться інженерами-випробувачами перед будь-якою розробкою.

Потім ці тестові випадки обговорюються та передаються всій команді. Члени команди тепер беруть участь у зустрічі для обговорення, вдосконалення та перегляду тестових випадків (їх також називають «Три аміго»). Крайові справи також додаються до списку тестових випадків під час цієї зустрічі.

Ми також можемо включити Власника продукту для додавання та перегляду тестових випадків, що створить впевненість у тому, що тестові кейси відповідають Критеріям прийнятності.

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

Розробка Test-First дозволяє розробникам створити приріст, який відповідає Критеріям прийнятності та має бай-ін від Власника продукту (голос Замовника).

На сьогоднішній день команди почали застосовувати підхід та основи тестового розвитку (TDD), що є наступним кроком до тестування першої розробки. Такі інструменти, як Огірок, Датчик, Спекфлоу тощо, є одними з найпопулярніших.

Принцип трьох аміго

Хто такі три Аміго?

троє друзів

Три Принципи Аміго говорять, що три Аміго; Бізнес-аналітики, розробники та аналітики якості повинні зібратися на зустрічі, де:

  • Бізнес-аналітик детально визначає з командою кожну з бізнес-вимог.
  • Члени групи з контролю якості обговорюють тестові кейси, уже створені для цих бізнес-вимог.
  • Члени групи розробників обговорюють з командою архітектуру та дизайн низького рівня.

Метою трьох зустрічей Amigo є подолання прогалин у розумінні Бізнес-специфікацій трьома Amigos.

Бізнес-аналітик стежить за тим, щоб усі в команді мали однакове розуміння та очікування щодо історії / вимоги бізнес-користувачів. Бізнес-аналітик збирає відгуки та переглядає коментарі від членів команди. Він / Вона також додає відсутні дані та видаляє неоднозначну інформацію з історії користувачів, якщо така є.

Оскільки працездатність програмного забезпечення завжди вимірюється за його високоякісними стандартами, команда із забезпечення якості детально вивчає функціональні та нефункціональні аспекти приросту програмного забезпечення та деталізує тестові випадки, визначені для перевірки приросту. Вони також переконуються, що тестові випадки відповідають усім критеріям прийнятності.

Інші члени команди допомагають збагатити тестові кейси, знаходячи крайні випадки та відсутні сценарії. Члени Групи розробників поділяться своїми технічними обмеженнями щодо знань, які можуть призвести до обмежень тестування.

як викликати масив в Java - -

Розробники обговорюють своє розуміння вимог і те, що потрібно для побудови Інкременту. Вони також обговорюватимуть з командою схему архітектури та дизайн низького рівня, щоб сформувати загальне розуміння того, що буде будуватися.

Загальний результат сесії 'Три Еміго' полягає в тому, що вся команда має єдине розуміння того, що вона збирається побудувати в рамках наступного спринту.

Процес трьох аміго

Процес трьох аміго складає наступне:

# 1) Учасники

По одному представнику від команди розробників та групи забезпечення якості та бізнес-аналітика. Пропонується мати цих представників, людей, які насправді збираються працювати над цією вимогою, щоб максимально використати концепцію. Інші, такі як архітектори тощо, завжди можуть приєднатися до зустрічі та надати свої вказівки.

# 2) Графіки

Три сеанси Amigo зазвичай проводяться в спринті N-1. Це також подія, приурочена до часу, тобто їх не можна продовжити. Рекомендований час для сеансу - 1 година, що також є його максимальною тривалістю.

Якщо функцію слід розробляти в Sprint N. Тоді настійно рекомендується провести сесію Three Amigo у N-1 або N-2 Sprint.

# 3) Формат

# 1) Зустріч починається з того, що бізнес-аналітик представляє учасникам вимогу разом із проектною документацією або каркасними рамками. Очікується, що вимоги до бізнесу будуть добре підготовлені та задокументовані. Очікується, що команда виконала вимогу вже до наради.

# 2) Наступним кроком учасники розглянуть вимогу та нададуть відгуки, які згодом будуть включені бізнес-аналітиком. Присутні також вкажуть на неоднозначності та прогалини, якщо такі є. Також очікується, що бізнес-аналітик усуне неоднозначності та заповнить прогалини у вимозі.

Іноді можуть траплятися ситуації, коли бізнес-аналітику може знадобитися підтвердити запити, розміщені іншими учасниками, і не може безпосередньо включати цей огляд там.

# 3) Як тільки вимога буде достатньо доглянута, а учасники більше не матимуть відгуків чи відкритих питань, вимога буде позначена як „Готова”.

# 4) Далі тестові кейси представляються учасникам, як і вимоги. Очікується, що тестові кейси вже будуть добре сформовані та підготовлені.

# 5) Учасники тепер будуть переглядати тестові кейси та надавати відгуки. Член контролю якості враховуватиме всі запропоновані пропозиції. Учасники також вказуватимуть на пропущені тестові випадки та крайові сценарії. Основною метою тут залишається те, що тестові кейси повинні відповідати всім Критеріям прийнятності та мати гарне охоплення тестами.

# 6) Наступним кроком є ​​розгляд залежностей та передумов, які могли виникнути під час сесії.

найкращий блокувальник спливаючих оголошень для chrome -

# 7) Визначаються залежності та створюються елементи дій, які призначаються відповідному члену команди. Подібним чином створюються та призначаються завдання для попередніх вимог.

№8) Усі згадані вище артефакти (Вимоги, Тестові кейси, завдання, залежності) слід зберігати в Інструменті управління проектами, як JIRA, щоб кожен міг легко отримати до них доступ.

№9) Якщо коментарів до огляду занадто багато, бізнес-аналітик та інженер із забезпечення якості можуть вирішити включити їх після сесії.

Висновок

У цьому підручнику ми познайомили вас з поняттям Принцип трьох аміго що виявилося дуже корисним для швидшого надання правильного рішення із сильними петлями зворотного зв'язку.

Три сеанси Amigo не залишають місця для того, щоб по-різному розуміти одну і ту ж вимогу. Мета зустрічі - привести всіх на одну сторінку, а потім дозволити їм прийняти вимогу, перш ніж переходити до фази розвитку.

Якщо ви вже працюєте в Agile Framework, то я настійно рекомендую спробувати провести пару сесій «Три аміго» та спостерігати за змінами на власні очі.

У нашому підручнику буде розказано більше про Scaled agile framework!

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^