Blog

Organizacija velikih razvojnih timova

Danas su agilne metodologije postale de facto standard razvoja softvera, a kao jedno od ključnih pitanja nameće se pitanje kako skalirati agile na velike razvojne projekte i timove.
Objavljeno 24.03.2014.

Čest nesporazum oko agilnih pristupa razvoju softvera proizlazi iz tvrdnje da su oni namijenjeni samo malim, kolociranim timovima. Da, mnogo je lakše biti uspješan s malim, kolociranim timovima, a i zašto ulaziti u dodatni rizik kada to nije potrebno? No ponekad je stvarnost neizbježna, i vi se nađete u situaciji u kojoj vam je potreban velik distribuirani tim, a još uvijek biste htjeli biti agilni. Dobra je vijest da to još uvijek možete biti, iako ćete morati zaobići neke najbolje agilne prakse kako biste uspjeli. Kako, pitate se?

Ispitajte potrebu za velikim timom

Imate razvojni tim, no niste sigurni spada li on u kategoriju velikih timova koje spominjemo? U kontekstu primjenjivosti ovog vodiča, velikim razvojnim timom smatramo svaki tim ili skup podtimova koji broji od 20-ak do nekoliko stotina članova i sudjeluje u razvoju proizvoda za implementaciju kojeg je potrebna suradnja niza različitih specijalnosti.

Ako ste utvrdili da imate velik razvojni tim, najprije se zapitajte treba li vam on zaista! Naime organizacije često pretpostavljaju potrebu za velikim i složenim timovima. Razlozi tome su zaista raznovrsni, no najčešće je riječ o pretjerano složenom razvojnom procesu ili je organizacija i dalje sekvencijalno, waterfall organizirana, ili je u organizaciji takva praksa da je drugačije jednostavno nezamislivo. Kao rezultat pretjerane specijalizacije uloge zaposlenika te birokracije potrebne za organiziranje i validaciju rada, za posao petero ljudi može biti potrebno i desetero visokospecijaliziranih zaposlenika. Nikada nećete imati tim od 100 ljudi, već ćete imati skup timova koji sveukupno broje 100 ljudi, odnosno imat ćete tim timova. Pristup “podijeli pa vladaj”.

Podredite strukturu tima poslovnim zahtjevima

S obzirom da ste na drugoj točki, pretpostavljamo da želite podijeliti vaš tim na više manjih timova, ali vas zanima kako? Ukratko, preporučujemo podjelu i specijalizaciju timova prema funkcionalnim cjelinama proizvoda koji razvijate, a ne prema komponentama i tehnološkim slojevima tog istog proizvoda. Detaljnije, u Scrumu i drugim agilnim okvirima preporuča se organizacija tima oko feature timova, dugotrajnih, višedisciplinskih i samoorganizirajućih timova koji implementiraju cjelovite zahtjeve klijenta. Nisu organizirani oko specifičnih komponenti sustava, već su vertikalni, višekomponentni timovi koji mogu raditi na svim modulima potrebnim za implementiranje poslovnog zahtjeva.

Za razliku od feature timova, u tradicionalnim, komponentnim timovima ljudi se grupiraju oko pojedinih tehnoloških funkcija, odnosno komponenti sustava. Takva organizacija rezultira usko specijaliziranim timovima koji najčešće odgovaraju horizontalnoj podjeli sustava u slojeve, poput npr. UI tima, middleware tima, DB tima i drugih.

Iskusni feature tim ponaša se poput start-up poduzeća – agilan je, s velikim mogućnostima prilagodbe zahtjevima klijenta te minimalnim troškovima razvoja. Valja istaknuti da su feature timovi u potpunosti u skladu s lean principima. Uklanjanjem jaza i tipičnog silos ustroja među različitim tehničkim funkcijama postiže se smanjenje troškova prijenosa posla, čekanja, količine posla u tijeku (WIP), razmjene informacija te drugih poznatih lean otpada. Feature timovi ključ su smanjenja vremena do tržišta i skaliranja agilnog razvoja.

1

Tranzicija prema feature timovima

Uvjerili smo vas da su feature timovi odličan koncept i sada želite timove organizirati na taj način, no već ste organizirani komponentno? Na sreću postoji nekoliko strategija tranzicije prema feature timovima. Za većinu organizacija uvođenje feature timova složena je promjena organizacijske strukture i načina razmišljanja. Sljedeće strategije omogućuju postupnu tranziciju, smanjujući tako sveukupni opseg i rizik promjene:

  • reorganizacija prema velikim višekomponentnim feature timovima,
  • postupno širenje odgovornosti komponentnog tima.

Cilj reorganizacije prema velikim višekomponentnim timovima je grupirati stručnjake iz komponentnih timova u jedan tim koji kolektivno posjeduje cjelovito znanje o sustavu za određeno poslovno
područje. Raspuštanje svih komponentnih timova u jednom koraku često predstavlja velik organizacijski pothvat. Zato preporučujemo da se feature timovi formiraju postupno, jedan po jedan, prema projektnim potrebama, toliko dugo dok svi članovi komponentnih timova ne postanu članovi nekog feature tima.

Postupnim širenjem odgovornosti komponentnih timova u više se faza srodni komponentni timovi (oni koji često zajedno surađuju) stapaju u krupnije, višekomponentne timove, dok se na kraju
ne pretvore u potpune feature timove.

2

Specijalisti su legitimni

Potreban vam je specijalist, a Scrum nalaže da članovi tima moraju biti generalisti. Kako dalje? U većim razvojnim timovima često postoji prolazna potreba za dodatnim znanjima i vještinama koji inače nisu dio feature tima (DBA, grafički dizajner…), a potrebni su za implementaciju poslovnog zahtjeva. Preporučeni je pristup radu sa specijalistom korištenje takozvanih timskih konzultanata. Timski konzultant je osoba unutar organizacije koja je dostupna za obavljanje određenog visokospecijaliziranog posla i neposredno ispunjava jaz u ekspertizi tima i potreba projekta. umjesto da se posveti jednom timu, timski konzultant nudi svoje usluge internog konzultanta, pružajući specifična znanja prema potrebi. Pravovremena dostupnost specijalista često predstavlja usko grlo u planiranju i izvođenju posla. Stoga vam preporučujemo da u radu specijalista fokus uvijek bude na podučavanju i provjeri rada tima, a ne na izoliranom izvođenju zadatka.

Koristite neovisne timove za testiranje i integraciju

Neovisni tim za testiranje često je potreban na srednje do velikim agilnim projektima kako bi se poboljšala kvaliteta testiranja. Nemojte krivo shvatiti: ovo testiranje ne zamjenjuje testiranje feature tima, već ga nadopunjuje i provodi se paralelno s njim. Testiranje se provodi minimalno svake iteracije, iako je poželjno i češće. Provodi se na naprednije načine nego je to moguće prilikom razvoja. Provjeravaju se nefunkcionalni zahtjevi, kvaliteta usluge (Q oS), sigurnosti, reprodukcija tehničkih problema te ostali aspekti koji inače nisu obuhvaćeni poslovnim zahtjevima.

Za složene sustave, na kojima veliki timovi uobičajeno i rade, učinkovita integracija sustava često je presudna za uspjeh. Iako to na početku najčešće nije slučaj, s razvijanjem sustava raste i potreba za neovisnim timom za integraciju. Takav tim možemo smatrati specijaliziranom vrstom komponentnog tima koji uz uobičajene razvojne aktivnosti i istražuje i ispravlja integracijske probleme.

Ne zanemarite razmjenu znanja

Uveli ste poslovno orijentirane timove i sada vas brine da bi to moglo štetiti tehničkoj inovativnosti vaše organizacije? Jedan od rijetkih nedostataka feature timova jest to što su, za razliku od komponentnih timova, stručnjaci istog tehničkog područja distribuirani u različite timove i izolirani jedni od drugih. Navedeno rezultira otežanom razmjenom tehničkog znanja i iskustva, a dobre ideje sporo se propagiraju kroz organizaciju. Jedino rješenje je ponovna uspostava horizontalne komunikacije među stručnjacima istog tehničkog područja. Preporučujemo vrlo poznat i uspješan pristup: koncept zajednica praksi (Community of Practice).

Zajednice prakse neformalne su grupe pojedinaca istih vještina koji se dobrovoljno sastaju zbog svoje strasti prema određenoj tehnologiji ili pristupu, u svrhu razmjene znanja i ideja te poboljšanja same prakse. Na velikom su projektu takve zajednice korisne za ukidanje granica i povlačenje stručnjaka iz različitih timova u jednu zajednicu, s jedinstvenim ciljem učenja, razmjene iskustva i inovacije.

SelfOrgTeam_9_0611_v2

Imajte snažan fokus na koordinaciji

Koordinacija je vjerojatno najvažnija i najutjecajnija aktivnost u radu s velikim razvojnim timovima. No kako ostvariti kvalitetnu koordinaciju bez uvođenja teškog management procesa? Većina agilnih praksi i ceremonija usmjerena je upravo poboljšanju kolaboracije unutar i izvan timova. Međutim za potrebe srednjih i velikih razvojnih projekata standardni oblici koordinacije i suradnje nisu dovoljni. Kako bi se omogućila kvalitetna i pravovremena koordinacija na svim razinama, potrebno je skalirati agilne prakse i uvesti hijerarhiju u većinu rola i sastanaka s kojima se
uobičajeno susrećemo u agilnim metodologijama. Postoje mnogi oblici koordinacije, ali detaljnije ćemo opisati samo tri najvažnija oblika: koordinaciju poslovnih zahtjeva, koordinaciju radnih aktivnosti i koordinaciju arhitekture.

Koordinacija poslovnih zahtjeva

Rad na proizvodu s više od pet timova složen je za timove (teško je istovremeno raditi na cijelom proizvodu), ali i za Product Ownere (teško je raditi s velikim brojem timova). Zato je dobar pristup skaliranje feature timova grupiranjem srodnih timova u veća poslovna područja. Poslovna područja predstavljaju kategorije poslovnih zahtjeva te su, poput feature timova, orijentirana prema klijentu, ne mapirajući se nužno na arhitekturalne komponente. Zahtjevi jednog poslovnog područja definiraju se, ažuriraju i prioritiziraju neovisno od zahtjeva drugog područja. Taj posao obavlja Product Owner, specijaliziran za to poslovno područje. Svi Product Owneri poslovnih područja čine zajedno s glavnim Product Ownerom jedan tim – Product Owner tim, koji se sastaje redovito (npr. na kraju svake iteracije) u svrhu razmjene informacija, dogovora prioriteta te rješavanja svih sporova vezanih uz poslovne zahtjeve.

Koordinacija radnih aktivnosti

U suradnji više timova često je korisno znati što drugi timovi rade i s kakvim se problemima susreću. Za koordinaciju rada tehnologije i trendovi | Organizacija velikih razvojnih timova unutar tima najčešće se koristi dnevni sastanak, tzv. Daily Scrum, na kojemu članovi tima redovito komuniciraju svoj trenutačni status i aktivne probleme. Kako bi se ista koordinacija učinkovito skalirala razinu više, predstavnici timova prisustvuju dnevnom koordinacijskom sastanku timova, Scrum of Scrums, gdje se ista vrsta informacija dijeli na timskoj razini. Uz klasični koordinacijski sastanak, na kojemu najčešće sudjeluju voditelji timova, svakako preporučujemo i paralelno održavanje koordinacijskih sastanaka po disciplinama – npr. koordinacija testera ili koordinacija analitičara. Takav pristup omogućuje kvalitetniju sinkronizaciju aktivnosti u zajedničkim radnim zadacima i pri radu sa zajedničkom, dijeljenom infrastrukturom.

Koordinacija arhitekture

Činjenica je da je bez kvalitetne koordinacije arhitekture gotovo nemoguće razviti kvalitetan proizvod. Nedostaci koordinacije najčešće su vidljivi tek u kasnim fazama razvoja – prilikom integracije komponenti te kasnije prilikom održavanja, koje zbog nemogućnosti evolucije i tehničkih poteškoća postaje znatno skuplje. Analogno ulozi Product Ownera, preporučujemo uvođenje tehničke uloge Architecture Ownera. Ovu ulogu najčešće poprima viša tehnička osoba ili često voditelj tima, koji je svojevrstan moderator arhitektonskih odluka tima i kao dio ekspertnog tima uključen je u stvaranje inicijalne arhitekture sustava temeljem inicijalnih poslovnih zahtjeva. Architecture Owneri razlikuju se od tradicionalne uloge arhitekta po tome što oni nisu jedini odgovorni za postavljanje arhitekture sustava, već samo olakšavaju razvojnim timovima njezino stvaranje i kontinuirani razvoj.

1361303728175

Izneseni savjeti i prakse svakako ne predstavljaju cjelovit popis, već samo kratak presjek određenih praksi koje su se u organizacijama pokazale uspješnima. Nažalost, jedinstven pristup za organizaciju velikih razvojnih timova ne postoji i u dobroj se mjeri treba razviti u vašoj organizaciji. Ne zaboravite: agile je fokusiran na fleksibilnost i prilagodbu načina rada potrebama projekta. Dok će nekim projektima samo neki od ovdje iznesenih pristupa biti potrebni, drugima će oni biti tek dio veće priče.

Tagovi:
Povratak