Gebruikers kijken niet onder de motorkap van hun it-systemen: zij willen prettige functionaliteit, snelheid en veiligheid. De Agile en scrum trend – waar ik overigens heel blij mee ben – werkt dat nog eens extra in de hand. Dat komt door de nadruk op werkende software en de waarde voor de business. Daar is natuurlijk niets mis mee, maar it-kwaliteit onder de motorkap is lange termijn business waarde.
Rond de millenniumovergang had iedereen het er over, maar ‘de softwarecrisis’ lijkt inmiddels geen topic meer te zijn. Toch is het dat nog wel, want er wordt nog steeds code van slechte kwaliteit geproduceerd en vaak is dat een tikkende tijdbom. In Agile en Scrum kennen wij het begrip ‘debt’ en ik merk dat we daar veel over spreken. Debt is achterstallig onderhoud, bijvoorbeeld onder de motorkap van je it-systeem.
Grote beurt: stabilisatiesprint
Veel Scrum-teams doen uiterst zorgelijk over het fenomeen dat ze dit niet aan de business kunnen uitleggen. Dat ze namelijk zo nu en dan een sprint nodig hebben waarin ze geen coole nieuwe functies voor de business opleveren, maar de zaak onder de motorkap weer netjes maken en rechttrekken, hun ‘debt’ inlossen dus. Ik verbaas me daar altijd over, want iedere automobilist snapt dat je zo nu en dan naar de garage moet voor een beurt of een reparatie. Ja, dat kost tijd en geld, maar hoort er gewoon bij. Je kunt dus ook iedere it-gebruiker die wel eens een auto heeft gezien uitleggen dat onderhoud onder de motorkap er gewoon bij hoort. Dat doe je bijvoorbeeld in een zogenaamde ‘stabilisatiesprint’. In een stabilisatiesprint besteed je extra aandacht aan programmeerstandaarden en codekwaliteit. Refactoring heet dat in Agile-termen, een begrip dat eigenlijk uit Extreme Programming (XP) stamt.
Nu is het wel zaak om het aantal stabilisatiesprints binnen de perken te houden. In software-land vinden allerlei concepten ingang die daaraan bijdragen, waaronder:
- Continuous integration: elk nieuw stukje code wordt ingecheckt op de continuous integration server, waarin het direct automatisch wordt getest in de context van de totale applicatie. Bovendien, en dat is in dit verband nog belangrijker, wordt de code automatisch gevalideerd op integriteit en het voldoen aan afgesproken standaarden.
- Continuous Deployment: dit gaat nog een stapje verder; nieuwe code wordt continu (misschien wel dagelijks) uitgerold naar de gebruikers.
- Test Driven Development: dat werkt zo: 1. schrijf testscript 2; run testscript (moet falen, ‘false positive’ uitgesloten); 3. schrijf/modificeer software; 4. herhaal 2 en 3 net zolang tot de test niet meer faalt. Testen is daarmee geen activiteit achteraf meer, en je kunt dus ook geen achterstand in (regressie)testen opbouwen.
Secure software development is ook zo’n thema: hoe bouw je systemen die onder de motorkap al inherent veilig zijn? Dat is beter dan een Owasp-auditje achteraf. Ik hou het hier even kort. Hier lees je nog wat meer en ik ben benieuwd naar de reacties.
Agile is bedoeld voor het kunnen opbouwen van achterstanden, om zo sneller aan de business vraag de kunnen voldoen. In businesstermen : lean en businessdriven.
APK’s zijn niet vrijwillig en autobezitters zijn ook een stuk minder enthousiast als ze de rekening zien. O.a. Ruud Mulder schreef al eens een artikel over APK t.b.v. ICT in computable.
Maar APK is iets anders. Dat is het bewijs dat je auto in orde is. Dus eigenlijk een audit.
Je kunt de kosten vervelend vinden maar op een gegeven moment zijn de kosten van niet onderhouden hoger. En dan kom je met panne langs de weg te staan. Dan blijkt dat de keuze voor de nieuwe toepassingen toch niet helemaal de beste keuze, helemaal als deze dan fouten blijkt te bevatten. Inderdaad, nog beter is het om zo veel mogelijk de fouten er al bij het ontwikkelen uit te halen. Hoe beter de kwaliteit tijdens de ontwikkelfase des te minder onderhoud er later nog weer nodig is. Helaas hangt er aan de kwaliteit ook een prijskaartje.
@Felix, je hebt gelijk, maar waarom je APK noemt weet ik niet want dat woord had ik (hier) niet gebruikt geloof ik. Blijft natuurlijk wel staan dat ook APK-keuringen in het belang van ‘de business’ zijn: alle weggebruikers en de eigenaar in het bijzonder. Het gaat verder dan korte termijn ‘hij rijdt toch’. Ook bij lean en business driven kan dat een valkuil zijn.
@Berry: helemaal met jou eens. ALS we kwaliteit onder de motorkap vanaf het begin serieus nemen (in planning, DoD, demo’s en retro’s) DAN hoef je geen stabilisatiesprints etc. te doen. Helaas zie ik teveel niet-ideale situaties…