Postizanje swarminga u Agilnim timovima – Prvi 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.

Prvi deo

Swarming je definisan u rečniku kao „velika grupa insekata i drugih životinja, koje se kreću zajedno“. Neposredno se prevodi kao „rojenje“, ali je swarming prihvaćen kao internacionalni opis fenomena koji ovde razmatramo.

Mi obično swarming posmatramo u kontekstu insekata. Shvatamo ga kao ponašnje roja koji je sposoban za mnogo složenija ponašanja i daleko je sposobniji od pojedinačnih insekata koji ga čine.

Kod ljudi, međutim, swarming ima donekle drugačije značenje. Obično ga razumemo kao kolaborativno ponašanje grupe. U tom značenju, swarming je ponašanje normalno prisutno kod ljudi. Posebno u ranom uzrastu, kod predškolske dece (tj. pre nego što ga socijane norme ili školski sistem ne potisnu).

Ukoliko grupi dece damo kompleksan problem (pri čemu je kompleksnost definisana Cynefin frejmvorkom), ona će gotovo uvek pokušati da taj problem reše individualno. Počeće da se nadmeću međusobno, sve dok ne shvate da nemaju neophodne sposobnosti za individualno rešavanje problema. Kada to shvate, onda će potražiti pomoć od drugih i počeće da razmenjuju informacije i da nadgrađuju ideje u toj razmeni. Ovo, naravno, zavisi od ličnosti deteta, ali nadgradnja na idejama drugih se gotovo uvek dešava.

Kada školski sistem završi sa našim oblikovanjem, naš pogled je tako značajno izmenjen, da čak i kada počnemo da se profesionalno bavimo poslom, tamo tražimo zone komfora u kojima bismo mogli da radimo individualno u samoći. Nažalost, većina kompanija podržava, a čak i ohrabruje ovakvo ponašanje.

U rešavanju kompleksnih problema, međutim, stečeno znanje i najbolje prakse nisu dovoljne. Neophodno je eksperimentisanje i postavljanje hipoteaza. Moramo da pravimo pretpostavke i da pravimo nove pretpostavke zasnovane na njima, pri čemu ih praktično ulančavamo (pravimo lance ili nizove međusobno zavisnih pretpostavki).

Posmatrajte na primer programera. Tipični programer svkaog dana pravi na desetine pretpostavki i odluka i akcija zanovanih na tim pretpostavkama. Te pretpostavke idu od trivijalnih do izuzetno složenih. Svaka naredna pretpostavka zavisi od ispravnosti prethodnih, što zapravo čini lanac pretpostavki. Ukoliko se u nekom trenutku početna pretpostavka pokaže pogrešnom, sve naredno pretpostavke su najverovatnije pogrešne, a sve ono što je učinjeno pod tim pretpostavkama je najverovatnije bačeni trud.

Posmatrajmo za trenutak prostor svih mogućih rešenja određenog problema, od najlošijeg do optimalnog. Svaki pojedinac je, u skladu sa prethodnim iskustvom, znanjem i ograničenjima okolina (npr. vremenski rokovi), sposoban da u najboljem slučaju dođe do malog podskupa svih mogućih rešenja. U potrazi za optimalnim rešenjem, on dalje otpisuje te predloge rešenja jedan za drugim, opet u skladu sa prethodnim iskustvom, znanjem i ograničenjima okolina (npr. vremenski rokovi), a ovoga puta i ličnim preferencama. Otpisivanje se nastavlja, sve dok ne ostane samo jedno rešenje, za koje pojedinac smatra da je u pomenutim okolnostima optimalno.

Različiti pojedinci, naravno, imaju različite početne pozicije i različite perspektive, te se njihovi skupovi predloženih rešenja razlikuju. Isto tako, oni će se navjerovatnije odlučiti za različita rešenja koja smatraju optimalnim. Ukoliko se njihove perspektive ne kombinuju, onda će oni najverovatnije nastaviti dalje sa neoptimalnim rešenjem.

Ukoliko se, međutim, njihove perspektive ukrste, oni će se upustiti u razmenu informacija, davajući i primajući feedback. Na taj način oni izazivaju, potvrđuju ili obaraju pretpostavke drugih. Što je kraća feedback petlja, veća je verovatnoća da će protraćeni uloženi rad biti sveden na najmanju moguću meru.

Setite se našeg tipičnog programera sa dugim lancem pretpostavki. Ukoliko se njegova početna pretpostavka vrlo brzo pokaže pogrešnom, onda će i uloćeni rad vezan za to pogrešno usmerenje biti minimalan.

Značaj kratkih feedback petlji je najbolje opisan citatom: „Najbolji trenutak za otkrivanje bagova je oprilike 3 minuta od njihovog nastanka“. Poreklo citata je iz razvoja softvera, ali zapažanje važi i za sve ostale kontekste.

Dobro, a šta Agile nudi u ovom pogledu? Kakve feedback mehanizme pruža?

Daleko najpopularniji agilni pristup je Scrum. Scrum obezbeđuje prilike za feedback na različitim nivoima: na nedeljnom nivou Sprintova i dnevnom nivou Daily Scrum-ova.

Sprintovi su iteracije fiksnog trajanja, od jedne do četiri nedelja. Feedback od klijenta i feedback u vezi sa procesom je garantovan na kraju svakog sprinta. Dakle, timovima koji rade sa dvonedeljnim sprintovima, je garantovan feedback svake druge nedelje. To može da bude i predugo u većini okružanje, tako da Scrum predviđa i Dail Scrum-ove.

Daily Scrum obezbeđuje feedback petlju na svakih 24 sata i garantuje timu feedback sesiju barem jednom dnevno. Za programera iz našeg primera, koji donosi na desetine odluka u toku jednog dana, ovo može biti predugo. Međutim, Scrum ne predviđa kraće feedback mehanizme.

S druge strane, suosnivač Scrum-a, Jeff Sutherland, je rekao da je za razoj softvera najbolje kombinovati Scrum sa Extreme Programming (XP) praksama. Tako da, ukoliko ih koristime, imamo sledeće feedback mehanizme:

  • Continuous Integration (CI) – integrisanje rada pojedinca sa radom drugih, pri čemu se vrši provera njegovog inkrementa, tj. da li se on uklapa u proizvod na ispravan način ili ne. Tipično se CI ciklus dešava više puta dnevno, ali će biti izvršen bar jednom u toku dana (kada programer pošalje svoj rad pre nego što krene kući).
  • Unit Testing – pisanje unit testova u toku, a pre pisanja koda (TDD), garantuje proveru ispravnosti nečijeg koda, čak i nakon refaktoringa i drugih izmena. Izvršava se tipično više puta u toku CI ciklusa, ali će se garantovano izvršiti bar jednom, kada programer pošalje svoj kod.

Na taj način dobijamo vrlo kratku feedback petlju, koja se dešava mnogo puta u toku dana. XP, međutm, predlaže još jednu, mnogo kraću feedback petlju – kontinualnu feedback petlju! Ona se dešava u Pair Protrammingu (programiranju u paru).

A zašto je programiranje u paru važno za ovu priču? Zbog toga što je par najmanji mogući vid swarming-a i ima samo dva člana (tako da, zapravo, u ovom slučaju swarming posmatramo u prilično ekstremnom kontekstu).

Hajde da razmotrimo raspodelu sposobnosti pojedinca u toku rešavanja problema, a u funkciji od pojedinih faza u rešavanju tog problema. Ta raspodela, naravno, varira u zavisnosti od osobe. Ukoliko kombinujemo dve osobe njihovim uparivanjem, razumno je očekivati maksimum njihovih sposobnosti u bilo kom trenutku. Međutim, uparivanje ne funkcioniše na taj način. Ukoliko se oni upuste u uparivanje, oni će se zapravo upustiti u neprekidnu brainstorming sesiju, pri čemu će neprekidno međusobno nadograđivati ideje i predloge, uz to potvrđujući njihovu ispravnost. Rezultat predstavlja indukovano znanje, do koga oni ne bi bili u stanju da dođu samostalno, radeći u izolaciji.

Ukoliko nastavimo da dodajemo članove tima toj razmeni, efekat će nastaviti da raste, ali samo do određene tačke, jer ne možemo dodavati članove timu beskonačno, a da tim nastavi da performira. Postoji prava mera za veličinu tima, a koja zavisi od organizacije i okolnosti u kojima tim radi.

Međitim, ovakvo grupisanje je stvarnost, ono postoji i ma ime – Mob Programming (ili Mobbing) i naročito je popularno u Skandinaviji, sa rastućom popularnošću širom sveta.

Transkript se nastavlja u drugom delu, na primeru Scrum tima.

Ovde je i bonus video jednog dana u timu koji radi mob programming.