Metodologia Agile: Mama Dragonilor sau Toate Metodologiile Flexibile

1. codare — con­form stan­dard­e­lor comune de lay­out ale echipei;
2. testare — testele sunt cre­ate prac­tic de pro­gram­a­tori înainte de scrierea unui cod care va fi testat;
3. plan­i­fi­care — atât pen­tru build-ul final, cât și pen­tru iter­ații sep­a­rate. Aces­tea din urmă au loc în medie la fiecare două săptămâni.
4. audi­tion — atât a dez­volta­to­rilor, cât și a clien­tu­lui, pen­tru a elim­i­na punctele neclare și a defi­ni cer­ințele și valorile.

Metodologii Crys­tal

1. livrarea rapidă a codu­lui oper­ațion­al — evoluția ideii pen­tru mod­elul iter­a­tiv în dez­voltarea Agile.
2. îmbunătățirea prin reflex­ie — o nouă ver­si­une de soft­ware este îmbunătățită pe baza infor­mați­ilor despre ver­si­unea anterioară.
3. inter­acți­une ​„osmotică” — ino­vația lui Alis­tair, o metaforă pen­tru comu­ni­carea și schim­bul de infor­mații între dez­volta­torii soft­ware-ului care se află într‑o sin­gură cameră.

• ver­si­u­ni oper­aționale frecvente ale produsului
• autonomie a dez­volta­to­rilor în luarea deciziilor
• testare pe par­cur­sul ciclu­lui de lucru.

1. ciclul mod­elu­lui funcțion­al — crearea doc­u­mentelor analitice și prototipurilor.
2. ciclul de proiectare și inginer­ie — punerea în funcți­une a unui sistem.
3. ciclul de imple­mentare — des­fășu­rarea sistemului.

Dez­voltare con­dusă de car­ac­ter­is­ti­ci (FDD)

EssUP folosește con­cep­tul de prac­tică care include:

• măsurarea vitezei de oper­are a echipei;
• orga­ni­zarea de întâl­niri zil­nice și ret­ro­spec­tive la finalizarea iterațiilor;
• con­cep­tul de micro pași și testare tim­purie folosind checkliste;
• metodolo­gia de dez­voltare baza­tă pe mod­el Agile (AMDD).

1. rec­on­cilierea intere­selor și atin­gerea viz­iu­nii comune în muncă comună;
2. îmbunătățirea con­tin­uă prin feed­back­ul constant;
3. con­cen­trarea pe arhi­tec­tura apli­cației în stadi­ile tim­purii pen­tru a min­i­miza riscurile;
4. max­i­mizarea val­orii pen­tru con­suma­torul final.

1. Pro­duc­tiv­i­tate — se ală­tură metri­cilor Veloc­i­ty și WIP. Pri­ma nu se potrivește pen­tru toate proiectele, deoarece numărul sarcinilor final­izate pe iter­ație este măsurat, dar iter­ați­ile nu sunt egale. Met­i­ca Work-in-Progress definește limi­ta sarcinilor în diferite faze: și cu cât este mai mare, cu atât mai rău se desfășoară;
2. Pre­vizionare — met­ri­ca Capac­i­tate, care con­stă în a deter­mi­na numărul de ore per­fecte disponi­bile în urmă­torul sprint. În con­secință, este posi­bil să se înțe­leagă can­ti­tatea de timp disponi­bil pen­tru muncă, gradul de efi­ciență în îndeplinirea sarcinilor, pre­cum și să se plan­i­fice numărul de sarci­ni pen­tru un sprint;
3. Cal­i­tate — de exem­plu, indicele de sta­bil­i­tate a cer­ințelor care este cal­cu­lat prin for­mu­la = (Numărul total de cer­ințe orig­i­nale de afac­eri + Numărul cer­ințelor mod­ifi­cate în funcție de ter­menul dat + Numărul cer­ințelor adău­gate + Numărul de cer­ințe  elim­i­nate) / (numărul total de cer­ințe orig­i­nale). Această met­rică este folosită pen­tru a deter­mi­na can­ti­tatea de timp petre­cut pen­tru refac­erea sarcinilor;
4. Val­ori — această met­rică este cal­cu­lată indi­vid­ual în fiecare caz, în funcție de for­mat­ul proiec­tu­lui. De exem­plu, în start­up-ul AirBnb, numărul de fotografii de înaltă cal­i­tate descăr­cate a fost ales ca met­rică pen­tru deter­minarea val­orii finale a pro­dusu­lui pen­tru uti­liza­tori. Pe măsură ce acest număr a cres­cut, numărul de uti­liza­tori a cres­cut proporțional.

• cer­ințe stricte pen­tru echipă și clienți — fără o inter­acți­une strân­să între echipa de proiect și uti­liza­tori, este imposi­bil să se asig­ure lansarea unui pro­dus de înaltă cal­i­tate cu o val­oare înaltă. Mai mult, abun­dența unel­telor și metode­lor Agile pre­de­ter­mină ca echipa să fie exper­i­men­tată pen­tru o intro­duc­ere corec­tă a acestora.
• nu este potriv­it pen­tru exter­nalizare și pen­tru proiecte în care par­tic­i­panții inter­acționează între ei doar în mod online.
• riscul ca ver­si­unea soft­ware finală să nu fie nicio­dată lansată — sur­prinză­tor, acest deza­van­taj provine din avan­ta­jele Agile, cum ar fi dez­voltarea iter­a­tivă și îmbunătățirea con­tin­uă a produsului.
• eșuează fără o viz­iune clară asupra scop­urilor de afac­eri ale proiec­tu­lui — deoarece o echipă Agile este ghi­dată de părțile intere­sate, este imposi­bil să dezvolți un pro­dus fără un scop și con­cept clar definite.

1. con­fig­u­rați etichetele și sta­tusurile care sunt nece­sare pen­tru munca din com­pa­nia dvs. Sta­tusurile pot fi: în des­fășu­rare, ver­i­fi­care, com­ple­tat, refac­erea nece­sară, crit­ic, funcțion­al­ități, plată datorată. Etichetele sunt ade­sea for­mu­late ast­fel: lay­out, testare, pro­ducție, con­cept, cod.
2. creați prod­uct back­log și sprint­ul de proiect.
3. creați sarci­ni și liste pre­lim­inare de ver­i­fi­care, schițe etc. în backlog.
4. în tim­pul întâl­nir­ilor, deter­mi­nați sarcinile sprint­u­lui și trans­fer­ați-le din back­log în sprint.
5. uti­liza­ți acce­sul oaspeților al clienților la sarci­ni ast­fel încât să aveți întot­deau­na feed­back coor­do­nat și rel­e­vant asupra proiectului.
6. etichetați per­soanele respon­s­abile în sarci­ni, ast­fel încât fiecare coleg să știe dome­ni­ul său de respon­s­abil­i­tate și să se simtă impli­cat în rezul­tat­ul sprintului.