Dit artikel is geschreven door Ton van Velzen, consultant bij IBM Nederland, en bespreekt de belangrijkste kenmerken van de Eclipse Way, de opzet van het OpenUP, en somt tot slot een aantal best practices op met betrekking tot gereedschappen voor agile-teams.
RUP en verder
Het Rational Unified Process (RUP) staat niet stil. Sinds IBM een deel van deze methode (en een deel van het bijbehorende content management gereedschap) heeft gedoneerd aan de Eclipse-organisatie komen er nog steeds vernieuwingen van de aloude RUP beschikbaar. Die donatie kwam volgens sommigen voort uit de wens het succes te kopiëren dat de UML toeviel nadat het van een proprietary een open standaard werd.
Hoe dan ook, RUP wordt soms – terecht, of niet – gezien als een methode met een hoog ceremonieel gehalte. Agile-methodes als XP, Crystal en Scrum leggen daarentegen de nadruk op individuen en interacties, op werkende software en op veranderlijkheid, en leggen wat minder nadruk op een cultuur van planning en processen. Het proces dat door open source-projecten in de Eclipse-organisatie wordt gevolgd, heeft een aantal kenmerken van een agile-methode. Dit proces wordt wel de ‘Eclipse Way’ genoemd en heeft overeenkomsten met de door IBM aan Eclipse gedoneerde variant van RUP, die OpenUP (open unified process) wordt genoemd.
Eclipse Way
Erich Gamma, bekend van Design Patterns, JUnit, en veel meer, heeft de Eclipse Way omschreven als een verzameling gebruiken (‘practices’) die voor zijn team en andere goed werkten. Zijn weergave daarvan laat zien dat het bij de Eclipse Way gaat om een combinatie van uitgangspunten die ontleend zijn aan agile-benaderingen om open source-gebruiken en om manieren om een teamomgeving op te schalen. Essentieel voor de Eclipse Way zijn de agile practices ‘iterative, reflect, adapt, incremental, feedback’.
Ook de RUP kent de iteratieve, incrementele, op feedback gerichte en adaptieve benadering. Maar waar RUP heel duidelijk rollen en disciplines met hun eigen workflow onderscheidt, waardoor een beeld van continue doorlopende aparte processen kan ontstaan, daar ligt in de agile-praktijk juist de nadruk op ‘just-enough’-process en ‘just in time’-planning. Eerst een volledige set use cases opstellen? Vergeet het maar in agile-projecten. Desgevraagd zei Erich Gamma laatst dat requirements in zijn team ‘incrementeel’ worden ontwikkeld. Een gedetailleerde architectuur modelleren? Ja, maar per diagram niet meer dan wat op een standaard white board past. Daarentegen zegt de Eclipse Way: schrijf een ‘news and noteworthy’-rubriek voor elke milestone (van werkende software) die je oplevert, zodat je de kans op ‘stale defects’ (problemen die intussen al weer opgelost zijn) vermindert en de kans op feedback op nieuwe features vergroot. En ook: een milestone-datum is heilig, maar een feature set níet. Gebruikers vergeten een feature meer of minder immers sneller dan een te late oplevering. Een ander goed gebruik is dat van de ‘end game’: de laatste iteratie voor een oplevering wordt besteed aan test-fix passess, waarbij de regels van het spel, die al geleidelijk toenamen, scherper zijn dan daarvoor. Daarbij wordt gestreefd naar zogenaamde ‘release convergence’: alles staat in het teken van het stabiliseren van de code ten behoeve van de release-oplevering.
In Eclipse-projecten wordt gewerkt met een getrapt organisatiemodel. Aan de top van de hiërarchie staat het PMC, de project management committee, die het release-plan opstelt, de thema’s waaraan gewerkt wordt vaststelt en die bevordert dat bijvoorbeeld aan architectuurdiscussies wordt deelgenomen door alle teams. Daaronder staan de component leads die voor een team van committers de iteratie en testplannen maken van een bepaalde component van de architectuur. De committers spelen typisch meerdere rollen (ontwikkelaar, tester, architect, support, release engineer). Elk component team is op zich vaak klein maar empowered, en essentiëel is dat keuzes van zowel het PMC als van component teams transparant zijn. Elk team organiseert zichzelf, is multidisciplinair, en is verantwoordelijk voor zijn eigen proces en voor zijn eigen evaluaties en aanpassingen. Kerngebruiken zijn gemeenschappelijk voor alle teams. Gebruiken die te maken hebben met samenwerking zijn bijvoorbeeld de dagelijkse stand-up meetings of de wekelijkse coördinatie calls (telefonische vergaderingen) van alle component leads. Daarnaast is het ook vast gebruik dat elk teamlid (na tests) aftekent voor een milestone deliverable. Na elke iteratie en na elke release wordt een retrospectief gehouden en wordt gekeken wat het team geleerd heeft en wat er verbeterd kan worden. Het zal intussen geen verbazing wekken dat de teams bijna standaard gebruik maken van online chats en real-time data voor onderlinge communicatie. De Eclipse Way samengevat: ‘It is about being continuous
Continuous iterative and adaptive planning
Continuous design/refactoring
Continuous integration/testing
Continuous delivering/demos
Continuous feedback
Continuous learning
Continuous health.’
OpenUP
Het Open Unified Process (OpenUP) gaat uit van vier principes. ‘Balance’: breng een balans aan tussen strijdende prioriteiten zodat de waarde voor belanghebbenden maximaal is. ‘Collaborate’: werk samen om belangen op elkaar af te stemmen en gemeenschappelijk begrip te kweken. Hieronder valt ondermeer het handhaven van gezonde werkomstandigheden (zie ‘continuous helath’ hierboven). ‘Focus’: concentratie in het begin op de architectuur om risico’s te bestrijden en de softwareontwikkeling te organiseren. ‘Evolve’: evolueer door regelmatige feedback van belanghebbenden en verbetering van het begin af aan en demonstreer regelmatig de toegevoegde waarde. Voor wie bekend is met de key principles (best practices) van RUP, maar ook voor ‘agilists’ zijn dit herkenbare uitgangspunten.
OpenUP is minimaal, compleet en uitbreidbaar. Het team dat de schrijvers van OpenUP voor ogen stond, past de procesceremonie toe die minimaal noodzakelijk is en die daadwerkelijk waarde toevoegt. Dat team vermijdt de belasting van improductieve formele werkproducten. Het gebruikt een proces dat op maat gemaakt kan worden als de noodzaak daartoe zich aandient. De OpenUP is een ‘agile’, een lichtgewicht proces dat bekende, goede gebruiken van softwareontwikkeling omvat. Iteratieve ontwikkeling, teamsamenwerking, continue integratie en tests, regelmatige oplevering van software, aanpassen aan veranderlijkheden, etc. zijn niet uniek voor OpenUP, maar wel kenmerkend. Net als RUP geeft OpenUP een beschrijving van rollen, werkproducten en taken die essentieel zijn voor softwareontwikkelteams. Meer nog dan in RUP geldt voor OpenUP dat teamleden meerdere rollen spelen. Ook OpenUP kent de vier fasen (of ‘seizoenen’, zoals Scott Ambler ze noemt) van RUP, maar onderkent binnen een iteratie het fenomeen van het micro-increment: een kleine, meetbare stap naar het doel van de iteratie dat het resultaat is van enkele uren of dagen werk voor een paar mensen die samen toewerken naar een doel. Micro-increments hebben elk precies één werkitem.
De disciplines (dat wil zeggen de rollen) van OpenUP worden beschreven door een zogenaamde ‘reference workflow, tasks, en guidance’. De disciplines zijn requirements, architectuur, development, test, configuration and change management en projectmanagement. De belangrijkste OpenUP Work Products zijn Architecture Notebook, Implementation (source code), Build, Iteratieplan, Projectplan, Vision, Use Case Model, Supporting Requirements, Test Cases, Test Logs, Test Scripts. OpenUP versie 1.0 is beschikbaar via http://www.eclipse.org/epf.
Tot slot
Welke eisen stellen de twee besproken agile-methods aan de gereedschappen die gebruikt worden? Uiteraard zijn daar de min of meer gewone tools als IDE’s (integrated development environments), versiebeheersystemen en testtools. Echter, om de korte cycli en intensieve samenwerking te ondersteunen die in agile-projecten wenselijk is, zijn tools nodig om realtime samenwerking en rapportage ‘in context’ te bieden. Het liefst is zo’n omgeving gebaseerd op open standaards- en/of open source-oplossingen. Het moet een infrastructuur zijn waar naar believen componenten vervangen kunnen worden door andere (bijvoorbeeld een commerciële database versus een open source-database, CVS door ClearCase of SubVersion, de ingebouwde build engine door een andere). En die omgeving moet zowel met bestaande systemen (zoals versie beheersystemen) kunnen samenwerken als die vervangen en uiteraard daaruit moeten kunnen importeren. Daarnaast dient een agile-softwareontwikkelomgeving met nadruk een teamomgeving te zijn en dus een stap verder te gaan dan IDE’s die zich immers op een enkele rol richten en bijvoorbeeld integratieaspecten als planning en builds hooguit indirect ondersteunen. In die zin is de gewenste agile-softwareontwikkelomgeving een verdere evolutie van de IDE.
Wie het laatste jaar op een developersconferenties als JavaPolis is geweest, heeft daar wellicht een voorproefje gezien van Jazz, IBM’s infrastructuur voor een nieuwe application lifecycle offering, Rational Team Concert, dat naar verwachting midden 2008 zijn eerste release beleeft. Dit product wordt niet alleen ontwikkeld door het team dat Eclipse ontwikkeld heeft, gebruikmakend van Eclipse en de Eclipse Way, maar het is ook bedoeld voor teams die agile-methodes gebruiken en naar believen open source en ‘enterprise class’-tools inzetten. Zie http://jazz.net voor de open commercial development site van Jazz.
Ton van Velzen, consultant bij IBM Nederland
Agile Manifesto
De vier principes die door een zeventiental behartigers van lichtgewicht softwareontwikkelprocessen tijdens een winterweek in 2001 zijn opgesteld, zijn als volgt:
"Wij vinden betere manieren om software te ontwikkelen door het te doen en anderen helpen het te doen. Door dit werk zijn wij waarde gaan hechten aan individuen en interacties boven processen en tools, werkende software boven alomvattende documentatie, samenwerking met de klant boven contractonderhandeling en reageren op verandering boven het volgen van een plan. Dat wil zeggen, hoewel er waarde zit in de dingen aan de rechterkant, geven wij de voorkeur aan de dingen aan de linkerkant."
De opstellers van het Agile Manifesto, waarvan bovenstaand citaat de beginregels zijn, kwamen daarnaast nog een twaalftal principes overeen en noemden zich de Agile Alliance.
