d:mag | Et magasin fra DIPS ASA 2-2017

d:mag | 2-2017 19 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. DIPS-Ordlista Nye workshops ved behov, når produktet er mer reelt og det er enklere å se hva vi mener og hvordan det blir. Utviklingsteamene bryter ned featurene i PBI’er. PBI’ene er i praksis en huskeliste over alle små detaljer på hva sommå 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 opp- gavene er, og tar eierskap til backlogen. 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. – For hovedproduktet vårt har vi to hovedversjoner i året. Vi bruker cirka femmåneder på å utvikle hver hovedversjon gjennom sprinter, forklarer produktlinjeleder Annette Lund Lillegaard. – For versjon 18.1 vil kode- frys 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 flexi- tid, men jobber i all hovedsak på dagtid med utvikling. 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. 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 ompriori- tere 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 syke- pleier som jobber i DIPS og som har erfaring fra sykehus eller kommunal helsetjeneste. DIPS har også flere sykepleiereog 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 spesifika- sjonen 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 sommå gjøres for å nå målet. Dette kalles en Product Backlog item. Samlet blir disse til en kø av oppgaver sommå 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. Annette Lund Lillegaard forklarer utviklings­ prosessen.