Scrum en CMMI – Requirements Management

In een vorige post heb ik in het algemeen gekeken naar de combinatie van Scrum en CMMI. In deze post kijk ik dieper naar de process area Requirements Management. Is Scrum hiervan een goede implementatie?

Het doel van requirements management is om requirements te beheersen en inconsistenties tussen requirements, plannen en werkproducten te identificeren. Er zijn vijf werkwijzen (specific practices) die geïmplementeerd moeten worden:

SP1.1 Ontwikkel een begrip voor de requirements van de klant

Binnen Scrum speelt de Product Owner de rol van de klant. Van de product owner wordt verwacht dat hij de requirements beschrijft (meestal in de vorm van user stories) en in de Planning Meeting precies aan het team uitlegt wat hij bedoelt. Dat lijkt een prima implementatie van deze werkwijze.

SP1.2 Zorg voor commitment voor de requirements door het project-team

Ook hiervoor is de Planning Meeting bedoeld. Het team spreekt net zolang over de requirements met de product owner totdat alles helder is, maakt dan schattingen van de hoeveelheid werk en commit zich aan een bepaalde hoeveelheid user stories voor de komende sprint.

SP1.3 Beheers veranderingen in de requirements

Scrum stelt dat tijdens uitvoering van een sprint de requirements absoluut niet mogen veranderen. Dat lijkt een starre manier van beheersen, maar doordat sprints kort zijn (2-4 weken) is dat in de praktijk prima uit te voeren. Buiten de huidige sprint heeft de klant (de product owner) alle vrijheid om requirements te veranderen, anders te prioritiseren, etc. Mooie implementatie van CMMI met een goede balans tussen control en flexibiliteit.

SP1.4 Onderhoud traceability tussen requirements en werkproducten

Hierover zegt Scrum eigenlijk niets. Deze werkwijze zal dus binnen het team (de organisatie) moeten worden vastgelegd.

SP1.5 Indentificeer inconsistenties tussen project planning, werkproducten en requirements

Dit is in Scrum prima geregeld. Aan het einde van elke sprint wordt een demo gegeven van het tot dan bereikte resultaat. Hiermee wordt de consistentie tussen de requirements (sprint backlog) en werkproducten (potentially shippable product) aangetoond. Daarnaast wordt de planning bewaakt met burndown charts. Die geven een helder beeld van hoeveel geplande requirements in deze sprint werkelijk worden opgeleverd. Op een wat hoger niveau geeft de release burndown chart de relatie tussen release planning en requirements aan.

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in software engineering and tagged , , . 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