Case : Telemedicin
Side 4
80%
20%
0
0.5
1
1.5
2
Kronikere
Omkostninger
Mill.
Mål
1. Empowerment
2. Ressourcer
3. Kvalitet
Mål
1. Empowerment 2. Ressourcer 3. Kvalitet
Hvorfor?
Hvordan?B1 Måleudstyr i
hjemmet
B2 Virtuel konsultation
B3 Vidensoverførsel
B4 Nem installation
B5 Dataoverførsel
Hvad?
Acceptkriterier
Acceptkriterier
Behov
Krav
Hvor meget?
Empowerment
Mål:
Borgeren føler sig selvhjulpen i eget hjem
(Hvorfor?)
Behov:
Borgeren kan selv følge med i data og agere
proaktivt
(Hvordan?)
Metrik:
• Stigning i livskvalitet på 70%
• Reduktion af genindlæggelse med 30%
(Hvor meget?)
Værdi
• Realisering af
specifikke mål
Vurdering af behov
Side 8
Høj
Lav
Lav Høj
VÆRDI
RISIKO
Risiko
1. Forretningsmæssig
2. Social
3. Teknisk
4. Omkostning + tid
Specifikke mål:
1. Borgeren føler sig
selvhjulpen –
Empowerment
2. Frigøre ressourcer
hos personale
3. Højere kvalitet i
behandlingen
Forretningsmæssige Mål Forretningsmæssige Behov Relaterede krav
1. Empowerment ved at
borgeren føler sig selvhjulpen i
eget hjem
B1: Opsamling af data fra måleudstyr
som borgeren betjener i eget hjem
…
2. Frigøre ressourcer ved
reduktion af ambulante besøg
B2: Virtuel konsultation mellem borger
og behandler (eks. video-konsultation)
…
3. Højere kvalitet ved bedre
planlægning af behandlingen
B3: Nem vidensoverførsel fra borger til
behandler om borgerens tilstand (eks.
spørgeskema)
…
2. Frigøre ressourcer i regi
af kommunal pleje
B4: Nem installation af måleapparater
og opsamlingsenheder
…
3. Højere kvalitet ved mere
systematisk opfølgning på data
og målinger
B5: Automatisk overførsel af data fra
måleudstyr til relevant behandler
…
#1 Øvelse Vurdering - Materiale
1. Prioritere
2. Småt er nemmere
3. Afdække afhængigheder
4. Undgå gold-plating
Hvorfor nedbryde behov og krav?
Metode#1: Handlinger i en arbejdsproces
For at kunne implementere en simpel end-to-
end og putte komplicerede trin på bagefter
Som professionel behandler ønsker jeg at
behandle en elektronisk forespørgsel fra en borger
for at give en god sundhedsvejledning…
Modtage Svare Registrere Afslutte
Metode#2 Simpel/kompleks
Hvad er den simpleste version af denne funktionalitet?
De mere komplekse variationer følger efter
Som borger ønsker jeg at få en alarm hvis mine
målingerne afviger en generel tærskel…
45 45
43
45
43
44
Behandler Borger
Metode#3 Variationer i data
Hvilke typer af data skal systemet kunne håndtere. Hvad er
den mest basale type?
Som borger ønsker jeg at kunne levere
måledata til behandleren …
Måledata
Lunge-
funktion BlodprøveBlodtrykTemperatur
Metode#4 Operationer
De forretningsmæssige operationer kan være spredt over flere
forskellige opgaver og roller.
Som sygehus ønsker jeg at tilbyde borgeren en
behandling af X…
Oprette
Beskrive
Opsætte Anvende Nedlægge
Skift i brugere!
Metode#5: Hver enkelt forretningsregel
• … med en praktiserende læge
• … med en jordemoder
• … med en speciallæge
• … med en psykolog
Som borger ønsker jeg at anmode om video-konsultation
med en professionel behandler…
§1
§2
§3
§4
Metode#6 Stor indsats og efterfølgende
Det første krav bærer den tekniske byrde for de efterfølgende
Som en borger ønsker jeg at betale for en
specialbehandling med VISA, MasterCard, Diners
Club, eller American Express …
• …at betale med én af kreditkorttyperne (VISA, MC, DC, AMEX)
• …at betale med alle fire kreditkorttyper (VISA, MC, DC, AMEX) (givet at
en type allerede er implementeret).
Metode#7 Input metode
Hvordan ser den simple brugergrænseflade ud? Den mere
brugervenlige og smarte?
• ... med en almindelig brugergrænseflade
• ... med mulighed for store taster til svagtsynede
• ... ved at bruge stemmen og undgå tastaturet
Som borger ønsker jeg at kunne opsamle oplysninger
om min sundhedsmæssige tilstand...
Metode#8 Ydeevne
Hvordan får vi det til at fungere? Hvordan får vi det til at gå hurtigt?
• … langsom søgning der viser et timeglas
• … under 1 sekund, så borgeren ikke behøver at vente
Som borger ønsker jeg at få oplysninger om
tilgængelige behandlingstider hos behandlere…
Metode#9 Undersøgelse (spike) og implementation
• … verificere kundens identitet på en IPad?
• … hvor skal ikke-underskrevne dokumenter lagres?
• … implementer løsningen efter spiken (et krav der sandsynligvis
skal nedbrydes yderligere)
Ved dårlig forståelse af løsning. Et nyt område enten teknisk eller
forretningsmæssigt. Et Proof Of Concept (POC)
Som borger vil jeg gerne kunne underskrive dokumenter via
min IPad, for at undgå ventetid på at underskrive papirer…
9 metoder til nedbrydning:
#1 handlinger
#2 simpel/kompleks
#3 datavariationer
#4 operationer
#5 forretningsregler
#6 stor indsats og efterfølgende
#7 input metode
#8 ydeevne
#9 undersøgelse og implementation
Metode#1 Nedbrydning i handlinger i en arbejdsproces
Metode#2 Nedbrydning i simpel/kompleks
Metode#3 Nedbrydning i variationer i data
Metode#4 Nedbrydning i operationer
Metode#5 Nedbrydning i hver enkel forretningsregel
Metode#6 Nedbrydning i stor indsats og efterfølgende
Metode#7 Nedbrydning i input metode
Metode#8 Nedbrydning i ydeevne
Metode#9 Nedbrydning i undersøgelse og implementation
9 metoder til nedbrydning:
B1: Opsamling af data fra måleudstyr som borgeren
betjener i eget hjem
Følgende måleudstyr ønskes understøttet: blodtryks-måling,
hæmoglobin-måling, spirometri(lungefunktion)-måling og vægt.
B3: Understøttelse af spørgeskema til borger fra
behandler
Behandleren definerer spørgeskemaet ud fra en skabelon, borgeren
udfylder spørgeskemaet, behandleren kvitterer for udfyldelse af
spørgeskemaet, behandleren stiller diagnose på baggrund af
spørgeskema og sender til borgeren.
B4: Det skal være muligt at udvide systemet med nye
måleapparater
#2 Øvelse Nedbrydning
Nedbrydningsmøde 1-1½ time
Mål At nedbryde epics eller store User Stories i flere mindre User Stories, i
forhold til udvikling og test. Afklaring af afhængigheder og ressourcer
Forberedelse Product Owner indsamler baggrundsmateriale. Deltagere læser User Stories
igennem inden møde
Deltagere Product Owner, udvikling, test, evt. eksterne deltagere (afhængigheder)
Input En eller flere User Stories
Aktivitet Baggrund for User Stories forklares kort af PO.
Nye mindre User Stories skrives i fællesskab. Gerne ved tavle på kort
Eventuel estimering af nye User Stories (ikke nødvendigvis Planning Poker)
Resultat En samling af nye User Stories evt. med estimater og markering af
afhængigheder, der kan prioriteres efterfølgende.
Efterbehandling Registrering af nye User Stories i værktøj. Prioritering.
Tommelfingerregel: User Stories skal nedbrydes så de kan laves inden
for en iteration
Checkliste til User Stories/Epics
B23
User story:
Som <hvem> ønsker jeg at <hvad> således at <hvorfor>
Beskrivelse:
Acceptkriterier:
Afklaringer:
Afhængigheder:
Testbehov:
Klargøring: Testscenarier
• Klar ide om hvornår User Story er færdig
• Undgå tilbageløb og fejl
Testeksempler (i overskrifter):
1. Forventet opførsel (solskinsscenarie)
2. Eksempler på uønsket opførsel (negativ scenarier)
B23
Testscenarier:
Klargøringsmøde 1½ - 2 timer
Mål En yderligere detaljering af User Stories, så User Stories kan implementeres uden
væsentlige forhindringer og tilbageløb.
Forberedelse Deltagere læser User Stories igennem inden møde. Test har evt. indsamlet en
række testeksempler som kan gennemgås på mødet.
Deltagere Product Owner, udvikling, test
Input En eller flere User Stories der er nedbrudt til en passende størrelse og eventuelt
har defineret initielle acceptkriterier
Aktivitet Baggrund for User Stories forklares kort.
For hver User Story skrives der i fællesskab overskrifter for testeksempler/accept
test, der vil blive gennemført inden User Story kan kaldes færdig
Resultat En samling User Stories med yderligere acceptkriterer og testeksempler, der er
klar til at putte ind i en iteration.
Efterbehandling Opdatering af User Stories. Registrering af testeksempler i værktøj.