Меню

Принципът 3 Amigo в Agile: BA, Developer и QA Three Amigos

3 amigo principle agile

Опитайте Нашия Инструмент За Премахване На Проблемите

Въведение в 3 принципа Amigo:

фази на жизнения цикъл на развитието на системата с примери

Преди това в серията Scrum ви запознахме с концепцията за носене самодостатъчност в рамките на членовете на Scrum Team да предизвика културата, произвеждаща бизнес стойност, без да се изисква каквато и да е помощ от външния свят.

Напоследък бях съгласуван с клиентски проект, където работех като Scrum Master. След като работех в множество проекти, базирани на Scrum, успях успешно да съчетая методологията с начина на работа на клиента.

След определен период от време обаче се откри много неяснота около изискването за разбиране.

Всеки член на екипа на Scrum има своя собствена версия на разбирането за изискванията!

3 приятелски принцип

Какво ще научите:

Общ преглед

Какво би се случило, ако разработчиците и QA имат две различни перспективи на едно и също изискване?

Очевидният начин на действие в този случай ще бъде, че разработчиците ще разработят инкремента, имайки предвид перспективата си, докато тестерите ще го тестват, като имат предвид собствената си перспектива.

Двете перспективи са склонни да създават празнина и проблемите след това се разглеждат едва към края на Спринта. Дори най-лошият случай би бил, ако не остане време за решаване на тези проблеми в рамките на Sprint, което ни приземи в ситуация да добавим допълнителни елементи в Product Backlog.

За да разрешим горното изявление на проблема, ние излязохме с решение за провеждане на повече дискусионни сесии сред членовете на екипа, за да анализираме и обмислим изискванията като цяло. И оттук на бял свят излезе идеята за Принципа на трите амиго.

Преди да преминем към Принципа на Трите Амиго, нека първо да обсъдим една от Agile Testing Practices, Test First Development (TFD) и как тя е свързана с Трите Amigos.

Тествайте първо развитие (TFD)

Както подсказва самото име, Test First Development е практика, при която тестовите случаи се пишат от тестовите инженери преди каквато и да е разработка.

След това тези тестови случаи се обсъждат и споделят в целия екип. Сега членовете на екипа участват в среща, за да обсъдят, подобрят и прегледат тестовите случаи (наричани още „Трите амиго“). Крайните случаи също се добавят към списъка с тестови случаи по време на тази среща.

Можем също да включим Собственика на продукта, за да добавим и прегледаме тестовите случаи, което би изградило увереност, че тестовите случаи отговарят на критериите за приемане.

Сега, когато тестовите случаи са разработени, цялото развитие ще се основава на тези тестови случаи. Това явление е известно още като цикъл на изграждане на тест. В рамките на цикъл на изграждане на тестове, изграждайте, докато не бъдат преминати всички тестови случаи, не оставяйки място за грешки в системата.

Програмата Test-First позволява на разработчиците да създадат приращение, което отговаря на критериите за приемане и има бай-ин от собственика на продукта (глас на клиента).

В днешно време екипите започнаха да възприемат подхода и рамката на Test Driven Development (TDD), което е следващата стъпка към Test First Development. Инструменти като Краставица, Измервателен уред, Specflow и др. Са сред най-популярните.

Принципът на трите амиго

Кои са тримата Амиго?

трима приятели

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

  • Бизнес анализаторът подробно описва всяко от бизнес изискванията с екипа.
  • Членовете на екипа за осигуряване на качеството обсъждат тестовите случаи, които вече са създадени за тези бизнес изисквания.
  • Членовете на екипа за разработки обсъждат с екипа архитектурата и дизайна на ниско ниво.

Целта на трите срещи Amigo е да се преодолеят пропуските в разбирането на бизнес спецификациите от три Amigos.

Бизнес анализаторът гарантира, че всички в екипа имат същото разбиране и очаквания от историята / изискването на бизнес потребителя. Бизнес анализаторът събира отзивите и преглежда коментарите от членовете на екипа. Той / тя също добавя липсващата информация и премахва неясната информация от Потребителската история, ако има такава.

Тъй като здравето на софтуера винаги се измерва чрез неговите висококачествени стандарти, екипът за осигуряване на качеството разработва функционалните и нефункционалните аспекти на нарастването на софтуера и детайлизира тестовите случаи, идентифицирани за тестване на увеличението. Те също така се уверяват, че всички критерии за приемане са изпълнени от тестовите случаи.

Останалите членове на екипа помагат за обогатяването на тестовите случаи, като намират крайни случаи и липсващи сценарии. Членовете на екипа за разработка ще споделят своите технически ограничения на знанията, които биха могли да доведат до ограничения за тестване.

как да разархивирате 7z файлове на

Разработчиците обсъждат разбирането си за изискванията и какво е необходимо, за да се изгради приращението. Те също така ще обсъдят с екипа архитектурно оформление и дизайн на ниско ниво, за да формират общо разбиране за това, което ще се изгради.

Общият резултат от сесията на Three Amigo е, че целият отбор има общо разбиране за това какво ще изгради като част от следващия спринт.

Процес на три амиго

Процесът на трите амиго съставлява следното:

# 1) Участници

Един представител от екипа за разработка и екипа за осигуряване на качеството и всеки бизнес анализатор. Препоръчва се тези представители, хората, които всъщност ще работят по това изискване, да се възползват максимално от ползата от концепцията. Други като архитекти и т.н. винаги са добре дошли да се присъединят към срещата и да дадат своите насоки.

# 2) Срокове

Три сесии Amigo обикновено се провеждат в N-1 Sprint. Това също е събитие с време, т.е. не могат да бъдат удължени. Препоръчителното време за сесията е 1 час, което е и максималната му продължителност.

Ако функцията ще бъде разработена в Sprint N. Тогава е силно препоръчително да проведете сесията Three Amigo в N-1 или N-2 Sprint.

# 3) Формат

# 1) Срещата започва с бизнес анализатор, който представя изискванията на присъстващите заедно с проектните документи или каркасите. Очаква се бизнес изискването да бъде добре подготвено и документирано. Очаква се от екипа да е преминал през изискването още преди срещата.

# 2) Като следваща стъпка присъстващите ще прегледат изискването и ще предоставят обратна връзка, която по-късно ще бъде включена от бизнес анализатора. Присъстващите също ще посочат неяснотите и пропуските, ако има такива. Очаква се бизнес анализаторът също така да премахне неяснотите и да попълни пропуските в изискването.

Понякога може да има ситуации, при които бизнес анализаторът може да се наложи да потвърди заявки, публикувани от останалите присъстващи, и да не може да включи директно този преглед там.

# 3) След като изискването бъде достатъчно добре обработено и присъстващите вече нямат обратна връзка или отворени въпроси, изискването се отбелязва като „Готово“.

# 4) След това тестовите случаи се представят на присъстващите точно като изискванията. Очаква се тестовите случаи да бъдат добре оформени и подготвени вече.

# 5) Присъстващите сега ще преглеждат тестовите случаи и ще предоставят обратна връзка. Членът на QA ще включи всички предоставени предложения. Присъстващите също ще посочат пропуснатите тестови случаи и сценариите на крайните случаи. Основната цел тук остава, че тестовите случаи трябва да отговарят на всички критерии за приемане и да имат добро покритие на теста.

# 6) Следващата стъпка е да разгледаме зависимостите и предварителните условия, които може да са излезли по време на сесията.

конвертирате множество видеоклипове в YouTube в mp3

# 7) Зависимостите се определят и елементите за действие се създават и присвояват на съответния член на екипа. По същия начин се създават и възлагат задачите за предварителни условия.

# 8) Всички споменати по-горе артефакти (Изисквания, Тестови случаи, задачи, зависимости) трябва да се съхраняват в Инструмент за управление на проекти като JIRA, така че всеки да може лесно да има достъп до тях.

# 9) Ако има твърде много коментари за преглед, бизнес анализаторът и инженерът по осигуряване на качеството могат да изберат да ги включат след сесията.

Заключение

В този урок ви запознахме с концепцията за Принципът на трите амиго което се оказа много полезно за доставяне на правилното решение с по-бързи темпове със силни вериги за обратна връзка.

Трите сесии Amigo не оставят място за различно разбиране на едно и също изискване. Целта на срещата е да привлече всички на една и съща страница и след това да им позволи да приемат изискването, преди да преминат към фазата на развитие.

Ако вече работите в Agile Framework, тогава силно препоръчвам да опитате и да проведете няколко сесии The Three Amigo и да наблюдавате промяната сами.

Нашият предстоящ урок ще обясни повече за Scaled agile framework!

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^