Dit software ontwikkel/project management -model gebruik ik regelmatig. Het maakt duidelijk wat je kunt verwachten van de kwaliteit van het eind product en de bepalende invloed daarop van deze factoren: de functionaliteiten die je afspreekt te bouwen (de scope), het tijdsbestek waarbinnen deze functionaliteiten klaar moeten zijn en binnen welk budget dat gerealiseerd zou moeten worden. Deze 3 factoren zijn onlosmakelijk met elkaar verbonden.

Wanneer bijvoorbeeld blijkt dat de scope toeneemt van een project en je past de andere twee factoren niet aan, dan heeft dit onvermijdelijk invloed op de kwaliteit. Een ander voorbeeld: Wanneer er sneller geleverd moet worden (minder tijd), dan moet je als opdrachtgever een keuze maken: of meer budget om meer resources in te zetten of het aantal op te leveren functionaliteiten verkleinen.

De opdrachtgever heeft de sleutel in handen om te kiezen welke factoren voor hem/haar het zwaarste wegen. Je kunt één of twee factoren ‘vast’ zetten en dan de derde factor moet dan daarop worden aangepast. In de figuur hieronder zijn 2 voorbeelden opgenomen:

• Traditionele software ontwikkeling: de gewenste functionaliteiten staan vooraf vast (in de praktijk komt dit bijna nooit voor). De benodigde looptijd en resources niet.
• Agile software ontwikkeling: de tijdspanne en het aantal beschikbare resources staat vast. Het aantal op te leveren functionaliteiten na afloop van de vast tijdspanne niet.

Agile project management

De rechter driehoek geeft weer hoe de Agile werkwijze (met behulp van Scrum) past in het duivelsdriehoek-model. In een scrum-sprint, van bijvoorbeeld 2 weken, staat de tijdspanne vast, de resources tijdens de sprint blijven ook gelijk (bijv. 4 personen voor 2 weken 32 uur/week). Maar de scope (opgeleverde functionaliteiten na afloop van de sprint) is vooraf alleen maar in te schatten. Je weet vooraf dus altijd wat het gaat kosten, maar de opgeleverde functionaliteiten liggen vooraf niet vast.

De ervaring heeft mij geleerd, dat de scope van een project gedurende de looptijd vaak toeneemt. Dit is te verklaren doordat tijdens  een project, de ontwikkelaar erg gedetailleerd de diepte in gaat om het betreffende proces te kunnen automatiseren. Het ontwikkelproces zorgt er eigenlijk voor dat de opdrachtgever ook in groot detail aan het nadenken wordt gezet over hoe het bedrijfsproces exact verloopt of zou moeten lopen (IST-SOLL). Hierdoor worden globale wensen vooraf (bijv. ik wil een betaalmogelijkheid hebben in mijn webshop), steeds verder verfijnd (bijv. voor een kassa in de webshop is nodig: een iDeal-contract met een bank, een speciale rekening bij deze bank, Paypal moet ingeregeld worden, een API-interface moet worden ingebouwd in webshop om met de bank en met Paypal te kunnen communiceren, ook moeten er SSL-beveiligde verbindingsopties worden ingebouwd op de webshop, etc., etc.). Omdat je meestal vooraf niet alle implicaties van de scope, als opdrachtgever en als opdrachtnemer, volledig kunt overzien, werkt de Agile methode van software ontwikkeling het meest effectief.

In bovenstaande figuur is de Agile/Scrum manier van werken verduidelijkt. Je werkt in sprints naar een werkend product-increment. De programmeur levert zo’n product increment op naar de laatste input die hij gehad heeft van de klant (volgens zijn inzichten vooraf). De kunst van de programmeur is om de vooraf globaal bekende ideeën bij de opdrachtgever, zo goed mogelijk vertalen naar een werkend ‘product increment’. Waarbij hij rekening heeft te houden met de randvoorwaarden van het platform waarop de applicatie draait. Meestal is na paar product increments, het eind-product daar, waarbij de globale inzichten vooraf bij de opdrachtgever overeenkomen met het uiteindelijk zeer gedetailleerd uitgewerkte eindproduct.

Wanneer je hierover meer wilt weten, neem rustig contact op.