Skip to main content

Bild

Image

Digital transformation Enfo
Blogg

Konsten att jobba snabbare genom att sakta in

Sektioner

Image

Sara Grey, Enfo

Text

Har du någon gång varit med om att du beställt någonting men sedan fått någonting helt annat? Eller kanske har du suttit som utvecklare och arbetat med en uppgift när beställaren plötsligt kommer in med ändringar, men att du sen får frågan: ”Varför tog det här sån tid?”. Trots att de flesta av oss arbetar agilt och därmed ska jobba snabbare och med rätt saker verkar det som att så inte är fallet i verkligheten. Istället går det ofta fel längs vägen.

 

Att jobba agilt är ingenting nytt och någonting som de flesta inom IT gör mer eller mindre. Det vanligaste i mina ögon verkar inte vara att gå ”by the book” utan att anpassa det agila ramverket till sina egna behov. Varför jobbar vi agilt då, kan man fråga sig? Jo, idén är i grund och botten att kunna arbeta mer snabbfotat, få ut lösningar och därmed värde till användarna snabbare och i mindre delar. Detta istället för som i vattenfallsmodellen där man levererar lösningen till användaren först när det är 100% klart. Att jobba agilt innebär även att man snabbare kan byta riktning och fokus om man inser att det man jobbar på inte var vad man hade tänkt sig eller att det faktiskt inte går att göra - en så kallad fail fast.

Om nu i stort sett alla företag jobbar agilt, då måste de vara experter på att prioritera vad som ska göras och veta vad som ger mest värde för användarna, eller? Nja, för:

  • Att jobba agilt och att jobba med rätt sak behöver nödvändigtvis inte vara det samma
  • Att jobba med rätt sak och leverera vad användarna har beställt behöver inte heller vara det

Att jobba snabbt och anpassningsbart behöver alltså inte betyda att man identifierat och jobbar med det som ger mest värde till användarna. I praktiken innebär det här att vi kan jobba agilt och få ut jättemycket ny funktionalitet till användarna utan att för den delen tillföra värde. Vad kan vi då göra för att säkerställa att vi jobbar agilt, med rätt sak och att det som har högst prioritet också är det som användarna helst vill ha?

 

Ett verktyg när kommunikationen haltar

Kommunikation är nyckeln till framgång här, men att kommunicera över kunskapsområden kan vara svårt. Det kan vara lite som att försöka prata med någon på ett språk man själv inte behärskar riktigt. Användaren har inte den underliggande förståelsen för hur logiken i koden hänger ihop med vad de ser i applikationen. Utvecklaren däremot har full koll på koden och funktionerna men har svårare att förstå värdet i det stora hela. Som tur är finns det ett hjälpmedel man kan använda för att underlätta kommunikationen, nämligen kravinsamling.

Med kravinsamling kommer det ta längre tid att komma igång, men det betyder inte att den totala tiden som läggs ner på att utveckla ny funktionalitet kommer att bli längre - den kan på sikt till och med bli kortare. Genom att användare och utvecklare sätter sig ner tillsammans och pratar om vilka behov som finns, vilka resultat man förväntas uppnå, om det finns specialfall och liknande, kommer detta lägga en viktig grund och en samsyn kring vad som ska göras. Istället för att beställare och utvecklare arbetar var för sig kommer nu båda på ett naturligt sätt bli delaktiga i hela processen och arbeta tillsammans mot ett och samma mål. Om man dessutom dokumenterar det man kommer fram till får man en väldigt bra början till en kravspecifikation.

 

5 frågor som hjälper er komma igång

Det kan vara svårt att veta var man ska börja och därför har jag tagit fram några frågor som användare och utvecklare kan gå igenom tillsammans:

  1. Vilket resultat vill vi uppnå?
    Denna punkt syftar till att ge utvecklaren förståelse för vad användaren vill kunna göra och vilket mervärde detta kommer att ge.
     
  2. Finns det externa beroenden?
    Är detta ett arbete som användaren och utvecklaren kan göra på egen hand eller kommer de vara beroende av externa resurser? Saknas det någon kompetens inom området? Kommer användaren själv att testa av funktionaliteten eller ska någon annan göra det? - Försök att hitta alla beroenden som finns eller kan uppstå.
     
  3. Vad finns det för regler och restriktioner?
    Vad är tillåtet och inte? Hur ska systemet agera om någonting otillåtet inträffar? Vad ska t.ex. hända om ett specialtecken matas in i ett fält där man förväntar sig en siffra?
     
  4. Vad finns det för olika utfall?
    Beroende på vad som ska göras kan denna punkt bli väldigt kort, som:
     ”Om A = 1, visa grönt. Om A = 0, visa rött.”
    Men den kan också bli väldigt lång då man vill hitta och fånga upp alla olika utfall.
     
  5. Finns det några specialfall som ska hanteras?
    Att redan från början känna till specialfall gör att utvecklaren kan planera för och inkludera dessa i lösningen. Då slipper hen upptäcka och hantera dem i efterhand, vilket ofta ökar komplexiteten och försvårar förvaltningen.

När ni sedan besvarat frågorna och kanske ytterligare frågor som ni kommit på, då har ni en väldigt bra grund till en kravlista och även ett testprotokoll. Varje krav ni har tagit fram motsvarar ett testfall med förväntat utfall.

 

Prioritera tillsammans

Hur kan man sen avgöra vilka av aktiviteterna i kravlistan som ger mest värde för insatsen, dvs är högst prioriterade? Det är inte bara användarnyttan hos ett krav som avgör vilket man vill sätta högst upp på listan, utan man behöver också ta hänsyn till andra saker som komplexitet, kostnad och risk. Här behövs både användare och utvecklare som tillsammans kan fundera över de olika aspekterna. Utvecklaren kan bedöma komplexiteten eller tidsåtgången och användaren kan bedöma nyttan för sin verksamhet. Till sin hjälp kan man visualisera kraven i en matris som den nedan. Då får man en enkel överblick och kan rangordna kraven så att alla är överens om i vilken ordning de ska utföras.

Image

krav

Text

Det är lätt att tro att man sparar tid och pengar genom att kasta sig huvudstupa in i arbetet utan att ha lagt den här viktiga grunden, men då har man missförstått det agila arbetssättet. Jag har många gånger varit med om att man använder frasen ”vi arbetar agilt” som en ursäkt för att dra igång projekt utan tydlig målbild. Att lägga lite extra tid i början kommer resultera i att alla inblandade har samma bild av vad som ska göras och inte göras, vad som ska testas och godkännas innan man kan säga att man är klar. Personligen tror jag inte bara att det här är en snabbare väg att gå då man kommer göra rätt sak från början, jag tror också att det här sättet att arbeta kommer stärka tilliten mellan användare och utvecklare, affären och IT.

 

Sara Grey, BI-konsult, Enfo

sara.grey@enfogroup.com

Linkedin

Dela