când încep să lucrez cu o echipă de produse Agile, una dintre cele mai frecvente situații pe care le găsesc este în cazul în care echipele au întâlniri lungi și frustrante de planificare a sprintului, deoarece elementele restante sunt slab definite și nu sunt bine înțelese; au o viteză lentă, precum și un design slab, deoarece detaliile sunt încă elaborate în timpul sprintului; iar cantitatea de deșeuri și reprelucrare este foarte mare, deoarece elementele restante nu au fost validate.

amintiți-vă că obiectivul nostru de ordin superior este de a valida ideile noastre cel mai rapid și mai ieftin mod posibil. De fapt, construirea și lansarea unei idei de produs este, în general, cel mai lent, cel mai scump mod de a valida ideea.

de aceea sunt un mare avocat pentru ceea ce este uneori denumit Dual-Track Agile (aka Dual Track Scrum, falsificați-l înainte de a-l face, construiți lucruri care nu scalează/construiesc lucruri care fac scară, mișcați rapid/nu rupeți lucrurile, descoperire continuă/livrare continuă etc.).

obișnuiam să mă refer la asta ca la simple sprinturi de descoperire, dar asta are o implicație a descoperirii în cutie de timp și, de asemenea, serializarea fazelor. Jeff Patton mi-a împărtășit mai întâi termenul “Scrum Dual-Track” și prefer acest termen pentru că surprinde mai bine natura paralelă a descoperirii și livrării.

piesa Discovery este vorba despre generarea rapid validate elemente backlog produs, iar piesa de livrare este vorba despre generarea de software eliberabil.

un alt motiv pentru care îmi place metafora Dual-Track Agile este că găsesc mulți oameni care fac în esență mici mini-cascade în cadrul lor Scrum. Managerul de produs face un fel de” cerințe ” de lucru, și care este trecut la un designer care face desenele sale și generează artefacte sale (de obicei, wireframes adnotate), și apoi că este predat la echipa de livrare pentru a construi și de testare.

în schimb, în Dual-Track Agile, fluxul de lucru nu este caracterizat de fiecare rol care livrează artefacte la pasul următor; mai degrabă este colaborativ – managerul de produs, proiectantul și inginerul principal lucrează împreună, unul lângă altul, pentru a crea și valida articole restante.

cititorii acestor articole știu cât de important consider designul experienței utilizatorului, dar una dintre dificultățile pentru multe echipe Agile este că ritmul și ritmul Agile pot fi foarte dificile pentru echipele tradiționale UX. Acesta este motivul pentru care sunt un fan al Lean UX. Lean UX și Dual-Track Agile sunt făcute unul pentru celălalt. În loc să ne concentrăm pe artefacte, ne concentrăm pe prototipuri și validarea acestor prototipuri în descoperire, cu avantajul suplimentar că prototipul servește drept spec pentru livrare.

cel mai important, spre deosebire de un proces de cascadă în care validarea are loc după lansare, în Dual-Track Agile, validăm în timpul descoperirii. În principiul validării cât mai rapid și ieftin putem, o mare parte din timp putem face de fapt validarea noastră înainte de a scrie orice cod de producție, în spiritul “falsificați-l înainte de a-l face.”

deci, dacă echipa dvs. de produse este frustrată de cantitatea de deșeuri și de ritmul lent în obținerea rezultatelor reale de afaceri, luați în considerare încercarea Dual-Track Agile. Vedeți dacă acest lucru poate inspira un nivel de colaborare, iterație rapidă și validare care să ducă la o muncă mult mai bună.

Lasă un răspuns

Adresa ta de email nu va fi publicată.