Deel 5 Ontwikkelstrategieën

3 Ga uit van verandering en houd opties open. Veelal worden vereisten aan het begin van een project sterk afgelijnd. Dat houdt echter een risico in: als het startpunt fout is, is de kost voor de wijziging groot en duurt het te lang om te implementeren. Daarom is het aangewezen rekening te houden met de veranderingen die nog zullen moeten worden doorgevoerd door verschillende opties open te houden.

4 Bouw incrementeel met snelle geïntegreerde cycli. Zorg voor snelle iteraties die altijd een nieuw stukje functionaliteit toevoegen aan een werkend systeem.

5 Baseer milestones op een objectieve evaluatie van het werkende systeem. Zorg na elke iteratie voor een evaluatie van de software: levert de software de verwachte economische waarde? Is het technisch van goede kwaliteit? Doet het wat we verwachten?

6 Zorg voor een lean proces.

Maak WIP (work in progress) zichtbaar en probeer het zoveel mogelijk te reduceren zodat het de ontwikkelcapaciteit niet onder druk zet.

Zorg voor kleinere batches functionaliteit, zodat ze sneller en betrouwbaarder tot in productie geraken.

– Probeer wachttijden te minimaliseren zodat de business niet te lang moet wachten op nieuwe functionaliteiten.

7 Zorg voor een ritme en doe aan planning over de domeinen heen. Als de ontwikkelingscycli volgens een bepaald ritme worden herhaald, worden ze voorspelbaar en kan een deel van de onzekerheid worden gereduceerd. Door bovendien de planning ruimer te bekijken dan enkel op het eigen domein, zorg je ervoor dat bepaalde problemen op een hoger niveau kunnen worden opgelost.

8 Zorg voor intrinsieke motivatie bij het team. Zorg voor engagement bij de teamleden door ze autonomie te geven en door een gezamenlijke missie en visie te creëren. Geloven in een gemeenschappelijk doel zorgt voor meer motivatie dan traditionele motivators zoals geld en status.

9 Zorg voor gedecentraliseerde beslissingen

Als beslissingen altijd op het hoogste niveau moeten worden genomen, zorgt dat voor heel veel vertraging. Als er gewerkt wordt met snelle, kort opeenvolgende ontwikkelcycli, is een dergelijk beslissingsproces nefast. Er moet dus voor worden gezorgd dat de operationele beslissingen ook op een lager niveau worden genomen.

4 Kanban

4.1 KANBAN om werk te organiseren

KANBAN is een methodiek die de laatste jaren dikwijls wordt toegepast in de praktijk en vooral sterk opkomt bij softwaredevelopment. KANBAN is Japans en betekent in het Engels ‘Sign Board ’ . Een eenduidige Nederlandstalige vertaling is moeilijk, maar het is belangrijk dat KANBAN tot doel heeft werk te organiseren door (voornamelijk) in te zetten op visualisatie. Het zichtbaar maken van het werk heeft namelijk duidelijke voordelen:

1. Het uit te voeren werk inzichtelijk maken en dus iedereen in het team doen begrijpen wat er dient te gebeuren (ook eventueel buiten de eigen scope of buiten de eigen expertise);

2. Duidelijk en transparant weergeven welke werkitems in de scope van het project zitten en wat hun huidige status is;

3. Iedereen binnen en buiten het team eenzelfde, duidelijke status geven over het project.

Hoe KANBAN in de praktijk getoond (‘gevisualiseerd’) wordt op een project, zie je in volgend voorbeeld. Zo’n inzichtelijke visual wordt een KANBAN-bord genoemd.

Bron: https://productivityland.com/what-is-kanban-board/.

4.2 Bouwstenen van KANBAN

Om KANBAN toe te passen op een project zijn (minstens) drie zaken nodig:

1. KANBAN-bord: het bord wordt de centrale cockpit van het project. Hier worden alle werkitems opgelijst en schuiven ze van links (‘ backlog’) naar rechts (‘ done’). We geven mee dat er geen vaste afspraken zijn rond de kolommen op een KANBAN-bord. Elke kolom toont in welke status (bv. backlog, in progress, done) of in welke fase (bv. backlog, in analyse, in ontwikkeling, in test, done). Dat geeft dus enige flexibiliteit en laat eveneens toe om op een later tijdstip kolommen toe te voegen. Op die manier ondersteunt KANBAN dus de lerende organisatie.

2. KANBAN-kaartjes: elke kaart is één (en slechts één) werkitem. In de praktijk gebruikt men vaak post-its om die werkitems te noteren. In softwaredevelopment kan een KANBAN-kaartje overeenkomen met een feature. Binnen een agile context staat een KANBAN-kaartje vaak gelijk met een user story. Het projectteam kan zelf kiezen welke info ze noteren op de KANBAN-kaartjes, zolang de info het team helpt om de werkitems goed te laten doorstromen richting de oplevering.

3. Afspraken rond work in progress ( WIP): WIP verwijst naar de taken die bezig zijn en dus de beschikbare resources aan het werk zetten. Om KANBAN goed toe te passen en volop van de voordelen te kunnen genieten, maak je bij de start van het project goede afspraken hoeveel werkitems er in elke status of elke fase mogen zitten. Dat kan verschillen per kolom. In veel bedrijven zijn er bijvoorbeeld meer ontwikkelaars dan testers. Er zullen dus minder werkitems kunnen worden toegewezen aan de testkolom dan aan de ontwikkelkolom. Het zijn de testers die afhankelijk van de voortgang volgende werkitems opeisen en dus verplaatsen naar de testkolom. Veelal zien we dat die afspraken aanleiding geven tot een resourceoptimalisatie. Als de capaciteit in een bepaald team (of kolom) beperkt is, kan die bottleneck mogelijk worden verholpen door resources te verschuiven tussen kolommen.

Tegenwoordig zijn er tal van digitale tools die het gebruik van KANBAN ondersteunen. Zoals al gemeld in het hoofdstuk ‘Hoe past mijn initiatief binnen de digitale context van mijn bedrijf? #ITGovernance’ zijn Trello en JIRA tools die daarvoor in veel bedrijven, zeker in de softwarewereld, worden gebruikt.

5 RUP (Rational Unified Proces)

RUP is een agile, iteratieve ontwikkelmethode die begin deze eeuw ontwikkeld werd binnen een afdeling van IBM. In die methode worden de verschillende projectfases onderverdeeld in vier grote fases die alsmaar worden herhaald: inception, elaboration, contsruction en transition. Zoals op volgende figuur is te zien, komen de meeste fases van projectuitvoering daarin terug.

Bron: https://www.toolshero.com/information-technology/rational-unified-process-rup/.

In het model is duidelijk te zien dat de meeste activiteiten al zeer vroeg in het project opstarten. Dat komt omdat RUP werkt met prototyping, waardoor er al bij de start geanalyseerd, geïmplementeerd en getest moet worden. De vier fases binnen RUP worden als volgt ingevuld:

– Inception: in deze fase wordt de structuur van het project vastgelegd en wordt er gekeken of de digitale oplossing haalbaar is of niet. Deze fase is sterk te vergelijken met de initiatie die we in het deel ‘Projecten initiëren’ besproken hebben. Mogelijke deliverables in deze fase zijn een visie, businesscase, risicoassessment, projectplan, prototype en een eerste afgewerkte use case.

Elaboration: op dit moment in het project worden de requirements en de architectuur vormgegeven. Daar gaan we de grondige analyse doen van de digitale oplossing. Mogelijke deliverables zijn de rest van de use cases, de architectuur, de WBS, gebruikershandleidingen, …

– Construction: tijdens de constructiefase wordt de digitale oplossing volledig gebouwd. Daar zijn de deliverables de afgewerkte oplossing en de documentatie.

– Transition: in de laatste fase wordt de oplossing vrijgegeven aan de eindgebruiker. We krijgen daarbij een laatste vorm van testing, er worden opleidingen voorzien en de communicatie rond de oplossing wordt uitgerold.

Hoofdstuk 18 Welke agile manieren van werken zijn er? #agile

Binnen RUP is de definitie van de rollen en de activiteiten strikter dan bij SCRUM of KANBAN. Het blijft echter een agile methode omdat de verschillende fases ook in iteraties worden uitgevoerd en elke nieuwe iteratie verder bouwt op de beste versie uit de vorige iteratie. In wezen is RUP iets minder wendbaar als SCRUM waardoor het in grote organisaties eenvoudiger te gebruiken is. Het vooraf definiëren van activiteiten en rollen levert een stabiliteit op die SCRUM moeilijker kan bieden.