Har du startet å bruke smidige metoder, men lurer på hvordan du skal få det til å fungere bedre? I denne artikkelen kan du få konkrete tips om hvordan å forbedre kommunikasjonen, kvaliteten og forretningsfokus på ditt smidige eller ikke-smidige utviklingsprosjekt.
Bedre kommunikasjon
- Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
- Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
- Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner «venter», «under arbeid» og «ferdig». Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til «ferdig» hver dag.
Bedre kvalitet
- Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
- Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
- Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.
Bedre forretningsfokus
- Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
- Bli helt ferdig med funksjonalitet: Teamet får kun «poeng» for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
- Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.
Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.