Er du på vej mod nirvarna?

Der er noget fascinerende, men også farligt, ved modenhedsmodeller “maturity models”, som i deres natur postulerer, at det nødvendigvis er bedre at befinde sig i den modne ende af skalaen. Dermed skal man vælge sin model (og dermed skala) med omhu.

En af de modeller, som jeg personligt har skelet en del til og brugt som forklaringsmodel bl.a. i forbindelse med at min afdeling blev kigget efter i sømmene inden firmaet blev opkøbt sidste år, er en “Continuous Delivery Maturity Model”. Det kan være et nyttigt framework både for at illustrere for andre, hvad det er for processer og værktøjer, man benytter sig af, men også for at give inspiration til, hvad næste skridt kunne være.

Konkret har jeg haft brugt den model, som danske Praqma har skrevet et whitepaper om, men der findes andre fornuftige varianter, bl.a. fra Thoughtworks.

Jeg kan se, at Justin Vaughn Brown fra CA Technologies holder et oplæg på Goto Copenhagen her i oktober om "The DevOps Maturity Curve - where are you on it?" og det kunne nok gå hen og blive interessant at høre endnu en vinkel på det, med mindre det viser sig at være et skalkeskjul for at gøre reklame for hans arbejdsgivers værktøjssuite, som de jo engang imellem sker.

Eftersom vi ikke har et produkt, der hostes af os, men skal installeres hos kunderne, er vi selvfølgelig ikke nødvendigvis på vej mod fuld continuous deployment, men der er rigtigt mange relevante skridt, man kan tage ad den vej alligevel. Hvis jeg f.eks. ser på, hvor vi har bevæget hos hen i år, så har vi f.eks. rykket os adskillige skridt i modellen, bl.a. ved at sikre, at alle commits er linket til tasks, at vi har fået værktøjsunderstøttelse (Stash) til code review og nu committer på branches, så vi kan få pre-testet vores commits inden de ender på master-branchen.

Maturity models giver en sti, hvor andre mennesker har trådt græsset ned og defineret en vej, de vil anbefale. Selvfølgelig skal man ikke ukritisk følge efter, men der kan være gode pointer at hente.

Hvilke modeller abonnerer du på?

Kommentarer (2)
Allan Ebdrup Blogger

Vi er på vej ned af samme vej mod nirvana.

Jeg checkede lige efter, I dag var en god dag, vi deployede 10 gange til produktion, ca. 50/50 mellem små bugfixes, og nye features der var klar til produktion.

Generelt deployer vi en 3-5 gange til produktion hver dag.

Vi forbedrer vores process og tooling der hvor vi har pains. Hvis noget er smertefuldt eller besværligt, så gør det oftere (og med tooling). Det har virket godt. En fordel ved den måde at gøre det på, er at alle støtter op om tiltagene. Teamet har selv være med til at beslutte at tingene skal ændres (fx på retrospective) vi gør det fordi det giver mening, ikke fordi der står i en eller ande model at det skal vi gøre.

Det gør det også nemmere (ikke nemt) at acceptere at tingene ændrer sig hurtigt. Tools skiftes ud og processer ændres og fin-tunes forholdsvis ofte. Det kan være lidt svært for nogle, ind i mellem.

Som sådan abonnerer vi ikke på nogen bestemt model. Vores største inspirationskilder, har nok været blogposts fra folk der fortæller hvordan de konkret gør hos dem, nærmere end en model.

Samtlige forbedringer vi har lavet, er kommet fra vores teams. Fra dem med fingrene i bolledejen. Ikke en eneste ændring er blevet dikteret af ledelsen.

Resultatet er indtil videre at vi leverer mere værdi til vores brugere, hurtigere og i højere kvalitet. Samtidig med at hverdagen som PO, QA, udvikler og teamlead er blevet bedre. Vi snakker virkelig markante forbedringer. Så hvis du overvejer en vej mod nirvana, kan jeg, udfra vores erfaringer, klart anbefale det.

Når man først går i gang med at forbedre sine processer og tooling i et højt tempo, så stopper man ikke igen. Der er altid ting der kan gøres bedre, det bliver en del af hverdagen med ændringer. Det kan jeg personligt godt lide. Men man skal nok være typen der synes at forandring fryder.

Pelle Söderling

Den største fejl jeg ser folk begå er at følge modeller slavisk enten fordi man tror andre må vide bedre eller fordi det er blevet dikteret oppefra af ledelse eller investorer at sådan skal man gøre (fordi de tror andre end deres medarbejdere må vide bedre).

Det eneste der giver mening er at studere modellerne, forstå hvad det er for nogle problemer de forsøger at løse og forholde sig til om det er noget der giver mening i forhold til ens virksomhed, projekt, team og virkelighed.

Cherry-pick det som giver mening og ignorer al det hvor tradeoff'et ikke er besværet værd. Sig 100x oftere nej end ja til at tilføje mere overhead til udviklingsprocessen og når det er nødvendigt at tilføje overhead så sørg for at involvere hele teamet i beslutningsprocessen - sørg for alle forstår hvad det er for et problem der skal løses og er enige i at det her er måden at løse det på - træk aldrig rigide processer ned over hovedet på intelligente mennesker som de ikke kan se meningen med, det giver aldrig et godt resultat.

Log ind eller Opret konto for at kommentere