Slik foregår utvikling i DIPS
Publisert
Med et komplett DIPS Arena på plass kan utviklerne i DIPS rette blikket framover, for å utvikle ny funksjonalitet som kan forenkle og effektivisere arbeidshverdagen i et sykehus. Her presenterer vi utviklingsprosessen slik den foregår i DIPS.
Foto: Marthe Mølstre
1. Ideen oppstår, enten gjennom en konkret bestilling fra en kunde, eller som følge av at DIPS selv har en idé eller visjon om hvor de vil ta et spesielt produkt.
2. Planleggingsfasen. DIPS inviterer inn sine største kunder til en workshop for å presentere ideen eller bestillingen for at alle skal kunne komme med innspill, og for at DIPS skal være sikker på å utvikle en løsning som kan brukes og konfigureres for alle og ikke er spesialtilpasset en enkelt kunde. Her går vi for eksempel gjennom et pasientforløp for å finne den mest hensiktsmessige arbeidsflyten som produktet bør ha. Alternativt brukes interne konsulenter og medisinske rådgivere dersom produktet er lite og/eller området godt kjent.
3. UX-designere hentes inn, gjerne allerede i workshop for å kunne lage skisser for hvordan dette kan bli seende ut. Hvis produktet skal inneholde funksjonalitet for klinikere deltar også medisinske rådgivere.
4. Nye workshops ved behov, når produktet er mer reelt og det er enklere å se hva vi mener og hvordan det blir.
5. Produkteier i DIPS er ansvarlig for å utvikle en god spesifikasjon som leveres til ett eller flere utviklingsteam avhengig av hva som skal utvikles. Lister opp og går gjennom detaljer i det som skal utvikles.
6. Spesifikasjonen brytes opp i features, det vil si utviklingsdeler, som beskriver hva produktet skal gjøre. En feature beskriver en del av et produkt og kan for eksempel være at en bruker skal kunne fornye en resept med endring.
7. Utviklingsteamene bryter ned featurene i PBI’er. PBI’ene er i praksis en huskeliste over alle små detaljer på hva som må gjøres. En Avbryt-knapp i skjermbildet for fornying av resept kan for eksempel være en egen PBI. Teamene estimerer så hva de trenger av tid på utviklingen av de enkelte PBI’ene, hvor stor oppgavene er, og tar eierskap til backlogen.
8. Produkteier prioriterer de ulike featurene, med tilhørende PBI’er, alene eller sammen med produktlinjeleder, andre produkteiere og kliniske rådgivere. Produkteier har ansvar for å prioritere hva som lages først i utviklingsløpet.
9, Utviklere jobber med PBI’ene i sprinter. Dette inkluderer test og dokumentasjon av det som er laget, samt eventuelle feilrettinger.
10. PBI’ene legges i et felles testmiljø for å teste det kommende produktet mot resten av miljøet. Dette kan også føre til feilrettinger eller justeringer som teamet må ta tak i for så å levere på nytt til felles testmiljø. I noen tilfeller vil en kunde kunne være med å teste før endelig ferdigstilling.
11. Ferdigstiller versjonen med alle produkt, databaseendringer og dokumentasjon og kjører en siste installasjons- og funksjonatest.
12. Lansering via DIPS Kundeportal
13. Hver kunde legger inn sine spesifikasjoner, det vil si de får tilgang til den generelle versjon som de konfigurerer til sitt bruk.
14. Produktet går i drift, som for DIPS i denne fasen inkluderer fortløpende vedlikehold, evt opplæring av kunder hvis det er et stort og omfattende produkt.
– For hovedproduktet vårt har vi to hovedversjoner i året. Vi bruker cirka fem måneder på å utvikle hver hovedversjon gjennom sprinter, forklarer produktlinjeleder Annette Lund Lillegaard.
– For versjon 18.1 vil kodefrys være i mai. Så består tiden fram til lansering til testing, justering og feilretting. Mindre produkter tar som regel betydelig kortere tid. De kan gå fra start til mål på en måned.
Utviklerne i DIPS har flexitid, men jobber i all hovedsak på dagtid med utvikling.
DIPS-Ordlista
Produkteier: Ansvarlig for utvikling av produktet. Produkteieren eier visjonen for det som skal utvikles og representerer de som skal bruke produktet. Bestemmer hvem som skal involveres og når, og prioriterer rekkefølgen i utviklingen og rekkefølgen på de ulike product backlog items som utvikles. Produkteier kan omprioritere rekkefølgen ved behov.
UX-designer: Jobber med bruksopplevelsen og brukergrensesnittkomponentene i produktene. Sørger for at det er enkelt og intuitivt å navigere inne i applikasjonen.
Medisinsk rådgiver: Fagutdannet lege eller sykepleier som jobber i DIPS og som har erfaring fra sykehus eller kommunal helsetjeneste. DIPS har også flere sykepleiere og bioingeniører som er ansatt som konsulenter i team eller ut mot kunder.
Utviklingsteamet: Utviklingsteamet er tverrfaglig og består som regel av tre til ni personer. Det er helt avgjørende at teamet innehar all kompetansen som er nødvendig for å lage det som er beskrevet i spesifikasjonen for produktet. Bare på den måten vil de kunne jobbe optimalt som selvorganisert team. Teamet tar kollektivt ansvar for å skape mest mulig verdier for interessentene.
Sprint: Et utviklingsløp i DIPS kalles en sprint. Det bety at hvert utviklingsteam jobber i tidsbokser med fast lengde. En sprint kan maksimum ha en lengde på en måned, og den kan gjerne være kortere. De fleste sprinter går over to uker. Når en sprint starter, forplikter teamet seg til å levere det omfanget fra produktkøen de har tro på at de skal klare.
Product Backlog item: For å kunne løse oppgaven må et utviklingsteam definere alle de oppgavene som må gjøres for å nå målet. Dette kalles en Product Backlog item. Samlet blir disse til en kø av oppgaver som må løses og som produkteier prioriterer rekkefølgen av.
Kodefrys: Tidspunktet når utviklingsteamene må ha fullført sine oppgaver, og det kun er testing ut mot kunde som gjenstår.
Konfigurering: Gjøre klar softwaren for drift hos en kunde, ved å legge inn sentrale parameter som er bestemt for den enkelte organisasjon. |