Utviklersamlingen JavaZone 2005 kjøres i Oslo denne uken. Oppslutningen er større enn noen sinne. Konsulentselskapet Bekk bidrar med sju foredrag. To av foredragsholderne fra Bekk, Trond Arve Wasskog og Reidar Sande, forteller her noe av det de har på hjertet. Begge har vært med i Bekk fra starten, og er henholdsvis prosjektsjef og fagsjef.
– Smidig metode, eller «agile method», er et området der det skjer veldig mye, poengterer de.
Det dreier seg om nye tanker for å gjøre skreddersydd applikasjonsutvikling smidigere og raskere, og følgelig mer innbringende for begge parter. Det finnes et Agile Manifesto som samler en del av prinsippene.
– Smidig metode angriper problemet med kravspesifikasjoner. Kravspesifikasjoner skal ikke skrives i stein, men må kunne endres hele tiden, sier de to.
I stedet starter man med testen.
– Vi tester fortløpende under hele utviklingsprosessen. Vi skriver testen på forhånd, for både det funksjonelle og det tekniske. Dette er en disiplinert heller enn en formalisert framgangsmåte.
Det starter altså med test. Så lages det kode. Så tester man koden. Man stykker opp leveransen i korte etapper – iterasjoner – på et par tre uker.
Poenget er å komme ut av rytmen «kravspesifikasjon – design – utvikling – test» og heller levere bit for bit. I stedet for at kunden lener seg tilbake etter å ha bidratt til kravspesifikasjonen og så venter et perfekt system etter et år eller to, blir kunden trukket inn ved hver etappeovergang. I stedet for at det går et år eller to før man ser noe av det nye systemet, setter man det viktigste i produksjon allerede etter noen få måneder.
– Vi må selvfølgelig starte med krav, men de er ikke nødvendigvis komplette. Vi behøver ikke ha med oss alt, men nok til å starte utviklingen. Så er det design, utvikling og testing av en bit av løsningen.
Denne første etappen tar to til fire uker.
– Da kan man vise det til kunden. Det frigjør nye ideer. Så kjører man en ny etappe på to til fire uker. Etter noen etapper har man en «release» som kan gå ut i produksjon.
En «release» behøver ikke bare mer enn tre måneder, gjerne mindre.
– Den kritiske funksjonalitet skal være i den første releasen. I forhold til gammelmetoden kan kunden begynne å høste gevinster mange måneder tidligere.
Ifølge Wasskog og Sande er overspesifisering et typisk trekk ved «gammelmetoden». De viser til USAs forsvarsdepartementet som konstaterte at 45 prosent av den opprinnelige funksjonaliteten fra den store initiale kravspesifikasjonen, aldri ble benyttet.
– Den smidige metoden tar hensyn til læringskurven i prosjektet. Den tar alltid med det som gir verdi i øyeblikket, og man omprioriterer ut fra det. Da får man et system som oppfyller kravene som er aktuelle i det øyeblikket du går på lufta, ikke dem som var for et år tilbake da prosjektet var helt i startfasen.
Wasskog og Sande har gode erfaringer med å la utviklingsprosessen styres av en eller flere som kan selve «domenet», det vil si forretningen som applikasjonen skal brukes på.
– Ved et tilfelle lot vi den forretningsansvarlige styre utviklingen, og vi la opp til etapper, eller «iterasjoner» på to uker. Hver iterasjon startet med en samling av forretningsansvarlig og utviklere. De plukket ut hva som skulle gjøres i neste iterasjon. Så gikk utviklingsgruppen sammen og delte opp dette i mindre biter, med tanke på at hver bit ikke skulle ta mer enn tre dager. Når bitene var bestemt, skrev man testen for hele iterasjonen, for å spesifisere nøyaktig hvordan alt skulle fungere når det var ferdig. Etter hvert som utviklingsarbeidet går, kjører man flere og flere tester. På slutten av iterasjonen skal alle testene kjøre, det viser at alt er gjort.
Det viste seg at prioritetene endret seg hos den forretningsansvarlige i løpet av prosessen. Dette er ikke et irritasjonsmoment for utviklerne, men et normalt utslag av læring. Tilbakemeldingene etter hver iterasjon lærte også utviklerne mer om forretningsområdet.
– Mentaliteten med «vi har laget spekken, værs så god lever», er borte. Partene lærer mer av hverandre.
Det krever at kunden må allokere ressurser kontinuerlig, ikke hoppe av når kravspesifikasjonen er klar.
– Første gang vi prøvde dette var arbeidet preget av usikkerhet fra både vår og kundens side. Etter et par iterasjoner ble det mer flyt i hele prosessen.
Sande og Wasskog understreker at det krever disiplinert opptreden fra alle parter.
– Hver enkelt har sin rolle med hensyn til beslutninger og egen funksjon i prosjektet. Når man har prioritert i en iterasjon kan man ikke omprioritere før iterasjonen er ferdig.
En fordel for alle, er at man blir mer herre over tiden.
– Testingen gjør at man får fortløpende tilbakemeldinger om hva som er ferdig og hva som ikke er det. Det gir god estimeringsnøyaktighet. Tre dager er oversiktlig for å vurdere hvor mye tid noe tar. Tar man tre uker om gangen, vet man egentlig ikke hvor lang tid noe tar. Man prioriterer inn i en iterasjon det man tror man kan levere. Man kan hente inn et krav til hvis man har prioritert for lite, eventuelt kutte. Det er teamet som helhet som skal ta stilling til dette.
Den smidige metoden gir et eget måltall for framdriften.
– Vi sier at farten i prosjektet, på engelsk «velocity», måles med testet funksjonalitet per iterasjon. Tre iterasjoner ute i et prosjekt ser man at man leverer et visst tall. Hvis det er viktig at man går «live» innen en gitt dato, er det da enklere å anslå hvor godt man ligger an i forhold til fristen.
Sande og Wasskog understreker at de har ikke noe «bevis» for at den smidige metoden er den eneste rette, selv om de har en klar følelse av at den er en mye mer riktig måte å drive utviklingsarbeid på. Bekk driver fortsatt prosjekter etter «gammelmetoden».
– Vi har opplevd å ha levert alt etter en bestemt kravspesifikasjon og så fått tilbakemelding om at kunden ikke er fornøyd. Med den smidige metoden lever misforståelser bare i to uker, ikke i ett år.
Les også:
- [22.08.2008] Nå bør du bli Scrum-master
- [27.09.2006] Tjener rått på å holde seg unna produkter
- [07.08.2006] JavaZone starter eget «universitet»
- [08.06.2006] Vær smidig, glem kravspec-en
- [31.01.2006] Bekk girer opp med flere folk
- [13.09.2005] Javafolket foran SOA-oppklaring
- [30.08.2005] SOA-krig på norsk konferanse
- [23.06.2005] Kjente profiler på JavaZone 2005
- [07.04.2005] Ett språk for program og databaser
- [02.11.2004] Svært lønnsomt med moderne utviklerverktøy
