RUP op Maat: een Agile toepassing

RUP op Maat: een Agile toepassing van Rational Unified Process

Boekrecensie: RUP op maat – Agile met RUP, Scrum en PRINCE2
Auteurs: Remi-Armand Collaris en Eef Dekker

Het projectmanagement vakgebied is volop in beweging, weg van het blind volgen van processen en initiële planningen, richting het flexibel omarmen van verandering. Echte teams worden steeds belangrijker, om in te kunnen spelen op de overvloed aan technische wensen, mogelijkheden en de steeds groter wordende complexiteit van de huidige projecten.
Het inrichten van multidisciplinaire projectteams is echter niet meer voldoende. Ook participatie van business en beheer is onmisbaar om de nieuwe generatie projecten succesvol van de grond te krijgen. 

RUP op Maat is een Agile toepassing van RUP en maakt gebruik van de best practices uit Scrum en heeft een heldere aansluiting op het management met PRINCE2. Het richt zich zowel op ontwikkelteamleden en de stakeholders (zoals gebruikers, beheerders en managers).
RUP op Maat geeft antwoord op de volgende vragen:

• Hoe betrek ik de klantorganisatie bij het ontwikkelproces?
• Hoe schrijf ik goede Use Cases? Hoe zorg ik dat teamleden optimaal inzetbaar zijn?
• Hoe breng ik kwaliteit in mijn ontwikkelproces? Hoe zie ik of we succesvol samenwerken?

Het biedt een aanpak voor het iteratief uitvoeren en managen van projectopdrachten, vanaf het offertetraject tot en met de oplevering van een bruikbare ICT-oplossing. RUP op Maat richt zich voornamelijk op softwareontwikkelprojecten, maar is net als Agile breder toepasbaar.

8 uitgangspunten van RUP

RUP is gebaseerd op 8 uitgangspunten die zijn afgeleid van de Agile principes.

Uitgangspunt	Beschrijving	Kenmerken
Pas je proces aan	Pak de RUP gereedschappen die je nodig hebt (op maat maken) en stel dit gedurende het project bij.	Het ontwikkelproces is aan te passen op de volgende aspecten: - onderkende rollen - uit te voeren activiteiten en hun volgorde - te vervaardigen werkproducten - inrichting van procesondersteuning
Geef belanghebbenden een stem	Software wordt gebouwd voor mensen die er belang bij hebben, dus deze software moet aansluiten op hun uiteenlopende en vaak tegenstrijdige wensen.	Het vroeg inventariseren en prioriteren van deze wensen maakt het mogelijk om tot een evenwichtig pakket van requirements te komen. Koppel gedurende het hele project terug naar de stakeholders, waaronder in ieder geval de toekomstige gebruikers en beheerders van de software.
Bestrijd risico's vroeg en continu	RUP legt een grote nadruk op het naar voren halen van de risico's. Hoe eerder een proejctrisico onder ogen wordt gezien, hoe minder kosten het met zich meebrengt.	Een groot deel van de risico's bij automatiseringsprojecten is technisch van aard. De risico's zijn het best te bestrijden in Proofs of Concepts en door het vroeg realiseren van riskante functionaliteit.
Lever iteratief iets van waarde voor de klant	Bij softwareontwikkeling draait het om het leveren van werkende software waar de klant op zit te wachten.	Onderstaande punten zijn van belang: - betrek de klant bij het ontwikkelproces - communiceer functionaliteit aan de hand van voor de klant herkenbare taken - maak specificaties behapbaar en begrijpelijk voor de klant - vraag elke iteratie terugkoppeling op werkende software
Speel in op wijzigingen	Wijzigingen vormen een zekerheid. De klant heeft zijn probleem wel helder, maar een passende oplossing wordt vaak pas gaandeweg helder. De kunst in een ontwikkelproject is om dit voortschrijdend inzicht zo goedkoop mogelijk te omarmen.	Stel de scope van het zo systeem zo vroeg mogelijk op hoofdlijnen vast. Betrek de klant bij het beoordelen van de omvang. Detailleer iteratief en zo laat mogelijk (vlak voor de bouw). Wijzigingen binnen de scope en vóór detaillering hoeven dan geen grote impact te hebben. Wijzigingen na detailleren, of wijzigingen die de omvang van de scope doen toenemen, dan is het aan de klant welk ander stuk van de functionaliteit vervalt, of hij accepteert de toename van de scope.
Stabiliseer de architectuur in werkende code	Softwarearchitectuur heeft als doel de complexiteit van de software te reduceren en daarmee de robuustheid en onderhoudbaarheid te verhogen. Vervolgens moet in werkende code worden aangetoond dat de gekozen software-architectuur werkt binnen de aanwezige kaders.	De softwareontwikkeling is de technische ruggengraat van de software. Pas wanneer we weten dat het goed zit met die ruggengraat, bouwen we de rest.
Werk samen als één team	Voor het succesvol ontwikkelen van software zijn effectief samenwerken en een goede communicatie onontbeerlijk. Gebruikersbehoeften, softwareontwikkeling en beheersaspecten moeten op elkaar worden afgestemd.	Om dit te bereiken zorg je ervoor dat alle benodigde expertises gedurende het hele project betrokken blijven. Plaats teamleden zoveel mogelijk in één ruimte en zorg voor korte communicatielijnen. Vraag commitment van het team voor kortetermijn-planningen en laat de teamleden zichzelf evalueren. Zorg ervoor dat gebruikers en andere stakeholders voldoende beschikbaar zijn.
Kwaliteit is een manier van leven, geen toevoeging achteraf	Iedereen levert een optimale bijdrage aan het product en het proces. Kwaliteit wordt tastbaar gemaakt door al heel vroeg in het traject en gaan testen en hier de klant bij te betrekken.	Dit is als volgt te bereiken: - formuleren van heldere doelen (planning en richtlijnen) - ter beschikking stellen van voldoende tijd en middelen - inregelen van terugkoppeling - oppakken van activiteiten wanneer ze actueel zijn

Wie doet wat, wanneer?

Een RUP-ontwikkeltraject kent net als ieder andere methode allerlei elementen, zoals taken, werkproducten, rollen, fasen, workflows en disciplines. De samenhang tussen deze elementen wort bepaald door het antwoord op de vraag:

Wie Doet Wat, Wanneer?

• Wie; dit zijn niet zozeer personen, maar rollen. Bij een rol past een bepaalde rolomschrijving en bepaalde kennis en vaardigheden die de vervullers van de betreffende rol moeten bezitten.
• Doet; hier denken we aan taken. Een taak heeft een duidelijk omschreven doel en is bruikbaar als eenheid voor planning. Taken zijn op te splitsen in stappen. RUP groepeert taken waarvoor vergelijkbare kennis en vaardigheden nodig zijn tot disciplines.
• Wat; hier denken we aan de werkproducten die de uitkomst zijn van een taak of de input vormen voor een taal. Dit kan een document of model zijn, maar ook een softwarecomponent.
• Wanneer; dit zijn de vier fasen die RUP hanteert en aan de iteraties (timeboxes) waaruit een fase is opgebouwd. De volgordelijkheid van taken binnen deze taken en iteraties wordt gevisualiseerd in workflows. Deze tonen de samenhang tussen de verschillende rollen, taken en werkproducten.

RUP levenscyclus

RUP is een softwareontwikkelmethodiek met als belangrijkste kenmerken: iteratief, architectuurgecentreerd, gefocust op risico’s en gestuurd op Use Cases. Het heeft een duidelijk afgebakende levenscyclus met vier fasen:

• Inception: overeenstemmen bereiken over het doel van het project.
• Elaboration: functionaliteit ontwikkelen om te bewijzen dat de architectuur voldoet.
• Construction: de oplossing op effectieve wijze verrijken met de complete functionaliteit voor een release naar productie.
• Transition: afronding van de overdracht, zodat de business klaar is om de oplossing in gebruik te nemen.

 

Een RUP project kan meerdere releases naar productie bevatten en zal dan ook meerdere malen de RUP levenscyclus doorlopen.

Iteratief ontwikkelen en timeboxing

Een iteratie is een afgebakende, korte periode waarin een samenhangende hoeveelheid functionaliteit wordt ontworpen, gerealiseerd of geaccepteerd.

 

Na de afbakening van de projectopdracht in een gezamenlijke visie en het bepalen van een globale planning (kosten, resources, doorlooptijd en mijlpalen) begint het iteratieve proces. In opeenvolgende iteraties van ontwerp (Use Case ontwerp, testontwerp en technisch ontwerp), realisatie (bouw en test) en acceptatie door de opdrachtgever wordt toegewerkt naar een steeds completer eindproduct. Elke iteratie wordt afgesloten door een iteratie-evaluatie en een detailplanning voor de volgende iteratie. Ervaringen uit elke stap in dit proces dienen als input voor de volgende stappen. Dit zorgt ervoor dat de impact van wijzigingen in de requirements en fouten in de interpretatie ervan zo klein mogelijk blijft.

Elke iteratie is een timebox, d.w.z. dat de tijdsduur vastligt. Het vastleggen van de tijdsduur heeft een aantal voordelen:

• Het team komt in een vast ritme van uit te voeren activiteiten.
• Teamleden willen graag dat hun stuk werk voor de oplevering af is en zijn gemotiveerd om dit te halen.
• Teamleden leren hoofd- en bijzaken onderscheiden (goed is goed genoeg) en taken te prioriteren.

 

RUP disciplines

RUP-disciplines zijn groeperingen van taken binnen het ontwikkelteam waarvoor vergelijkbare kennis en vaardigheden nodig zijn.

 

• Requirements
  Informatie vergaren uit bestaande bronnen – via interviews met de projecteigenaar, domeindeskundigen en andere stakeholders.
  Deze informatie wordt samengebracht in de Vision. De requirements worden verder uitgewerkt in Use Case Model en de individuele Use Case specificaties. In de Glossary en het Business Proces Model wordt een gemeenschappelijk discussiedomein gecreëerd en aangescherpt. De opdrachtgeverorganisatie maakt de requirements meetbaar door middel van acceptatiecriteria in het Acceptatieplan.
  • Doelen:
    • Het ontwikkelen van een gezamenlijke visie op het doel van het project.
    • Vastleggen van wensen en eisen en daarmee de scope van de applicatie.
    • Planning op hoofdlijnen.
    • Kostenschatting en benodigde ontwikkeltijd op hoofdlijnen.
    • Ontwikkelen van een gebruikersvriendelijke interface.
    • Overbrengen
• Architectuur en Bouw
  De architectuur wordt beschreven in het Software Architectuur Document (SAD). Het technisch ontwerp wordt, voor zover het afwijkt van het SAD of nadere specificatie behoeft, vastgelegd in op de Use Cases gebaseerde Use Case Realizations. Verder zijn binnen deze discipline visualisatie van de Use Cases en realisatie van werkende code en testsuites aan de orde.
  • Doelen:
    • Het technisch ontwerpen van de applicatie op basis van de requirements.
    • Het ontwikkelen van een robuuste architectuur.
    • Het technisch ontwerp en de softwarearchitectuur laten aansluiten op het beoogde implementatieplatform.
    • Bouwen van de gewenste functionaliteit (in deelcomponenten).
    • (Geautomatiseerd) testen van de gerealiseerde functionaliteit.
    • Samenstellen van de gerealiseerde componenten tot een uitvoerbaar systeem.
• Test
  De te volgen teststrategie wordt vastgelegd in het Testplan en geconcretiseerd in de Testontwerpen. Gebreken die tijdens het testen worden gevonden worden gedocumenteerd in de Bevindingen en samengevat in een Testrapport.
  • Doelen:
    • Evalueren en bewaken van de kwaliteit van de producten.
    • Valideren van gedane aannames in het ontwikkelproces naar demonstratie.
    • Valideren dat het softwareproduct werkt zoals het is ontworpen.
    • Valideren dat het softwareproduct voldoet aan alle requirements (zowel functioneel als niet-functioneel).
    • Vinden en documenteren van gebreken in de software en in de kwaliteit van de software.
• Ondersteuning
  • Doelen:
    • Het ontwerpen en opzetten van de ontwikkelomgeving voor het ontwikkelteam.
    • Het definiëren en managen van de configuratie van benodigde items en hun eventuele versies.
    • Het samenstellen van Opleveringen.
• Projectmanagement
  Het doel is een evenwicht te vinden tussen het behalen van de doelstellingen, het managen van de risico’s en het overwinnen van hindernissen. Je wilt komen tot een softwareproduct dat aansluit bij de opdrachtgeverorganisatie nodig heeft. De globale planning wordt vastgelegd in het Projectplan dat onderdeel uitmaakt van het Software Development Plan. De detailplanning per iteratie wordt kort voor het begin van de betreffende iteratie vastgelegd in een iteratieplan.
  Verder worden onderkende risico’s vastgelegd, bestreden en gemonitord met behulp van een Risicolijst.
  • Activiteiten:
    • Continu monitoren en bestrijden van risico’s.
    • Plannen van het project (globaal, verdeeld over de diverse RUP-fasen en per iteratie).
    • Monitoren van de voortgang en sturen van de projectinspanningen richten het gewenste einddoel.
    • Management van scopewijzigingen.

Vervolgens gaat het boek dieper in op de Use Cases, het ontwikkelproces, projectmanagement, de oriëntatie op de projectopdracht, het managen van iteraties, de rollen binnen een RUP-team en de werkproducten. De vragen uit de inleiding:

• Hoe betrek ik de klantorganisatie bij het ontwikkelproces?
• Hoe schrijf ik goede Use Cases? Hoe zorg ik dat teamleden optimaal inzetbaar zijn?
• Hoe breng ik kwaliteit in mijn ontwikkelproces?
• Hoe zie ik of we succesvol samenwerken?

worden beantwoord.

Verder zijn er praktisch toepasbare templates en een projectinschatting met het gebruik van Use Case punten opgenomen in het boek. Er is een praktische naslagsite beschikbaar. RUP op Maat maakt softwareontwikkelingstrajecten begrijpelijk voor niet-ontwikkelaars en koppelt het ontwikkeltraject aan projectmanagement.