agile (NL)

Een van de eerste fasen in de ontwikkeling van een nieuwe tool (software of hardware) is een functionele specificatie. De functionele specificatie rijpt in discussies tussen de ontwikkelaars (afdeling R&D) en de vertegenwoordigers van de klant (vaak de afdelingen marketing en verkoop).

Natuurlijk is een functionele specificatie handig: het is erg moeilijk om iets nieuws te ontwikkelen zonder een idee te hebben van hoe de nieuwe tool zal worden gebruikt en waarmee deze zal worden vergeleken. Het definiëren van een functionele specificatie kan echter ook te ver gaan. In sommige organisaties zijn de functionele specificaties tot in de kleinste details uitgewerkt. Aan het einde van een lange formele procedure wordt het bestekboek ondertekend als een contract tussen marketing en ontwikkeling. De ontwikkeling kan pas worden gestart als de lijst met handtekeningen compleet is en zal worden uitgevoerd in complete afzondering van de wereld van potentiële gebruikers. Waarom maken organisaties hun specificaties op deze manier? Het is vaak een poging om de verantwoordelijkheden van de afdelingen te scheiden, zodat als er iets niet lukt de juiste partij de schuld krijgt. Als het eindproduct niet voldoet aan de functionele specificaties, kan dit worden toegeschreven aan de ontwikkelaars. En als het product niet slaagt terwijl het wel aan alle functionele specificaties voldoet, wordt dat aan de marketing toegeschreven.

Ik heb een serieus probleem met deze benadering: hoe kan men er met behulp van deze procedure voor zorgen dat het product nuttig zal zijn? Na twee jaar zonder interactie kan ontwikkeling precies opleveren waar marketing om vroeg (alle deadlines halen en binnen budget), maar de markt is veranderd en heeft het ontworpen product niet meer nodig. Of de techniek is veranderd, en betere specificaties zouden binnen handbereik zijn geweest en worden aangeboden door de concurrentie. Of misschien heeft marketing echt een fout gemaakt en gevraagd om iets waar de wereld niet op zit te wachten. In deze gevallen kan de ontwikkelingsafdeling duidelijk niets worden verweten! Maar als je op deze manier een verouderd product ontwikkelt, waar blijft de organisatie als geheel dan? En als dit niet de beste oplossing is voor de organisatie als geheel, is het dan wel goed voor de ontwikkelafdeling? Ook al deed iedereen precies wat er van hem verwacht werd, toch kunnen er mensen ontslagen worden omdat ontwikkelingskosten niet terugverdiend kunnen worden.

De oplossing is, zoals zo vaak, om een middenweg te behouden. Met behulp van b.v. Met Agile- of LEAN-ontwikkelingsmethoden kunnen ontwikkelaars voortdurend in contact blijven met marketing. Iteratieve en modulaire ontwerpprocedures kunnen worden gebruikt om te controleren of de nieuwe tool doet wat hij moet doen, zonder te vertrouwen op het vermogen van mensen om specificaties vooraf in woorden te beschrijven. En omdat de communicatie met de markt niet verloren gaat tijdens het ontwikkelproces, heeft de tool een aanzienlijk grotere kans om daadwerkelijk bruikbaar te zijn op het moment van introductie.

Afbeelding (door QuiteLucid op Flickr): "een kameel is een racepaard ontworpen door een commissie".

Ultra-cool scrum kanban voor het Molgenis team

#agile #umcg #groningen

Er zijn twee manieren van autonavigatie: non-agile en agile. Niet-agile navigatie is wanneer u een vel papier meeneemt met instructies zoals deze:

5 km rijden. Ga naar links. Bij het derde stoplicht rechts, dan voor het blauwe gebouw links. Stop wanneer u aankomt bij een tankstation.

Niet-agile navigatie werkt prima als er een pad naar de bestemming is dat bekend is en waar je geen fouten kunt maken. Als er iets verandert op het pad, als er wegwerkzaamheden zijn, als je een fout maakt op de route: dan is er geen tweede kans; het zal onmogelijk zijn om met de bestaande instructies de bestemming te bereiken. Bovendien: als er niemand in de buurt is die naar dezelfde bestemming is geweest (zelfs meerdere keren), is het onmogelijk om zo'n gedetailleerde beschrijving van de route te krijgen.

Agile navigatie maakt gebruik van verkeersborden. Om bij het San Francisco Museum of Modern Art te komen, volg je eerst de borden naar Californië, vervolgens naar San Francisco en daar aangekomen volg je de borden naar SFMOMA. Het enige dat je moet weten, is waar je heen gaat, en ongeveer waar dat is (recursief, als je wilt). Deze manier van navigeren is zeer robuust: ook als een straat eenrichtingsverkeer wordt, of als het blauwe gebouw wordt afgebroken, kun je nog steeds op je bestemming komen. Wat nog beter is, is dat als uw exacte doel onderweg verandert, je de plannen nog steeds kunt wijzigen. Op weg naar San Francisco kun je nog steeds besluiten dat je in plaats van het museum de Golden Gate wilt bezoeken.

Nu probeer ik je natuurlijk niet te leren hoe je in een auto moet navigeren. Ik wil dit gebruiken als metafoor voor de ontwikkeling van software.

Hoe is softwareontwikkeling zoals navigatie? Je weet normaal gesproken niet precies wat je moet ontwikkelen. En slechts zelden kun je precies de sporen van iemand anders volgen. Softwareontwikkeling is niet zoals het bekende pad dat geschikt is voor niet-agile navigatie.

Toch wordt er nog steeds veel software ontwikkeld met behulp van niet-agile methodes. Specificaties worden volledig vastgelegd voordat de ontwikkeling wordt gestart. De exacte stappen die nodig zijn, zijn in detail beschreven. Contracten worden getekend. En dan ontstaan er wegblokkades, en het project overschrijdt het budget en loopt achter op schema. En als het project opgeleverd is, is de klant niet blij met de functionaliteit omdat ofwel zijn ideeën veranderd zijn, ofwel hij zich niet nauwkeurig genoeg heeft kunnen uitdrukken in de specificaties.

Agile softwareontwikkeling heeft alle voordelen van agile navigatie. Je kunt naar onbekende plaatsen gaan. Je kunt onderweg zelfs de details van de plannen wijzigen. En het is zeer robuust tegen onverwachte wegblokkades. Het is duidelijk de juiste keuze.

Agile softwareontwikkeling is niet eenvoudig. Maar het is minder vatbaar voor totale mislukking dan de traditionele methode. Laten we leren navigeren op de verkeersborden!

Agile in softwareontwikkeling betekent vooral dat de klant het gevoel moet hebben dat je direct aan de slag kunt.

Om snel resultaat te kunnen leveren, is gegarandeerde kwaliteit essentieel. Je moet ervoor zorgen dat niets wat je verandert de bestaande functionaliteit kapot maakt.

Als je echter uw kwaliteit probeert te verzekeren door releasevoorschriften en procedures voor codebeoordeling toe te voegen of door formaliteiten te verhogen door iemand tot releasemanager te maken, druist dit in tegen het agility-doel. Een bugfix van twee minuten wordt een beproeving van twee weken.

In plaats daarvan moet je de kwaliteit waarborgen door middel van geautomatiseerd testen. Tools voor continue integratie worden nooit moe van het steeds opnieuw uitvoeren van dezelfde tests. Ze zijn altijd beschikbaar wanneer je ze nodig hebt, maken nooit fouten en zijn snel. Zij zijn de agile kwaliteitsgarantie.