CMMI 1.3 is uit! Een eerste reactie

Versie 1.3 van het CMMI is op 28 oktober 2010 gepubliceerd.
Wat vind ik er van?

Het eerste dat opvalt is dat het model behoorlijk wat kleiner is geworden. De PDF van 1.3 bevat 482 pagina’s tegen 573 in versie 1.2. Dat lijkt goed nieuws, hoewel het nog steeds een heel fors model blijft. De reductie in pagina’s is voornamelijk cosmetisch, maar daarover later meer. Verder is duidelijk dat dit een minor upgrade is. Het gaat van versie 1.2 naar 1.3. Niet naar versie 2.0. Dat betekent ook dat er geen compleet nieuwe training nodig is. Alleen een upgrade training om de verschillen duidelijk te maken.

Mike Philips schreef een release note bij het model. Hierin geeft hij aan dat de verschillen met name zitten in het high maturity gedeelte (levels 4 en 5) en in veranderingen in de opzet van beide representaties, staged en continuous. Over high maturity zal ik verder niets schrijven. Ik ben niet formeel geautoriseerd als high maturity lead appraiser, ik werk nooit met high maturity bedrijven, en ik word ook meer en meer huivering voor het productie-denken dat de basis vormt voor high maturity.

De verschillen in representaties zijn wel fors. Hoewel, gewone gebruikers van CMMI die zich met name met maturity level 2 en 3 bezig houden zullen er niets van merken. Maar in de totale architectuur van het model is het wel een behoorlijke ingreep om generic goals 4 en 5 te laten vervallen. Dat betekent praktisch dat je het continuous model alleen nog maar kan gebruiken voor levels 2 en 3. Wil je door naar high maturity dan zal je naar staged om moeten. Omdat ik high maturity verder toch buiten beschouwing laat, kan ik dit verder ook laten liggen.

Daarnaast is ook het begrip IPPD (Integrated Product and Process Development) grotendeels verdwenen als separaat concept. Het is veel meer in het gewone model opgenomen. Een goede ontwikkeling!

Ik concentreer me eerst op het CMMI voor Development. In latere Blogs wellicht meer over CMMI voor Services en CMMI voor Acquisition.

De structuur van het model, en van het document is gelukkig niet aangepast. Dezelfde hoofdstukindeling. Dat maakt overstap niet moeilijker dan nodig.

De paragraaf die de verschillen met versie 1.2 aangeeft, spreekt over meer ondersteuning voor het gebruik van Agile practices. Daar ben ik met name benieuwd naar! Het is daarnaast wel aardig om te zien dat er ook veel voorbeelden gegeven worden over hoe CMMI toepasbaar is in combinatie met Product Lines. Jarenlang waren CMMI en productlines twee volledig gescheiden werelden binnen het SEI. Het lijkt erop dat men eindelijk met elkaar overlegt en synergie zoekt.

Aan de inleidende hoofdstukken is niet veel veranderd. Tekenend is wel dat de paragraaf die aangeeft dat de inspiratie voor CMMI komt vanuit procesverbetering in productie niet is weggehaald. Juist mijn werken met en bestuderen van Agile heeft me geleerd dat dit niet de juiste basis is. Productie is fundamenteel anders dan ontwikkeling. In productie is standaardisatie en herhaalbaarheid terecht heel belangrijk. In ontwikkeling is juist variatie belangrijk. Het gaat om het inspelen op de steeds veranderende behoeftes van klanten, steeds veranderende inzichten in hoe een goede oplossing gebouwd kan worden. Teveel standaardisatie leidt vaak af van die aandacht voor de context. Met alle aandacht die versie 1.3 geeft aan Agile geeft deze paragraaf aan dat er nog steeds een fundamenteel verschil in filosofie bestaat.

Er is een aparte paragraaf toegevoegd over interpretatie met Agile: “Interpreting CMMI When Using Agile Approaches”. Interessant om op te merken is dat hier kort verwezen wordt naar het Agile manifesto, maar dat agile vervolgens als volgt wordt omschreven:

Such approaches are characterized by the following:

  • Direct involvement of the customer in product development
  • Use of multiple development iterations to learn about and evolve the product
  • Customer willingness to share in the responsibility for decisions and risk

Ik vraag me dan af waarom het manifesto zelf niet wordt aangehaald. Zou het eerste statement dat Individuals and Interactions meer waarde hebben dan Processes and Tools teveel pijn doen? Of het tweede dat working software belangrijker is dan comprehensive documentation?

Part 2 over generic goals en practices is grotendeels hetzelfde gebleven. Er zijn twee grote wijzigingen: de generic goals op levels 4 en 5 zijn verwijderd. En een tekstuele wijziging: alle info over de generic practices staat nu hier en er wordt niets meer herhaald bij de process areas. Dit is de grote truc geweest om de besparing in het aantal pagina’s te bereiken. Maar inhoudelijk heeft dat natuurlijk niet tot een minder groot model geleid.

Dan het eigenlijke model, part 3, de beschrijving van de process areas (PA’s). Ik bespreek slechts een paar PA’s. De meeste PA’s zijn niet of nauwelijks veranderd.

Bij configuration management is inhoudelijk weinig veranderd. Wel valt op dat in het lijstje voorbeelden van items die onder CM geplaatst kunnen worden er meer en betere voorbeelden zijn voor toepassing in een hardware omgeving (drawings, product data files) en voor gebruik in een Agile omgeving (user stories en iteration backlogs). In de ‘Agile interpretation box’ wordt aangegeven dat CM in een Agile omgeving nog belangrijker is dan in een traditionele omgeving, en terecht. Wel proef je verschillen in waarden. Waar Agile alle nadruk legt op team performance en specialistische rollen zoveel mogelijk reduceert, suggereert CMMI hier dat één teamlid verantwoordelijk gemaakt wordt voor CM.

De measurements and analysis process area is inhoudelijk niet echt veranderd. Alle specific goals en practices zijn gelijk. Er is wel een zeer verhelderende tabel toegevoegd die veel beter dan voorheen de intentie van information needs, measurement objective en meetdefinitie aangeeft. Waar velen in het verleden krampachtige moeite deden om metingen te koppelen aan bedrijfsdoelstellingen en vervolgens vastliepen in nietszeggende generalisaties, is nu kraakhelder dat het gaat om het doel van een meting. Bijvoorbeeld milestone performance wordt gemeten om het objective inzicht in voortgang te bereiken. Een koppeling naar aandeelhouderswaarde is niet nodig. Ik ben heel blij dat ik voor die discussie nu mijn argumenten direct uit het model kan halen!

Ook de Product Integration PA is inhoudelijk nauwelijks aangepast, maar bevat wel een goed stukje verheldering over Agile. Hoe past continuous integration binnen de CMMI aanpak?

Tot mijn verbazing is er bij Project Monitoring and Control geen Agile stukje opgenomen. Geen expliciete aandacht dus voor burndown charts en daily scrum meetings. Daarentegen staat er een goed stuk bij PP.

Binnen Requirements Management staat een zeer nuttige Agile hint. Traceability binnen Agile projecten wordt bereikt door in de Sprint Review te demonstreren dat de User Stories die aan het begin van de Sprint zijn afgesproken zijn gebouwd. Dat betekent dat daarnaast geen ingewikkelde en nauwelijks onderhoudbare traceability matrices hoeven te worden gemaakt. Pure winst!

Over de agile hint bij Risk Management heb ik gemengde gevoelens. Enerzijds herkent het CMMI dat binnen Agile projecten veel risico management impliciet in de methode is opgenomen. Principes als ‘fail fast’ en ‘spikes’ om onzekerheden zo snel mogelijk aan te gaan worden benoemd. Anderzijds wil het SEI dat we toch ‘hun’ methode toepassen, want dát is een systematische aanpak. Dat is toch wel sterk! Dus een agile aanpak die risico management systemisch opneemt in de project aanpak is niet systematisch en een aanpak om ‘naast het gewone werk’ met risicolijstjes te werken is wel systematisch? Daarnaast worden dan wel weer nuttige opmerkingen gemaakt over hoe risk management gekoppeld kan worden aan typisch agile practices als sprint planning en estimating.

Iets soortgelijks geldt voor de hint bij Verification. Toegegeven wordt dat binnen agile door veel sterkere interactie met de klant en door korte iteraties er veel meer validatie plaats vindt dan in traditionele projecten. Maar volledige waardering blijft toch uit. Het onderscheid dat CMMI maakt tussen VERification en VALidation leiden toch tot een meer systematische aanpak, althans, zo stelt de hint. Ik geloof hier persoonlijk niets van. Agile is op dit terrein gewoon veel sterker dan CMMI.

De Glossary bevat een paar nuttige verbeteringen.

Versie 1.2 bevatte een bizarre definitie van ‘proces’, als “activiteiten die herkend kunnen worden als implementaties van CMMI practices”. Een bizarre definitie vanuit een CMMI-centrisch wereldbeeld. Die definitie is er gelukkig uit.

Ook de definitie van ‘project’ is weer normaal: “een set activiteiten […] met een helder begin en eind”. Dat eind van een project was er in versie 1.2 afgehaald om ook diensten als project te kunnen definiëren. Maar je kunt in een model waarin projectmanagement zo’n centraal begrip is niet straffeloos het projectbegrip uithollen. Die fout is gelukkig ook hersteld.

Samenvattend is versie 1.3 een iets beter model dan versie 1.2. Dit geldt in ieder geval binnen de scope die ik aanhoud van maturity levels 2 en 3. De aanpassingen op high maturity zijn groter en fundamenteler. Maar omdat dat in Nederland niet of nauwelijks gebruikt wordt kunnen we dat gerust buiten beschouwing laten. Binnen diverse process areas worden nuttige hints gegeven over hoe CMMI en agile in combinatie kunnen worden toegepast. Maar er blijven nog wel een paar fundamentele inzichten staan.

Deze release van CMMI bevat alleen nog het model zelf. Daarnaast worden ook de appraisal methode SCAMPI en het trainingsmateriaal aangepast. Ik ben met name nog sterk geïnteresseerd in de aanpassingen aan SCAMPI. Appraisers bepalen in de praktijk vrij sterk hoe er met het model wordt omgegaan, zoals rechters bepalen hoe wetten worden geïnterpreteerd. Sommige SCAMPI regels maakten naar mijn mening het model meer rigide dan nodig. Ik hoop dat dit verbeterd is en zal verslag doen zodra de nieuwe SCAMPI beschikbaar is.

André Heijstek is gecertficeerd Lead Appraiser en Trainer voor CMMI en is ook Certified Scrum Master.

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in CMMI, software engineering. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s