Det er Javazone igjen i Oslo Spektrum. Et tilbakevendende tema er «agile method» eller «smidig utvikling», en kategori utviklingsmetoder som blant annet omfatter Scrum. Smidig utvikling er et alternativ til «fossefallsmetoden». Det dreier seg om å dele prosjekter inn i etapper som kan settes i produksjon underveis, og om kontinuerlig og nær kontakt med dem som skal bruke systemet.
Erfaringene til dem som bruker Scrum eller annen smidig metodikk, er jevnt over positive: Prosjektene går raskere, kostnadene går ned, kundene er mer tilfredse og kodekvaliteten går opp. Men store og komplekse prosjekter stiller egne utfordringer til smidighetsprinsippet, og ordninger og verktøy som strekker til for mindre utviklergrupper virker ikke når større eller geografisk spredte grupper skal koordineres, eller det dukker opp andre kompliserende forhold.
– Det er derfor jeg arbeider med en modell for hvordan smidige utviklingsmetoder kan skaleres, sier Scott Ambler, en av smidighetens mer kjente internasjonale evangelister.
Ambler foredro om skalerbar smidighet på Javazone. Han har skrevet bøkene Agile Modeling, Agile Database Techniques og The Object Primer 3/e der han gir detaljerte beskrivelser av sin metodikk, Agile Modeling. Han arbeider i dag for IBM, nærmere bestemt innen utviklingsverktøyene til Rational.
– Jeg deler smidig utvikling i tre kategorier, sier han i en samtale med digi.no. — Basiskategorien er når man holder seg til selve kjernen i metodikken, og fokuserer kun på selve utviklingen. Skal du opptre profesjonelt, trenger du noe mer, fordi du må håndtere hele livssyklusen til koden. Da dreier det seg om disiplinerte og smidige leveranser. Man forholder seg ikke bare til verdiene som skapes, men også til risiko, og trekker inn et rammeverk for prosesstyring. Den tredje kategorien dreier seg om å skalere smidig utvikling, det vil si «Agility@Scale».
Ifølge Ambler spiller sju faktorer inn i begrepet «skalering». Mange av faktorene gjenspeiler kompleksitet heller enn mengde:
- Hvor mange som er med i prosjektet, er alltid viktig, ifølge Ambler
- Geografisk fordeling er ofte en utfordring, fordi de færreste utviklergruppene sitter tett sammen. Risiko øker når utviklerne er fordelt på ulike etasjer, bygg, byer eller land.
- Offentlig lov- og regelverk gjelder også utviklere. Ambler har erfaring for at mange klager over byråkratisk innblanding i utviklingsprosessen.
- Å forholde seg til mange ulike avdelinger, brukergrupper, partnere og så videre stiller spesielle krav til hvordan man håndterer blant annet opphavsrett og sikkerhet.
- Ulike kulturer og betraktningsmåter er en annen kilde til økt kompleksitet der mange organisasjoner er involvert.
- Teknisk kompleksitet kan vanskeliggjøre kodingen betraktelig. Ifølge Ambler må fire av fem prosjekter hanskes med data og programvare fra foreldede systemer, eller et miljø med heterogene plattformer.
- Pålegg fra bedriften om arkitektur, drift, gjenbruk og så videre er en ytterligere kilde til kompleksitet.
– Skalering dreier seg med andre ord om langt mer enn bare å samordne flere og flere utviklere. Det er mange forskjellige situasjoner og utallige kombinasjoner av ulike faktorer. Man må velge verktøy som lar seg tilpasse de aktuelle behovene. Jeg har erfaring for at utviklergrupper havner i problemer fordi de tviholder på verktøy og teknikker som ikke egner seg til kompliserte situasjoner.
Rådene som Ambler gir til utviklergrupper i problemer, gjenspeiler sunt folkevett.
– Et typisk eksempel er en utviklergruppe som famlet. De var flere enn noen av dem var vant med, og arbeidsplassene var ikke samlet. Likevel fortsatte de å bruke metoder som bare egner seg for små grupper. Å orientere seg om framgang ved å be alle svare på tre spørsmål fungerer bra i små grupper, men ikke når man er femti eller hundre. Det grunnleggende rådet er å hente inn nye kommunikasjonsverktøy, for eksempel Rational Team Concert i stedet for kartotekkort.
Brukermedvirkning er en kjerne i smidig utvikling.
– Når utviklerne sitter spredt, er det selvfølgelig mer utfordrende å trekke inn brukerne. Det er flere mulige løsninger. Man kan satse mer på modellering, og man kan dele seg i undergrupper. Måtene man trekker inn brukerne på, må bli mer varierte. Mye av Jazz-plattformen til Rational er innrettet mot dette.
Ambler mener det er viktig i store smidige prosjekter å sørge for et uavhengig system for testing.
– La oss si en av utviklergruppene sitter i India, og at man ønsker å sjekke hvor god koden de produserer faktisk er. Det finnes verktøy for slikt, for eksempel «Razor» [Rational Software Analyzer]. Jeg anbefaler at det brukes en gang i uke. Bygger man nettsteder, finnes tilsvarende verktøy, blant annet for sikkerhetstesting.
Finnes det et øvre tak på hvor mange som kan være med i et prosjekt basert på smidig utvikling?
– Noen utviklingsprosjekter må jo være store. Et databasesystem som DB2 kan ikke utvikles av en gruppe på ti. I IBM har vi levert prosjekter med 500 deltakere. Jeg har hørt snakk om prosjekter med 1000 og flere deltakere.
Et viktig tema i alle utviklingsprosjekter er produktivitet.
– I våre undersøkelser finner vi belegg for at grupper som driver smidig, leverer bedre kvalitet, krever færre ressurser, holder timeplanen bedre og lager programvare som brukerne stiller seg mer positive til.
Ambler sier han ofte stusser over at bedriftsledere krever produktivitetsmål på smidig utvikling, uten å ha et produktivitetsmål på andre utviklingsmetoder.
– Det er et merkelig selvbedrag å se bort fra all erfaring om at smidig utvikling er bedre og mer effektivitet, og samtidig kreve et produktivitetsmål uten å ha begreper om hva de skal sammenlikne det med.
Det er viktigere, ifølge Ambler, å følge med i den relative utviklingen, enn å måle et absolutt nivå.
– Det er endringen som er interessant, ikke nivået. Blir du flinkere eller dårligere over tid? Blir du dårligere, har du et alvorlig problem.
I den smidige verden kan man ikke måle produktivitet absolutt, slik at man kan si om en gruppe gjør det bedre enn en annen. Ifølge Ambler er det derimot nærmest trivielt å måle endringer i en gruppe over tid.
– Vi har et punktsystem for å måle «fart» [velocity]. La oss si du greier 18 poeng i en første iterasjon, og så 20 poeng i den neste. Da er du blitt bedre. Måler du derimot 17 poeng, vet du at gruppen må skjerpe seg.
Fordi dette punktsystemet, i motsetning til «function points», ikke tar mål av seg til å sammenlikne en gruppe med en annen, er det svært enkelt å implementere. «Function points» er dyrt, og ifølge Ambler er det mange faktorer som undergraver metodens objektivitet.
Det relative punktsystemet er brukt i en løsning som Rational nylig har lansert, ved å ta i bruk teknologi fra et annet av IBMs oppkjøp, Cognos: Rational Insight.
– Tankegangen er at en leder med ansvar for tjue utviklergrupper, trenger et verktøy for å skaffe seg oversikt. Beslutningsstøtteteknologi fra Cognos er derfor brukt til å lage et dashbord som henter data fra flere kilder. Punktutviklingen og andre data fra hver utviklergruppe hentes automatisk i tilnærmet sanntid: Tidsavviket er maksimalt et par timer. Erfaringen er at dette gir et grunnleggende sett korrekt bilde av hva som skjer.
En fordel for utviklergruppene, er at dette verktøyet gjør manuell rapportering overflødig.
– Alle hater statusrapporter. Her kan man slippe det. Det er et godt eksempel på hvordan integrerte verktøy avskaffer byråkrati. Vi har helt enkelt lagt Cognos på toppen av Rationals Jazz-plattform.
Les også:
- [15.09.2009] IBM lanserer kjapp beslutningsstøtte
- [09.09.2009] Java-utviklere fyller Oslo Spektrum
- [12.06.2006] Smidig utfordring til «databasefolket»
- [08.06.2006] Vær smidig, glem kravspec-en
