Scrumban.

Ce e de fapt Scrumban

Scrumban păstrează părțile din Kanban și Scrum care își fac treaba și renunță la rest. Din Kanban ia panoul vizual, fluxul pe coloane și limitele de lucru în curs — lucrurile care fac fluxul lizibil. Din Scrum ia sprintul cu timp limitat — lucrul care transformă un backlog într-un plan.

Ce sare: standup-urile zilnice, ședințele de grooming, ceremoniile cu story points, retrospectivele ca ritual. Acelea merg pentru zece ingineri într-o organizație reglată; nu merg pentru un fondator care încearcă să livreze sâmbătă.

De ce Weft alege Scrumban

Weft există pentru că majoritatea managerilor de sarcini sunt modelați pentru una din două extreme: fie o aplicație de to-do solitar (listă infinită, fără cadență), fie o suită Agile de cincizeci de oameni (overhead de proces pentru un fondator de unul singur). Scrumban stă exact la mijloc — destulă structură ca să forțeze o livrare săptămânală sau bisăptămânală, nu atât de multă încât să-ți petreci ziua de livrare administrând-o.

Cum îl implementează Weft

• Patru coloane implicite: Backlog, Todo, Doing, Done. Poți adăuga limite WIP pe coloană. Ghidul Kanban tratează o politică explicită de limitare a lucrului în curs ca parte a definiției unui flux, astfel încât elementele noi să fie trase doar pe măsură ce se eliberează capacitate.
• Un singur sprint activ odată. Sprinturile sunt opționale — sari peste ele dacă Kanbanul pur se potrivește. Ghidul Scrum definește sprinturile ca evenimente de lungime fixă, de o lună sau mai puțin, cu un sprint nou care începe imediat după încheierea celui anterior.
• Sarcinile au prioritate, estimare, termen și o atașare opțională la sprint. Fără epics, fără fluxuri, fără câmpuri personalizate.
• Timpul de ciclu începe când o sarcină se mută într-o coloană cu semantic="doing" și se termină în "done". Cifrele ies din utilizare onestă, nu din aritmetică de story points.

Când Scrumban nu e metoda potrivită

• Rulezi mai multe echipe Scrum concurente. Ghidul Scrum pune o echipă Scrum la de obicei 10 oameni sau mai puțin și spune că produsele mai mari ar trebui organizate în mai multe echipe Scrum care împart un singur obiectiv de produs și un singur backlog de produs. Raportare la nivel de program, viteză comună, dependențe între echipe — Scrum complet în Jira își merită locul. Ghidul Nexus e scris pentru acea situație: mai multe echipe Scrum lucrând dintr-un singur backlog de produs, cu practici suplimentare pentru scoaterea la suprafață și rezolvarea dependențelor între echipe.
• Faci suport pur / operațiuni continue. Nu e nevoie de cadență de sprinturi — Kanbanul pur sau un sistem de tickete se potrivește mai bine.
• Ai nevoie de diagrame Gantt și cronologii. Scrumban e concentrat pe sprinturi, nu pe grafuri de dependențe.