Geen Fragile documentatie in Agile development

Geen Fragile documentatie in Agile development

Zoals vorige week gemotiveerd zijn user stories ongeschikt als product (applicatie) documentatie, met als gevolg dat AGILE-documentatie m.i. dus FRAGILE-documentatie wordt.

Use cases kunnen echter wel gebruikt worden als documentatie van een applicatie. Wat nu? Als de use case beschrijving direct in een realisatie van de user story wordt gebruikt om deze nader te definiëren ontstaat wel functioneel bruikbare documentatie.

Om systemen te kunnen onderhouden en moderniseren is het van cruciaal belang om een gedetailleerd inzicht te hebben in de architectuur, structuur en werking van het systeem. Omnext biedt al oplossingen op dit gebied die gebaseerd zijn op software analyse met behulp van statische broncode analyse. Om het functionele inzicht in applicaties in de vorm van documentatie verder te verbeteren en naar een hoger niveau te brengen heeft Omnext de wens om ook inzicht te verschaffen in de structuur en werking van systemen met behulp van Use Case Mining technieken verder ontwikkeld.

Het doel is opdrachtgevers een instrument te bieden om in Agile development omgevingen gebaseerd op broncode analyse Use Cases te reproduceren. Dit helpt u om ook voor steeds veranderende applicaties met een hoge wijzigingsgraad de requirements en de functionele werking up-to-date te brengen en te houden.

Moet dit dan voor de gehele applicatie? Onze ervaring is dat over het algemeen 20 tot 30% van de applicatie functioneel essentiële is. Dus actualiseren is te overzien en actueel houden een piece of cake.

Meer weten, neem contact op met mij?

-Jaco de Vries

jaco.de.vries@omnext.com

Van AGILE documentatie naar FRAGILE documentatie?

Van AGILE documentatie naar FRAGILE documentatie?

Vandaag de dag werken de meeste organisaties volgens een Agile software-ontwikkelmethode. Hierin worden bestaande systemen onderhouden en nieuwe functionaliteiten en/of applicaties gerealiseerd. Deze applicaties moeten meestal nog lang onderhouden worden, wat in de tijd niet altijd plaatsvindt door dezelfde teamsamentelling. Belangrijk is dus dat van de essentiële functionaliteit (20% tot 30%) een goede actuele productbeschrijving aanwezig is.

Karakteristiek bij Agile development is dat gebruik wordt gemaakt van User stories. User stories zijn ontstaan binnen de Extreme Programming (XP) methodiek, waarbij ze primair gebruikt werden als een ‘speelstuk’ in de planning game. Alle user stories komen in principe op de backlog en bieden daarmee een geprioriteerde lijst waarmee de PO en het development team een volgende iteratie of release kunnen plannen. Per individuele story worden de benodigde taken (development, test, requirements, etc…) bepaald die nodig zijn om de gewenste functionaliteit op te kunnen leveren.

We zouden derhalve kunnen stellen dat een user story voor een significant deel een planningseenheid is. Uiteraard bevat een user story ook primaire requirements om de acceptatiecriteria van de story zo scherp te maken. Deze acceptatiecriteria kunnen vervolgens gebruikt worden om de story te valideren op volledigheid en correctheid.

Bij het gebruik van user stories wordt meestal voor iedere wijziging een nieuwe user story beschreven zonder de oude aan te passen. Hierdoor kan het lastig worden om na oplevering een scherp beeld te hebben van de actuele functionaliteit. User stories zijn hierdoor ongeschikt als product (applicatie) documentatie.

Zo wordt AGILE-documentatie m.i. dus FRAGILE-documentatie.

Bent u het eens met deze stelling en benieuwd naar mijn visie over hoe dit op te lossen valt? Lees dan volgende week deel II uit deze blog-serie.

Voor iedereen die niet kan wachten en nu al graag het gesprek aan gaat, voel je vrij om contact met mij op te nemen!

Jaco de Vries

jaco.de.vries@omnext.com