Tips og triks / 5 minutter /
33 tips til selvorganiserende programvareteam
Innenfor programvareindustrien er “selvorganiserende team” en trend i tiden. Målet er hypereffektive team som skaper de beste løsningene. Og det er mange veier man kan gå for å komme dit. På mitt team har vi jobbet mot dette målet de siste 3 årene og finner stadig noe vi kan forbedre. Her er noen tips for å komme i gang. NB! Hver og en av tipsene er like viktige!
- Sett sammen teamet av personer med utfyllende evner og interesser
- Innfør en arbeidsflyt der medlemmene på teamet har mulighet til å plukke arbeidsoppgaver etter lyst, interesse og faglig styrke
- Skap en felles ansvarsfølelse, stol på hverandre, hjelp hverandre
De tre første punktene virker som en selvfølge, men det er ikke alltid dette blir vektlagt. Gjør noe med det! - Anskaff et wiki-lignende verktøy
Dere kommer til å få bruk for det. - Bytt på å gjøre en del arbeidsoppgaver
Slik får man utvekslet kompetanse og redusert sårbarhet med tanke på “nøkkelpersoner”. - Evaluer forrige arbeidsperiode
Hvis et team skal finne ut hvordan det ønsker å jobbe må det identifisere hvor skoen trykker. Det kan for eksempel gjøres på denne måten:
- hver og en på teamet forteller hva som var positivt og negativt med forrige arbeidsperiode. NB! Ingen avbrytelser eller diskusjoner her.
- grupper negative områder
- diskuter negative områder og finn tiltak til neste arbeidsperiode - Kommuniser med produkteier og brukere
- IKKE kommuniser med produkteier/brukere ved hjelp av e-post
Det er INGEN fordeler ved å kommunisere ved hjelp av e-post:
- ingen andre enn de som får e-posten vet hva som kommuniseres
- diskusjoner er bortimot umulig å strukturere ved hjelp av e-post, slik at man kan i ettertid kan forstå innholdet
- nye medlemmer på teamet får ikke innblikk i viktig historikk - Gjerne kommuniser med produkteier ved hjelp av et wiki-lignende verktøy
- Innfør en fast puls i arbeidet
“Fast puls” betyr regelmessig å gjennomføre en del faste aktiviteter:
- avklaring av spørsmål og hindringer med produkteier
- evaluering av forrige arbeidsperiode
- demo av programvare som er utviklet
- levering av programvare - Noter ned alle hindringer og spørsmål i det daglige arbeidet, ta det opp på neste avklaringsmøte med produkteier
- IKKE la enkelthindringer stoppe flyten, det meste kan vente litt, se forrige punkt.
- Gjerne noter hindringer og spørsmål i et wiki-lignende verktøy
- Evaluer forrige arbeidsperiode. Start med å gå gjennom hvilke tiltak man satte opp forrige gang
- Vær villig til å gjøre endringer
Dette punktet virker som en selvfølge, men er basis for at teamet sammen finner fram til en god arbeidsform. Konservative teammedlemmer kan være et hinder for å gjøre forbedringer, og det er derfor viktig å være (selv)bevisst rundt dette punktet. - Ha det moro
- Møt virkelige brukere og lytt på hva de plages med, gjerne sammen med produkteier
- La minst 2-3 personer på teamet finne ut hva brukerne har behov for og hvordan systemet kan løse behovene
Husk! Det er ikke alltid at: Hva brukerne plages med = hva brukerne har behov for -> krav. Det er best å være flere personer med forskjellig bakgrunn sammen når man skal analysere dette, for å få belyst forskjellige perspektiver. - Spesifiser krav
- IKKE spesifiser krav i dokumenter
- Få produkteier til å eksplisitt godkjenne alle krav etter at teamet har bearbeidet dem
- Gjerne samle alle krav i et wiki-lignende verktøy
- Oppdater krav underveis, hver gang dere tror dere har forstått brukernes behov eller dere støter på en teknisk hindring som gjør at løsningen blir annerledes enn først planlagt. NB! Husk punkt 21!
Å spesifisere krav i dokumenter er like uhensiktsmessig som å kommunisere med produkteier på e-post. Spørsmålet “Hva er gjeldende krav?” dukker alltid opp, og det er ingen gode svar, bare upålitelige forslag: "Dokumentet som ligger på filtjener ‘X’ har kanskje siste krav", eller “Jeg mener jeg sendte ut oppdatert kravdokument på e-post i forrige uke”.
Når produkteier må ta stilling til hvert enkelt krav ved å godkjenne dem i et wiki-lignende verktøy tvinger man frem en produktiv diskusjon som er synlig for alle involverte parter. - Vær tålmodig
Endring tar tid. Selvorganisering er endring. - Automatiser kjedelige oppgaver
Kjedelige oppgaver er en risikofaktor! Når man gjør kjedelige oppgaver er det stor sannsynlighet for at man begår feil. Siden kjedelige oppgaver også ofte er tidkrevende vil en nyttig bieffekt av å automatisere være at man øker effektiviteten. - Skriv kode sammen
- Skriv og diskuter gjerne kode sammen med “testere"
- Skap en kultur der alle på teamet gjør kvalitetssikring så tidlig som mulig, det lønner seg
Koding og testing er to sider av samme sak. Målet er å skape programvare som gjør det den skal gjøre og ikke noe annet (det vil si “bugs”). Derfor bør alle på teamet gjøre begge deler. Og gjerne sammen, da det er lettere å lage riktig kode på et tidlig stadium når man er nødt til å diskutere den. Å lage riktig kode er egentlig er å finne “bugs”, før de er laget! - Lever programvare så ofte som mulig slik at teamet får tilbakemelding på utført arbeid så fort som mulig slik at teamet kan forbedre seg kontinuerlig
- Si “NEI” til oppgaver teamet ikke har lyst til å jobbe med eller ikke føler det har forutsetninger for å løse
- Evaluer forrige arbeidsperiode. NB! Dette er det viktigste tipset!
- Skaff en kunde som skjønner at det er lurt å jobbe på denne måten - eller omvend en kunde som ikke har skjønt det enda
- Følg disse tipsene og få et team av dyktige personer som ønsker å jobbe sammen over lengre tid