Menu

Zasada 3 Amigo w Agile: BA, Developer i QA Three Amigos

  • Główny
  • Inny
  • Zasada 3 Amigo w Agile: BA, Developer i QA Three Amigos

3 amigo principle agile

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wprowadzenie do 3 Zasady Amigo:

wyodrębnij adresy e-mail ze strony internetowej za darmo

Wcześniej w serii Scrum przedstawiliśmy wam koncepcję bring samowystarczalność członków Zespołu Scrumowego wzbudzać kulturę wytwarzającą wartość biznesową bez konieczności pomocy ze strony świata zewnętrznego.

Ostatnio dostosowałem się do projektu klienta, w którym pracowałem jako Scrum Master. Pracując w wielu projektach opartych na Scrumie, udało mi się z powodzeniem połączyć metodologię ze sposobami pracy Klienta.

Jednak po pewnym czasie znaleziono wiele niejasności związanych z wymogiem zrozumienia.

Każdy członek zespołu Scrum ma swoją własną wersję zrozumienia wymagań!

Zasada 3 przyjaciół

Czego się nauczysz:

Przegląd

Co by się stało, gdyby programiści i kontrolerzy mieli dwie różne perspektywy tego samego wymagania?

Oczywistym sposobem postępowania w tym przypadku będzie to, że Deweloperzy opracowaliby Przyrost, mając na uwadze ich perspektywę, podczas gdy testerzy testowaliby go, mając na uwadze własną perspektywę.

Obie perspektywy tworzą lukę, a problemy są rozwiązywane dopiero pod koniec Sprintu. Jeszcze najgorszym przypadkiem byłoby, gdyby nie zostało czasu na rozwiązanie tych problemów w ramach Sprintu, w wyniku czego możemy dodać dodatkowe elementy do Backlogu Produktu.

Aby rozwiązać powyższe stwierdzenie problemu, wymyśliliśmy rozwiązanie polegające na przeprowadzaniu większej liczby sesji dyskusji na temat wymagań wśród członków zespołu w celu analizy i burzy mózgów nad wymaganiami jako całością. I stąd idea zasady trzech amigo wyszła na jaw.

Zanim przejdziemy do zasady trzech amigo, omówmy najpierw jedną z praktyk testowania zwinnego, najpierw testowanie (TFD) i jej związek z trzema Amigo.

Testuj pierwsze opracowanie (TFD)

Jak sama nazwa wskazuje, Test First Development to praktyka, w której przypadki testowe są pisane przez Inżynierów Testów przed jakąkolwiek czynnością programistyczną.

Te przypadki testowe są następnie omawiane i udostępniane całemu zespołowi. Członkowie zespołu biorą teraz udział w spotkaniu w celu omówienia, ulepszenia i przeglądu przypadków testowych (zwanych również „Trzech Amigos”). Przypadki brzegowe są również dodawane do listy przypadków testowych podczas tego spotkania.

Możemy również dołączyć Właściciela Produktu do dodawania i przeglądu przypadków testowych, co pozwoliłoby na uzyskanie pewności, że przypadki testowe spełniają Kryteria akceptacji.

Teraz, gdy przypadki testowe zostały opracowane, cały program będzie oparty na tych przypadkach testowych. Zjawisko to jest również znane jako cykl testowania i budowania. W ramach cyklu budowania testów buduj, dopóki wszystkie przypadki testowe nie zostaną zaliczone, nie pozostawiając miejsca na istnienie błędów w systemie.

Program Test-First Development umożliwia programistom zbudowanie przyrostu, który spełnia kryteria akceptacji i ma poparcie właściciela produktu (głos klienta).

Obecnie zespoły zaczęły przyjmować podejście i framework Test Driven Development (TDD), który jest kolejnym krokiem do Test First Development. Narzędzia takie jak Cucumber, Gauge, Specflow itp. Należą do najpopularniejszych.

Zasada trzech Amigo

Kim są trzej Amigos?

trzech przyjaciół

Zasada trzech Amigo mówi, że trzech Amigo; Analityk biznesowy, programiści i analitycy jakości powinni spotkać się na spotkaniu, na którym:

  • Analityk biznesowy szczegółowo omawia z zespołem każde z wymagań biznesowych.
  • Członkowie Zespołu Zapewnienia Jakości omawiają przypadki testowe już utworzone dla tych wymagań biznesowych.
  • Członkowie zespołu deweloperskiego omawiają z zespołem architekturę i projekt niskopoziomowy.

Celem trzech spotkań Amigo jest wypełnienie luk w zrozumieniu Specyfikacji Biznesu przez trzech Amigo.

Analityk biznesowy upewnia się, że wszyscy w zespole mają takie samo zrozumienie i oczekiwania dotyczące historii użytkownika / wymagań biznesowych. Analityk biznesowy zbiera opinie i przegląda komentarze członków zespołu. Dodaje również brakujące informacje i usuwa niejednoznaczne informacje z historii użytkownika, jeśli takie istnieją.

Ponieważ stan oprogramowania jest zawsze mierzony za pomocą jego standardów wysokiej jakości, zespół zapewniania jakości opracowuje funkcjonalne i niefunkcjonalne aspekty przyrostu oprogramowania i szczegółowo określa przypadki testowe zidentyfikowane w celu przetestowania Przyrostu. Upewniają się również, że wszystkie kryteria akceptacji są spełnione przez przypadki testowe.

Pozostali członkowie zespołu pomagają we wzbogacaniu przypadków testowych, znajdując przypadki skrajne i brakujące scenariusze. Członkowie zespołu deweloperskiego podzielą się swoją wiedzą o ograniczeniach technicznych, które mogą prowadzić do ograniczeń testowych.

pytania i odpowiedzi na rozmowę z narzędziem szefa kuchni

Deweloperzy omawiają swoje zrozumienie wymagań i tego, co jest potrzebne do zbudowania Przyrostu. Omówiliby także z zespołem układ architektury i projekt niskiego poziomu, aby wypracować wspólne zrozumienie tego, co ma zostać zbudowane.

Ogólny wynik sesji Three Amigo jest taki, że cały zespół ma wspólne zrozumienie tego, co zamierza zbudować w ramach następnego sprintu.

Trzy procesy Amigo

Proces Three Amigo składa się z poniższych:

# 1) Uczestnicy

Po jednym przedstawicielu z Zespołu Deweloperskiego i Zespołu Zapewnienia Jakości oraz analityka biznesowego. Sugeruje się, aby mieli tych przedstawicieli, osoby, które faktycznie będą pracować nad tym wymogiem, aby wykorzystać maksymalne korzyści z koncepcji. Inni, tacy jak architekci itp., Są zawsze mile widziani, aby dołączyć do spotkania i udzielić wskazówek.

# 2) Osie czasu

Trzy sesje Amigo są zwykle przeprowadzane w N-1 Sprint. Jest to również wydarzenie ograniczone czasowo, tj. Nie można ich przedłużyć. Zalecany przedział czasu na sesję to 1 godzina, co jest jednocześnie maksymalnym czasem trwania.

Jeśli funkcja ma być rozwijana w Sprincie N. W takim przypadku zdecydowanie zaleca się przeprowadzenie sesji Three Amigo w Sprincie N-1 lub N-2.

# 3) Format

# 1) Spotkanie rozpoczyna się od przedstawienia przez analityka biznesowego wymagań uczestnikom wraz z dokumentami projektowymi lub makietami. Oczekuje się, że wymóg biznesowy będzie dobrze przygotowany i udokumentowany. Oczekuje się, że zespół spełnił wymagania jeszcze przed spotkaniem.

# 2) W kolejnym kroku uczestnicy zapoznają się z wymaganiami i przekażą informacje zwrotne, które zostaną później uwzględnione przez analityka biznesowego. Uczestnicy zwrócą również uwagę na niejasności i ewentualne braki. Oczekuje się również, że analityk biznesowy usunie niejasności i wypełni luki w wymaganiu.

Czasami mogą wystąpić sytuacje, w których analityk biznesowy może potrzebować potwierdzenia zapytań przesłanych przez innych uczestników i nie może bezpośrednio uwzględnić tam tej recenzji.

# 3) Gdy wymagania zostaną dostatecznie przygotowane, a uczestnicy nie będą już mieli więcej informacji zwrotnych ani pytań otwartych, wymaganie zostanie oznaczone jako „Gotowe”.

# 4) Następnie przypadki testowe są przedstawiane Uczestnikom, podobnie jak wymagania. Oczekuje się, że przypadki testowe będą już dobrze sformułowane i przygotowane.

# 5) Uczestnicy będą teraz przeglądać przypadki testowe i przekazywać opinie. Członek kontroli jakości uwzględni wszystkie podane sugestie. Uczestnicy wskazywali również na pominięte przypadki testowe i scenariusze skrajnych przypadków. Głównym celem pozostaje tutaj to, aby przypadki testowe spełniały wszystkie kryteria akceptacji i miały dobre pokrycie testowe.

# 6) Następnym krokiem jest przyjrzenie się zależnościom i wymaganiom wstępnym, które mogły pojawić się podczas sesji.

jak sflashować bios windows 10

# 7) Zależności są określane, a elementy akcji są tworzone i przypisywane do odpowiedniego członka zespołu. Podobnie tworzone i przypisywane są zadania dla wymagań wstępnych.

# 8) Wszystkie artefakty (wymagania, przypadki testowe, zadania, zależności) wymienione powyżej powinny być przechowywane w narzędziu do zarządzania projektami, takim jak JIRA, aby każdy miał do nich łatwy dostęp.

# 9) Jeśli jest zbyt wiele komentarzy do recenzji, analityk biznesowy i inżynier ds. Zapewnienia jakości mogą zdecydować się na ich uwzględnienie po sesji.

Wniosek

W tym samouczku przedstawiliśmy koncepcję Zasada trzech Amigo co okazało się bardzo korzystne w dostarczaniu właściwego rozwiązania w szybszym tempie z silnymi pętlami sprzężenia zwrotnego.

Trzy sesje Amigo nie pozostawiają miejsca na inne zrozumienie tego samego wymagania. Celem spotkania jest zebranie wszystkich informacji na tej samej stronie, a następnie umożliwienie im zaakceptowania wymagań przed przejściem do fazy rozwoju.

Jeśli już pracujesz w Agile Framework, gorąco polecam wypróbowanie kilku sesji The Three Amigo i samodzielne obserwowanie zmiany.

Nasz nadchodzący samouczek wyjaśni więcej o Scaled Agile Framework!

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^