Smidige ting å fokusere på i min nye jobb

---

torsdag 30. juli 2009 Jobb Softwareutvikling

Som nevnt et par-tre (eller fire, fem) ganger nå begynner jeg om få dager i ny jobb. Det er utrolig mange ting jeg har lyst til å ta tak i og forsøke å gjennomføre, selv om jeg selvsagt vet alt for lite om forholdene jeg kommer til og hvilke utfordringer som er viktigst – et forbehold du må ha i bakhodet når du leser denne artikkelen.

Jeg har plukket ut fire ting som jeg føler veldig sterkt for, som jeg vil forsøke å innarbeide så tidlig som mulig. Jeg håper teamet vil se verdien i disse tingene, og at ledelsen er med på at det er viktige fokusområder. Jeg vil gjøre hva jeg kan for at utviklingsavdelingen i PSWinCom skal bli en smidig enhet som kan levere høy kvalitet or respondere raskt på endringer, og for å få til det vil jeg forsøke å jobbe med følgende…

1. Kontinuerlig integrasjon

Husker jeg riktig fra intervjurundene jeg har vært igjennom bruker man i dag ingen byggserver / continuous integration server. For meg er dette en absolutt nødvendighet for et profesjonelt utviklingsteam. Jeg satser på å installere TeamCity en av de første dagene mine (siden det er den jeg har best erfaring med – kjørte en test-install på laptopen på under 2 minutter, og integrerte Snookiepoof og Foosball Manager på rundt 15 minutter).

I tillegg vil dette være en fin øvelse å gjennomføre for at jeg skal bli kjent med hvilke løsninger vi har og hvordan de henger sammen.

En integrasjonserver er viktig av mange grunner. Den sørger for at vi har software som fungerer - ikke bare på utviklerens maskin – og at vi kan release hurtig. Den sørger for at alle testene kjører gjevnlig (se neste punkt), og reduserer betraktelig problemer knyttet til merging.

Jeg vil skape en kultur hvor man gjør hva man kan for å ikke bryte builden. Jeg vil at vi skal sjekke inn endringer så ofte som mulig, og få øyeblikkelig feedback om noe er galt. Som sagt vet jeg ikke hvordan forholdene rundt dette er i PSWinCom i dag, men jeg håper vi kan etablere kontinuerlig integrasjon som et senntralt konsept i vår utviklingsprosess.

2. Testing

Det neste jeg vil sette fokus på er testing. Vi har ingen dedikerte testressurser i mitt nye selskap, men vi leverer en tjeneste hvor stabilitet er superviktig. Jeg kjenner ikke til (og tviler på) om det eksisterer noen form for automatiserte tester i dag, men jeg vil jobbe for å gradvis få systemene våre under test.

Videre vil jeg introdusere gutta for testdreven utvikling og design (TDD), og håper jeg over tid kan illustrere hvordan dette fører til design/arkitektur som er enklere å vedlikeholde og endre, og som er mer intuitiv, i tillegg til ferre bugs og mindre regresjon, hurtigere utvikling, og en større trygghet i hva man leverer.

For som Robert C. Martin sa det i hovedtalen på NDC i år: "Debatten er over. Testdreven utvikling fungerer, og det finnes ingen gode grunner til å ikke bruke det. Faktisk kan det tenkes man bør karakterisere det som uprofesjonelt å ikke bruke det."

Igjen vil innføring av tester være en god øvelse for meg, som vil gjøre meg kjent med den eksisterende koden. Jeg leser nå Working Effectively with Legacy Code for å være bedre rystet til å skrive enhetstester for et system som i utgangspunktet ikke er designet for det.

Til slutt et lite gullkorn fra Martin Fowler: "Manual scripted testing should be a human rights violation!" Jeg tror han mener det oppriktig.

3. Kvalitetskode

Kodekvalitet har etterhvert blitt noe av det viktigste for meg som utvikler. Det er ikke nok at programvaren tilfredstiller de funksjonelle kravene – vi må også stille krav til vedlikeholbarhet, og jeg ønsker derfor at vi i vår daglige utvikling skal legge vekt på ting som enkelhet i design, ren kode, og å følge DRY, SOLID og andre prinsipper som kjennetegner en god kodebase.

Jeg ønsker også at vi skal sammarbeide godt om utviklingen som et team, og at vi skal bruke en viss grad av parprogrammering og kodegjennomgang for å øke kvaliteten og felles eierskap til koden (Coding Horror: Pair Programming vs. Code Reviews). Parprogrammering er i tillegg nok en teknikk som vil hjelpe meg som er ny på teamet til å bli kjent med de eksisterende løsningene.

4. Iterasjoner og prosess

Dette er området hvor det sansynligvis er størst forventninger til at jeg skal bruke min erfaring til å forbedre måten PSWinCom jobber på. De har brukt Scrum en viss tid, men jeg fikk inntrykket av at de selv ikke er helt fornøy med hvordan de har gjennomført det. Utfordringen er at dette punktet er det som er mest uklart for meg før jeg får et bedre innblikk i hvordan ting fungerer i dag.

Smidige prosesser er ikke enkle oppskrifter som man bare kan følge for å oppnå raskere utvikling, høyere kvalitet og forutsigbarhet. Smidige teknikker må tilpasses, og det er ikke sikkert mine erfaringer er direkte overførbare. Dessuten har det skjedd mye i Agile-miljøet etter at Scrum dukket opp (i den formen som jeg har lært); ting som Lean og Kanban er ting vi bør se nærmere på, og som sansynligvis vil passe bra i en bedrift som vår.

Uansett ser jeg på dette som en viktig oppgave – å etablere en god prosess for prioritering, planlegging og gjennomføring. Jeg ønsker at vi skal kunne slippe oppdateringer ofte – alltid ha fungerende software, og at vi skal kunne fokusere på få ting om gangen (multitasking fungere ikke!). Som jeg var inne på i forrige artikkel mener jeg det er viktig at teamet skaper denne prosessen i felleskap.

Så det var altså mine fire, smidige kjepphester. Jeg håper å kunne rapportere tilbake til mine lesere med gode erfaringer rundt alle disse om noen måneders tid.

Knagger: Clean Code, DRY, kontinuerlig integrasjon, parprogrammering, PSWinCom, Robert C. Martin, Scrum, SOLID, TeamCity, TDD

---

comments powered by Disqus