Få realiseret værdi hurtigere med Continuous Deployment

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5

  • asdfasdf
This is a quote

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Peter Lindberg

Konsulent

plb@syndicate.dk

3

min. læsetid

September 24, 2018

For mig har et team ikke leveret et værdifuldt inkrement til deres produkt, før det er kommet i hænderne på slutbrugeren. Fra udviklingen af en feature begynder og frem til det bliver taget i brug, er det lidt groft sagt værdiløst.

Scrum handler i bund og grund om at levere værdifuldt software kontinuerligt i god kvalitet til brugerne. Jeg oplever, at mange teams - og ikke mindst organisationer - tror, at hvis man bare arbejder inden for Scrum frameworkets rammer, så kommer resten af sig selv. Det gør det sjældent. Med det udgangspunkt er teamet halvvejs på vej mod “Scrum virker ikke for vores team og organisation” — inden de overhovedet er kommet igang.

Scrum er et framework, der skaber rammerne for, at teamet kan arbejde agilt. Der er fokus på kontinuerlig feedback og forbedring, og alle events eksisterer for at give teamet feedback. Alle events er mulighed for inspect & adapt.
Hvad er det, der inspiceres og tilpasses for hvert event? Det er et spørgsmål værd at overveje i et hvert Scrum Team.
Mange Scrum Teams har glæde af Scrums indbyggede feedback-loops med det samme, men hvordan ser det ud med det produkt, som teamet arbejder på at levere til brugerne?

I sine tidligere udformninger beskrev Scrum Guiden, hvordan release typisk sker efter sprint review, og altså kun en enkelt gang per sprint. Selvom der nu i Scrum Guiden bliver opfordret til at release oftere, er der stadig mange teams, der releaser en gang per sprint (og mange endda sjældnere).

Men behøver det være sådan?

Med Continuous Deployment bliver kadencen sat op, og et team kan i princippet release til produktion flere gange dagligt. Det bør for de fleste teams være et scenario, de stræber efter. Det sætter feedback-kadencen op og giver mulighed for, at man ikke skal vente til efter afslutningen af et sprint på at få feedback fra slutbrugere, og måle værdien af en funktionalitet.

Start i det små

Men hvad skal der så til for at nå dertil?

Det handler meget om arkitektur! Det er svært at release ofte og i god kvalitet, når du har et stort og komplekst system med hårde afhængigheder og grænseflader til en masse andre systemer.

Virker det uoverskueligt at slippe ud af den suppedas?

Start i det små. Microservices og asynkron beskedudveksling services imellem er et sted, du kan starte. Find en del af systemet med tydeligt og afgrænset ansvar, og separer det til en selvstændig service, der kan kommunikere med resten af systemet asynkront — eksempelvis via en message-bus. Dermed kan du arbejde i mod løsere koblede systemer, der kan releases ofte, individuelt og automatisk!
Kig eventuelt på Domain Driven Design og Microservice arkitektur for inspiration. Begynd der, og når erfaringerne og aha-oplevelserne er høstet, tag en bid mere. Elefanten skal spises en bid af gangen.

Teamet kan udnytte en af de mest brugte (og samtidig mest oversete/glemte) artefakter i Scrum til at motivere og skabe fokus omkring hyppige releases — Definition of Done (DoD).

Definition of Done er teamets aftale for, hvornår et Product Backlog Item (PBI) er færdig og kan betragtes som “Done”.

Definition of Done består af målbare punkter, og for mange Scrum Teams stopper det desværre ved kriterier, der omhandler et ønsket niveau af automatisteret test-coverage, at acceptkriterier er opfyldt, at der er lavet kode-review, manuel test osv.

Der skal ikke meget til for, at Definition of Done effektivt kan bruges til også at motivere imod daglige/hyppige releases til produktion.
Jeg har med flere teams været med til at føje til teamets Definition of Done, at en PBI ikke er “Done”, før den er verificeret i produktion. Det skaber et incitament til at skrive små PBI’er, der kan implementeres parallelt, og der opnås et mere effektivt flow med mindre “work in progress”.

Med den hurtigere feedback fra brugerne, bevæger teamet sig med hjælp fra Definition of Done mod at blive mere outcome-baseret fremfor aktivitets- og output-baseret.

Så hvad indeholder jeres DoD?