I det første indlæg om det agile manifest kiggede vi udelukkende på det første punkt ud af fire “Individer og interaktion over processer og værktøjer”. Nu er det så tid til at kigge på punkt to.
I kontekst lyder den:
Through this work we have come to value:
– Working software over comprehensive documentation.
That is, while there is value in the items on the right, we value the items on the left more.
Netop dette punkt har ført til en af de mest populære myter i den agile verden: vi dokumenterer ikke. Det er det vilde vesten.
Myten er forståelig. Projekter er tidspressede og dokumentationen ender så langt nede på prioriteringslisten at vi ikke når til den. På grund af dette punkt i det agile manifest er det altid den samme prioritering vi har.
Det er korrekt at der ofte dokumenteres mindre i agile projekter – det er bare ikke hele historien.
I virkeligheden forholder den agile verden sig kritisk til hvilken dokumentation, der giver værdi. Man må aldrig producere dokumentation for dokumentationens skyld – f.eks. store dokumenter som bliver lagt i en skuffe og aldrig læst eller årsværker af kravspecifikationer som er outdatede den dag de bliver færdige. Der hvor dokumentationen er nødvendig og giver værdi er det til gengæld en del af produktet – en del af “definition of done”. I tidspressede projekter vil man ikke bare droppe dokumentationen, men i stedet kigge på emergency procedures – f.eks. genoverveje scope, dvs. hvor stor en del af projektet kan vi levere til vores definition of done altså i værdi-tilførende nødvendig dokumenteret form?
Modsat visse traditionelle projektsstyringsmetoder vil de agile metoder helst ikke definere for mange one-size-fits-all-type dokumenter, men i stedet opfordrer det agile manifest os til at udfordre de steder hvor vi bliver bedt om at dokumentere – er det rent faktisk nødvendig værditilførende dokumentation? Hvis det er så er det selvfølgelig en del af det arbejde der skal udføres. Der spørges også om vi kan opnå det samme informationsniveau med mere strømlinet dokumentation end en dokumentation af alle detaljer? Kan vi i stedet for en generel projektstatus bruge målrettede kommunikationsartefakter som svarer på lige de spørgsmål vi gerne vil have svar på?
Et godt eksempel på denne optimering finder vi i Scrum som har selvorganiserende teams. Derfor er der ikke samme behov for styring udefra, hvilket også skærer ned på den nødvendige afrapportering og dokumentation, som ellers skulle sætte andre i stand til at tage fornuftige beslutninger.
Scrum tager nogle værktøjer i brug som f.eks. burn-down charts for at dokumentere om projektet kører efter planen eller afviger. Det er en meget simpel akkumulerende repræsentation af det arbejde som er udført i sprintet og det arbejde som vi stadig mangler at udføre. Vi bekymrer os ikke om hvorvidt hver opgave var estimeret lige til minuttet, men vi bekymrer os om det store billede – helheden. Det er simpelt, men giver stadig svar på et vigtigt spørgsmål – er vi bagud, foran eller lige på deadlinen?
En backlog er også et eksempel på en strømlinet udgave af de mere traditionelle store up-front-kravspecifikationer. Det er et levende dokument, som vi først forfiner, når vi skal bruge informationen, hvilket minimerer spild i forhold til ændrede omstændigheder, glemte beslutninger eller dokumentation af hvilke beslutninger der er taget (som man så glemmer at kigge i, når man skal bruge informationen).
Målet er at optimere den tid teamet arbejder på softwaren frem for den tid de arbejder på biprodukterne. Desværre er det et punkt der har ført til myten om at man ikke dokumenterer i agile projekter. Hvad siger du – holder myten i praksis?
Den største fejl som læsere af det Agile Manifesto gør, er at misforstå nødvendigheden af det til højre. Der står skrevet i manifestet at der er værdi i dokumentation, men man skal lære hvornår den skal afviges fra. Dokumentationskrav var høje i sidste årtusind, og i bagklogskabens lys var det meste overflødigt og blev aldrig brugt. Den tid som blev brugt til at holde dokumentation ved lige var i den henseende nærmest direkte overflødig.
Som arkitekt støder jeg ofte på to tilhørende paradigmer i forbindelse med arkitekturdokumentation. At koden er selvdokumenterende og at unittestene virker som dokumentation.
Koden er selvdokumenterende i det omfang, at hvad systemet gør er direkte relateret til kildekoden. Desværre så er 20.000 liniers kildekode ikke nok til at skabe overblik, og giver ihvertfald ikke meget overblik over arkitekturlag og platforme. Unittest som dokumentation er yderst vanskeligt at forstå på andet en komponentniveau. Det kan højst svare til en anvisning på en æske skruer om hvordan skruerne skal bruges.
Hvis man observerer nye projektdeltagere, så vil de ret hurtigt søge tilflugt til enhver form for dokumentation for bare at forstå en lille smule sammenhæng, og som regel får de bare en time med arkitekten tegner og fortæller. Det står i mine øjne lidt i skarp relief til moderne open-source projekter, som er blevet fantastisk gode til at levere overordnet dokumentation upfront. Måske fordi vi ellers ikke vil begynde at bruge teknologierne.
Projekter skal i mine øjne dokumentere sin arkitektur. Ihvertfald på overordnet niveau, og gerne med diagrammer etc. I dag findes der mange gode dokumentationsværktøjer, som faktisk gør at dokumentation kan ligge sammen med kildekoden. Jeg bruger personligt AsciiDoc så det kan genereres via build værktøjer og publiseres direkte. Ingen arkitekturdokumentation er i mine øjne direkte skadeligt for et projekt på lang sigt.
Resten af projektdokumentationen til projekt- og opgavestyring er fantastisk relevant med de agile værktøjer vi har idag, som du selv skriver. Dog savner jeg enkelte executive summaries. Overblik er gyldent.
Helt enig. Der er noget at lære fra visse open source-projekter – de har været nød til at tænke over hvordan de kan få overlevering af viden på den absolut “billigste” måde (billigt i form af tid og med hensyntagen til manglende co-lokation). Ingen chef til at diktere at noget dokumentation skal eksistere uden at skulle argumentere for at det giver værdi. Absolut et potentielt forbillede. Ikke at den verden er perfekt – jeg har siddet mange frustrerende arbejdstimer med open source-software fordi der ikke eksisterede dokumentation eller fordi dokumentationen var outdated… men open source-projekter har potentiale til at få en god balance i forhold til dokumentation.
Hvis du savner executive summeries, så er der intet i den agile verden som forhindrer dig i at indføre dem. Det er altid tilladt at identificere et behov for kommunikation og så indføre det også selv om det ikke er en del af den agile værktøjskasse man sidder med “out of the box”. Continuous improvement FTW!
[…] i kontekst lyder det fjerde og sidste punkt i det agile manifest (se også punkt 1, punkt 2 og punkt […]