Draft

Åben leverancemodel

Sådan får I styr på leverancerne!

Jan Maack Kjerbye - Enterprise Arkitekt @ os2.eu ✉️

Som projektleder i det offentlige kan du stå i en situation hvor du indkøber softwareudvikling uden at kunne se, hvad leverandøren faktisk laver. Men det behøver ikke være sådan!

En åben leverancemodel gør alt arbejde synligt og sporbart - fra den første idé til den endelige leverance. Modellen bygger oven på jeres kontrakt - I får nu dokumentation for hvad der er lavet, hvad der mangler, og hvem der har gjort hvad.

Fordelene

Enighed om leverancer

Skab fælles forståelse mellem myndighed og leverandør ved at definere alt arbejde som synlige, prioriterede opgaver. Når prioriteringer laves åbent, kan begge parter se og acceptere hvad der leveres hvornår.

Handlefrihed til myndigheden

Behold kontrollen over jeres projekt uanset hvilken leverandør I vælger at bruge, nu eller i fremtiden. Når al kode og dokumentation er tilgængeligt, kan I til enhver tid skifte leverandør uden at miste viden eller investeret arbejde.

Digital suverænitet

Digital suverænitet er et mål for mange myndigheder, men vejen derhen kan føles uklar. Denne model giver et konkret svar: Når I ejer kildekoden, har uafhængig teknisk kompetence og arbejder transparent, har I allerede taget de vigtigste skridt. EU’s og statens ambitioner om digital suverænitet starter med at have kontrol over jeres egne digitale løsninger.

Direkte genbrugelighed

Når I betaler for en løsning der er udviklet i det åbne med denne metode, kan andre offentlige myndigheder genbruge den med blot ganske få lokale tilpasninger. Dette maksimerer værdien af skatteborgernes penge og styrker det fællesoffentlige digitale økosystem.

Tre enkle trin til implementering

1. Organisering

Etabler klare roller og prioritering

Følg OS2’s styringsmodel og etabler en styregruppe og en koordinationsgruppe til at varetage projektets ledelse og produktansvar. Skriv til os2@os2.eu for at komme i gang med det organisatoriske.
Definér en maintainer-rolle der har det tekniske overblik. Styregruppen, koordinationsgruppen og maintaineren har forskellige fokusområder men et fælles mål: at levere kvalitetssoftware til tiden.
Som koordinationsgruppens forlængede tekniske arm understøtter Maintainer-rollen kvalitet og kadence gennem automatiserede processer. For at bevare kontrollen skal rollen være leverandøruafhængig og ligge uden for leverandørens organisation. Rollen kræver dyb dokumenteret erfaring med git og open source-processer.

2. Teknisk implementering

Skab et standardiseret fundament

Alt starter i jeres projekts OS2-ejede repository. Skriv til os2@os2.eu for oprettelse samt onboarding af maintainer og projektleder.
Jeres leverancestyring konfigureres og styres fra dette repo - I har som medlemmer direkte adgang og indflydelse. Kildekode, dokumentation og leverancehistorik m.m. placeres her, uden for udviklings- eller hostingleverandørernes interne systemer.
Maintainer opsætter branch protection-regler der sikrer at kun gennemgået, godkendt kode kan merges ind i projektet.
Maintainer opsætter pull request-skabeloner der sikrer at alle ændringsanmodninger (pull requests) indeholder nødvendig kontekst.
Maintaineren opsætter issue-skabeloner der sikrer at alle nye opgaver indeholder de nødvendige informationer.
Maintaineren opsætter i samarbejde med projektlederen meningsfulde labels (emne-markører) og milestones (milepæle), der passer til projektets kontekst.
Moderne git platforme har indbygget CI/CD-funktionalitet - klar til brug med det samme. Maintaineren vælger fra et stort bibliotek af automatiseringsbyggeblokke og tilpasser dem til projektet.
Adgangsrettigheder konfigureres og vedligeholdes for at sikre at kun maintainer og projektleder (på vegne af styregruppen) har skriveadgang til main branch.

3. Proces-etablering

Arbejd transparent fra dag ét

Definer en backlog i jeres issue-tracker med alle ønsker og krav, og bind dem sammen med en branch inden arbejdet godkendes til at blive sat i gang. Prioriter synligt, så leverandøren ved præcis hvad der skal laves. Dette binder den leverede kode og dokumentation sammen med den definerede opgave.
Alt arbejde udspringer af en aftalt opgave (issue). Når leverandøren har udført arbejdet, kan I se det via en anmodning om godkendelse (pull request). Her kan I stille spørgsmål, bede om rettelser eller demoer. Først når I har godkendt det, bliver det en del af løsningen.
Leverandøren kan på denne måde starte med at levere dokumentation og kode med det samme, men kan ikke ændre den endelige løsning uden jeres godkendelse. Ligesom alt andet arbejde er også godkendelsen synlig i ændringshistorikken.
Resultatet af arbejdet leveres som en pull request. Før kode merges, gennemgås den af en anden end forfatteren selv.
Som behovet stiger tilføjes automatiske tests via den indbyggede CI/CD inden kode merges.

Fremadrettet

Når I arbejder åbent og transparent, kan I opbygge et fællesskab omkring jeres løsning. Andre myndigheder kan følge med i udviklingen og bidrage med forbedringer. Denne model er et simpelt leverancekrav - ikke anderledes end at stille krav til dokumentation eller kvalitetssikring.

Forstå begreberne

Klik på begrebet for en længere ekstern forklaring (på engelsk)

Term	Beskrivelse
`issue` ↗	En opgave, fejl eller idé der registreres i projektets `issue-tracker`
`issue-tracker` ↗	Repositoriets indbyggede opgavestyringssystem
`branch` ↗	En isoleret arbejdskopi der knyttes til et issue
`backlog` ↗	Alle opgaver der venter på at blive prioriteret
`maintainer` ↗	Teknisk ansvarlig der sikrer processerne overholdes og kan automatisere dem
`branch protection` ↗	Regler der forhindrer kodeændringer uden godkendelse
`pull request` ↗	Anmodning om at få kodeændringer gennemgået og godkendt før de optages i projektet
`repository` ↗	Projektmappe med kode, dokumentation og releaseprocesser
`merge` ↗	Godkendelse og publicéring af kode, dokumentation eller konfiguration
`main branch` ↗	Den godkendte, endelige version af koden (klar til udgivelse)
`repo` ↗	Almindeligt brugt forkortelse for repository – projektmappe med kode og dokumentation
`git` ↗	Versionsstyringssystem der holder styr på ændringer i projektet
`CI/CD` ↗	Værktøjer til automatisering af test og udgivelse af kode
`labels` ↗	Mærkater brugt til at kategorisere og sortere issues og pull requests
`milestones` ↗	Tidsbundne mål for projektet, der hjælper med at holde fokus på vigtige leverancer