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.

 

Kvinnelig utvikler foran PC
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 spesial­tilpasset en ­enkelt kunde.  Her går vi for eksempel gjennom et pasientforløp for å finne den mest ­hensiktsmessige arbeids­flyten 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åd­givere. 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 produktlinje­leder 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 Arena skjermbilde

 

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 rekke­fø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 bruker­grensesnittkomponentene i produktene. Sørger for at det er enkelt og intuitivt å navigere inne i appli­ka­sjonen.

 

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 ­av­gjø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.

 

 

 

Relatert