Meny

The 3 Amigo Principle in Agile: BA, Developer og QA Three Amigos

  • Hoved
  • Annen
  • The 3 Amigo Principle in Agile: BA, Developer og QA Three Amigos

3 amigo principle agile

Prøv Instrumentet Vårt For Å Eliminere Problemer

Introduksjon til 3 Amigo-prinsipp:

hvilket av følgende er banen til ‘ta et skjermbilde’ -knapp?

Tidligere i Scrum Series introduserte vi deg med konseptet med å bringe selvforsyning innen Scrum Team-medlemmene å indusere kulturen som produserer forretningsverdi uten å kreve hjelp fra omverdenen.

I det siste ble jeg tilpasset et klientprosjekt der jeg jobbet som Scrum Master. Etter å ha jobbet i flere Scrum-baserte prosjekter, klarte jeg å blande metodikken i klientens arbeidsmåter.

Imidlertid, etter en bestemt periode, ble det funnet mye uklarhet rundt kravet om forståelse.

Hvert Scrum Team-medlem har sin egen versjon av Kravforståelsen!

3 venn prinsipp

Hva du vil lære:

Oversikt

Hva ville skje hvis utviklerne og kvalitetssikringene har to forskjellige perspektiver av det samme kravet?

Det åpenbare handlingsforløpet, i dette tilfellet, vil være at utviklerne vil utvikle inkrementet med tanke på perspektivet, mens testerne vil teste det med tanke på deres eget perspektiv.

De to perspektivene har en tendens til å skape et gap, og problemstillinger blir da adressert bare mot slutten av Sprint. Et enda verste tilfelle ville være om det ikke er tid igjen til å løse disse problemene i Sprint og komme oss i en situasjon for å legge til flere artikler i et produktetterslep.

For å løse den ovennevnte problemstilling, kom vi med en løsning for å ha flere diskusjonsøkter mellom teammedlemmene for å analysere og brainstorme kravene som helhet. Og derav kom ideen om Three Amigo Principle fram.

Før vi hopper videre til Three Amigo-prinsippet, la oss først diskutere en av Agile Testing Practices, Test First Development (TFD) og hvordan den er forbundet med The Three Amigos.

Test første utvikling (TFD)

Som navnet selv antyder, er Test First Development en praksis der testsakene er skrevet av testingeniørene før noen utviklingsaktivitet.

Disse testtilfellene blir deretter diskutert og delt på tvers av hele teamet. Teammedlemmene kommer nå inn på et møte for å diskutere, forbedre og gjennomgå testtilfellene (også referert til som 'The Three Amigos'). Randsakene blir også lagt til i listen over testsaker under dette møtet.

Vi kan også inkludere produkteieren for å legge til og gjennomgå testtilfellene, noe som vil skape en tillit til at testtilfellene oppfyller akseptkriteriene.

Nå som testsakene er utviklet, vil hele utviklingen være basert på disse testsakene. Dette fenomenet er også kjent som test-build-syklusen. Innen en testbyggingssyklus, bygg til alle testtilfellene er bestått, og la ikke plass til at det finnes feil i systemet.

Test-First-utviklingen lar utviklerne bygge et trinn som oppfyller godkjennelseskriteriene og har et innkjøp fra produkteieren (kundens stemme).

I dag har lagene begynt å ta i bruk TDD-tilnærmingen og rammeverket Test Driven Development, som er neste trinn for å teste First Development. Verktøy som Agurk, Gauge, Specflow etc. er blant de mest populære.

The Three Amigo Principle

Hvem er de tre Amigos?

tre venner

De tre Amigo-prinsippene sier at de tre Amigos; Forretningsanalytiker, utviklere og kvalitetsanalytikere bør komme sammen i et møte der:

  • Forretningsanalytikeren beskriver hvert av forretningskravene med teamet.
  • Medlemmene av kvalitetssikringsteamet diskuterer testtilfellene som allerede er opprettet for disse forretningskravene.
  • Medlemmene av utviklingsteamet diskuterer arkitekturen og lavt nivå design med teamet.

Målet med de tre Amigo-møtene er å bygge bro over hullene i forståelsen av forretningsspesifikasjonene fra tre Amigos.

Forretningsanalytikeren sørger for at alle i teamet har samme forståelse og forventning fra forretningsbrukerhistorien / kravet. Forretningsanalytikeren samler inn tilbakemeldinger og gjennomgår kommentarer fra teammedlemmene. Han / hun legger også til den manglende informasjonen og fjerner den tvetydige informasjonen fra brukerhistorien, hvis noen.

Siden helsen til programvaren alltid måles av de høye kvalitetsstandardene, utdyper kvalitetssikringsteamet de funksjonelle og ikke-funksjonelle aspektene ved programvaretilskuddet og beskriver testtilfellene som er identifisert for å teste trinnet. De sørger også for at alle akseptkriteriene blir oppfylt av testsakene.

De andre teammedlemmene hjelper til med å berike testsakene ved å finne kantsaker og manglende scenarier. Medlemmene av utviklingsteamet vil dele sin kunnskap tekniske restriksjoner som kan føre til testbegrensninger.

hvordan du kan vise .eps-filer

Utviklerne diskuterer deres forståelse av kravene og hva som skal til for å bygge Increment. De vil også diskutere arkitekturoppsettet og lavt nivå design med teamet for å danne en felles forståelse av hva som skal bygges.

Det samlede resultatet av Three Amigo-økten er at hele teamet har en felles forståelse av hva de skal bygge som en del av neste sprint.

Tre Amigo-prosesser

Three Amigo-prosessen utgjør følgende:

# 1) Deltakere

Én representant fra utviklingsteamet og kvalitetssikringsteamet hver og forretningsanalytikeren. Det foreslås å ha disse representantene, menneskene som faktisk skal jobbe med dette kravet for å utnytte maksimal nytte av konseptet. Andre som arkitekter osv. Er alltid velkommen til å delta på møtet og gi veiledning.

# 2) Tidslinjer

Tre Amigo-økter gjennomføres vanligvis i N-1 Sprint. Det er også en tidsbestemt boksbegivenhet, dvs. de kan ikke utvides. Den anbefalte tidsboksen for økten er 1 time, som også er den maksimale varigheten.

Hvis funksjonen skal utvikles i Sprint N., anbefales det sterkt å gjennomføre Three Amigo-økten i N-1 eller N-2 Sprint.

# 3) Format

# 1) Møtet starter med at forretningsanalytikeren presenterer kravet til deltakerne sammen med designdokumentene eller trådrammene. Forretningskravet forventes å være godt forberedt og dokumentert. Det forventes at teamet har gått gjennom kravet allerede før møtet.

# 2) Som et neste trinn vil deltakerne gjennomgå kravet og gi tilbakemelding som senere vil bli innlemmet av forretningsanalytikeren. Deltakerne vil også påpeke tvetydighetene og eventuelle hull. Forretningsanalytikeren forventes også å fjerne uklarhetene og fylle ut hullene i kravet.

Noen ganger kan det være situasjoner der forretningsanalytikeren kan trenge å bekrefte spørsmål som er lagt ut av de andre deltakerne og kanskje ikke direkte innlemme den anmeldelsen der.

# 3) Når kravet er preparert nok og deltakerne ikke har flere tilbakemeldinger eller åpne spørsmål, er kravet merket som 'Klar'.

# 4) Deretter blir testsakene presentert for deltakerne akkurat som kravene. Test tilfeller forventes å være godt utformet og forberedt allerede.

# 5) Deltakerne vil nå gjennomgå prøvesakene og gi tilbakemelding. QA-medlemmet vil ta med alle forslagene som er gitt. Deltakerne vil også peke på tapte testsaker og edge case-scenarier. Hovedmålet her er fortsatt at testsakene skal oppfylle alle akseptkriteriene og ha god testdekning.

# 6) Neste trinn er å se på avhengighetene og forutsetningene som kan ha kommet ut i løpet av økten.

verdens beste programvare for hacking av datamaskiner gratis nedlasting

# 7) Avhengighet bestemmes og handlingselementene opprettes og tildeles det relevante teammedlemmet. På samme måte blir oppgavene for forutsetninger opprettet og tildelt.

# 8) Alle gjenstandene (krav, testtilfeller, oppgaver, avhengigheter) som er nevnt ovenfor, bør oppbevares i et prosjektstyringsverktøy som JIRA, slik at alle enkelt kan få tilgang til dem.

# 9) Hvis det er for mange kommentarer, kan forretningsanalytikeren og kvalitetssikringsingeniøren velge å innlemme dem etter økten.

Konklusjon

I denne veiledningen introduserte vi deg for begrepet The Three Amigo Principle som har vist seg å være veldig gunstig for å levere riktig løsning i raskere tempo med sterke tilbakemeldingsløkker.

De tre Amigo-øktene gir ikke rom for å ha en annen forståelse av det samme kravet. Målet med møtet er å bringe alle på samme side og deretter la dem godta kravet før de hopper videre til utviklingsfasen.

Hvis du allerede jobber i Agile Framework, vil jeg anbefale å prøve å ha et par The Three Amigo Session og observere endringen selv.

Vår kommende veiledning vil forklare mer om Scaled agile framework!

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^