Dokumentera mindre

Har du hört talas om begreppet dokumentera mera? Tänkte nästan det. Men dokumentera mindre då?

Varje dag skrivs en mängd dokument med syfte att dokumentera systemutveckling, men har du någon gång reflekterat över varför du skriver ett visst dokument. Kanske har du känt att du skriver för blinda ögon ibland.  All tid som läggs påonödig dokumentation kostar timmar. Timmar som kunde lagts på att utveckla ny funktionalitet.

I det Agila Manifestet som författades 2001 gjordes ett tydligt ställningstagande kring dokumentation. Dokumentation är viktigt, men fungerande mjukvara är viktigare. Du ska inte dokumentera förrän du har en fungerande IT-lösning. Att poängtera är att fungerande i detta fall inte är det samma som färdigutvecklad. Fungerande pekar mer på en specifik funktion i en IT-lösning.

Att dokumentera först när en funktion fungerar skapar förutsättningar för att dokumentationen blir korrekt. Att dokumentera något som inte är fastställt i detalj innebär merjobb med att ändra i dokumentationen om det visar sig att funktionen måste kodas om. Dokumentera därför aldrig något som inte är fastställt eller inte fungerande. Fokusera istället på att få IT-lösningen att fungera istället för att dokumentera hur IT-lösningen borde fungera.

Dokument brukar bli omfattande. Omfattande dokument är svåra att hålla uppdaterade när en IT-lösning ständigt förändras. Ofta är det också så att dokumentation prioriteras lägst och görsi mån av tid. Till slut vet ingen hur IT-lösningen fungerar eftersom dokumentationen inte uppdaterats på flera år.

Hur kan man då arbeta med dokumentation för att undvika det här?

Eftersom uppdatering i dokumentation historiskt sett är eftersatt på många håll bör man se till att ha så lite dubbellagrad information som möjligt. Helst ska den mesta informationsmängden inte finnas i dokumentform. Istället är exempelvis testfall ett oerhört kraftfullt sätt att beskriva hur en IT-lösning ska fungera (positiva testfall) men även inte fungera (negativa testfall). Testfall är något som används i det dagliga arbetet och man är därför mån om att dessa ständigt är uppdaterade.

Koden bör vara välkommenterad eftersom det är lättare att uppdatera kommentarerna när man redan ändrat i koden på samma ställe.

I exemplet ovan finns den detaljerade beskrivningen av en IT-lösning direkt i koden och i testfallen. Ofta finns också en övergripande systembeskrivning. Denna kan med fördel dokumenteras i ett dokument. Denna beskrivning ändras inte särskilt ofta och när den väl gör det är ändringarna så pass små att det är lätt att uppdatera dokumentet.

Granskning då?     

En vanlig metod för kvalitetsgranskning är att granska dokument. Man utgår då ifrån att det som står i ett dokument är sant. Verkligheten är tyvärr ofta en annan. Beslut fattas utifrån hur en IT-lösning borde fungera och inte hur den faktiskt fungerar. För att råda bot på detta fenomen bör man som granskare istället för att granska dokument få tillgång till IT-lösningen och titta direkt i exempelvis kod eller testfall.

Självklart finns det dokument som måste tas fram för att kunna leverera en högkvalitativ IT-lösning. GEM arbetar med att ta fram dessa dokument men vi fokuserar på att hålla den obligatoriska nivån så låg som möjlig för att underlätta för flexibilitet. Olika dokument behöver tas fram beroende på IT-lösningen. Därför bör man endast producera dokument först när de efterfrågats för att kunna motivera investeringen i ett dokument.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Google-foto

Du kommenterar med ditt Google-konto. Logga ut /  Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s