Systeemontwikkelaars kampen regelmatig met het problemen van snel veranderende eisen. De methodologie Extreme Programming (XP) is bedoeld om softwareontwikkeling te structureren binnen dynamische omgevingen. Ze is gebaseerd op eenvoud, communicatie, feedback en durf, en is met name geschikt voor kleine ontwikkelteams, meent consultant Rini van Solingen.
De praktijk van het structureren van softwareprojecten is veel chaotischer dan in de theorie wordt geleerd. De volgende voorbeelden verduidelijken dit.
Ontwikkelprocedures worden niet zorgvuldig beschreven, en als het al gebeurt worden ze vaak niet gebruikt.
Zelden worden de eisen volledig gedocumenteerd, worden kwaliteitseisen beschreven of eisen naar ‘features’ worden vertaald.
Klanten of gebruikers hebben regelmatig geen idee wat een systeem moet kunnen, wat ze er mee gaan doen en hoe het ze het gaan inzetten. Het specificeren van een dergelijk systeem gebeurt daardoor onvoldoende of niet.
Versiebeheer wordt informeel geregeld, over het eigendom van code zijn geen regels en over de analyseerbaarheid en overdraagbaarheid van software wordt veel gesproken, maar er wordt weinig aan gedaan.
Systemen worden zelden volledig getest. Tests worden niet of onvoldoende voorbereid, inspecties worden slechts sporadisch doorgevoerd en kwaliteitsborging blijft beperkt tot het binnenhalen van een ISO-certificaat.
Het delen van kennis en ervaring tussen ontwikkelaars gebeurt alleen op basis van toeval; niemand is op de hoogte van elkaars kennis en slechts weinig werkgevers institutionaliseren kennisopslag en -overdracht.
Bijeenkomsten worden zelden gepland, en doelen niet vastgelegd. De verkeerde mensen zijn er aanwezig, waardoor de bijeenkomsten over het algemeen zeer inefficiënt en ineffectief zijn.
Het gebrek aan gekwalificeerde ontwikkelaars wordt niet opgelost door het te ontwikkelen systeem te verkleinen of te vereenvoudigen, maar met het inzetten van ongekwalificeerd personeel. Dat leidt vaak tot frustratie bij de aanwezige competente ontwikkelaars.
Met deze opsomming zouden we nog wel even door kunnen gaan. De reden voor deze chaos heeft (in tegenstelling tot wat nogal wat ‘deskundigen’ beweren) niets te maken met een gebrek aan discipline of professionaliteit van software-ontwikkelaars. Integendeel, software-ontwikkelaars zijn heel intelligente en competente professionals. Dankzij hen worden er nog systemen opgeleverd en operationeel gehouden.
Aanpassen aan omgeving
De reden voor de chaos is heel eenvoudig. De realiteit is gewoon veel complexer dan we met de beperkte middelen aan kunnen. Binnen de vele eisen die gesteld worden (en vooral ook de vele eisen die niet gesteld worden) wordt een compromis gezocht waarmee iedereen tevreden wordt gehouden. Een software-ontwikkelaar optimaliseert daardoor dan ook naar d�e parameters, waarop beoordeeld wordt.
Een ‘goede’ ontwikkelaar is iemand die belooft extra functies morgen klaar te hebben, en die de daarin gemaakte fouten binnen een aantal dagen oplost en altijd klaar staat om collega’s te helpen om de door hem gemaakte code uit te leggen. Gevraagd om extra functies, zal hij niet eerst een dag nodig hebben om ze te specificeren en in te plannen, en daarna een week bezig zijn om ze (volledig geïnspecteerd en getest) op te leveren.
Helaas moeten we leven met eisen die veranderen, gebruikerswensen die niet beschikbaar zijn, een tekort aan gekwalificeerde ontwikkelaars, en een veel te positieve planning van projecten die daardoor uitlopen. Het heeft geen zin om ontwikkelaars te betichten van een ‘gebrek aan discipline’ en ‘gebrek aan professionaliteit’, of om een afdeling kwaliteitspolitie te installeren. Projecten zijn zo verschillend dat ze niet in een paar eenvoudige procedures te gieten zijn. Het kost veel meer om alle mogelijke processen tot in de diepste details te documenteren, dan het oplevert. We zullen moeten accepteren dat software-engineering binnen een omgeving plaatsvindt met veel onzekerheden. Onze wijze van werken moeten we daaraan aanpassen.
Oplossingen zijn dan ook altijd afhankelijk van de desbetreffende omgeving en de daarin geldende bedrijfsdoelstellingen – het zogenaamde contingentiefenomeen. Oplossingen van het type ‘one-size-fits-all’ en de telkens opdoemende ‘silver-bullits’ bieden geen soelaas.
Behoefte aan structuur
De complexiteit van softwareontwikkeling en de overdaad aan mogelijke oplossingen betekent echter niet dat we maar bij de pakken moeten neerzitten. Je kunt echter tegen de realiteit vechten of deze accepteren. Methoden die onzekerheid, complexiteit en individuele voorkeuren omarmen en beheersen, leveren veel meer waar voor hun geld dan methoden die de strijd aangaan.
De hierboven geschetste problematiek is hanteerbaar te maken met structuur. In veel gevallen wordt geen volledig sluitende oplossing geboden, maar een hulpmiddel beschikbaar gesteld die helpt de problemen in de hand te houden. Structureren is goed, maar net als met zoveel dingen in het leven geldt: niet ’te veel’. Bij een overdaad aan structuur bestaat het gevaar van een bureaucratie van procedures en formulieren, of wordt structuur middel in plaats van doel. Bedrijven die kampen met een overmaat aan structuur, reduceren vervolgens (na een aantal jaren van procedurebureaucratie) het aantal procedures drastisch en keren terug naar de oorspronkelijke doelen. Doelgericht werken op basis van bedrijfsdoelstellingen is de beste basis voor verbetering. Het behalen van certificaten is ten hoogste een middel. Te ver doorschieten en overmatig structureren is gevaarlijk, en kan op termijn leiden tot serieuze problemen.
Maar waar leg je de grens? Wanneer structureer je iets wel en wanneer niet, of minder?
Structurering van softwareprocessen
De meest voor de hand liggende wijze om complexiteit te verkleinen is het bieden van structuur. Door bijvoorbeeld procedures, verantwoordelijkheden, doelstellingen en standaarden te documenteren, is stabiliteit te creëren in zaken die anders flexibel blijven. Binnen de software-engineering heeft deze beheersingsproblematiek veel voortgang geboekt met methoden voor procesverbetering. De meest bekende methoden zijn wel het Capability Maturity Model (CMM) en ISO 9001, maar ook Tick IT (ISO9000-3), Spice (ISO15504), Bootstrap, AMI, Efqm, Profes en GQM zijn methoden die op basis van processtructurering problemen trachten te voorkomen.
Hoofdzaak zijn concrete bedrijfs- en verbeterdoelstellingen. Deze doelen moeten kwantitatief gespecificeerd zijn. Dat betekent dus niet: ’time-to-market’ reduceren, maar ‘de gemiddelde doorlooptijd van projecten terugbrengen naar zes maanden met een standaardafwijking van twee maanden’. De basis van alle verbeterprogramma’s wordt gevormd door algemene veranderprincipes zoals betrekken van het management, motivatie, ‘piloting’, en dergelijke, maar daarnaast ook structureel meten. Zo zijn zaken te concretiseren en kwantitatief te maken. Ook dat gebeurt op basis van de gestelde doelen. Alleen die zaken worden gemeten, die bijdragen aan de doelen of op basis waarvan beslissingen genomen dienen te worden.
Vier pijlers
Verbetertrajecten kennen vier pijlers (gerangschikt op basis van tijdsvolgorde).
Identificeren: het in kaart brengen van verbetermogelijkheden. Dit is doorgaans de eerste stap in een verbeterprogramma. Evaluatiemethoden zoals het CMM of Spice helpen bij het identificeren van mogelijke verbeteringen. Ook beschikbare metingen zijn hiervoor te gebruiken, aangezien deze aangeven waar de grootste prestatieproblemen zitten. Dit is mogelijk voor zowel het proces als het product.
Specificeren: het documenteren van de veranderingen. Veranderingen in producten, procedures, communicatieprocessen, en dergelijke moeten gedocumenteerd worden. Het maken van een proceshandboek of on-line werkstroomprocedures is zo’n tweede stap.
Implementeren: het doorvoeren van de veranderingen. Nadat het voorbereidende werk is gedaan, wordt de verandering geïmplementeerd. Hieraan gekoppeld is het geven van cursussen, het uitvoeren van ‘monitoring’, en het verzamelen en analyseren van metrieken. Dit is de belangrijkste stap, omdat hier de winst behaald wordt.
Evalueren van de effecten. De laatste stap, maar zeker niet de onbelangrijkste is het evalueren van de verandering. Op basis van meetwaarden wordt gekeken of veranderingen wel het geld waard zijn en of de bijdrage aan de doelstelling zodanig is als verwacht. Zonder een dergelijke evaluatie blijven maatregelen slechts veranderingen en wordt niet duidelijk of het wel verbeteringen waren.
Lichtgewicht methodologie
Extreme Programming (XP) is een ‘lichtgewicht’ methodologie voor software-ontwikkeling. XP is gebaseerd op vier basisprincipes: eenvoud, communicatie, feedback en durf. Extreme Programming is opgezet voor kleine ontwikkelteams (twee tot tien personen) die in korte tijd software moeten ontwikkelen, terwijl de eisen snel en vaak veranderen. De schepper van XP is Kent Beck [1]. Uitgangspunt van XP is dat ieder team zijn eigen werkwijze moet definiëren, maar dat de principes en uitgangspunten van XP als basis dienen.
XP kent twaalf uitgangspunten.
Programmeren in paren (‘Pair programming’). Alle software wordt geprogrammeerd door twee programmeurs achter één computer. Experimenten hebben aangetoond dat dit onderhoudbare software met minder fouten oplevert tegen gelijkblijvende kosten. De noodzaak van ‘peer reviews’ verdwijnt grotendeels, doordat dat als het ware tijdens het programmeren plaatsvindt.
Klant is aanwezig. Er is altijd een vertegenwoordiger van de klant aanwezig die bevoegd is om beslissingen te nemen en die weet waarvoor het systeem gebruikt wordt (eindgebruikerervaring). Dit verbetert de communicatie en versnelt beslissingsprocessen. Wanneer men het beschikbaar stellen van een dergelijke vertegenwoordiger ’te duur’ vindt, is dat een indicatie dat het gevraagde systeem niet belangrijk is, en dus wellicht beter niet gemaakt kan worden.
Planning. De klant bepaalt de ‘waarde’ van ‘features’ en vergelijkt deze met de door de ontwikkelaars geschatte kosten. Op basis hiervan worden prioriteiten gesteld en beslissingen genomen. Door zo te plannen zijn continu bedrijfseconomische afwegingen te maken voor (delen van) het systeem. De ontwikkelaars zijn echter de ‘eigenaar’ van de planning, waardoor deze realistisch blijft.
Eenvoud. Het eenvoudigste programma dat voldoet aan de gestelde eisen, wordt gemaakt. Dat lijkt triviaal, maar zo werkt het niet altijd in de praktijk. Bij Extreme Programming denkt men niet na over eventuele toekomstige wijzigingen als deze nog niet bij de huidige eisen staan. Hierdoor blijven de implementaties eenvoudig en wordt voor toekomstige uitbreidingen opnieuw een kosten/baten-afweging gemaakt voor de dan geldende kosten. ‘Features’ met een lagere prioriteit worden dan vaak duurder, en dus alleen geïmplementeerd als ze voldoende waarde hebben.
Testen. Het valideren van software is een continu aandachtspunt. (Geautomatiseerde) tests worden ontwikkeld vóór de software.
Kleine releases. Het te maken systeem wordt in de vorm van kleine, simpele versies uitgebracht, waarna het in korte, snelle cycli wordt uitgebreid.
Continu integreren. Meerdere keren per dag – minimaal één keer – wordt het gehele systeem gecompileerd en geïntegreerd. Hierdoor worden integratieproblemen aan het eind van de ontwikkeling drastisch ingeperkt.
Metafoor. Het XP-team werkt met een metafoor van het systeem en de daarbij behorende systeemterminologie om de communicatie te vereenvoudigen.
Herontwerp. Het ontwerp van het systeem wordt constant verbeterd en heroverwogen gedurende de gehele ontwikkeltijd.
Codeerstandaarden. Alle software-code moet voldoen aan codeerstandaarden, aangezien er in paren geprogrammeerd wordt. Ook zijn zo eenvoudig aanpassingen te doen.
Collectief eigendom. Alle software behoort aan alle ontwikkelaars. Individueel eigendom van code bestaat niet. Als er iets veranderd moet worden: doe het!
Veertig-urige werkweek. Een XP-team werkt niet over. Overwerk wordt gezien als het eerste symptoom van falen, aangezien dit leidt tot ongeconcentreerde en uitgeputte ontwikkelaars.
Een XP-project
Je kunt prima starten met XP in een nieuw project. Begin met het opschrijven van gebruikscenario’s en werk op basis hiervan toe naar een eerste-versieplan. Klant, ontwikkelaars en leidinggevenden moeten aanwezig zijn in de versieplanningsbijeenkomst om samen de planning aan te passen en te accorderen. Dan kan het project beginnen. Middels verschillende iteraties wordt het systeem samengesteld. Eerst moeten de testscenario’s worden gemaakt. Anders is het immers onduidelijk wat er precies geïmplementeerd moet worden. Implementeren geschiedt in paren van twee ontwikkelaars. Voor elke ‘feature’ wordt een automatische test ontwikkeld, die op basis van het regelmatige bouwproces wordt doorgevoerd.
Op basis van de testscenario’s vindt een acceptatietest plaats. Wanneer de aanwezige vertegenwoordiger van de klant de resultaten accepteert, kan de eerste versie de deur uit. Er zullen er nog veel volgen, want het systeem wordt in veel iteraties opgeleverd, zodat aanvullende eisen en problemen direct gesignaleerd worden.
Risico’s
Extreme Programming is ontwikkeld als reactie op omgevingen waar eisen zeer dynamisch zijn, en dus sprake is van snelle en veelvuldige veranderingen. Het gaat met name om innovatieve projecten waar klanten, gebruikers, adviseurs en management niet precies weten wat er gemaakt moet worden. In dergelijke dynamische situaties is één van de weinige constanten het gegeven dat de eisen steeds veranderen. Hierop is het proces dus in te richten. XP is met name geschikt als proces.
Extreme Programming kan een goede oplossing zijn in situaties waarin de risico’s groot zijn omdat de eisen steeds veranderen, of omdat er grote belangen met het systeem zijn gemoeid, of de deadlines erg strikt zijn. Met name voor kleine teams (twee tot tien personen, zowel ontwikkelaars, manager én klant) biedt de methodologie een omgeving met vrijheden – waar die zijn toegestaan – en met structuur, daar waar nodig. XP is niet geschikt voor grote teams, omdat de informele communicatiestructuur dan niet meer voldoet.
Hoewel de beschikbare literatuur aangeeft dat XP gebruikt kan worden door ontwikkelaars met diverse ervaring, lijkt het er op dat de methodologie met name geschikt is voor de meer ervaren technici. Dat komt doordat er veel informeel geregeld wordt en er weinig wordt gecontroleerd. Daarom is het van belang dat de mensen weten wat ze doen. Uiteraard bestaat de mogelijkheid om onervaren mensen middels ‘pair-programming’ aan ervaren mensen te koppelen, waarbij hun software in het kader van de opleiding wordt bekeken.
Er zijn nog weinig experimentele resultaten met XP geboekt. Tot nu is slechts een industriële case-study uitgebreid beschreven. Over de onderliggende technieken, met name ‘pair-programming’, zijn experimentele data van studenten bekend.
De grote doorbraak?
XP is een verzameling technieken die binnen dynamische omgevingen bepaalde problemen kan oplossen. Helemaal nieuw is het niet, omdat de iteratieve ideeën natuurlijk al eerder gepubliceerd zijn (denk maar aan iad, rad, en dergelijke). XP is een verzameling van technieken die goed zijn, en optimaal worden toegepast. De methodologie lost niet alle software-engineering problemen op, omdat zij met name geschikt is voor kleine teams. Voor grotere projecten beidt ze dus (nog) geen oplossing. Bestaande methoden voor procesverbetering verliezen hun bestaansrecht zeker niet. In grotere organisaties waar structuur gebracht moet worden in de ontwikkelactiviteiten, bieden de SPI-methoden nog steeds voldoende houvast.
Om structuur te brengen binnen een kleine organisatie, of nog beter binnen een specifiek project, kan XP een oplossing zijn. Vergeet echter niet dat de methodologie een middel is en geen doel. Ze is bedoeld om grip te krijgen op ontwikkeling binnen een situatie met sterk veranderende eisen, korte doorlooptijden en redelijke kwaliteitseisen. Afhankelijk van het project, of liever de bedrijfskundige doelstelling waar een software-systeem aan moet bijdragen, zal een weg gekozen moeten worden.
Op basis van doelstellingen zoals doorlooptijd, kosten, menskracht, betrouwbaarheid, bruikbaarheid, en dergelijke, moet een proces samengesteld worden dat zo efficiënt en effectief mogelijk aan deze doelen voldoet. De keuze van een proces op basis van dergelijke doelstellingen is niet altijd even makkelijk, en kan niet altijd helemaal alleen genomen worden.
Binnen bepaalde randvoorwaarden kan XP dus een prima oplossing zijn, maar er leiden meer wegen naar Rome. Even verder kijken kan zeker geen kwaad.
Literatuur
[1]. Kent Beck, Etreme Programming Explained: Embrace Change, Addison-Wesley; Isbn: 0201616416. (1999)
[2]. Ron Jeffries, Chet Hendrickson, Ann Anderson: Extreme Programming Installed, Addison-Wesley Pub Co; Isbn: 0201708426, (2000)
[3]. Kent Beck en Martin Fowler: Planning Extreme Programming, Addison-Wesley Pub Co; Isbn: 0201710919. (2000)
Informatie
http://www.extremeprogramming.org/
http://www.xprogramming.com
http://www.xpdeveloper.com/
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
XP case-study:
Pair programming experiment:
Conferenties
http://www.xp2001.org/
http://www.objectmentor.com/XPuniverse/
Rini Van Solingen Principal Consultant Product- En Procesverbetering Cmg
