Wat is DSDM (methode voor de ontwikkeling van dynamische systemen)?
Wat is DSDM?
De methode voor dynamische systeemontwikkeling (DSDM) is een wendbaar raamwerk voor projectoplevering dat voor het eerst ontstond in 1994 en destijds werd gebruikt voor softwareontwikkeling. Het was bedoeld als verbetering van snelle applicatieontwikkeling (RAD), waarbij snelle prototyping en iteratie op basis van gebruikersfeedback prioriteit hadden. Net als veel wendbare methoden voor projectoplevering evolueerde het DSDM-raamwerk voor wendbare projecten uiteindelijk van een softwarespecifieke oplossing naar een algemener hulpmiddel voor projectmanagement.
Elementen van de methode voor dynamische systeemontwikkeling zijn onder andere:
- Onderscheidt zich van andere methoden door een sterke afhankelijkheid van solide fundamenten en bestuur
- Incrementele, iteratieve aanpak van de voortgang
- Feedback van gebruikers of klanten is essentieel voor voortdurende verbeteringen
- Is afhankelijk van strikte beperkingen op het gebied van kosten, kwaliteit en tijd
- Geeft prioriteit aan de reikwijdte op basis van Moet hebben, Zou moeten hebben, Zou kunnen hebben of Zal niet hebben
Naast de methode zelf leidde DSDM in 1994 ook tot de oprichting van het DSDM Consortium. Softwareontwikkelaars en andere experts bundelden hun krachten om het raamwerk te ontwikkelen en te verbeteren als een geldig alternatief voor de gangbaardere methoden voor snelle applicatieontwikkeling. Destijds bestond de groep uit vertegenwoordigers van onder andere British Airways, American Express, Oracle, Logica, Data Sciences en Allied Domecq. De groep heeft inmiddels een nieuwe naam en heet nu het Agile Business Consortium.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Het DSDM-handboek werd in 2014 gratis online beschikbaar gesteld om te bekijken en te gebruiken.
DSDM versus RAD versus wendbaar werken
De RAD-methodologie was begin jaren 90 enorm populair als methode voor systeemontwikkeling voor softwareontwikkeling en andere IT-projecten. In deze periode vond er een verschuiving plaats van de traditionele UX met een “groen scherm” naar de grafische gebruikersinterfaces die nu synoniem zijn met alle technologie. Deze verandering betekende dat ook de ontwikkelcyclus kon veranderen, door dit nieuwe type visuele gebruikersinterface te gebruiken voor communicatie, snelle prototyping en iteratie.
De RAD-methodologie was een enigszins chaotische wendbare methode voor systeemontwikkeling. Er was geen enkele overeengekomen aanpak of definitie. DSDM was een meer gestructureerde aanpak van dit type softwareontwikkelingsmodel. De methode voor dynamische systeemontwikkeling was sterk gericht op tijd- en kostenbudgetten door middel van strikte prioritering van de reikwijdte. Ook geeft deze methode prioriteit aan communicatie (en de daaruit voortvloeiende acties) tussen alle belanghebbenden.
DSDM stelt niet alleen strikte eisen aan deadlines en budgetten, maar hanteert doorgaans ook een vaste volgorde van gebeurtenissen: de fase vóór het project, de projectlevenscyclusfase en de fase na het project. Softwareontwikkelingsmethoden voor snelle applicatieontwikkeling draaien meer om vrij werk, waarbij creativiteit en onafhankelijkheid de vrije hand krijgen, zelfs ten koste van het uitputten van middelen.
Scrum versus DSDM
Scrum en DSDM vertonen veel overeenkomsten, maar hebben ook enkele belangrijke verschillen. Sommige verschillen zijn slechts gebaseerd op terminologie. Zo verdeelt DSDM het werk in de “ontwikkelactiviteit” (ook wel de ontwikkelfase genoemd) en de “ontluikende oplossing” (ook wel het resultaat genoemd). Bij Scrum staat het resultaat daarentegen bekend als de “potentieel opleverbare stap”.
Beide methoden hebben lijsten met subtaken die worden voltooid op basis van het naleven van strakke deadlines. Beide methodologieën werken ook toe naar een voltooid project, dat Scrum markeert zodra het project de “Definitie van gereed” bereikt. Er is echter geen specifiek moment binnen het project waarop deze “Definitie van gereed” wordt overeengekomen. Dit is een belangrijk verschil tussen Scrum en DSDM.
Bij DSDM is er een vaste fase waarin de definitie van het werk (en van voltooid werk) wordt overeengekomen: de funderingsfase van het project. Dit gebeurt relatief vroeg, wat soms kan betekenen dat nog onbewezen aannames het planningsproces beïnvloeden. Om hiermee rekening te houden, wordt de definitie van “voltooid” werk periodiek gedurende de levenscyclus van het project geëvalueerd. Een ander aandachtspunt is dat teamleiders een groot ontwerp vooraf (BDUF) moeten vermijden, omdat dit meer kenmerkend is voor watervalmethodologieën en niet voor wendbare methoden.
DSDM-principes
De wendbare principes van DSDM vormen de leidraad achter elk project. Er zijn in totaal 8 principes.
- Richt je op de bedrijfsbehoefte
- Lever op tijd
- Werk samen
- Doe nooit concessies aan kwaliteit
- Bouw incrementeel voort op solide fundamenten
- Ontwikkel iteratief
- Communiceer voortdurend en duidelijk
- Toon controle
DSDM-technieken en -praktijken
Wat DSDM onderscheidt van andere methoden voor systeemontwikkeling zijn de volgende technieken en praktijken.
Tijdblokkering: DSDM hanteert strikte deadlines. Hiervoor moet het hele project worden opgesplitst in kleinere onderdelen die elk een vast budget en tijdsbestek hebben. Om dit te kunnen beheren, krijgen de vereisten prioriteiten toegewezen. Als de tijd of het geld opraakt, worden vereisten met de laagste prioriteit verwijderd. Een voltooid project bestaat dan alleen uit de meest essentiële vereisten.
MoSCoW: Dit zijn de prioriteringsgroepen die worden gebruikt om onderdelen te rangschikken van het hoogste tot het laagste belang. De prioriteringsgroepen zijn Moet hebben, Zou moeten hebben, Zou kunnen hebben en Zal niet hebben. Configuratiebeheer helpt bij het beheren van al deze concurrerende op te leveren onderdelen, die vaak tegelijkertijd worden ontwikkeld.
Modellering en iteratieve ontwikkeling: Modellering helpt om verschillende aspecten van het project gaandeweg te visualiseren. Dit helpt om elk onderdeel dat in ontwikkeling is te presenteren en iteratieve ontwikkeling mogelijk te maken door regelmatig feedback te geven en verbeteringen door te voeren.
Prototyping: Net als bij veel agile methodologieën is prototyping essentieel om het project in een vroeg, conceptueel stadium proef te draaien. Het is een manier om de basisfuncties in kaart te brengen, duidelijke zwakke punten te ontdekken en gebruikers de software te laten testen.
Workshops: Gebruikers en belanghebbenden worden samengebracht om vereisten, problemen, resultaten en tests te bespreken. DSDM steunt vanaf het allereerste begin op een hoge mate van gebruikersinteractie. Testen is zeer belangrijk voor DSDM, omdat het resultaten van hoge kwaliteit garandeert.
Rollen binnen DSDM
Bij elke agile systeemontwikkeling hoort een lijst met rollen die moeten worden ingevuld. Dat geldt ook voor DSDM. Volgens het handboek zijn dit de essentiële rollen in elke DSDM-omgeving.
1. Uitvoerend sponsor (de “projectkampioen”) - De gebruikersorganisatie en/of de klant levert iemand voor deze rol. Deze persoon kan indien nodig ook geld en middelen toewijzen. Hij of zij heeft het “laatste woord” bij besluitvorming.
2. Visionair - Gewapend met concrete doelstellingen en inzicht in de bedrijfsvoering van de gebruiker start de visionair het project door al vroeg de vereisten met de hoogste prioriteit vast te leggen en het team op basis daarvan te begeleiden.
3. Gebruikersambassadeur - Een ideale “testgebruiker” die het perspectief van de gebruikersgemeenschap in het project vertegenwoordigt. Deze persoon wordt gedurende het hele proces een belangrijke bron van feedback.
4. Gebruikersadviseur - Een ander type gebruiker dat essentiële perspectieven aan het betreffende project moet toevoegen. Deze persoon kan unieke inzichten of andere expertise hebben, waardoor hij of zij de ideale kandidaat is.
5. Projectmanager - Een projectmanager is degene die het algehele project beheert.
6. Technisch coördinator - Deze persoon ontwerpt de systeemarchitectuur en is verantwoordelijk voor de kwaliteitscontrole van alle technische elementen.
7. Teamleider - De leider van het team, verantwoordelijk voor coördinatie en het faciliteren van samenwerking.
8. Oplossingsontwikkelaar - Deze persoon beheert alle systeemvereisten, modelleert het systeem, ontwikkelt de op te leveren code en maakt prototypes.
9. Oplossingstester - Test het product en levert opmerkingen en documentatie wanneer er fouten optreden. Deze persoon test het product ook opnieuw nadat correcties zijn doorgevoerd.
10. Verslaglegger - Legt de vereisten, overeenkomsten, beslissingen en andere nuttige informatie voor de voortgang van het project vast.
11. Begeleider - Deze persoon is verantwoordelijk voor het motiveren en voorbereiden van de workshop om de voortgang consistent en stabiel te houden. Hij of zij moet uitstekend kunnen communiceren en iedereen op koers houden.
12. Specialistische rollen - Dit zijn rollen die worden ingevuld door specialisten in hun vakgebied of sector en die extra ondersteuning bieden afhankelijk van de behoeften van het project. Ze kunnen per project en per team verschillen. Voorbeelden van dergelijke rollen zijn bedrijfsarchitect, kwaliteitsmanager, systeemintegrator en meer.
Tips voor projectmanagement met DSDM
Deze tips kunnen helpen om het meeste uit uw DSDM-project te halen, hoewel alle agile systemen ook baat kunnen hebben bij het toepassen van delen van deze kennis.
1. Het senior management en alle medewerkers moeten de gekozen methodologie voor een project begrijpen en er volledig achter staan.
2. Het team dat het project leidt, moet zich gedurende het hele proces—van concept tot lancering—committeren aan gebruikerstests, feedback en betrokkenheid.
3. Er moet een stabiel en slagvaardig centraal projectteam zijn. Teamleden moeten beslissingsbevoegdheid hebben om ervoor te zorgen dat het proces niet vastloopt in onnodig omslachtige voorstel- en goedkeuringsprocessen. Het team moet ook alles hebben wat nodig is om te functioneren, zoals de juiste technologie, een gezonde ontwikkelomgeving, projectmanagementtools en meer.
4. Er moet een ondersteunende en proactieve relatie zijn tussen de klant en de leverancier, ongeacht of de projecten intern worden ontwikkeld of worden uitbesteed.
5. Het team moet onbevreesd zijn wanneer het aankomt op het eerlijk prioriteren van projectbehoeften en het waar nodig schrappen van onderdelen met een lage prioriteit. Zo blijven zaken op schema en binnen het budget.
