RUP (rational unified process) wordt door veel mensen niet als agile-methodiek gezien, maar kan wel degelijk zo worden toegepast. Sterker nog, in RUP zijn veel agile-principes terug te vinden! Aangezien RUP nog steeds een belangrijk en veelgebruikt ict-ontwikkelproces/raamwerk is, is het belangrijk om eens te belichten waarom een concrete RUP-implementatie vaak een laag agile-gehalte heeft en hoe voordeel te halen is uit het benadrukken van agile-principes in RUP.
Sinds anderhalf jaar ben ik bezig bij een klant om RUP in te voeren. Van mijn 'agile-minded' collega's krijg ik dan regelmatig te horen: "Hoeveel kilo templates heb je al gemaakt?" en "Zijn ze al gewend aan de stapels documentatie?". Helaas hebben veel daadwerkelijke RUP-implementaties nog steeds te kampen met grote hoeveelheden documentatie, een overdreven ruim opgezet proces en zwaar opgetuigde tooling.
Desondanks heeft RUP veel agile-aspecten, als het tenminste juist wordt ingevoerd en begrepen. Die aspecten zijn bijvoorbeeld het samenwerken in en tussen multidisciplinaire teams, het met regelmaat opleveren van werkende, waarde toevoegende software, het grote belang van sterke betrokkenheid van klant/belanghebbenden en het omgaan met wijzigingen.
Waarom wordt RUP dan toch vaak een log, bureaucratisch en bovendien watervalachtig proces? Een belangrijke oorzaak is dat de RUP-fasering een lineaire, watervalmanier van werken lijkt te suggereren. Daardoor blijft de essentie van RUP, namelijk iteratief werken, vaak de grote afwezige. Een andere oorzaak ligt in het toekennen van rollen aan specifieke personen, vaak één rol per persoon. Uit onderzoek blijkt dit vaak inefficiënt door bijvoorbeeld onnodige overdrachtsmomenten. Een aantal aspecten van RUP zijn inmiddels gemeengoed geworden. Vrijwel iedereen ziet het belang van architectuur ('use component architectures') en van visueel modelleren ('model visually'). Echter, te veel focus op modellen en plaatjes leidt af van het hoofddoel: het produceren van werkende software. Ten slotte worden (te) veel RUP-artefacten zonder meer bestempeld als verplicht op te leveren.
Hoe kunnen we de effecten van bovenstaande punten opheffen? Vaak wordt gedacht dat veel of alle procesonderdelen gevolgd moeten worden, maar ze moeten slechts worden gezien als richtlijn. Het is zeker niet de bedoeling om domweg het standaardproces te volgen, zonder te kijken naar het resultaat ervan. Dus pas toe wat effectief is en laat de rest weg.
Een beproefde manier om tot een effectief proces te komen, is nu juist door de agile-principes toe te passen. Met andere woorden, leg de nadruk op de agile-aspecten van RUP, in het bijzonder op iteratief werken, samenwerking en focus op werkende software. Bijvoorbeeld 'manage requirements' betekent niet zozeer veel tijd spenderen aan uitgebreide documenten maken met veel speciale tooling, maar veel meer serieus samen met de opdrachtgever(s) blijven nadenken over wat nu werkelijk gewenst is. RUP kan (en moet) dus agile ingezet worden!
Zeker, RUP en agile zijn niet elkaars vijanden wanneer je goed naar de methodes kijkt. Het vooroordeel wordt veroorzaakt door de aanpak die IBM/Rational vaak zelf verkiest: veel procesmodellering en veel consultants die je komen “helpen”. Implementaties van RUP kosten op die manier niet zelden tienduizenden euro’s.
Een scherpe lezer vindt echter heel veel waarde in RUP, bijvoorbeeld de focus op architectuur in de Elaboration fase. Er zijn al praktische implementaties van RUP, bijvoorbeeld Rup op Maat (www.rupopmaat.nl).
Ik sluit me aan bij Anko’s reactie. Een andere oorzaak zit in de IBM tooling om het proces te documenteren. Separation of Concerns staat hoog in het vaandel, wat betekent dat procesplaatjes en methodische content zoveel mogelijk gescheiden zijn. Voor process engineers is dit handig, voor iemand die het proces probeert te doorgronden niet.
Gevolg is dat je vanuit een procesplaatje minimaal 3 keer moet klikken om te zien welke rollen en werkproducten bij een bepaalde processtap (Activity) betrokken zijn. Verder richten processtappen zich meestal maar op ��n discipline waardoor samenwerking tussen disciplines (de kern van Agile) niet inzichtelijk wordt. De drempel om het RUP proces te versimpelen en inzichtelijk te maken voor een ontwikkelteam is daardoor hoog. Het is dus lastig om aan het eerste uitgangspunt van RUP “Adapt the Process” tegemoet te komen.
RUP op Maat doet hier iets aan door in zijn processtappen te focussen op samenwerking. Taken rollen en werproducten worden samen in ��n plaatje inzichtelijk gemaakt. (zie http://www.rupopmaat.nl/naslagsite2008)