Postizanje swarminga u Agilnim timovima – Drugi 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 prethodni deo, ovaj link vas vodi na prvi deo.

Drugi deo

Scrum je ubedljivo najpopularniji agilni framework. To je framework za razvoj proizvoda i jedna od najvažnijih karakteristika je insistiranje na važnosti isporuke poslovno najvrednije stvari u jednom trenutku. Pri tome, čitav tim bi trebalo da radi na toj jednoj, najvrednijoj stvari. Međutim, većina kompanija smatra takav pristup neefikasnim i insistira da čitav tim radi u istom trenutku na što je više moguće različitih stvari. Takav pristup ima za rezultat to da na kraju sprinta većina stvari nije u potpunosti završena. To dalje tim dovodi u situaciju da nema ništa (ili ima vrlo malo) da pokaže klijentu, čime gube priliku za dobijanje važnog feedback-a.

S druge strane, tim koji završava stavke jednu po jednu, vodeći računa o tome da radi na najvrednijoj u datom trenutku, maksimizuje priliku za važan i vredan feedback. Oni će završiti sav posao na kome su radili (osim možda poslednje stavke) i moći će da ga prikažu klijentu. Ovaj princip bi mogao da se formuliše na sledeći način – bolje je u potpunosti završiti 80% planiranih stavki, nego raditi na svemu, a ne završiti ništa.

To nas dovodi do prve swarming prilike za Scrum tim – u svakom trenutku radite kolaborativno kao tim na najvrednijoj stavci, a pređite na sledeću tek nakon potpunog završetka trenutne (najvrednije u datom trenutku).

Ovu sliku poznajete kao Scrum tablu. Međutim, uprkost uvreženom mišljenju, tabla nema tri kolone – „To Do“, „In Progress“ i „Done“. Ima ih ČETIRI. Krajnja leva kolona predstavlja Sprint Backlog i u njoj se nalaze stavke koje opisuju ŠTA je potrebno uraditi da bi se zadovoljila potreba klijenta (danas se tu skoro isključivo stavljaju User Story-ji). Tim se obavezuje da radi na njima, ali ne radi na njima neposredno. Umesto toga, oni kreiraju sve neophodne aktivnosti, potrebne da bi se realizovala ŠTA stavka. Zadaci i aktivnosti koje oni kreiraju su sve neophodne aktivnosti, u okviru svih specijalnosti u timu. Npr.:

  • sve aktivnosti za frontend developere
  • sve backend aktivnosti
  • svi aktivnosti na bazama podataka
  • sve neophodne aktivnosti za postavljanje inkrementa na „živi“ sistem
  • sve aktivnosti testiranja (identifikacija i kreiranje svih slučajeva testiranja, pisanje automatskih testova)
  • zadaci vezani za dizajn
  • zadaci vezani za istraživanje i eksperimentisanje

Sve ove aktivnosti opisuju KAKO će te ŠTA stavke biti realizovane. I, naravno, tim ih dodaje i uklanja u toku sprinta u skladu sa potrebama.

Ovo nas dovodi do druge prilike za swarming u Scrum timu – grupišite se oko aktivnosti u okviru spelijalizacija – uparujte developere, dizajnere, testere i ostale u okviru njihovih specijalnosti.

NOTE: U vašem timu možda nema eksplicitno određenih specijalnosti (tj. svi imaju potpun potreban skup veština za obavljanje posla), ali u trenutku ovaljvanja aktivnosti, same aktivnosti su u vezi sa pojedinim specijalnostima.

Scrum implementacije često počinju entuzijastima u okviru kompanije, koji pročitaju knjigu ili blog postove ili čak prisustvuju dvodnevnom sertifikacionom treningu. Oni onda najčešće kreću u implementaciju korišćenjem Scrum table sa tri stanja (najčešće u Jiri) – „To Do“, „In Progress“ i „Done“. Sprint backlog obično formiraju u „To Do“ koloni i, skoro po pravilu, developeri individualno počinju sa radom na pojedinačnim User Story-jima (pošto skoro uvek koriste User Story-je) pri čemu karticu pomera u „In Progress“ kolonu. Kada je developer završio sa pisanjem koda, neko iz tima, najčešće QA, preuzima kod kako bi ga istestirao. Međutim, to je teško predstaviti na tabli, tako da se obično dodaje „QA“ kolona, kako bi se zadovoljila ta potreba. U tom trenutku „In Progress“ kolona gubi smisao, tako da se često preimenuje u „Develop“.

Ovo je vrlo čest antipatern u implementaciji Scrum-a i vodi kreiranju silosa specijalnosti. Između silosa nema kolaboraciju izuzev na tačkama prebacivanja posla, pri čemu se između specijalnosti deli samo delić raspoloživih informacija.

Naravno, kada se formiraju prvi silosi, onda se nastavlja sa dodavanjem i ostalih, novih silosa, što rezultuje procesom bez kolaboracije i kulturom prebacivanja posla. Rezultat je nekolaborativni, neefektivni sekvencijalni proces, koji nema nikakve veze sa Scrum-om.

S druge strane, jednostavnost Scrum table ohrabruje i promoviše kolaboraciju, što nas dovodi do treće prilike za swarming u Scrum timu – radite kolaborativno između različitih specijalnosti u okviru istog tima.

Šta to zapravo znači? Razmotrimo sekvencijalni proces koji smo upravo opisali u prethodnom primeru. Kada developer počne sa radom na User Story-ju u „To Do“ koloni, on pokušava da identifikuje sve neophodne slučajeve upotrebe i sve putanje koje mora da implementira kako bi realizovao User Story. Kada završi pisanje koda, on prebacuje rezultat svog rada testeru. Ona, zatim, pokušava da identifikuje sve slučajeve testiranja neophodne za proveru ispravnosti implementacije. Naravno, pošto u tom procesu nema saradnje između njih dvoje, oni će najverovatnije doći do različitih skupova za implementaciju i proveru, tako da će imati različita očekivanja od druge strane. Ovo je savršeni scenario za igru mačke i miša u kojoj tester pokušava da zaskoči developera i da mu pronađe grešku. A naravno, biće grešaka, jer će tester pokušati da proveri nešto što developer nije implementirao ili će developer implementirati nešto što neće biti provereno. U svakom slučaju, ovakav rad rezultuje višestrukim prebacivanjem posla između specijalnosti, što konačno rezultuje bespotrebno bacanje novca i vremena. Da ne spominjemo i frustracije koje se rađaju kao dodatni efekat.

Nasuprot tome, korišćenje Scrum table ohrabruje developere i testere da rade zajedno od samo početka na istim stvarima, identifikujući potpun skup slučajeva korišćenja i slučajeva testiranja. Na taj način developer saznaje šta je ono što bi trebalo da napravi i šta će biti provereno, a to isto važi i za testera. Time se prilika za nerazumevanje i propuštene prilike daleko smanjuje.

Lepota ovakvog pristupa je u prilici da se doda još neka specijalnost ovakvoj saradnji. Ukoliko, na primer, dodamo UX dizajnera ovom paru, ona bi mogla da primeti da neki koraci koje je zamislila nemaju smisla nakon zajedničkog razmatranja, kao i da neki važni koraci nedostaju, te bi onda mogla da ih doda.

Na ovaj način se kvalitet ugrađuje u proizvod od samog početka. Da ne spominjem da trošak prebacivanja posla u tom slučaju ne postoji, kao i da ne postoje nepotrebne petlje u procesu.

Nastavite na treći deo – primer Kanban tima

Evo još jednog bonus videa na kome je prikazan jedan dan tima koji radi mob programming (Woody Zuill video).