💬 Spørsmål fra nettverket 💬
En evig utfordring er hvordan utviklere i teamet skal få løpende tilbakemeldinger på jobben de gjør (kodekvalitet, leveranser, løsningsvalg osv). Feedback via pull requests varierer siden folk i teamet har ulike preferanser på hvor mye tilbakemeldinger de liker å gi – eller er i stand til å gi. Tech Lead skal vel gjerne kunne gjøre dette, men i praksis fungerer ikke dette alltid. Tech Lead er overarbeidet, klarer ikke følge opp både frontend, backend like bra – og er heller ikke kapabel til det. Personalleder er ikke teknisk og for langt unna teamet. PO er ikke teknisk og skal ikke gi tilbakemeldinger på dette. Hvordan løser dere dette i teamene deres?
Å gå over til parprogrammering kan gi verdi for utviklingsteam. Ofte kan pull requests, der en senior utvikler kvalitetssikrer andres kode, forsinke arbeidet unødvendig. Flere organisasjoner har innført parprogrammering med gode resultater.
En viktig erkjennelse er at det ikke bør være én persons ansvar å sikre kodekvalitet. Dette gjelder spesielt når team jobber med ulike teknologistakker, noe som gjør det vanskelig for én person å ha oversikt over alt.
🚀 Ulike måter å sikre kodekvalitet
Parprogrammering er likevel kun en av metodene som kan brukes. Under er en liste med andre metoder for å sikre god kodekvalitet som en del av hverdagen:
- Codereview som del av team-prosessen: Koden gjennomgås løpende av flere i teamet, i stedet for at det skjer i en egen fase senere av en person
- Show & Tell i teamet: Teamene viser frem arbeidet sitt og diskuterer hva som kan forbedres.
- Automatiserte tester: Integrer tester i deployment-prosessen, så utviklerne får umiddelbare tilbakemeldinger fra systemet.
- Synlige metrikker: Data på kvalitet og stabilitet er tilgjengelig for hele teamet, og tilbakemeldinger fra kundene skaper bevissthet.
- Futurespect: Planlegging av tekniske forbedringer som kan heve kvaliteten på produktet.
💪🏼 Eierskap og ansvar i teamet
Uansett hvilke metoder som velges, er det avgjørende at teamet selv tar ansvar for kodekvaliteten og bruker de verktøyene som passer best for dem. Å investere tid i å styrke teamets forståelse av kvalitet og stabilitet er viktig, slik at utviklerne ser det som en naturlig del av deres rolle. Når teamet selv får definere hvordan kvalitet skal sikres, fremmer det eierskap, læring og utvikling, i stedet for at eksterne pålegger løsninger utenfra. Dette skaper en kultur for kontinuerlig forbedring.
🫂 Umodne team trenger støtte
For team som kanskje er umodne eller nye i sine prosesser, er det viktig å gi dem starthjelp. Dette kan gjøres ved å investere tid i å styrke techleads som fasilitatorer, og gi dem de rette verktøyene for å lykkes. Her kan man fokusere på å bygge opp deres evne til å lede teamet gjennom prosesser for kvalitetsforbedring. Etter hvert som teamet modnes, vil de naturlig ta mer ansvar og eierskap for prosessene selv.
Som leder bør man tydelig kommunisere at kvalitet og stabilitet er mål man ønsker å oppnå, men samtidig la teamene finne ut av hvordan de best kan nå disse målene.
🛣️ Langsiktig oppfølging og dokumentasjon
Selv om parprogrammering er et flott verktøy, dekker det først og fremst mindre, daglige forbedringer. Derfor kan det være nyttig med 1-til-1-samtaler mellom techlead og utviklere hver tredje til sjette måned. Her kan man diskutere utviklerens styrker, svakheter, hva de liker og hva de ønsker å forbedre. Det kan også være en fin anledning til å avtale kurs, mentoring eller fokusert tid til læring.
Architectural Decision Records (ADR) er et nyttig verktøy for å dokumentere viktige teknologivalg. ADR beskriver:
- Hvilket problem som skal løses
- Hvilke alternativer som er vurdert
- Hva som ble valgt og hvorfor
Dette gir teamet en historikk å se tilbake på, og alle kan lese og gi innspill på dokumentasjonen.
Oppsummering
Uansett hvilken metode teamet velger, er det avgjørende at de selv eier prosessen. Kombinasjonen av teknikker som parprogrammering, jevnlige samtaler, og dokumentasjon som ADR (Architectural Decision Records) kan bidra til bedre kodekvalitet og læring. Eierskap fremmer ansvar, læring, og kontinuerlig forbedring. Tilbakemeldinger kan gis gjennom flere metoder, og teamene bør tilpasse dem til sin situasjon for å finne balansen mellom kvalitet, fremdrift, og utvikling.