Et stort problem for
agile udviklingsproces er, som jeg ser det, at sikre fremskridt og konstant levering. Mange bøger beskæftiger sig ikke rigtigt med, hvordan man sikrer, at hver iteration producerer noget færdig funktionalitet, som principielt set skulle være deployment-klar.
Crystal Clear taler om
walking skeleton strategien, som går ud på at man først får et simpelt arkitekturskelet op og køre, og dernæst fylder kød på det. Scott Ambler med
Agile Unified Proces (som er den processmetode der ligger til grund for projekterne her på Den Blå Avis) taler om
requirements-driven architecture og modeling in small increments. Lidt samme ide igen: man opbygger arkitekturen i små bidder, dog krydret med at arkitekturen skal udspringe fra forretningens/kundens krav. Men det store spørgsmål forbliver, hvordan gør man egenligt?
Belært af tidligere projekter er jeg blevet meget påpasselig med at tage domænet for givet. Vi opererer med en arkitektur, hvor de grundlæggende forretningslogikker og -objekter afspejles i en domænemodel. For mig at se er det essentielt at få domænet på plads tidligt i projektet, før udviklingen af krav starter. Det betyder at
- Krav skal være tilpas detaljerede
- Kravstiller skal kunne stå inde for kravene
- Kravene skal mappes til domænet
- Domænet skal afspejle løsningen af kravene
Dette arbejde er interessant af flere grunde. Det skaber en kontakt imellem kravstiller og udviklere som er helt nødvendig for at få kravstiller til at tage et aktivt ansvar i udviklingsprocessen og for at få udviklerne til at tage et aktivt ansvar i kravene. Med andre ord de bringer de to verdner tættere sammen. Kravstiller og udvikler kan diskutere krav på en måde, som de begge hver især forstår: Kravstiller taler ud fra forretningen, udvikleren ud fra domænemodellen. Gode eksempler kunne være:
Udvikler: Jamen skal kunden kunne få den rabat hver gang han handler?
Kravstiller: Øh, ja... Kunden får rabatten, fordi han handler for mere end 3000 kr om året hos os.
Udvikler: Ok, så man skal altså logge den samlede sum en kunde handler for?
Kravstiller: Ja det vil jeg da klart mene
Udvikler: Og hvis den samlede sum overstiger 3000 kr, så får kunden en rabatsats?
Kravstiller: Ja på 2%. Hvis kunden handler for over 10000 så stiger rabatten til 5%
Udvikler: Så det er en slags konfigurerbar trappesats? Skal i selv kunne vælge procentsatserne og beløbene?
Kravstiller: Det ville da være at foretrække, så skal vi jo ikke belemre nogen fra udviklingsafdelingen hver gang vi skal have det ændret!
Udvikler sidder her og kigger på det domæne, hun har tegnet op. Sikkert bestående af nogle ordrer, kunder og varer. Men ved at diskutere rabat med kravstiller ud fra domænet lærer udvikleren hurtigt at der skal tilføjelser til domænet for, at rabatten kan virke som forretningen ønsker det. Pointen her er, at hvis man i de tidlige faser får vendt domæment med kravstiller og de krav, der er registreret, så får man et mere stabilt udgangspunkt for udviklingsfasen. Det er min påstand, at dette arbejde i et eller andet omfang er nødvendigt for at kunne levere færdig funktionalitet efter hver iteration i udviklingsfasen, ellers skal der bruges for megen tid på undersøgelse af krav og ændring af domæne efterfølgende.
Vi arbejder med fire faser (hentet fra Agile Unified Proces & Rational Unified Proces): inception, elaboration, construction og transition. Inception er projektfødsel, hvor man definerer overordnede rammer for projektet, elaboration er der hvor man fordyber sig i projektet, construction der hvor kravene udvikles og transitition er udrulningen af projektet. Vi arbejder på Den Blå Avis med en kravsprocess, som definerer krav som værende 10% færdige efter inception og 80% færdige efter elaboration. De sidste 20% kommer i løbet af construction, når kravene udvikles (man kan ikke vide alt up-front!). På samme måde foreslår jeg egentlig at man går til både domæne og arkitektur...
Etiketter: forretning, krav, proces
