Meniu

Principiul 3 Amigo în Agile: BA, Dezvoltator și QA Three Amigos

  • Principal
  • Alte
  • Principiul 3 Amigo în Agile: BA, Dezvoltator și QA Three Amigos

3 amigo principle agile

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Introducere în principiul 3 Amigo:

ce aplicație vă permite să descărcați videoclipuri YouTube

Anterior, în Seria Scrum, v-am prezentat conceptul de a aduce autosuficiență în cadrul membrilor echipei Scrum să inducă cultura producătoare de valoare a afacerii fără a necesita ajutor din partea lumii exterioare.

În ultima vreme, am fost aliniat la un proiect client în care am lucrat ca Scrum Master. După ce am lucrat în mai multe proiecte bazate pe Scrum, am reușit să amestec metodologia în modurile de lucru ale clientului.

Cu toate acestea, după o anumită perioadă de timp, s-a găsit multă vagitate în jurul cerinței de înțelegere.

Fiecare membru al echipei Scrum are propria sa versiune a înțelegerii Cerințelor!

3 principiul prietenului

Ce veți învăța:

Prezentare generală

Ce s-ar întâmpla dacă dezvoltatorii și QA-urile ar avea două perspective diferite ale aceleiași cerințe?

Cursul evident al acțiunii, în acest caz, va fi că dezvoltatorii vor dezvolta Incrementul ținând cont de perspectiva lor, în timp ce testerii ar testa-o ținând cont de propria lor perspectivă.

Cele două perspective tind să creeze un decalaj, iar problemele sunt apoi abordate doar spre sfârșitul Sprintului. Un caz chiar cel mai rău ar fi dacă nu mai rămâne timp pentru a rezolva aceste probleme în cadrul Sprint, ajungându-ne într-o situație de a adăuga articole suplimentare într-un Backlog de produse.

Pentru a rezolva afirmația problemă de mai sus, am venit cu o soluție pentru a avea mai multe sesiuni de discuții privind cerințele între membrii echipei pentru a analiza și a face brainstorming asupra cerințelor în ansamblu. Și de aici a apărut ideea Principiului Trei Amigo.

Înainte de a trece la Principiul Trei Amigo, haideți să discutăm mai întâi una dintre practicile de testare agile, Test First Development (TFD) și cum este asociat cu cei Trei Amigo.

Test First Development (TFD)

După cum sugerează și numele, Test First Development este o practică în care cazurile de testare sunt scrise de inginerii de test înainte de orice activitate de dezvoltare.

Aceste cazuri de testare sunt apoi discutate și distribuite întregii echipe. Membrii echipei intră acum într-o întâlnire pentru a discuta, îmbunătăți și revizui cazurile de testare (denumite și „cei trei amici”). Cazurile marginale sunt, de asemenea, adăugate la lista cazurilor de test în timpul acestei întâlniri.

Putem include, de asemenea, proprietarul produsului pentru a adăuga și a revizui cazurile de testare, care ar crea o încredere că cazurile de testare îndeplinesc criteriile de acceptare.

Acum că au fost dezvoltate cazurile de testare, întreaga dezvoltare s-ar baza pe aceste cazuri de testare. Acest fenomen este, de asemenea, cunoscut sub numele de ciclul test-construire. În cadrul unui ciclu de construire a testului, construiți până când toate cazurile de testare sunt trecute, lăsând spațiu pentru ca bug-urile să nu existe în sistem.

Test-First Development permite dezvoltatorilor să construiască un increment care îndeplinește criteriile de acceptare și are un buy-in de la proprietarul produsului (vocea clientului).

În zilele noastre, echipele au început să adopte abordarea și cadrul de dezvoltare testată (TDD), care este următorul pas către testarea dezvoltării primare. Unelte precum Castravete, Calibru, Specflow etc. sunt printre cele mai populare.

Principiul celor trei amigo

Cine sunt cei trei Amigos?

trei prieteni

Principiul celor trei Amigo spune că cei trei Amigos; Analist de afaceri, dezvoltatori și analisti de calitate ar trebui să se reunească într-o întâlnire în care:

  • Analistul de afaceri detaliază fiecare dintre cerințele de afaceri împreună cu echipa.
  • Membrii echipei de asigurare a calității discută cazurile de testare deja create pentru aceste cerințe comerciale.
  • Membrii echipei de dezvoltare discută cu echipa arhitectura și designul de nivel scăzut.

Obiectivul celor trei întâlniri Amigo este de a reduce lacunele în înțelegerea specificațiilor de afaceri de către trei Amigos.

Analistul de afaceri se asigură că toată lumea din echipă are aceeași înțelegere și așteptare din povestea / cerința utilizatorului de afaceri. Business Analyst colectează feedback-ul și analizează comentariile de la membrii echipei. El / Ea adaugă, de asemenea, informațiile lipsă și elimină informațiile ambigue din User Story, dacă există.

Deoarece sănătatea software-ului este întotdeauna măsurată prin standardele sale de înaltă calitate, echipa de asigurare a calității elaborează aspectele funcționale și nefuncționale ale incrementului software și detaliază cazurile de testare identificate pentru a testa incrementul. De asemenea, se asigură că toate criteriile de acceptare sunt îndeplinite de cazurile de testare.

Ceilalți membri ai echipei ajută la îmbogățirea cazurilor de testare prin găsirea cazurilor marginale și scenarii lipsă. Membrii echipei de dezvoltare își vor împărtăși cunoștințele restricții tehnice care ar putea duce la constrângeri de testare.

cum se vizualizează fișierele .eps

Dezvoltatorii discută despre înțelegerea lor despre cerințe și despre ce este nevoie pentru a construi Incrementul. De asemenea, vor discuta cu echipa aspectul Arhitecturii și Proiectarea la nivel scăzut pentru a forma o înțelegere comună a ceea ce urmează să fie construit.

Rezultatul general al sesiunii Three Amigo este că întreaga echipă are o înțelegere comună a ceea ce vor construi ca parte a sprintului următor.

Trei procese Amigo

Procesul Trei Amigo constituie cele de mai jos:

# 1) Participanți

Un reprezentant din echipa de dezvoltare și echipa de asigurare a calității fiecare și analistul de afaceri. Este sugerat să aveți acești reprezentanți, oamenii care vor lucra efectiv la această cerință pentru a beneficia de avantajul maxim al conceptului. Alții, cum ar fi Arhitecți etc., sunt întotdeauna bineveniți să se alăture întâlnirii și să le ofere îndrumare.

# 2) Cronologii

Trei sesiuni Amigo se desfășoară de obicei în N-1 Sprint. Este, de asemenea, un eveniment temporizat, adică nu poate fi prelungit. Caseta de timp recomandată pentru sesiune este de 1 oră, care este, de asemenea, durata sa maximă.

Dacă funcția urmează să fie dezvoltată în Sprint N. Apoi este foarte recomandat să efectuați sesiunea Three Amigo în N-1 sau N-2 Sprint.

# 3) Format

# 1) Întâlnirea începe cu analistul de afaceri care prezintă cerința participanților, împreună cu documentele de proiectare sau wireframe. Cerința de afaceri este de așteptat să fie bine pregătită și documentată. Se așteaptă ca echipa să fi trecut prin cerințe deja înainte de întâlnire.

# 2) Ca pas următor, participanții vor revizui cerința și vor oferi feedback care va fi încorporat ulterior de Business Analyst. Participanții vor indica, de asemenea, ambiguitățile și lacunele, dacă există. De asemenea, se așteaptă ca analistul de afaceri să elimine ambiguitățile și să completeze lacunele din cerință.

Uneori pot apărea situații în care este posibil ca analistul de afaceri să fie nevoit să confirme întrebările postate de ceilalți participanți și poate să nu încorporeze în mod direct acea revizuire acolo.

# 3) Odată ce cerința este suficient de îngrijită și participanții nu mai au feedback sau întrebări deschise, cerința este marcată ca „Gata”.

# 4) Apoi, cazurile de testare sunt prezentate participanților la fel ca și cerințele. Se așteaptă ca cazurile de testare să fie deja bine formate și pregătite.

# 5) Participanții vor examina acum cazurile de testare și vor oferi feedback. Membrul QA va încorpora toate sugestiile furnizate. Participanții ar indica, de asemenea, cazurile de test ratate și scenariile cazurilor marginale. Principalul obiectiv aici rămâne ca cazurile de testare să îndeplinească toate criteriile de acceptare și să aibă o acoperire bună a testelor.

# 6) Următorul pas este să analizăm dependențele și cerințele prealabile care ar fi putut apărea în timpul sesiunii.

ce este testarea alfa și beta

# 7) Dependențele sunt determinate și elementele de acțiune sunt create și atribuite membrilor echipei relevante. În mod similar, sarcinile pentru premise sunt create și atribuite.

# 8) Toate artefactele (cerințe, cazuri de testare, sarcini, dependențe) menționate mai sus ar trebui păstrate într-un instrument de gestionare a proiectelor precum JIRA, astfel încât toată lumea să le poată accesa cu ușurință.

# 9) Dacă există prea multe comentarii de recenzie, analistul de afaceri și inginerul pentru asigurarea calității pot alege să le încorporeze după sesiune.

Concluzie

În acest tutorial, v-am prezentat conceptul de Principiul celor trei amigo care s-a dovedit a fi foarte benefic pentru livrarea soluției potrivite într-un ritm mai rapid, cu bucle de feedback puternice.

Cele trei sesiuni Amigo nu lasă spațiu pentru o înțelegere diferită a aceleiași cerințe. Obiectivul întâlnirii este de a aduce pe toți pe aceeași pagină și apoi să îi lase să accepte cerința înainte de a trece la faza de dezvoltare.

Dacă lucrați deja în cadrul Agile, atunci vă recomand cu încredere să încercați să organizați câteva sesiuni ale celor Trei Amigo și să observați singuri schimbarea.

Următorul nostru tutorial va explica mai multe despre cadrul agil Scaled!

PREV Tutorial | NEXT Tutorial

Lectură recomandată

^