Feit of fictie?
Overheden proberen zonder enige twijfel goed werk te verrichten, ook als het om IT-projecten gaat. Zij gaan te rade bij experts en sparen kosten noch moeite om de lessen uit het verleden ter harte te nemen, maatregelen te treffen, good practices te gebruiken. Toch valt het vaak tegen.
Een van de problemen is dat niet alleen buitenstaanders onvoldoende overzicht blijken te hebben over wat wel en niet werkt, en in welke omstandigheden, maar dat ook de – soms zelfbenoemde – experts er niet uitkomen.
Het beroemde MIT (Massachusetts Institute of Technology) trok dit naar een nog hoger niveau en ontwikkelde een ‘Automatic CS Paper Generator’. CS staat voor Computer Science. MIT stuurde allerlei papers waarbij alle tekst, inclusief titel, guren, tabellen, referenties werden gegenereerd, naar allerlei, veelal bedenkelijke conferenties. Doel: kijken of ze na peer review werden geaccepteerd. En dat gebeurde zowaar, soms zelfs in conferenties onder auspiciën van het gezaghebbende IEEE (Institute of Electrical and Electronics Engineers).
Onderscheiden van feit en fictie is dus bepaald geen sinecure voor menigeen in dit vakgebied. Agile is zo’n term waar iedereen achteraan holt. Men papegaait elkaar na, weet niet wat er werkelijk speelt, of het wel een goed idee is, en ondertussen geeft iedereen er zijn eigen invulling aan. Bijvoorbeeld wel elke paar weken een sprint, maar nooit werkende software in productie brengen. Maar goed, Agile is geen methode maar een beweging!
Over het algemeen tref ik niet Agile aan, maar een combinatie van copy-paste, trial & error en repair (ik kort dat af met de term CREPT, spreek uit als CRAP). Flagrante engineeringfouten worden begaan: geen eisenanalyse, niet-functionele eisen vergeten, architectuur komt onderweg pas, ontwerp stelt niets voor, documentatie is een drama, geen testontwerp (hoe kan het ook zonder eisen en een design). Maar we bouwen wel code! Ineens blijkt het project toch tegen te vallen en dat terwijl we zo hard aan het werk zijn.
Softwareontwikkeling is heel lastig, vooral als het om grote systemen gaat met vage eisen, harde deadlines en strakke budgetten. Stap 1 is een gedegen requirements engineeringfase, zodat je een maakbaar en consistent pakket van eisen kunt afkaarten waar iedereen het over eens is. Als je die stap niet voor elkaar kunt krijgen in een overheidscontext: vergeet het dan maar, je gaat geld verbranden. Veel geld.
Het uitvoeren van stap 1 is geen kwestie van “gewoon even doen”; dat vergt vakmanschap en een degelijke opleiding. Het behelst onder andere: elicitatie, identifcatie, analyse, modellering, validatie en management van eisen. Zowel voor de functionele als niet-functionele eisen zoals performance security, availability, reliability, enzovoort.
Maar nu de test: is dit waar? Ik wens u er veel plezier mee! En kijk ook eens in dit artikel: ‘Comparing Systems Engineering and Project Success in Commercial-focused versus Government-focused Projects’.
Dat Agile is me wat. Een beweging? Misschien wel een religie, ik kom hem vaak tegen, de Agile evangelist.
Een mooie pleidooi voor een gedegen aanpak en de rol van de documentatie. Maar zegt het Agile manifesto niet, niet teveel documenteren als het maar werkt? Agile is inderdaad slecht gedefinieerd, het leidt tot oeverloze discussies en in de praktijk is Agile synoniem met de procesbegeleidingsmethode scrum. Ik heb zelfs al vernomen dat scrum gedoceerd wordt in het beroepsonderwijs. Het is te hopen dat er ook aandacht besteed wordt aan de de rol van documentatie en aanpak zoals genoemd in deze column. En niet dat de grote scrum todo lijst voldoet.
Ook al denk dat er wel iets in zit, Agile in de enge zin: wendbaar en flexibel. Er moet ruimte zijn voor voortschrijdend inzicht, dat is de manier waarop software ontstaat. Een stap achteruit om er weer een paar naar voren te zetten. Dat is wat anders zoals het nu is: van sprintje naar sprintje wat door ‘de business’ gewenste functionaliteit erin wrotten.