torsdag 30. juni 2011 Softwareutvikling Team
Det er på tide med et gjensyn med de små tegneserieheltene mine. Denne gangen dreier det seg om effekten av å ha mange utviklere som jobber på det samme prosjektet.
Jeg har alltid sagt at jeg foretrekker å jobbe i små utviklingteam. Størrelsen på et team har mye å si for hvilke utfordringer man får, og hvilke resultater man kan oppnå. Historien presentert over er ikke intuitiv, men har likevel endel sannhet i seg.
Et viktig stikkord er kommunikasjon. Etterhvert som et team vokser øker også antall kommunikasjonspunkter internt i teamet, og dermed også antall steder hvor kommunikasjonen kan bryte sammen. Tiden man må dedikere til kommunikasjon øker også betraktelig (figur 1 og 2).
Sammarbeid er vanskelig! Vi fokuserer mye på å lære å bli gode programmerere, men glemmer ofte at sammarbeid er en helt egen og veldig viktig ferdighet alle team-medlemmene trenger.
For å begrense problemene med kommunikasjon i større team legger man mere vekt på formaliteter, planlegging og dokumentasjon. I tillegg kommer man ofte opp med rollen teamleder. Et tradisjonelt utviklingsteam har en sentral leder som styrer utviklerne. Denne lederen skal fungere som et kommunikasjons-nav mellom utviklerne (figur 3). Han/hun får den ekstremt vanskelige oppgaven å sanke inn all den informasjonen som er viktig fra hver utvikler, og distribuere dem som trenger det. Det sier seg selv at man blir veldig sårbar for “feil” i dette leddet.
Og fleksibiliteten er borte… Etterhvert som smidig/agile har blitt populært har man lagt mindre fokus på å ha en sentral, styrende leder, og begrenser mengden planlegging, dokumentasjon og andre formaliteter – for at man skal kunne være mer fleksibel. Et lite team er da helt nødvendig.
Men det finnes også ulemper med små team; de er mere sårbare for forstyrrelser, sykefravær og slike ting.
En teknikk som hjelper på kommunikasjonen i teamet, og som muliggjør team bestående av flere utviklere, er utstrakt bruk av parprogrammering. Når utviklere jobber i par fokuserer to og to utviklere på den samme oppgaven, og kommunikasjonen dem imellom er svært tett og forhåpentligvis god. Antall øvrige kommunikasjonslinjer reduseres (figur 4).
Men husk at parprogrammering også er vanskelig, en ferdighet man må trene opp.
Det finnes dem som hevder at det optimale teamet kun består av én utvikler. I artikkelen Why a Great Individual Is Better Than a Good Team sier Jeff Stibel at det er vanskelig å finne dyktige personer, men at hver av dem er verdt et uendelig antall middelmådige personer. Ikke bare det, men dyktige enkeltpersoner er ofte mer verdifulle enn grupper/team som inkluderer dyktige personer.
Når vi blir en del av et team synker nemlig vår evne til å yte – blant annet på grunn av kommunikasjonsutfordringen. Stibel sier:
“When an activity can be performed sufficiently by one person with adequate skills, doing the activity as a group should be avoided.”
I 2009 blogget jeg om menneske-problemet, hvor det blant annet refereres til forskning som påstår at dyktige programmerere kan være opp til 28 ganger bedre enn dårlige programmerere. Om du har en slik utvikler i stallen din, eller er en slik selv, så må du være klar over at for å ta ut potensialet i en team-setting så må man trene på kommunikasjon og sammarbeid, og fjerne det man kan av barriærer og muligheter for kommunikasjonssvikt og feil.
Har du positive erfaringer fra å delta i et større utviklingsteam? Hvordan var teamet organisert? Hva ble gjort for å sørge for at alle kunne bidra optimalt? Del gjerne dine meninger i kommentarfeltet.
PS: Jeg snakker ikke her om å sammarbeide med dedikerte testere, driftsfolk, eller personer med forretningskompetanse. Dette er selvsagt viktig i mange sammenhenger. Denne artikkelen omhandlet spesifikt team av programmerere.
Andre relaterte artikler: En smidig teamleder | Utviklerprofiler og fire ferdighetskategorier | Parprogrammering ansikt-til-ansikt | Egoløs programmering: De 10 bud