Scrum voor Nearshoring


Wanneer je alle mogelijke software pakketen hebt bekenken maar er geen een voldoet aan de wensen en/of eisen van het bedrijf wordt het wellicht tijd om over maatwerk software na te gaan denken.

Voor vele organisaties is maatwerksoftware laten ontwikkelen het gevoel dat ze een soort "zwartedoos" geleverd krijgen. Vooraf wordt besproken wat er ontwikkeld gaat worden, tegen welke kosten, de milestones en wanneer het klaar is. Je krijgt keurig netjes je voortgangsrapportages, je wordt gebeld bij het behalen van een milestone.

En dan op een mooie zonnige, zomerse dag staat er een persoon aan de deur met een doos onder zijn of haar arm met daarin de gevraagde applicatie.

Na onderzoek blijkt dat er toch wel wat dingen zijn die niet volgens specificatie zijn of die je als opdrachtgever toch wel anders had voorgesteld. Wanneer je dit meld wordt er al gauw verwezen naar het functioneel ontwerp. Wanneer je dat nog eens goed doorleest met in het achterhoofd het gene nu opgeleverd is zie je dat het FO inderdaad ruimte laat voor interpretatie. Na overleg over schuld en kosten worden wat aanpassingen gedaan wat je hoe dan op hogere kosten brengt dan je vooraf ingeschat had. Is het niet daadwerkelijke ontwikkelkosten dan wel de inkomsten die je op een of andere manier misloopt door het later dan verwacht implementeren van de software. Wanneer je de software in bijvoorbeeld Oost-Europa laat programmeren wordt het verschil tussen functioneel ontwerp en opgeleverde software vaak nog groter. Dit heeft deels te maken met het cultuurverschil.

Een methode om meer grip te houden op wat er nu daadwerkelijk in deze “zwartedoos”geproduceerd wordt is Scrum. Deze ontwikkel methodiek is gebaseerd op korte ontwikkel trajecten, sprints genaamd, en heeft tot doel om de paarweken een werkende versie af te leveren. De functionaliteit die in deze sprints wordt geproduceerd staat in de backlog, de beschrijving van wat er gedaan moet worden. Hierin wordt niet gefocust op techniek maar op wat moet het aan het eind van de twee weken kunnen, waar moet het aan voldoen. Op deze wijze stelt Scrum de functionaliteit en de kwaliteit centraal. Hierdoor ontstaan er geen onduidelijkheden meer over de kwaliteit!, is er dus elke start en eind van de sprint contact tussen opdrachtgever en ontwikkeling. Met als gevolg elke twee weken werkende software. Of je deze software ook wilt implementeren is natuurlijk geheel aan de opdrachtgever. Vanzelfsprekend kun je deze alleen gebruiken om de vorderingen en eventuele aanpassingen kaart te brengen. Feit blijft dat je meer controle hebt over het budget, elke sprint weetje wat het kost, na elke sprint kan je de stekker eruit trekken. En je hebt controle over de kwaliteit. Dit zijn voor Genie-IT de

Wanneer een ontwikkel team niet in de kamer naast je zit of op de zelfde etage maar enkele duizenden kilometers verderop dan is de controle op wat er ontwikkeld wordt lastiger. Je vliegt niet even naar Oost Europa of India of te gaan kijken wat de status is. Hier biet Scrum een uitkomst! Elke twee weken wordt er een werkende versie opgeleverd waar je kan zien of dit is wat je gevraagd hebt. Op die manier kan je tijdig bijsturen en zorgen dat ook daadwerkelijk dat gene wordt opgeleverd dat gevraagd is. Dit is voor Genie-IT redenen om alleen nog maar Scrum methodiek te hanteren voor de ontwikkeling.

Geen opmerkingen:

Een reactie posten