Page Comparison

Hela Biobank Sverige ITs arbetssätt utgår från agila principer. För den som vill ha en bättre introduktion eller uppdatering av vad det innebär än vad vi kan ge här rekommenderar vi varmt följande introduktion som satts ihop av Henrik Kniberg på Crisp och går igenom mycket av grunderna till agilt arbetssätt. https://www.youtube.com/watch?v=502ILHjX9EE
Resten av denna sida förklarar hur just Biobank Sverige IT jobbar för att vara agila.

Metodik

Biobank Sverige IT strävar efter att vara en integrerad del av verksamheten för att på så sätt bättre förstå våra utmaningar och behov. Vi tror inte att man kan bygga bra lösningnar om man inte förstår vilket problem de ska lösa och var i alla olika processer de passar in. Vi tror också att det är väldigt värdefullt att förså hela verksamheten för att på så sätt hjälpa till att se vilka delar som har mest nytta av IT-stöd så att vi kan hjälpas åt att prioritera de lösningarna som kräver lite IT-resurese och ger stor utdelning för verksamheten. Detta leder till ett ständigt lärande och nya insikter. En traditionell roadmap med lång planering är därför inte optimalt. Vi jobbar med ständig prioritering av vad vi ska göra allteftersom vi lär oss nya saker eller upptäcker nya utmaningar eller möjliga lösningar.
Det betyder inte att vi inte har ett mål eller en plan, men att det är viktigare att vi gör det mest värdefulla först än att följa en plan. Det är det vi menar när vi säger att vi är agila och finns fint summerat på https://agilemanifesto.org/

Praktik

Roller

• Produktägare
  Produktägaren är den som har sista ordet när det gäller prioritering av ärenden (och också om de över huvud taget ska göras). Produktägarens viktigaste uppgift är att väga kostnad mot nytta för varje ide som kommer in. Hur stor nytta en funktion har är det bara verksamheten som vet och det är därför mycket viktigt att produktägaren pratar med verksamheten, dels med indovoder, dels med olika referensgrupper för att kunna förstå.
  På samma sätt pratar produktägaren med utvecklingsteamet för att förstå kostnaden (tiden) för att bygga funktionen och om de får andra konsekvenser (t.ex. att vi behöver avtal med extern leverantör för signering).
  Produktägaren gör sedan en bedömning av vilka ärenden som ger mest nytta för pengarna och prioriterar utefter det

• Scrum-master
  Scrum-masters uppgift är att skydda utvecklingsteamet så att de kan jobba effektivt. Det betyder allt ifrån att vara kontaktperson till att se till att möten och annat planeras på ett sätt som passar för att alla ska få en så bra och effektiv arbetsmiljö som möjligt. Scrum-master är ofta en av utvecklarna i utvecklingsteamet.

• Utvecklare
  De som utgör kärnan av utvecklingsteamet och bygger mjukvaran.

Vardag

Vi arbetar just nu enligt den agila metoden kanban. Det innebär att det finns en lista med prioriterade ärenden där teamet plockar sina uppgifter. Nedan några begrepp som är centrala i vårt arbete.

...

Planen ovan representerar bara de fasta möten vi har enligt vår metodik. Utöver detta har vi möten vid behov för att prata framtida behov och krav, reda ut eventuella oklarheter i sprintens ärenden och mycket annat.

Hur får vi reda på behoven?

Behov kan variera väldigt i storlek och komplexitet, allt ifrån att justera formulering i en text till en applikation där medborgare kan hantera sina samtycken.
Det är därför viktigt att dels aktivt samla in behov, dels lyssna på alla de som på ett eller annat sätt använder eller påverkas av de system vi bygger.

Alla idéer, små och stora, förtjänar att lyssnas på och att tas på allvar, men det betyder inte att alla önskemål kommer att kunna tillgodoses. Produktägaren måste ständigt göra avvägningar mellan behov och kostnad. Vissa behov prioriteras och löses snabbt, andra läggs i vår backlogg för att lösas senare medans ytterligare andra måste avfärdas.

Image RemovedImage Added

Det absolut viktigaste när vi planerar vårt arbete är att förstå behovet, inte att få uppgifter. Genom att förstå varför någonting behövs kan vi tillsammans med verksamheten hitta bästa möjliga lösning som gör att behovet uppfylls. Ibland kan det vara något helt annat än urspringsförslagetursprungsförslaget. Ett bra exempel på detta är kravet i SBR där man hela tiden ville ha uppdaterad folkbokföringsadress när man tittade på ett samtyckesärende. Efter lite samtal kring detta visade det sig att det var för att man när som helst ska kunna skicka brev. Ytterligare diskussioner om när och varför man skickade brev ledde istället till en lösning där systemet automatiskt genererar (och snart skickar) breven. Något som inte hade hänt om vi inte pratat om syftet med funktionen.

Hur kommer vi till ärenden?

När vi börjar förstår ett behov jobbar vi mycket med skisser och lösningsförslag. Beroende på uppgiftens omfattning kan dessa visas för referensgrupper i omgångar och förfinas (t.ex. samtyckeshanteringen) eller bara stämmas av med några få intressenter vid enstaka tillfällen (t.ex. registerutdrag som stämts av med DSO:er)
. Oavsett hur detta arbete går till är det alltid i dialog med slutanvändare och andra intressenter. Vi försöker också alltid bryta isär större uppgifter så att vi kan leverera så tidigt som möjligt och lära oss mer innan vi går vidare istället för att leverera allt vid en stor release på slutet.
På sprintdemo visar vi alltid det som har utvecklats så att alla som är intresserade vet vad vi gjort och vart vi är på väg.

...