Fleksibel proces & metode - fordi verden ændrer sig hele tiden

Vi har erfaring for, at projekter bliver bedre, sjovere og koster langt mindre, når der er gjort et godt forarbejde i relation til at afdække de behov som projektet skal tilfredsstille, og anvendt tid på at designe et koncept, der virker fornuftigt - så dette er en essentiel del af alle vores systemudviklingsforløb.

Imidlertid så tror vi ikke på den traditionelle kravspecifikation, da den på et fundamentalt plan afviger fra vores egen indstilling til verden på følgende områder:

Kravspecifikationen forudsætter at verden ikke forandrer sig. Vi mener, at verden er i konstant forandring.
Kravspecifikationen forudsætter at it-systemer kan defineres på samme måde som et fysisk objekt, hvortil der kan opstilles klare, kvantitative krav til systemets udførsel. Vi mener, at it-systemer har en livs-cyklus som levende organismer, der udvikler sig hen ad vejen.
Kravspecifikationen forudsætter at kvaliteten af et it-system vurderes ud fra om det lever op til kravspecifikationen. Vi mener at kvaliteten defineres ud fra om it-systemet tilfredsstiller de behov der er til systemet på det tidspunkt det tages i brug.

Det nemmeste for os ville naturligvis have været at tilpasse os den traditionelle måde at tænke og arbejde på, hvor en masse tid anvendes på at specificere alle tænkelige forhold omkring et system, efterfulgt af et udviklingsforløb efter vandfalds-modellen - men da vi godt kan lide at være lidt på tværs har vi i stedet valgt at arbejde intenst med at gøre vores arbejdsmetoder og værktøjer så fleksible som muligt, og i navnligt at fokusere på at gøre det muligt kontinuerligt at forbedre dem.

Standarder - uden dem er alt kaos

Det første skridt vi tog var at indføre standarder i alle leder og kanter af vores software-udviklings-processer og værktøjer. Dette betyder at vi i vores team gør "tingene" på samme måde, og i særligt succesfulde tilfælde ikke er i stand til at identificere hvilket team-medlem, der har udviklet en given stump kode - med andre ord, så har standarderne givet os en meget stærk ressource-mobilitet med en utrolig lille omstillingstid, da alle kender den snor, der arbejdes efter.

Vores indstilling til standarder er, at de ikke er fastlagte procedurer, der til tid og evighed forbliver den samme. Hos os gælder det, at en standard gælder indtil den bliver udviklet og erstattet af en smartere, lettere eller mere fleksibel måde at opnå samme resultat på. Med andre ord så arbejder vi også kumulativt og inkrementelt med vores standarder; de er levende organismer, der udvikler sig. Måden standarder udvikler sig på hos os er ved at vi i fællesskab diskuterer potentielle løsninger, når vi står over for en ukendt situation, og på demokratisk vis vælger den løsning, der virker mest fornuftig - set ud fra den gældende standard som den nye løsning befinder sig inden for. Hvis vi så på et tidspunkt finder uhensigtsmæssigheder ved den valgte standard, så anvender vi tid på at identficiere problemerne og analysere os frem til potentielle løsninger, der så diskuteres og vedtages i fællesskab.

Konsekvensen af ovenstående måde kontinuerligt at forbedre vores processer på betyder, at vi rent faktisk arbejder efter "best practices", og at vores nyeste projekter i evolutionær forstand altid er en kumulativ overbygning på den erfaringsbase vi har skabt os fra samtlige tidligere projekter. Vi arbejder altså efter at gøre det bedre hver gang!

Iterativitet - fordi verden ikke står stille

Med en model for standarder og procesforbedring på plads var næste skridt at gøre op med den traditionelle kravspecifikation.

Vores indstilling er, at verden er i konstant forandring, hvormed at de krav der stilles til et givent it-system ændrer sig løbende, samt at it-systemer har en livscyklus der minder om levende organismer, hvormed de starter med at skulle tilfredsstille et meget specifikt behov, og så meget ofte hurtigt udvikler sig til også at kunne en hel masse andet. Med denne indstilling til verden betyder det, at den traditionelle kravspecifikation ikke passer til os, da vi mener at man aldrig vil være i stand til at afdække alle forhold i et givent projekt, og at man aldrig vil kunne skabe et "optimalt" system - for de behov som et givent it-system skal tilfredsstille, vil meget ofte ændre sig hen ad vejen. At arbejde efter den traditionelle fase-indelte vandfalds-model ville svare til at lukke øjnene på motorvejen og håbe på at alt går som det skal, men i værste fald kan man jo risikere, at de behov som berettigede et givet projekt til at starte med måske har ændret sig fuldstændigt når projekt-forløbet er gennemført, hvormed man står med et uanvendeligt system, der har kostet en sum penge, og nu er en tabt investering. Vi har valgt en alternativ løsning!

Når det gælder et konkret udviklingsforløb, så er vores fremgangsmåde funderet i den adrætte/agile Scrum-metode, der understøtter den fleksibilitet som vi selv mener er en nøglefaktor i om et system bliver en succes eller ej. Udover en række centrale formelle begreber som: Epics, themes, user-stories og story-points, så arbejder vi efter en model, hvor kunden er mere involveret i processen (som beslutningstager) end i et traditionelt udviklingsforløb, og hvor et konstant bi-direktionalt informationsflow sikrer at kunden såvel som udviklingsteamet arbejder i samme retning. I denne proces tillader vi os altid at sige vores mening og stille opklarende spørgsmål - både i relation til funktionalitet og forretningslogik, hvilket betyder, at produktet af et udviklingsforløb er den software, der er opstået i synergien mellem kunden og udviklingsteamet. Bedre løsninger - ganske enkelt! Ved at have en fungerende prototype, der udbygges gennem korte, iterative softwareudviklingsforløb nedbringes også softwarens "time-to-market", hvilket efter vores opfattelse er en kritisk faktor for et systems succes. Med vores måde at arbejde på, får kunden hurtigt et basalt system op at køre, og udover at dette bevirker at systemet hurtigere kan begynde at tjene sig selv ind, betyder det også, at projekt-kommunikationen på et tidligt tidspunkt kan tage udgangspunkt i erfaringer med systemet i stedet for blot systemet på et konceptuelt plan.