Onlangs las ik in het Financieele Dagblad een artikel over de problemen rond de stemapplicatie voor het lijsttrekkerschap bij het CDA. Een it'er en een notaris hadden samen onderzoek gedaan naar de applicatie. De conclusie: de applicatie werkt correct. Maar de it-onderzoeker merkte volgens de krant wel op dat ‘er geen functiescheiding tussen ontwerp, bouw, test en operationele ondersteuning van de applicatie’ was.
Toen ik deze passage las, moest ik terugdenken aan dertig of veertig jaar geleden, toen de meeste projecten nog uitgevoerd werden volgens het watervalmodel. Toen had je aparte functies voor functioneel ontwerp, technisch ontwerp, bouw, test en beheer, met bijbehorende salarisschalen. Al deze functies werden uitgevoerd door verschillende personen met ieder hun eigen takenpakket en verantwoordelijkheden. De reden waarom we dat vandaag de dag niet meer zo doen, is dat dat nogal wat problemen veroorzaakt.
Tegenwoordig bouwen we applicaties via een agile-proces in een multidisciplinair team waarbij ieder teamlid verschillende rollen op zich kan nemen en in principe zowel de analyse als design, bouw, test en delivery voor zijn rekening neemt. In een devops-omgeving is het team ook verantwoordelijk voor de operationele ondersteuning. Die functiescheiding waar de it-onderzoeker het hier over heeft, bestaat dus al zo’n dertig à veertig jaar niet meer.
Betekent dat dan dat er geen enkele controle meer is op wat een teamlid ontwerpt en bouwt? Ja, wel degelijk, want in een agile-proces is een work-item pas af als het gereviewd (verified) is door een ander teamlid. Dat laatste is lastig als je team slechts uit één persoon bestaat en dat is vermoedelijk waar de kritiek van de it-onderzoeker zich in dit geval op richt, al drukt hij zich daarbij wat ongelukkig uit.
Het is wel belangrijk ons te realiseren dat de controle die vroeger uitgevoerd werd door de genoemde functiescheiding, tegenwoordig vervangen is door peer reviews. Ook die worden onder tijdsdruk gemakkelijk overgeslagen en dat is natuurlijk niet de bedoeling, want dat kan leiden tot structurele ontwerp- of ontwikkelfouten.
Met alleen peerreviews ga je er echt niet komen. Dat is wellicht idee van de SCRUM-adepten, maar niet als je naar de concrete resultaten kijkt. Ontwerpen, bouwen, testen en operationele ondersteuning zou ik zeker vervolmaken met DOCUMENTEREN.
Als je iets nieuws maakt, moet je op zijn minst een stramien hebben, van hoe je de zaken denkt in elkaar te zetten. Nu is het menselijk brein maar heel mondjesmaat in staat om zaken “in een groter geheel” te zien. Overigens zijn er meer aspecten aan het bouwen van de applicatie, dan alleen de de functionele werking. Security, privacy, procesoptimalisatie (vertaling vanuit de business), produkteigenschappenrationalisatie, etc…
Het grootste probleem van programmeurs (ik noem ze even geen softwareontwikkelaars) is dat ze coderen het leukste werk vinden. Een technische uitdaging zit er soms ook nog wel in en dan heb je het bijna wel gehad. Ik ken maar weinig programmeurs die testen, als die niet functionele aspecten (security, privacy, etc….) meenemen in het ontwerp en DOCUMENTEREN leuk vinden.
En dat geeft niet, het is de aard van het beestje. Dat DOCUMENTEREN wordt door veel programmeurs afgedaan als een niet nuttige bezigheid. Ik zal een aantal voorbeelden geven waarbij DOCUMENTEREN van een compleet organisatie-landschap relevant is. Daarbij moet je je voorstellen dat je vanuit de producteigeschappen, de wet- en regelgeving, organisatie-proces, niet functionele aspecten, technische invulling (zowel software als infrastructureel) en de concrete opgeleverde code een integrale beschrijving van het geheel maakt. De voordelen zijn navenant:
– programmeurs hebben een belangrijk adagium, namelijk “NOT INVENTED here!” en gaan dus voor de tienduizendste keer dezelfde inlogprocedure schrijven
– infrastructuur (operations) hebben ook een belangrijk adagium, namelijk “QUICK and DIRTY and by hand!” en gaan dus lukraak maar wat zaken “uit en/of aan zetten, zonder na te denken waarom je dat zou willen
– door af te dwingen dat je integraal je documentatie op orde hebt (en laten we dat dan ook geautomatiseerd doen) zorg je ervoor dat je veel onderdelen niet nog eens gaat ontwikkelen: daadwerkelijk hergebruik van de keten
– ook levert het je op dat er aan het begin van de keten of misschien zelfs de oorspronkelijke vraagstelling een goede discussie met de lijnorganisatie op (diegene die uiteindelijk gaan werken met de software). Overigens ben ik allang niet meer overtuigd dat zoals dat aan het begin van deze eeuw werd gesuggereerd, dat de lijnorganisatie wel weet hoe ze hun eigen werk moeten organiseren. Het integraal vormgeven van een afdeling is vakwerk en dat vereist kennis van heel veel aspecten. Ik ken maar weinig leidinggevenden of mensen in de lijn, die de capaciteiten hebben om dat te doen
– een tweede aspect in de lijnorganisatie die lastig is, is dat bij procesrationalisatie en ook produktrationalisatie er wellicht werk wegvalt. Als je wat langer meeloopt weet je dat dat bij heel veel leidinggevenden als “lap op een rode stier werkt”. Minder werk en er geen andere taken voor terugkrijgen, betekent minder mensen en minder budget. Helaas wordt in de Angelsaksische wereld (waar wij Nederlanders ons aan afmeten) het aantal mensen dat je (in)direct aanstuurt in combinatie met je budget (of omzet/winst) gezien als succes
– on topic weer: voor mij is agile niets anders dan de manier waarop een gereed product tot stand komt. In kleine stukjes. Het eindresultaat van een agile project of een Waterval project zou in essentie qua inhoud niet moeten verschillen. Natuurlijk zou het wel kunnen zijn dat door voortschrijdend inzicht bij agile ontwikkelen er andere functionaliteiten in het eindproduct zitten dan bij een waterval aanpak
Conclusie: indien programmeurs willen promoveren naar ontwikkelaars zullen ze op zijn minst de ontwerpvaardigheden moeten hebben van een procesanalist en dat zie ik niet zo snel gebeuren. Veel ontwikkelaars hebben niet de vaardigheden om in het primaire proces van de eindgebruiker in te grijpen, ze worden door de lijnorganisatie weggezet als techneuten. Bouw vooral ICT en bemoei je niet met “ons proces”. Dat ICT en proces vandaag de dag compleet in elkaar verweven zit, zien beide kanten niet. Daar is het nog steeds nodig om dat juist inzichtelijk te maken en de meerwaarde van DOCUMENTEREN te laten ervaren.
– 1980-1990 devops ?
– al eens een devops team OPS zien uitvoeren op een mega applicatie ?
– hoe zou scrumpoker gespeeld worden bij OPS ?
– wat testen als de agile specs niet duidelijk zijn ?
– integratietests/systeemtests/gebruikersacceptatietests maar overslaan ? (komt wel goed uit als de teammembers toch geen idee hebben wat dat zijn)
– garanderen devops teams met T-profiel members niet gewoon slechte peer reviews, of gaat de specialist steeds reviewen 🙂 ?
Er is een reden dat we functie scheiding zoals trias politica invoeren bij zaken die complex zijn en ertoe doen.
Inderdaad, “Met alleen peerreviews ga je er echt niet komen”.
Haha, ik moest als IT onderzoeker nog weleens een reden zien te vinden voor de conclusie die al getrokken was. Zo kan ik me nog een IT project herinneren waarvan iedereen al wist dat het mislukt was maar kon die conclusie pas openbaar gemaakt worden toen de leverancier failliet ging. Deze had natuurlijk geen enkele schuld maar politiek kon die suggestie wel gewekt worden waardoor het bestuurlijke imago gered was. Een vakje met een rood potlood inkleuren is natuurlijk ouderwets maar de telling achteraf is wel transparanter dan het geklungel van een partij die een aversie tegen de democratie heeft.
@Dino : “al eens een devops team OPS zien uitvoeren op een mega applicatie ?”
2 jaar terug een SAP (HANA) systeem bekeken dat even snel in AWS was “gedeployed” door een DevOps (een tot DevOps bevorderde Linux man) die verder helemaal geen kennis had van de applicatie. Interessante ervaring!