Geschreven op 12 december 2014

De kunst van het veranderen

In de media verschijnen herhaaldelijk artikelen over uit de hand gelopen software projecten. Projecten die mislukken, projecten die enorme vertraging oplopen of projecten die het budget overschrijden…
 

Hoe groter het project, hoe groter de problemen. Dat is eigenlijk niet zo raar. Het heeft alles te maken met de aard van IT werkzaamheden. Het gaat vaak om 'iets' nieuws waardoor het heel lastig in te schatten is.

Ediso is een jong bedrijf en ook wij zijn inmiddels in die valkuil getrapt. Daarom zijn we enige tijd geleden overgestapt naar een nieuwe manier van werken met behulp van het Agile Manifesto.

U denkt waarschijnlijk dat de primaire waarde van software is dat het stukje software precies doet wat het moet doen. Wij zijn er echter van overtuigd dat dat maar de secundaire waarde is. De primaire waarde is volgens ons dat software is opgebouwd zodat het continu kan worden aangepast. Een organisatie is namelijk continu aan verandering onderhevig. Behoeften veranderen daardoor, en als er aan de aan hand van een pakket van vooraf opgestelde eisen wordt gewerkt, is er weinig ruimte voor veranderingen.

We weten dat een website of webapp nooit af is. Er is altijd werk aan de winkel, en daarom is doorontwikkelen van een project daar inherent aan. Doorontwikkeling is in de praktijk echter vaak een gedoe. Er moeten nieuwe offertes komen, budget moet vrij worden gemaakt...

Het idee van de Agile methodiek is dat er binnen een kort tijdsbestek wordt geleverd. In precies twee weken, een sprint, maken we een onderdeel helemaal af zodat het in een echte situatie gebruikt kan worden. Twee weken is namelijk net lang genoeg om iets substantieels gedaan te krijgen en tegelijkertijd kort genoeg om een redelijke inschatting qua tijd te maken.

In een grote digitale kaartenbak worden alle wensen opgeslagen. Iedereen die bij het project betrokken is, is vrij om er iets nieuws aan toe te voegen.  Vooraf  bepaalt de opdrachtgever in overleg met het ontwikkelteam wat er in die twee weken moet gebeuren (en dat staat dan vast). Na de sprint is er een klein gedeelte dat toegevoegd wordt aan het totale product. Na een aantal sprints is er waarschijnlijk een product dat in de praktijk gebruikt kan worden.

Als opdrachtgever heeft dit een aantal voordelen:

  • Je hebt zelf in de hand waar de prioriteit komt te liggen
  • Voortgang wordt beter inzichtelijk
  • Nieuwe onderdelen zijn iedere twee weken al te testen

Maar misschien wel de meest krachtige van allemaal: je bent vrij om als opdrachtgever de ontwikkeling (tijdelijk) te stoppen. Na iedere twee weken is er namelijk een mogelijk stopmoment. Zo is het budget veel beter te bewaken.

Als een project alleen wordt gedraaid om de functionele wens van de opdrachtgever te matchen ontstaat in de praktijk vaak programmeer-spaghetti. Code gaat op den duur 'rotten' en  programmeurs worden bang om code aan te passen omdat ze niet weten of een aanpassing gevolgen heeft voor andere delen van het product.

Daarom hanteren we het Test-driven development (TTD) principe. Waar we voordat we 'echte' code schrijven eerst een test maken om te zien of de code doet wat hij moet doen. De code wordt continu aangepast, maar de tests blijven bestaan zodat altijd gezien kan worden of een aanpassing in de code problemen in het systeem veroorzaakt.

Mijn advies is dan ook: voor projecten die langer dan vier weken in beslag nemen kies voor een flexibele, Agile, aanpak. Als opdrachtgever word je hiermee continu gedwongen om prioriteiten aan te geven. Tegelijkertijd creëer je een hoop flexibiliteit om nieuwe onderdelen in de software te verwerken. Het geeft opdrachtgevers en -nemers een blij en tevreden gevoel omdat zij beide het onderste uit de kan kunnen halen en het resultaat echt zichtbaar wordt!
 

Hoofdstraat 154
7811 EW Emmen
0591 - 785318

info@ediso.nl
support@ediso.nl
Menu Sluiten