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 ovenpå 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 autonomi 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. De tre roller har forskellige fokusområder men et fælles mål: at levere kvalitetssoftware til tiden.
  • maintainer rollen sikrer at arbejdet lever op til aftalte standarder og kan automatisere arbejdsgangene via CI/CD automatiseringsværktøjer indbygget i projektets versionsstyrings repository. Rollen kræver teknisk kompetence og et leverandøruafhængigt overblik - det kan være en teknisk kollega, eller en specialist I hyrer ind separat.

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 i dette repo - I har som medlemmer direkte adgang og indflydelse. Kildekode, dokumentation og leverancehistorik m.m. placeres her, uden for leverandørens interne systemer.
  • Maintainer opsætter branch protection regler der sikrer at kun gennemgået kode kan merges.
  • Maintainer opsætter også pull request-skabeloner der sikrer at alle pull requests indeholder nødvendig kontekst.
  • Moderne git platforme har indbygget CI/CD-funktionalitet - klar til brug med det samme. Maintaineren vælger fra et stort bibliotek af automatiserings byggeblokke og tilpasser dem til projektet.
  • Adgangsrettigheder konfigureres og sikrer at kun maintainer og projektleder (på vegne af produktejer) har skriveadgang til main branch.

3. Process Etablering

Arbejd transparent fra dag ét

  • Definer en backlog i jeres issue-tracker med alle ønsker og krav og bind dem sammen med koden via en branch når arbejdet er godkendt til at sætte i gang. Prioriter synligt, så leverandøren ved præcis hvad der skal laves.
  • 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.
  • Hver ændring arbejdes i en isoleret arbejdskopi kaldet en branch der knyttes til det relevante issue.
  • Leverandøren kan nu levere kode, men kan ikke ændre den endelige løsning uden jeres godkendelse - og 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 andre end forfatteren selv.
  • Som behovet stiger tilføjes automatiske tests via den indbyggede CI/CD inden kode man 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 issue-trackeren
branch ↗ En isoleret arbejdsmappe 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 godkendelse og publicering af kode
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 ↗ Kort 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

Læs mere