DevOps: Werkwijze van een DevOps team

Als we alle rollen die nodig zijn voor het ontwikkelen en beheren van een IT-oplossing bij elkaar brengen in een DevOps team, moeten we even stil staan bij de manier van werken.

Hoe wij werken
Het proces van een DevOps team is eigenlijk vrij eenvoudig. We gaan ervan uit dat het Minimal Viable Product (MVP) draait en het project inmiddels overgegaan naar het kernteam (DevOps team in zijn kleinste omvang). Dit kernteam wordt aangevuld met de juiste resources vanuit de partner (Zie DevOps: Een Nooit Af organisatie) De backlog is nog goed gevuld, we hebben nog veel zaken die moeten gebeuren. Doordat we in productie zijn komen er dagelijks uit te voeren werkzaamheden bij. Bugs moeten worden opgelost en nieuwe wensen worden opgepakt. Bovendien zijn er beheerwerkzaamheden die uitgevoerd moeten worden. Al deze werkzaamheden worden toegevoegd aan de backlog. Daar hebben we er dus maar één van. Alles wat we doen eindigt, als het klaar en getest is, direct in productie. We hebben dus niet meer te maken met sprints, de backlog is dus niet meer dan één grote to-do lijst. Iedereen kan hier items aan toevoegen. Er worden een aantal eisen gesteld aan een nieuw backlog item:

1. Het dient klein te zijn. Een item moet in korte tijd (bijvoorbeeld maximaal 3 dagen) opgepakt, uitgevoerd en afgerond kunnen worden.
2. Het moet duidelijk zijn wat er moet gebeuren. Alleen een titel invullen is niet voldoende. Iedereen uit het team moet het item zonder verdere navraag kunnen oppakken en uitvoeren.
3. Het verwachte eindresultaat moet gedetailleerd beschreven zijn. Op basis hiervan moeten namelijk testgevallen kunnen worden opgesteld.

Niet erg ingewikkeld, maar de ervaring leert dan met name het tweede punt weleens wordt vergeten. Vaak gaat de opsteller van het item ervan uit dat hij of zij het toch zelf oppakt. Maar dit hoeft dus niet. Als je het niet duidelijk beschrijft weet je in ieder geval zeker dat je het zelf moet oppakken, je collega's zullen het uit onbegrip maar laten liggen.

Het is aan te raden een kolom New voor de backlog te zetten (sommige tools maken deze kolom standaard aan). Dit is de plek waar items worden aangemaakt. De volgorde in deze kolom maakt niet uit en items worden hier ook nog niet zijn toegewezen aan een rol. Regelmatig (bijvoorbeeld eens per week) worden alle nieuwe items gereviewd. Dit is de taak van de product owner (die dus in het team zit). Voor alle duidelijkheid: product owner is een rol. Bij voorkeur de business verantwoordelijke, maar een ander teamlid kan deze rol ook vervullen. Als de persoon maar kan denken vanuit de waarde die wordt toegevoegd aan de organisatie. De ervaring leert dat het regelmatig prioriteren van de backlog een cruciale actie is die veel discipline vereist. Het is echt belangrijk hier veel aandacht aan te besteden.

Items die we daadwerkelijk gaan oppakken worden op de backlog geplaatst en geprioriteerd. Dit is niet meer dan op volgorde van relevantie zetten, belangrijkste items bovenaan. Daarnaast worden ze toegewezen aan een rol, bijvoorbeeld developer, beheerder of consultant. Zodra een teamlid klaar is met een item pakt hij simpelweg het bovenste item van zijn rol/expertise op uit de backlog. Zo simpel is het. Uiteraard kan een spoedklus prima snel door het proces worden gehaald. Als er een verstoring is in productie, is het niet de bedoeling om eerst te wachten tot het item geprioriteerd is. Gezond boerenverstand blijft nodig.

Verder moet er een plek zijn waar we de voortgang van de items kunnen bijhouden. Een kanban-achtig bord is hier het meest geschikt voor. Bij Wortell hanteren we hiervoor standaard de volgende kolommen:

1. Backlog
2. Realisatie
3. Test
4. Productie
5. Done

De kolommen weerspiegelen het proces waar alle wijzigingen en verbeteringen doorheen gaan. Door de items in de kolom te zetten waar er op dat moment actief aan het wordt gewerkt, hebben we een helder overzicht van wat zich waar bevindt. Niet alle items zullen door alle kolommen gaan. Als een beheerder een aanpassingen moet doen aan de configuratie van de SharePoint Online omgeving, zal hij dat direct in Test doen. Het item komt dan direct in de bijbehorende kolom terecht.

De voortgang wordt besproken tijdens een korte stand-up. Als het team net is gestart is het aan te raden dit dagelijks te doen. Als de werkwijze meer is ingesleten, kan de frequentie omlaag naar bijvoorbeeld 2 keer per week. De stand-up dient kort en krachtig te zijn. Alleen de items waar iets over te melden is komen aan bod. Heb je bijvoorbeeld hulp nodig van iemand uit het team bij een item waar je mee bezig bent is dit het moment om daar om te vragen. Een stand-up duurt daarom niet langer dan 5 tot 15 minuten. Trap niet in de valkuil om alle items een voor een af te gaan en een status te vragen. De stand-up is ook bedoeld om elkaar scherp te houden. Staat een kaartje al lang in dezelfde kolom en heeft de behandelaar inmiddels meerdere items op het bord staan, is het goed hem daaropaan te spreken. De afspraak moet zijn: Zodra een item op het bord verschijnt, moet hij zo snel mogelijk worden afgehandeld.

Wat komt er na SCRUM
DevOps: Als het toch nooit af is
DevOps: Een Nooit Af organisatie
DevOps: Ook management is Nooit Af
DevOps: Budgetteren in een DevOps organisatie