3 amigo principle agile
Uvod v načelo 3 Amigo:
aplikacije Java v resničnem svetu
Prej v seriji Scrum smo vam predstavili koncept prinašanja samozadostnost članov skupine Scrum spodbujati kulturo, ki ustvarja poslovno vrednost, ne da bi potrebovali kakršno koli pomoč zunanjega sveta.
V zadnjem času sem bil usklajen s projektom strank, kjer sem delal kot Scrum Master. Ko sem delal v več projektih, ki temeljijo na Scrumu, sem lahko uspešno združil metodologijo z naročnikovimi načini dela.
Po določenem časovnem obdobju pa je bilo okoli zahteve po razumevanju ugotovljenih veliko nejasnosti.
Vsak član ekipe Scrum ima svojo različico razumevanja zahtev!
Kaj se boste naučili:
- Pregled
- Test First Development (TFD)
- Načelo treh amigo
- Proces treh amigo
- Zaključek
- Priporočeno branje
Pregled
Kaj bi se zgodilo, če bi imeli razvijalci in nadzor kakovosti dve različni perspektivi iste zahteve?
Očitno bo v tem primeru, da bodo razvijalci pripomoček razvijali, upoštevajoč svojo perspektivo, preizkuševalci pa bi ga preizkušali, upoštevajoč svojo perspektivo.
Obe perspektivi ponavadi ustvarjata vrzel in vprašanja se nato obravnavajo šele proti koncu Sprinta. Še najslabši primer bi bil, če ne bi bilo časa za reševanje teh težav znotraj Sprinta, ki bi nas pristal v situaciji, da bi dodali dodatne elemente v zaostanek izdelkov.
Da bi rešili zgornjo izjavo o težavi, smo prišli do rešitve, da bi imeli člani ekipe več sej za razprave o zahtevah, da bi analizirali in razmislili o zahtevah kot celoti. In zato se je pojavila ideja o načelu treh amigo.
Preden se lotimo načela treh amigo, se najprej pogovorimo o eni od agilnih praks testiranja, preizkus prvega razvoja (TFD) in o tem, kako je povezan s tremi amigomi.
Test First Development (TFD)
Kot že samo ime pove, je Test First Development praksa, pri kateri testne primere pred kakršno koli razvojno dejavnostjo napišejo testni inženirji.
O teh testnih primerih se nato razpravlja in jih deli celotna ekipa. Člani ekipe se zdaj udeležijo sestanka, na katerem razpravljajo, izboljšujejo in pregledujejo testne primere (imenovane tudi 'Trije amigi'). Med tem sestankom so na seznam testnih primerov dodani tudi robni primeri.
Lastnika izdelka lahko vključimo tudi za dodajanje in pregledovanje testnih primerov, ki bi ustvarili zaupanje, da testni primeri izpolnjujejo merila sprejemljivosti.
Zdaj, ko so bili razviti testni primeri, bi celoten razvoj temeljil na teh testnih primerih. Ta pojav je znan tudi kot cikel preskusne gradnje. V ciklu preskusne gradnje gradite, dokler ne preidejo vsi preizkusni primeri, ne da bi bilo prostora za napake v sistemu.
Razvoj Test-First omogoča razvijalcem, da ustvarijo prirastek, ki ustreza kriterijem sprejemljivosti in ima vstop lastnika izdelka (glas stranke).
Danes so ekipe začele sprejemati pristop in okvir Test Driven Development (TDD), ki je naslednji korak k preizkusu prvega razvoja. Orodja, kot so kumare, merilniki, specflow itd., So med najbolj priljubljenimi.
Načelo treh amigo
Kdo so trije Amigo?
Tri načela Amigo pravijo, da trije Amigo; Poslovni analitiki, razvijalci in analitiki kakovosti bi se morali zbrati na sestanku, kjer:
- Poslovni analitik z ekipo podrobno opredeli vsako poslovno zahtevo.
- Člani skupine za zagotavljanje kakovosti razpravljajo o testnih primerih, ki so že bili ustvarjeni za te poslovne zahteve.
- Člani razvojne skupine se z ekipo pogovarjajo o arhitekturi in oblikovanju na nizki ravni.
Cilj treh srečanj Amigo je odpraviti vrzeli v razumevanju poslovnih specifikacij s strani treh družb Amigo.
Poslovni analitik skrbi, da imajo vsi člani ekipe enako razumevanje in pričakovanja glede zgodbe / zahteve poslovnega uporabnika. Poslovni analitik zbira povratne informacije in pregleduje komentarje članov ekipe. Prav tako doda manjkajoče podatke in odstrani dvoumne podatke iz uporabniške zgodbe, če obstajajo.
Ker se stanje programske opreme vedno meri po visokokakovostnih standardih, ekipa za zagotavljanje kakovosti podrobno obravnava funkcionalne in nefunkcionalne vidike povečanja programske opreme ter podrobno opredeli testne primere, ki so bili ugotovljeni za preizkušanje prirastka. Poskrbijo tudi, da testni primeri izpolnjujejo vsa merila sprejemljivosti.
Ostali člani ekipe pomagajo pri obogatitvi testnih primerov z iskanjem najpomembnejših primerov in manjkajočih scenarijev. Člani razvojne skupine bodo delili svoje tehnične omejitve znanja, ki bi lahko privedle do omejitev pri testiranju.
kakšen je omrežni varnostni ključ za wifi
Razvijalci razpravljajo o svojem razumevanju zahtev in o tem, kaj je potrebno za izgradnjo prirastka. Z ekipo bi se pogovarjali tudi o postavitvi arhitekture in oblikovanju na nizki ravni, da bi oblikovali skupno razumevanje, kaj bo zgrajeno.
Splošni izid seje Three Amigo je, da celotna ekipa skupno razume, kaj bo zgradila kot del naslednjega sprinta.
Proces treh amigo
Postopek treh amigo predstavlja naslednje:
# 1) Udeleženci
Vsak en predstavnik iz razvojne skupine in ekipe za zagotavljanje kakovosti ter poslovni analitik. Priporočeno je, da imamo te predstavnike, ljudi, ki bodo dejansko delali na tej zahtevi, da bi izkoristili kar največ koristi koncepta. Drugi, kot so arhitekti itd., So vedno dobrodošli, da se pridružijo sestanku in podajo svoje smernice.
# 2) Časovni trakovi
Tri seje Amigo običajno potekajo v N-1 Sprint. To je tudi časovno omejen dogodek, torej jih ni mogoče podaljšati. Priporočeno časovno polje za sejo je 1 ura, kar je tudi njeno največje trajanje.
Če naj bi funkcijo razvili v Sprint N. Potem je zelo priporočljivo, da sejo Three Amigo izvedete v N-1 ali N-2 Sprint.
# 3) Oblika
# 1) Sestanek se začne tako, da poslovni analitik udeležencem predstavi zahtevo skupaj z oblikovalskimi dokumenti ali žičnimi okvirji. Poslovna zahteva naj bi bila dobro pripravljena in dokumentirana. Pričakuje se, da je ekipa že pred srečanjem izpolnila zahtevo.
# 2) Kot naslednji korak bodo udeleženci pregledali zahtevo in poslali povratne informacije, ki jih bo kasneje vključil poslovni analitik. Udeleženci bodo opozorili tudi na nejasnosti in morebitne vrzeli. Tudi poslovni analitik naj bi odpravil dvoumnosti in zapolnil vrzeli v zahtevi.
Včasih lahko pride do situacij, ko bo poslovni analitik morda moral potrditi poizvedbe, ki so jih objavili drugi udeleženci, in morda ne bo vključil tega pregleda sam.
# 3) Ko je zahteva dovolj urejena in udeleženci nimajo več povratnih informacij ali odprtih vprašanj, je zahteva označena kot »Pripravljena«.
# 4) Nato se testni primeri udeležencem predstavijo tako kot zahteve. Testni primeri naj bi bili že dobro oblikovani in pripravljeni.
# 5) Prisotni bodo zdaj pregledali testne primere in poslali povratne informacije. Član QA bo vključil vse podane predloge. Udeleženci bi opozorili tudi na zgrešene testne primere in najboljše scenarije primerov. Glavni cilj tukaj ostaja, da morajo testni primeri izpolnjevati vsa merila sprejemljivosti in imeti dobro pokritost s testi.
# 6) Naslednji korak je preučiti odvisnosti in predpogoje, ki bi se lahko pojavili med sejo.
kateri programi lahko odprejo datoteke eps
# 7) Odvisnosti se določijo in elementi akcije se ustvarijo in dodelijo ustreznemu članu ekipe. Podobno se ustvarijo in dodelijo naloge za predpogoje.
# 8) Vse zgoraj omenjene artefakte (Zahteve, testne primere, naloge, odvisnosti) je treba hraniti v orodju za upravljanje projektov, kot je JIRA, tako da jih lahko vsi zlahka dostopajo.
# 9) Če je pripomb k pregledu preveč, se lahko poslovni analitik in inženir za zagotavljanje kakovosti po seji odločita, da jih vključita.
Zaključek
V tej vadnici smo vam predstavili koncept Načelo treh amigo kar se je izkazalo za zelo koristno za hitrejšo dostavo prave rešitve z močnimi povratnimi zankami.
Tri seje Amigo ne puščajo prostora za drugačno razumevanje iste zahteve. Cilj srečanja je pripeljati vse na isto stran in jim nato dovoliti, da sprejmejo zahtevo, preden preidejo v razvojno fazo.
Če že delate v programu Agile Framework, vam toplo priporočam, da poskusite nekaj sej Tri Amigo in opazujete spremembe sami.
Naša prihajajoča vadnica bo razložila več o Scaled agile framework!
PREV Vadnica | NASLEDNJA Vadnica
Priporočeno branje
- 4 koraki k razvoju agilnega miselnega načina testiranja za uspešen prehod na agilni postopek
- Agile Vadnica JIRA: Kako učinkovito uporabiti JIRA za upravljanje agilnih projektov
- Agile Manifesto: Razumevanje okretnih vrednot in načel
- Sprememba miselnosti agilnega preizkuševalca: uskladitev z agilnim manifestom
- Vadnica SAFe Agile: Kaj je Scaled Agile Framework
- Spletni kviz Agile Scrum: preizkusite svoje znanje Agile Scrum
- Avtomatizirano regresijsko testiranje: izzivi, postopek in koraki
- Agilno testiranje v vzponu - blagodejno ali bane?