Postizanje swarminga u Agilnim timovima – Treći deo


Na konferenciji Project Society Coference (u organizaciji PMI), održanoj 23.5. sam održao predavanje na temu Postizanje swarminga u Agilnim timovima. Slajdove možete pogledati na SlideShare-u, a ovde vam dajem prevod transkripta čitavog predavanja, organizovano u tri posta.

Ukoliko niste pročitali prethodne delove, ovaj link vas vodi na prvi deo, dok ovim linkom možete videti drugi deo.

Treći deo

Kanban je framework za optimizaciju procesa. Kao takav, primenjuje se na postojeći proces. Iako koristi tablu za vizuelizaciju – Kanban tablu – ona se prilično razlikuje od Scrum table, za razliku od koje ne dolazi sa predefinisanim stanjima. Broj i namena stanja zavisi od stvarnih faza procesa koji se optimizuje.

U ovom primeru se Kanban koristi za optimizaciju jednostavnog procesa. Vidimo da ima product backlog iz koga se biraju aktivnosti za razvoj, koje zatim idu u implementaciju (sama implementacija i red završenih implementacija), nakon čega se završeni inkrementa proizvoda uvodi u produkcioni sistem.

Mali brojevi u zaglavlju tih kolona su ograničenja posla u toku (WIP limit), koji označava da u datoj koloni ne može biti više od navedenog broja stavki u jednom tenutku. WIP limit je mehanizam optimizacije toka.

U našem primeru, tok je sledeći: Product Manager bira dve najznačajnije stavke (jer je WIP limit „Selected“ kolone postavljen na 2) i prebacuje ih u „Selected“ kolonu. Razvojni tim uzima te dve stavke i počinje da radi na njima. Pošto imamo DVE stavke i ČETIRI developera, to predstavlja swarming priliku za Kanban tim. Kako developeri ne bi sedeli besposleno, oni moraju da nađu način da rade zajedno na istoj stavci. Ovaj tim je odlučio da radi u parovima.

Kada završe svoj posao, developeri iz prvog development para prebacuju svoju stavku (stavku „A“) u „Develop/Done“ kolonu, odakle je odmah preuzima Deployment tim. Prvi development par zatim peruzima sledeću najvažniju stavku (stavku „C“).

Međutim, deployment tim shvata da su blokirani. Naišli su na nerazrešene zavisnosti, koje je uveo development par, pa nastavljaju da se trude da to samostalno reše. Njihov WIP limit je 1, tako da je to jedina stavka na kojoj mogu da rade u tom trenutku, a pored toga, to je i najvažnija stavka.

Otprilike u isto vreme, drugi development par završava svoju implementaciju (stavke „B“), ali ne mogu da preuzmi druge stavke pre nego što se „Develop/Done“ kolone ne isprazni, budući da je WIP limit za čitavu „Develop“ kolonu postavljen na 2, a već su dve stavke u „Develop“ koloni.

Dakle, rađa se druga swarming prilika za Kanban tim – drugi development par se pridružuje deployment paru u rešavanju zavisnosti na koje su naišli.

Čak i kada prvi par završi svoj posao, oni ne mogu da nastave sa razvojem zboj WIP limita, tako da moraju da se pridruže swarm-u i doprinesu uklanjanju blokade i pomognu isporuku najvažnije stavke (stavke „A“).

Na kraju, swarming donosi višestruke benefite. Ukoliko se odlučite da ga primenite, dobićete makar:

  • deljeno znanje i deljeno razumevanje proizvoda od strane tima
  • povećano vlasništvo tima nad proizvodom
  • priliku za češće inoviranje, bar u pogledu procesa, a najverovatnije i na strani proizvoda.

Ukoliko se odlučite na uklanjanje silosa, sigurno ćete dobiti:

  • povećani kvalitet, zbog ugrađivanja kvaliteta u proizvod od samog početka
  • eliminisanje troškova prebacivanja posla.

Postoje i mnogi drugi benefiti, a siguran sam da već možete da ih prepoznate i pronađete u vašim kontekstima.

Na samom kraju, evo još jednog bonus videa jednog dana u timu koji primenjuje mob programming.