Broncode wordt steeds vaker geproduceerd via een Agile-ontwikkelmethode, maar het schrijven van de projectdocumentatie blijft vaak in de traditionele combinatie van documenten in een contentbeheersysteem steken. Een wiki past veel beter bij de Agile-aanpak, beargumenteert Mark Robinson. Bovendien kan deze uitgroeien tot een bedrijfsbrede informatiebron en daarmee de ontwikkelafdelingen dichter bij elkaar brengen.
Je beste klant belt je omdat een kritiek product dat je recentelijk hebt opgeleverd ineens niet meer werkt. Waar is de herstelprocedure? Je beste medewerker is recentelijk vertrokken en heeft zijn kennis meegenomen. Hoe had je dit kennisverlies kunnen voorkomen? Of je team wordt continu onderbroken door vragen van collega‘s, steeds dezelfde. Hoe kun je dit voorkomen?
In veel bedrijven is kritieke zakelijke informatie niet gedocumenteerd. En als het dat wel is, is het vaak onvindbaar. En als het wel gevonden kan worden, is het waarschijnlijk weer achterhaald. De reden hiervoor is dat er bij traditionele documentatie een hoge drempel is voor het bewerken. Er is een programma voor (meestal Microsoft Word) en een ander programma voor het contentbeheer (het in- en uitchecken van het document). Ik heb regelmatig meegemaakt dat een gebruiker een document uitcheckt voor dagen of zelfs weken. Tijdens die periode zien zijn collega‘s niet de updates, want die staan lokaal op de computer van de auteur. Ondertussen kan ook niemand anders veranderingen doorvoeren, behalve via een ingewikkelde merge. De documenten worden vaak ook heel groot – ik heb documenten van boven de tweehonderd pagina‘s gezien.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.
