Menu

Het 3 Amigo-principe in Agile: BA, Developer en QA Three Amigos

  • Hoofd
  • Andere
  • Het 3 Amigo-principe in Agile: BA, Developer en QA Three Amigos

3 amigo principle agile

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Inleiding tot het 3 Amigo-principe:

SQL server interviewvragen en antwoorden voor ervaren pdf

Eerder in de Scrum-serie hebben we u kennis laten maken met het concept van brengen zelfredzaamheid binnen de Scrum Teamleden om een ​​cultuur te creëren die zakelijke waarde produceert zonder hulp van de buitenwereld.

De laatste tijd was ik afgestemd op een klantproject waar ik werkte als een Scrum Master. Na in meerdere op Scrum gebaseerde projecten te hebben gewerkt, was ik in staat om de methodologie met succes te combineren met de manier van werken van de klant.

Na een bepaalde tijd werd er echter veel vaagheid gevonden rond de vereiste van begrip.

Elk Scrum-teamlid heeft zijn eigen versie van het vereiste begrip!

3 vriendenprincipe

Wat je leert:

Overzicht

Wat zou er gebeuren als de ontwikkelaars en de QA's twee verschillende perspectieven hebben op dezelfde vereiste?

De voor de hand liggende manier van handelen, in dit geval, zal zijn dat de ontwikkelaars het increment zouden ontwikkelen met hun perspectief in gedachten, terwijl de testers het zouden testen met hun eigen perspectief in gedachten.

De twee perspectieven hebben de neiging om een ​​gat te creëren en problemen worden dan pas tegen het einde van de Sprint aangepakt. Een nog ergste geval zou zijn als er geen tijd overblijft om deze problemen binnen de Sprint aan te pakken, waardoor we in een situatie terechtkomen om extra items toe te voegen aan een Product Backlog.

Om de bovenstaande probleemstelling op te lossen, hebben we een oplossing bedacht om meer discussiesessies tussen de teamleden te houden om de vereisten als geheel te analyseren en erover te brainstormen. En zo kwam het idee van het Three Amigo Principle aan het licht.

Voordat we verder gaan met het Three Amigo-principe, bespreken we eerst een van de Agile Testing Practices, Test First Development (TFD) en hoe het wordt geassocieerd met The Three Amigos.

Test First Development (TFD)

Zoals de naam zelf suggereert, is Test First Development een praktijk waarbij de testcases worden geschreven door de Test Engineers voorafgaand aan elke ontwikkelingsactiviteit.

Deze testcases worden vervolgens besproken en gedeeld met het hele team. De teamleden komen nu in een vergadering om de testcases (ook wel ‘The Three Amigos’ genoemd) te bespreken, te verbeteren en te beoordelen. Tijdens deze bijeenkomst worden ook de edge cases toegevoegd aan de lijst met Testcases.

We kunnen ook de Product Owner erbij betrekken om de testcases toe te voegen en te beoordelen, waardoor het vertrouwen ontstaat dat de testcases voldoen aan de Acceptatiecriteria.

Nu de testcases zijn ontwikkeld, zou de hele ontwikkeling op deze testcases zijn gebaseerd. Dit fenomeen wordt ook wel de test-build-cyclus genoemd. Bouw binnen een test build-cyclus totdat alle testcases zijn doorstaan ​​en laat geen ruimte over voor bugs in het systeem.

De Test-First Development stelt de ontwikkelaars in staat om een ​​increment te bouwen dat voldoet aan de acceptatiecriteria en een buy-in heeft van de Product Owner (stem van de klant).

Tegenwoordig zijn de teams begonnen met het toepassen van de Test Driven Development (TDD) -benadering en -kader, wat de volgende stap is naar Test First Development. Tools zoals Cucumber, Gauge, Specflow etc. behoren tot de meest populaire.

Het Three Amigo-principe

Wie zijn de drie Amigo's?

drie vrienden

Het drie Amigo-principe zegt dat de drie Amigo's; Bedrijfsanalisten, ontwikkelaars en kwaliteitsanalisten moeten samenkomen in een vergadering waar:

  • De bedrijfsanalist legt elk van de bedrijfsvereisten met het team uit.
  • De leden van het kwaliteitsborgingsteam bespreken de testcases die al voor deze zakelijke vereisten zijn gemaakt.
  • De leden van het Development Team bespreken met het team de architectuur en het low-level design.

Het doel van de drie Amigo-bijeenkomsten is om de hiaten in het begrip van de Business Specificaties door drie Amigo's te dichten.

De Business Analist zorgt ervoor dat iedereen in het team hetzelfde begrip en dezelfde verwachting heeft van het Business User Story / Requirement. De Business Analist verzamelt de feedback en beoordelingen van opmerkingen van de teamleden. Hij / zij voegt ook de ontbrekende informatie toe en verwijdert de dubbelzinnige informatie uit het gebruikersverhaal, indien aanwezig.

Aangezien de gezondheid van de software altijd wordt gemeten aan de hand van de hoge kwaliteitsnormen, gaat het kwaliteitsborgingsteam dieper in op de functionele en niet-functionele aspecten van de softwarestap en geeft het de testcases weer die zijn geïdentificeerd om het increment te testen. Ze zorgen er ook voor dat aan alle acceptatiecriteria wordt voldaan door de testgevallen.

De andere teamleden helpen bij het verrijken van de testcases door edge cases en ontbrekende scenario's te vinden. De leden van het Ontwikkelteam delen hun kennis over technische beperkingen die kunnen leiden tot testbeperkingen.

waarom linux beter is dan windows

De ontwikkelaars bespreken hun begrip van de vereisten en wat er nodig is om het Increment te bouwen. Ze zouden ook de architectuurlay-out en low-level design met het team bespreken om een ​​gemeenschappelijk begrip te krijgen van wat er gebouwd gaat worden.

Het algemene resultaat van de Three Amigo-sessie is dat het hele team een ​​gemeenschappelijk begrip heeft van wat ze gaan bouwen als onderdeel van de volgende sprint.

Drie Amigo-proces

Het Three Amigo-proces bestaat uit het onderstaande:

# 1) Deelnemers

Elk één vertegenwoordiger van het Development Team en Quality Assurance Team en de Business Analyst. Er wordt voorgesteld om deze vertegenwoordigers te hebben, de mensen die daadwerkelijk aan die vereiste gaan werken om het maximale voordeel van het concept te benutten. Anderen zoals architecten enz. Zijn altijd welkom om de vergadering bij te wonen en hen te begeleiden.

# 2) Tijdlijnen

Drie Amigo-sessies worden meestal uitgevoerd in N-1 Sprint. Het is ook een getimed boxed-evenement, d.w.z. ze kunnen niet worden verlengd. Het aanbevolen tijdvak voor de sessie is 1 uur, wat ook de maximale duur is.

Als de functie moet worden ontwikkeld in Sprint N. Dan wordt het sterk aanbevolen om de Three Amigo-sessie in N-1 of N-2 Sprint uit te voeren.

# 3) Formaat

# 1) De vergadering begint met de Business Analist die de vereisten presenteert aan de aanwezigen, samen met de ontwerpdocumenten of wireframes. Er wordt verwacht dat de zakelijke eis goed is voorbereid en gedocumenteerd. Van het team wordt verwacht dat het de eis al voor de bijeenkomst heeft doorlopen.

# 2) Als een volgende stap zullen de aanwezigen de vereiste herzien en feedback geven die later door de Business Analist zal worden opgenomen. De aanwezigen zullen ook wijzen op eventuele onduidelijkheden en hiaten. Van de Business Analist wordt ook verwacht dat hij de onduidelijkheden wegneemt en de hiaten in de vereiste opvult.

Soms kunnen er situaties zijn waarin de bedrijfsanalist vragen die door de andere bezoekers zijn geplaatst, moet bevestigen en die recensie daar zelf niet direct in opneemt.

# 3) Zodra de vereiste voldoende is geprepareerd en de bezoekers geen feedback of open vragen meer hebben, wordt de vereiste gemarkeerd als ‘Klaar’.

# 4) Vervolgens worden de testcases aan de aanwezigen gepresenteerd, net als de vereisten. Van testcases wordt verwacht dat ze al goed zijn gevormd en voorbereid.

# 5) De aanwezigen zullen nu de testcases beoordelen en feedback geven. Het QA-lid zal alle verstrekte suggesties opnemen. De aanwezigen zouden ook wijzen op de gemiste testcases en de edge case-scenario's. Het belangrijkste doel hierbij blijft dat de testgevallen aan alle acceptatiecriteria voldoen en een goede testdekking hebben.

# 6) De volgende stap is om te kijken naar de afhankelijkheden en vereisten die tijdens de sessie naar voren zijn gekomen.

hoe het array-element in java te verwijderen

# 7) De afhankelijkheden worden bepaald en de actie-items worden gemaakt en toegewezen aan het relevante teamlid. Evenzo worden de taken voor eerste vereisten gemaakt en toegewezen.

# 8) Alle artefacten (vereiste, testgevallen, taken, afhankelijkheden) die hierboven zijn genoemd, moeten in een projectmanagementtool zoals JIRA worden bewaard, zodat iedereen er gemakkelijk toegang toe heeft.

# 9) Als er te veel reviewopmerkingen zijn, kunnen de Business Analist en de Quality Assurance Engineer ervoor kiezen om deze na de sessie op te nemen.

Gevolgtrekking

In deze tutorial hebben we je kennis laten maken met het concept van Het Three Amigo-principe wat zeer gunstig is gebleken voor het leveren van de juiste oplossing in een sneller tempo met sterke feedbackloops.

De drie Amigo-sessies laten geen ruimte voor een ander begrip van dezelfde vereiste. Het doel van de bijeenkomst is om iedereen op dezelfde pagina te brengen en ze vervolgens de vereiste te laten accepteren voordat ze doorgaan naar de ontwikkelingsfase.

Als je al in het Agile Framework werkt, zou ik je ten zeerste aanraden om een ​​paar The Three Amigo Session's te proberen en de verandering zelf te observeren.

Onze aanstaande tutorial zal meer uitleggen over Scaled agile framework!

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^