Tango Nuevo

Tango Nuevo

KOMMENTAR: "Agile" it-utvikling er som når et par danser tango.

Begge kan grunntrinnene i søvne og har selvtillit i massevis, de følger hverandre smidig og stoler på hverandre. De vet presist hva de gjør, de finner på nye trinn mens de danser, og de har stor glede av det. Raske føtter har de også.

Det er stor nysgjerrighet i markedet for "agile programming" som på norsk er døpt "smidig systemutvikling". Hver gang det blir arrangert kurser, møter det opp en masse folk. De tiltrekkes av det frie og kreative som metodikken lover. Vekk med de tykke metodehåndbøkene og eviglange spesifikasjonene, det er bedre å bruke sitt hode, tenker de. Tiltrekningskraften er lett å forstå. Men "agile" er ikke magi. Også her finnes det regler, men de er annerledes.

Den vanlige måten å utvikle systemer er i prinsipp tredelt. Først beskriver man nøye det som skal lages, deretter lager man det og til slutt tester man det for å fjerne feil og mangler. De som bestiller arbeidet deltar til å begynne med og på slutten. Utviklingen gjøres av folk som er utdannet til det, de spør bestilleren når noe er uklart. Bestillerne er opptatte personer, de har ikke tid til å delta aktivt i arbeidet. Det er ikke tid til å "danse tango".

Smidig utvikling innebærer at den som bestiller samarbeider med den som utvikler. Hele tiden, aktivt. De sitter sammen, diskuterer, planlegger, utfører, forandrer oppfatning, finner nye veier, alt i en integrert prosess. Ekte, direkte, engasjert teamarbeid. Teamet leverer programmer som lar seg teste hver uke eller minst annenhver uke. Målsetningen med "agile" er høy produktivitet, raskere gjennomføring og at man beholder endringsdyktigheten hele veien. De detaljerte kravene kan ikke spesifiseres i forkant, de blir til underveis. Å utvikle systemer er en læreprosess, kravene endres i takt med at vi lærer og tiden går.

Disse stikkord gir noe av det karakteristiske ved metodikken. Gruppen kan ikke være stor, maksimalt 12 personer som er den øvre grensen av et "jaktlag". Helst ikke flere enn ni til ti. Gruppen må bestå av bestillerpersoner og utviklerpersoner, typisk 80 prosent utviklere, 20 prosent bestillere. Bestillerne må ha myndighet til å treffe valg og beslutninger uten å måtte spørre sin sjef og sjefens sjef først. Bestillerne må derfor kjenne temaområdet svært godt og ha sterk ryggrad. Blant utviklerne må det finnes folk som har arbeidet på denne måten før og kan veilede de andre.

Da kommer spørsmålet: Er dette mulig? Finnes det folk som kan og vil påta seg bestillerens rolle? Er bedriften villig til å bruke dem til systemutvikling? Kan vi finne bedrifter som overlater utviklingsprosjekter til en håndfull personer? Er det ikke best og tryggest med spesifikasjoner som er signert av noen høyt oppe i hierarkiet, med styringsgruppe for å dekke ryggen og prosesshåndbøker? Møteprotokoller og dokumentasjon må vi vel ha?

Jeg tror at "agile" ikke egner seg for alle prosjekter og for alle bedrifter. Prosjektene må være passe store, eventuelt må store prosjekter kunne deles slik at de ligger i sekvens etter hverandre. Ikke mer enn ett eller maksimalt to av fem prosjekter egner seg. Bedriften kan ikke være gjennomsyret av hierarkisk tenkning – at de overordnede alltid vet best, det er derfor de er kommet så høyt på strå. Bedriftskulturen og utviklingsmetodikken må passe sammen.

"Agile" kan høres ut som hippienes våte drøm. No rules! Ingen planer, ingen prosedyrer, nå kjører vi gutter! Sånn kan det ikke være. Disiplin er essensielt. Det må finnes rammer, retning og måldatoer. Det er ikke sånn at vi holder på til vi blir ferdig. Poenget er å levere nyttig funksjonalitet hele tiden og mest mulig nytte i løpet av en på forhånd fastsatt ramme. Det er heller ikke slik at naturlovene blir opphevet. Verden er som den alltid har vært. For eksempel må vi ta i betraktning at folk kan slutte underveis av ulike grunner. Andre må kunne overta det de holdt på med. Derfor må det finnes stringent endringskontroll og programmeringsstandarder. Folk må kunne lese hverandres kode – ikke bare "må kunne", de skal!

Skal vi få frem produkter som er til å stole på, må de som jobber være profesjonelle og erfarne. "Agile" er ikke amatørenes juleball, det krever de beste og mest motiverte vi har.

hidas@online.no

LES OGSÅ: Ikke bare for spesielt interesserte

Er det noen som husker blåpapiret?

Når det piper i telefonen

Les om:

Enterprise