Documentatie dialogen

< Documentatie < Dialoog over systeemontwikkeling
 * Community: Systeemontwikkelaars

Introductie

 * In de IT zijn veel systemen onvoldoende gedocumenteerd.
 * Het goed beschrijven van de functionaliteit kost veel tijd en veel mensen hebben vaak geen zin om veel energie te steken in documentatie.
 * Deze houding zorgt wel voor een risico voor het team en/ of de organisatie.
 * Vanuit de systeemontwikkelaars is dan ook het advies om documentatie op de dialoog agenda te zetten.

On our mind

 * Om wijzigingen in de IT-infrastructuur door te voeren is het van belang dat de processen gedocumenteerd zijn.
 * In organisaties waarbij IT en business gescheiden zijn is het belangrijk om goede afspraken te maken over wie, wat documenteert.
 * Hieronder enkele voorbeelden
 * Procesdocumentatie
 * Vanuit team systeemontwikkeling hanteren we de good practice dat de proceseigenaar (meestal aan de business kant) verantwoordelijk is voor het up-to-date zijn van de procesdocumentatie.
 * Vaak zie je dat analisten van de IT-afdeling de procesdocumentatie opzetten en ook bijwerken. Is dat gewenst? Of wil je dat de business hier zelf verantwoordelijkheid in neemt.
 * Functionele wijzigingen
 * In een Agile way of working is een userstory vaak voldoende om de ontwikkelaars aan het werk te zetten.
 * Maar wat te doen als er allerlei functionele vragen zijn? Wie is verantwoordelijk voor het beantwoorden van die vragen?