De statistieken voor software-ontwikkelingsprojecten zijn ontnuchterend - en dat zijn ze al vele jaren. Nog steeds eindigen veel te veel projecten duurder dan beloofd en later dan afgesproken. De Standish Group, bekend van hun Chaos Reports over dit onderwerp, onderzocht zo'n 10.000 software-projecten en concludeerde, in een rapport dat eerder dit jaar verscheen, dat 21% van die projecten volledig was mislukt, als in: voortijdig stopgezet of geweigerd door de opdrachtgever. 37% van de onderzochte projecten werd wel met succes afgerond: op tijd, binnen budget en tot tevredenheid van de eindgebruikers. De overige 42% had problemen: ze werden te laat opgeleverd, kosten meer geld dan verwacht, kwamen niet tegemoet aan de wensen van de eindgebruikers, of een combinatie van die dingen.
Er kunnen grote belangen gemoeid zijn met dergelijke software-projecten, en het zal dan ook niemand verbazen dat bedrijven voortdurend op zoek zijn naar manieren om dergelijk kostbaar falen te voorkomen. Waar gaat het fout?
Die vraag wordt regelmatig voorgelegd aan Billie Blair, die als organisatie-psychologe en CEO van Change Strategists consultants mag komen opdraven als projecten van soms vele miljoenen dollars aan de grond dreigen te lopen.
Blair stelt voorop dat de oorzaak van falende software-projecten gewoonlijk bij het projectmanagement ligt. "Alles wat misgaat bij een bedrijf kan altijd worden herleid naar de manager," zegt zij. Vaak blijkt een projectmanager simpelweg niet klaar voor de toegewezen taak. Veel managers zijn van oorsprong ontwikkelaars, IT-ers of hoogopgeleide programmeurs die tot manager zijn gebombardeerd wegens de misvatting dat iemand met goede technische vaardigheden automatisch ook een goede manager zal zijn, aldus Blair.
Heil van agile?
De menselijke kant van de problemen in de software-ontwikkeling krijgt steeds meer aandacht dankzij de opkomst van 'agile' procestechnieken, waarin nadruk wordt gelegd op communicatie, samenwerking, razendsnelle codeproductie en geregelde feedback tussen alle leden van de ontwikkelingsteams.
Landmark Graphics, een ontwikkelaar van industriële systemen, heeft zijn organisatie agile ingericht. De bedrijfscultuur draait er om teams die optimaal samenwerken, zegt Todd Little, senior development manager bij het bedrijf. Little vergeleek de praktijk van de voortdurende reviews die plaatsvinden in agile projecten met de traditionele watervalmethode, "waar je pas aan het einde ontdekt hoe diep je in de problemen zit".
Wat Little opviel is dat, als er een probleem optreedt in een agile ontwikkelingsproject, het zelden om technische uitdagingen gaat. "Vrijwel altijd zit het probleem bij de mensen."
Barry Boehm, die leiding geeft aan het Center for Systems and Software Engineering aan de University of Southern California, merkt op dat agile weliswaar erg geschikt is om snel met bruikbare software te komen die naar behoefte kan worden doorontwikkeld, maar dat er ook nadelen kleven aan de methodiek.
Een van de problemen die Boehm ziet opduiken is wat hij "het makkelijkste eerst" of "technische schuld" noemt. Dat betekent dat een ontwikkelaar, die graag zijn gebruikers en klanten wil plezieren, geneigd kan zijn alles in main memory te stoppen. "Zo'n programma levert geweldige prestaties en je gebruikers zijn er blij mee - totdat het main memory vol zit," zegt Boehm. "Dan heb je opeens een architectuurprobleem in handen."
Boehm ziet daarnaast ook dat ontwikkelaars geneigd zijn beveiligingsfuncties op de lange baan te schuiven, tot het te laat is en er al teveel onveilige functionaliteit in het project is geslopen.
Volgens Boehm is de agile methodiek desondanks heel geschikt voor met name kleinere projecten, en projecten waarin de requirements snel veranderen - maar dan vooral "in organisaties waar mensen zich op hun gemak en verantwoordelijk voelen".
Reageer
Preview