(R)evolutie van de ontwikkelingsorganisatie

In de afgelopen jaren heb ik meerdere organisatorische wijzigingen binnen de softwareontwikkelingsbranche gezien en meegemaakt. De verschillende methodes/frameworks die in de organisatie werden toegepast zijn o.a. Waterfall, Scrum, DevOps, Feature teams & Agile scaling. In deze blog zal ik een korte introductie geven op de vijf methodes/frameworks, die ik ben tegengekomen en die veel in de verschillende organisaties worden gebruikt. Toen ik naar deze methodes/frameworks keek, zag ik dat er veel overlapping was en meestal wordt de ene methode/framework op de andere methode/framework gebouwd of is het een verlengstuk van die methode of dat framework.

Waterfall

Deze methode werd bij de traditionele softwareontwikkeling gebruikt. Eerst doe je een volledige analyse, waarbij je een team van analisten een compleet functioneel en tweede technisch ontwerp van het systeem laat maken. Wanneer het volledige ontwerp is afgerond, begin je met het bouwen van het systeem met behulp van een team van ontwikkelaars. Zodra de bouw van het systeem is afgerond, wordt het gehele systeem door een team van testers getest.

Scrum

Binnen het scrum-framework is er een hybride team bestaande uit ontwerpers, bouwers en testers die aan kleine onderdelen van de functionaliteit werken. Deze kleine onderdelen van de functionaliteit noemen we user stories. De volgorde waarin het team aan de user stories werkt, wordt door de producteigenaar bepaald. De producteigenaar is de verbindende schakel tussen de zakelijke belanghebbenden; de lijst met bestelde user stories wordt de backlog genoemd.

Het werk wordt in korte cyclussen uitgevoerd die sprints worden genoemd. Een sprint duurt gewoonlijk 2-4 weken. Een sprint begint met een planningsessie om te bepalen wat in de huidige sprint moet worden opgepakt. Het Scrum-team kijkt naar de backlog en bepaalt hoeveel user stories in de sprint passen. Voor de gekozen user stories worden tasks op het Scrum-board gemaakt. De tasks moeten ervoor zorgen dat de user stories aan het einde van de sprint voor productie gereed zijn. Het Scrum-board wordt gedurende de dag bijgehouden en tijdens de daily stand-up besproken. Elke dag wordt een daily stand-up gehouden om te bekijken waar de teamleden aan werken en of zij nog steeds op schema lopen om de user stories binnen de tijd van de sprint af te ronden.

Aan het einde van de sprint, toont het team de voortgang van de af te leveren producten van de sprint aan de belanghebbenden en krijgen zij informatie (o.a. demo van geleverde software). Ook kijkt het team terug op wat kan worden verbeterd voor de volgende sprints.

DevOps

Waar Scrum voor het Scrum-team eindigt bij het testen van de software en het evalueren van de af te leveren producten, gaat DevOps. Het DevOps-team is verantwoordelijk voor de volledige levenscyclus van een systeem. Dit omvat o.a. de ontwikkeling van nieuwe software, maar ook de productie daarvan en het ervoor zorgen dat de software operationeel blijft tijdens de productie. Het DevOps-team is een combinatie van Development en Operations. Een DevOps-team kan ook Scrum als framework gebruiken. Voor DevOps omvat het Scrum-board tevens additionele tasks voor de release en het onderhoud van het systeem.

Met DevOps zul je zien dat het team niet alleen aan het toepassen van systeemwijzigingen werkt, maar ook aan het automatiseren van het levenscyclusbeheer van het systeem (Continuous Integration, Continuous Deployment).

Feature teams

De ervaring die ik met feature-teams heb komt niet overeen met de theorie. Als je bijvoorbeeld op internet zoekt naar feature-teams, vind je een iets andere beschrijving dan die ik nu ga geven.

Een Scrum-team of een DevOps-team werkt meestal maar aan één systeem. In veel omgevingen moet je systeem met andere systemen in verbinding kunnen staan. Deze interactie wordt meestal gerealiseerd door services op een ander systeem op te roepen. Dus wanneer er een nieuwe (business) functionaliteit moet worden geïmplementeerd, moet je misschien wijzigingen op meerdere systemen doorvoeren. Deze wijzigingen op een of meerdere systemen worden features (eigenschappen) genoemd. Alle medewerkers die aan een feature werken, moeten tegelijkertijd klaar zijn met de wijzigingen in de verschillende systemen om deze gelijktijdig te kunnen testen en releasen. Om ervoor te zorgen dat de verschillende systemen tegelijkertijd klaar zijn, stel je een feature-team samen.

Het feature-team bestaat uit de ontwikkelaars en testers van de verschillende systemen die bij jouw feature betrokken zijn en samen zijn zij verantwoordelijk voor het voltooien van de feature. Dus als je bijvoorbeeld drie systemen hebt, kan het voorkomen dat er één team is dat bestaat uit de ontwikkelaars en testers van systeem A en B, een ander team van A en C en nog een ander team van A, B & C. Voor elke nieuwe feature bepaal je welke systemen erbij betrokken zijn en hoe de teams worden gevormd.

Het werken met feature-teams kan uiteraard gecombineerd worden met (delen van) het Scrum-framework of DevOps.

Agile scaling

Dit is de/het meest ontwikkelde methode/framework die/dat ik tijdens het werken in projecten persoonlijk heb gezien. Aangezien de onderneming Spotify de eerste was die deze methode/framework gebruikte, wordt het ook wel het Spotify’s framework genoemd. Voor deze methode/framework wordt een combinatie van de vorige methodes/frameworks gebruikt.

Squad: lijkt op een Scrum-team of DevOps-team.

Tribe: een groep squads die aan hetzelfde systeem/component/feature werken.

Chapter: leden van een squad die dezelfde rol delen (bijv. ontwikkelaar, tester). Leden van verschillende squads en/of tribes kunnen deel uitmaken van dezelfde chapter.

Guild: een virtuele groep mensen die dezelfde belangen deelt (bijv. testautomatisering: ontwikkelaars voor het testen van eenheden en testers voor het testen van systemen (integratie)). Leden van verschillende squads en/of tribes kunnen deel uitmaken van dezelfde guild.
Binnen Agile scaling wordt meestal gebruik gemaakt van het Scrum-framework om het werk binnen een squad te organiseren.

Conclusie

Deze blog geeft een overzicht van de verschillende methodes/frameworks die ik persoonlijk heb gezien tijdens het werken in projecten. In mijn volgende blog zal ik aangeven wat ik heb geleerd tijdens het werken met deze vijf methodes/frameworks.