Marco van Dop en Dennis Geluk

Welke methode gebruikt u voor softwareontwikkeling? Waterval, RUP, RAD, SCRUM, Lean, Agile, Safe of nog een andere variant? En weet u inmiddels welke methode voor softwareontwikkeling het beste bij uw organisatie past? Nee? Dan moet u misschien terug naar de kern!

Uit onderzoek blijkt dat alle softwareontwikkelmethoden dezelfde kern hebben. Wanneer u deze kern kent en begrijpt, heeft u de handvaten om de basis te leggen voor succesvolle softwareontwikkeling, volgens de werkwijze die voor uw organisatie én voor het te ontwikkelen product, het beste past.

Waarom zou u voor één ontwikkelmethode kiezen als u het beste van alle methodes kunt combineren?

Essence: een conceptuele benadering van softwareontwikkeling

Onderzoek toont dus aan dat alle methoden voor softwareontwikkeling een gezamenlijke kern delen. Deze kern, in het Engels “kernel” genoemd, staat beschreven in de Essence methode van de OMG (Object Management Group). De OMG verzorgt en beheert tal van standaarden die gemeengoed zijn in de IT. Denk bijvoorbeeld aan UML, BPMN en dus ook Essence.

Essence is een van de eerste en meest aansprekende resultaten van de SEMAT (Software Engineering Methods And Theory) community. SEMAT is een internationale non-profit community van mensen, bedrijven en universiteiten die zich tot doel heeft gesteld om een gemeenschappelijke basis, een kern of een fundament, voor software-engineering te creëren.

Het initiatief dat heeft geleid tot Essence was erop gericht om op een meer conceptueel niveau te komen tot een toekomstvast beeld van aspecten van kwalitatieve softwareontwikkeling, zonder iedere paar jaar een nieuwe (modegevoelige) methode als de facto standaard te moeten adopteren.

De kern: 3 basiselementen van softwareontwikkeling

Volgens Essence bestaat de kern van elke softwareontwikkelmethode uit 3 (verzamelingen van) basiselementen:

• Things to work with (Alpha’s),
• Things to do (Activity spaces),
• Skills needed (competences)

Iedere softwareontwikkelmethode die we vandaag kennen is dus uit te drukken met behulp van deze drie basiselementen: om tot een product (a) te komen moet je stappen (b) nemen en om stappen (b) goed te kunnen volbrengen heb je competenties (c) nodig.

Zo op het eerste gezicht lijkt dit geen hogere wiskunde maar blijkbaar heeft het ons als bedrijfstak toch diverse jaren gekost om tot dit simpele inzicht te komen.

Wat willen we onze studenten leren?

Waar we tot op heden in IT-opleidingen de methode van het moment onderwijzen (voorheen bijvoorbeeld DSDM of RUP, momenteel Scrum) zou het waarschijnlijk verstandiger zijn om studenten meer kennis te laten maken met de achterliggende concepten in plaats van één of twee specifieke methoden.

Het goed snappen van deze basisconcepten zou vervolgens voldoende moeten zijn om iedere nieuwe methode op waarde te kunnen schatten. Zo kunnen de ontwikkelaars van morgen sneller inspelen op nieuwe ontwikkelmethoden en in projecten later zelf beslissen welke (onderdelen van welke) ontwikkelmethode het best geschikt zijn om in een bepaalde context toe te passen.

Elk van de bovenstaande basiselementen zijn verdeeld in drie gemeenschappelijke aandachtsgebieden die elk IT-project heeft; de ‘areas of concern’:

1. De klant (Customer),
2. De (software)oplossing (Solution),
3. Het project (Endeavour)

Het is relatief eenvoudig om te zien dat iedere beschikbare softwareonwikkelmethode in meer of mindere mate invulling geeft aan één of meerdere onderdelen van Essence. Daarnaast mag het ook duidelijk zijn dat iedere methode zo zijn eigen sterke en zwakke punten heeft in de invulling ervan.

Alpha’s: things to work with

Essence beschrijft dus de Alpha’s, werkzaamheden en competenties die bestaan binnen elk aandachtgebied. In dit artikel gaan we dieper in op de “Things to work with”, de Alpha’s.

Alpha is een ezelsbruggentje voor “Aspiration Led Progress & Health Attribute”. Een Alpha is een essentieel onderdeel van de software-engineering, waaraan de ‘voortgang’ en ‘health’ van het ontwikkelproces beoordeeld kan worden.

Essence beschrijft 7 Alpha’s in de 3 aandachtsgebieden die binnen elk softwareontwikkeltraject bestaan. Deze zeven Alpha’s zijn hieronder in context weergegeven:

• Er is altijd een Klantbehoefte (Customer) die we kunnen identificeren als probleem of kans (Opportunity). Er zijn belanghebbenden (Stakeholders) die een eventuele oplossing financieren, gebruiken of er voordeel mee behalen.
• Er is een oplossing (Solution) die moet voldoen aan de wensen en eisen (Requirements) en die geïmplementeerd zal worden met behulp van een softwaresysteem (Software system)
• Er is een project (Endeavour) dat we gaan uitvoeren. Hierbij gaan we werk verzetten (Work) met een groep gekwalificeerde medewerkers (Team) volgens een goede, efficiënte manier van werken (Way of working).

Het “Health Attribute” onderdeel is hierbij interessant. Hoe kun je relatief abstracte begrippen als ‘Stakeholder’ of ‘Team’ meetbaar maken? Dit is binnen Essence opgelost door iedere Alpha te voorzien van een aantal gedefinieerde statussen. Deze statussen zijn scherp gemaakt door het simpele “checklist” principe toe te passen.

Zo kent de ‘Team’ Alpha bijvoorbeeld de volgende statussen: Seeded, Formed, Collaborating, Performing en Adjourned.

Hierbij is iedere individuele status in meer details uitgewerkt in criteria waaraan het team moet voldoen om te kunnen zeggen dat het conform een bepaalde status opereert.

Het voordeel van een dergelijke scherpe afbakening is dat we in de communicatie eenduidig kunnen zijn zonder iedere keer uit te moeten leggen wat we precies bedoelen. Het idee om zo snel mogelijk een “Collaborating” team te krijgen is een stuk beter te begrijpen dan wanneer we verwijzen naar vage begrippen als “een ingespeeld team” of “een performing team”.

Combineer (best) practices van verschillende ontwikkelmethodes

Zoals eerder aangegeven zal niet iedere methode een basisconcept evengoed invullen als de andere methode. Een methode als Scrum is bijvoorbeeld erg sterk op de onderdelen Team en Work maar geeft minder invulling aan Requirements en Opportunity.

Zou het niet mooi zijn als we als organisaties een methode kunnen samenstelling met de sterke onderdelen uit de diverse methoden? Iedere ontwikkelmethode heeft immers “best practices” opgenomen die hun meerwaarde in de praktijk al hebben bewezen.

Best practices in IT-context zijn herbruikbare principes/methoden die we eerder hebben toegepast en herhaaldelijk toegepast kunnen worden.

Nu we met Essence een basis hebben om ontwikkelmethoden te kunnen beschrijven kunnen we deze methode natuurlijk ook gebruiken om een best practice uit deze methoden en onze eigen praktijk te beschrijven. De meerwaarde van een dergelijke generieke beschrijving is dat de overdraagbaarheid van de practice omhoog gaat en dat we practices makkelijker kunnen combineren tot onze eigen manier van werken.

Een goed voorbeeld van een practice is bijvoorbeeld Use Case 2.0 Essentials van Ivar Jacobson. Deze practice kan gebruikt worden om de Requirements onderdelen concreet invulling te geven.

Met het beschikbaar komen van meerdere practices wordt het makkelijker om ontwikkelmethoden uit te drukken als een verzameling van practices. Om dit gemakkelijk en goed inzichtelijk te maken heeft Ivar Jacobson Interational de Practice Library ontwikkeld. Zo is het relatief eenvoudig om bijvoorbeeld “Agile at scale” uit te drukken als een verzameling van de volgende practices:

Naast een door Ivar Jacobson International samengestelde methode als “Agile at scale” kunnen ook al om bekende methodes als EssUp, DSDM of zelfs Scrum beschreven worden middels Essence.

In december hebben Scrum Inc en Ivar Jacobson International bijvoorbeeld aangekondigd dat  Scrum zal worden beschreven met behulp van Essence.

Conclusie: Terug naar de kern van softwareontwikkeling

In dit artikel hebben we stilgestaan bij Essence, een conceptualisering van softwareontwikkeling die het mogelijk maakt om op een abstract niveau naar een ontwikkelproces te kijken. Essence kan ook gebruikt worden voor het eenduidige beschrijven van best practices van softwareontwikkeling.

We hebben gezien dat elke ontwikkelmethode in essentie uit dezelfde 3 onderdelen bestaat. Als we die onderdelen kennen en begrijpen dan kunnen we voortaan de best practice(s) van verschillende ontwikkelmethodes combineren om in elke context weer de best mogelijke ontwikkelmethode ‘samen te stellen’ en te gebruiken.

Het is onze overtuiging dat we studenten in de toekomst waarschijnlijk beter kennis laten maken met de 3 basisconcepten van Essence in plaats van één of twee specifieke ontwikkelmethoden. Zo kunnen de ontwikkelaars van morgen later zelf beslissen welke (onderdelen van welke) ontwikkelmethode het best geschikt zijn om in een bepaalde context een bepaald stukje software op te leveren.

Wij zijn benieuwd hoe u hierover denkt!

Meer informatie

Wilt u meer weten of Essence of de diverse practices? Kijk dan zeker eens naar de Practice Library op de website van Ivar Jacobson. Uiteraard kunt u ook contact met ons opnemen. Wij vertellen u graag wat Essence en de diverse practices binnen uw organisatie kunnen toevoegen.

Neem contact met ons op