Sleutels tot Succes en Conclusie – Deel II Zijn fouten kostbaar bij software ontwikkeling?

BLOG | LEESTIJD: 4 MINUTEN

Dit is Deel II uit het tweeluik: Zijn fouten kostbaar bij software ontwikkeling? Bekijk hier eventueel Deel I

De sleutels tot succes lijken te zijn:

Lever minder, maar vaker software changes aan de klant en start waar mogelijk met een minimum viable product (MVP).

Blijf investeren in Continuous Integration en Continuous Delivery (CI/CD) en integratie met testautomatisering – maak voor efficiënte levering gebruik van CI/CD pipelines. En de gereedschapskist met tools ontwikkelt zich ook door. We hebben een blog over CI-tools en met plugins kun je ook de integratie met automatische testtools maken zodat automatisch testen een vast onderdeel wordt van je build of releaseproces.

Gebruik ideeën uit Lean om verspilling te identificeren en te elimineren en werk met bijvoorbeeld de KanBan methode om de cyclustijd te minimaliseren en incorporeer dit ook binnen je CI-tooling.

Neem voldoende tijd en aandacht voor de requirement en ontwerpfasen. Door vooraf voldoende tijd te besteden aan het begrijpen van vereisten en aan het ontwerp om het de eerste keer in ieder geval grotendeels goed te doen, valt later veel te besparen. Niet meer de misvatting van waterval; denken dat met veel planning vooraf en ontwerp denken, alles van tevoren goed te zullen krijgen. Maar het is ook belangrijk om geen tijd en geld te verspillen aan itereren wanneer dat niet nodig is. De grootste en soms kostbaarste fouten vinden meestal hun oorsprong in de requirement fase waardoor er simpelweg een product wordt ontwikkeld welke niet aansluit bij de behoefte van de business. De juiste aandacht voor requirement engineering en werken met een MVP waardoor je vlot de business een beter inzicht kunt bieden in waar het product naar toe beweegt en de mogelijkheid biedt te kunnen bijsturen voorkomt in elk geval kostbare herhaling van stappen.

Of je nu incrementeel en iteratief of sequentieel werkt, het is logisch om fouten zo vroeg mogelijk op te sporen. Of je dit nu doet door eerst testen en ontwikkelen, of door workshops en code reviews te eisen. Vaak is het een combinatie die nodig blijkt en het is uiteindelijk wat het beste voor je werkt.

De manier waarop softwareontwikkeling tegenwoordig wordt gedaan, stelt ons niet in staat deze ‘cost of defect’ metriek van Boehm meer toe te passen. Er is te veel veranderd sinds het is bedacht. De echte uitdagingen blijven nog altijd zitten in:
Communicatie, planning, management, teamwork en vooral kwaliteit.

Staar je niet blind op de kosten voor ontwikkeling maar beschouw ook de kosten over de totale levensduur. Vlot naar productie met slecht onderhoudbare code kan nu het goedkoopst lijken maar later kostbaar blijken.

Beschouw wijzigingen niet enkel als kostenpost, ze kunnen namelijk veel waarde toevoegen. Omgevingsfactoren maar ook inzichten kunnen wijzigen gedurende het ontwikkelproces. Althans kunnen opgemerkt worden want wijzigingen doen zich altijd voor – de wereld staat immers niet stil. De realiteit is weerbarstig wordt wel eens gezegd bij het plannen van projecten en schrijven van requirements maar dit heeft wat ons betreft een te negatieve toon en vormt wat ons betreft geen excuus tot het overslaan van de requirement fase. Wel is het raadzaam om deze dynamiek aan te nemen en het vangen van gewijzigde inzichten bij de business ook tijdens het ontwikkelproces en eventueel ruimte te nemen wijzigingen die de business vraagt procesmatig in te bedden. Verschillende studies laten zien dat wijzigingen die voortvloeien uit gewijzigde inzichten of marktomstandigheden vaak een gunstig effect hebben op de vanuit de business waargenomen waarde van het eindresultaat.

Conclusie:

De cost of defect metric van Boehm was eigenlijk het eerste en enige metric die er in het QA vakgebied voor lange tijd is geweest. Dit metric is met de huidige iteratieve ontwikkelmethoden inmiddels achterhaald. Als we kijken naast de cost of defect is het zinvoller te kijken naar the total cost of change waarbij meer kosten in acht genomen moeten worden en bepaalde kosten wel groter worden afhankelijk van in welke fase je in het proces zit. Met een goed agile ontwikkelproces waarbij er o.a. met minimal viable product wordt gewerkt en de business vroeg zicht krijgt op resultaten neemt de kans dat er aan het eind terug naar de tekentafel moet worden gegaan af.

Het mantra schrijf code, geen specificaties is legitiem maar gebrekige documentatie kan wel resulteren tot problemen en verspilling in de fasen na de ingebruikname. De ervaring dat hoog beschikbare software maar ook elk groot lifecycle project leert opnieuw het belang van documentatie. Als we kijken naar de wens goed onderhoudbare software te krijgen is altijd de aanbeveling duidelijke leesbaarheid van de broncode te borgen wat naast de kwaliteit van de ontwikkelaar tijdens de realisatie voortdurende aandacht vraagt. Adoptie van documentatiestandaarden zoals de J-STD-016 kan heel verstandig zijn voor bijvoorbeeld beheersbaarheid en portabiliteit in een vroeg stadium in te voeren. Maar een dergelijke standaard zonder pardon op elke fase voor elk product of project opleggen is onverstandig en allerminst lean. Een organisatie doet er goed aan om vast te stellen wat gedocumenteerd moet worden en dit afhankelijk te maken van het type applicatie en dit te ligneren aan o.a. de importantie van de businessprocessen die hiervan in min- of meerdere mate afhankelijk van zijn.

Als we breder kijken naar hoe kom je tot succesvolle (software)projecten en waarom projecten falen ligt de oorsprong vaak in de begin fasen. Zo wordt de businesscase meestal gebouwd op kostenreductie en worden besparingen gezocht tot dat de investering kan worden gerechtvaardigd. Daarbij worden vaak niet alle values voor het bedrijf geïdentificeerd wat de kans tot realisatie van het volledige potentieel aan waarden voor het bedrijf vele malen kleiner maakt. En ook in de requirementfase gaat het vaak op verscheidene niveaus mis en wordt in de meeste projecten niet met een minimum viable project gewerkt en projecten soms onnodig groot gemaakt waardoor de kans op slagen van een project ook afneemt.

Ook is het verstandig de requirements niet helemaal in steen te gieten maar ook tijdens het ontwikkelproces te toetsen met de business want gewijzigde inzichten en omgevingsfactoren kunnen leiden tot een aangepaste vraag en dergelijke wijzigingen en van grote invloed zijn op de bruikbaarheid en waarde van het uiteindelijke eindproduct.

De doorontwikkeling van het build- en releaseproces met CI/CD en integratie met testautomatisering blijft raadzaam – maak voor efficiënte levering gebruik van CI/CD pipelines. En de gereedschapskist met tools ontwikkelt zich uiteraard door. We hebben een blog over CI-tools en met plugins kun je ook de integratie met automatische testtools maken zodat automatisch testen een vast onderdeel wordt van je build of releaseproces.

Tenslotte:

Naast het kostenaspect, zijn wij sowieso blij dat we de ‘waterval’ ontwikkel methodiek achter ons hebben gelaten. Met name het ‘verrassingseffect’ voor de klant aan het einde van het ontwikkel en opleveringstraject heeft ons altijd bezwaard. Krijgt de klant, zo veel gedeclareerde uren en budget verder, waar zij om gevraagd heeft? Een 50/50% kans tussen blijdschap of teleurstelling.

Met de kennis van nu hadden we beter direct voor de verbeterde iteratieve ‘waterval’ versie van Royce, het zogenoemde spiral model, kunnen kiezen. Dan was de stap naar Agile sneller gemaakt. Met een actievere en meer betrokken rol van de klant met uiteindelijk geen of veel minder teleurstelling

Wil je als organisatie de volgende stap maken neem dan contact met ons op en afhankelijk van de fase waarin u zich bevindt kunnen wij adviseren wat en wie u op dit moment nodig heeft om de volgende stap te maken.

Weet ook dat wij voorstander zijn van gateway reviews of gewoon klankborden. Sta jij voor uitdagingen om op te schalen of wil je een review doen van je huidige programma of project of je build en releaseproces onder de loep nemen kunnen wij hierbij van dienst zijn.