Empiri på riktigt - en tilluxad agil utvecklingsmodell
•Descargar como KEY, PDF•
0 recomendaciones•606 vistas
Att utveckla utan feedback från användningen av systemet är som att skapa vetenskapliga experiment utan att göra några observationer. Talet beskriver en tänkt arbetsmodell för systemutveckling enligt den vetenskapliga modellen. Talare är Joakim Holm från Adaptiv Sthlm AB
Recomendados
Más contenido relacionado
Destacado
Destacado (10)
Más de Agila Sverige
Más de Agila Sverige (18)
Empiri på riktigt - en tilluxad agil utvecklingsmodell
- 1. EMPIRI PÅ RIKTIGT - en tilluxad agil modell Joakim Holm Adaptiv STHLM
- 3. ANVÄNDARNAS UPPLEVELSE ÄR ESSENTIELL FÖR GOD AFFÄRSNYTTA
- 5. MAGISK USER STORY? Som van användare vill jag spara mina sökkriteria för att slippa fylla i dem varje gång.
- 6. AFFÄRSNYTTA?
- 7. NYTTAN ÄR UTANFÖR TAVLAN
- 8. NYTTAN ÄR UTANFÖR TAVLAN
- 9. NYTTAN ÄR UTANFÖR TAVLAN €
- 10. MEN KANBAN DÅ?
- 11. Förkorta vårdköerna Affärsmål Radiolog Målgrupper Snabb, korrekt diagnos Användarmål
- 12. HALVTID
- 14. HALVTID Maximera feedback men lyssnar vi på användarna?
- 15. HALVTID Maximera feedback men lyssnar vi på användarna? Maximera ROI
- 16. HALVTID Maximera feedback men lyssnar vi på användarna? Maximera ROI men hur nytta utan användning?
- 17. HALVTID Maximera feedback men lyssnar vi på användarna? Maximera ROI men hur nytta utan användning? Optimera helheten
- 18. HALVTID Maximera feedback men lyssnar vi på användarna? Maximera ROI men hur nytta utan användning? Optimera helheten men saknar behov & användning?
- 19. USER EXPERIENCE
- 20. VETENSKAPLIGA METODEN Försökspersoner
- 21. VETENSKAPLIGA METODEN 1. Observera verkligheten Försökspersoner
- 22. VETENSKAPLIGA METODEN 1. Observera verkligheten 2. Forma hypotes Försökspersoner
- 23. VETENSKAPLIGA METODEN 1. Observera verkligheten 2. Forma hypotes Försökspersoner 3. Utforma experiment
- 24. VETENSKAPLIGA METODEN 1. Observera verkligheten 4. Genomför 2. Forma experiment hypotes Försökspersoner 3. Utforma experiment
- 25. VETENSKAPLIGA METODEN 1. Observera verkligheten 4. Genomför 2. Forma experiment hypotes Försökspersoner 3. Utforma experiment
- 26. I SYSTEMUTVECKLING 1. Observera verkligheten? 2. Forma 4. Driftsättning hypotes? Användare 3. Designa nytt produktinkrement
- 27. FRÅN BEHOV TILL LÖSNING Oidentifierade behov
- 28. FRÅN BEHOV TILL LÖSNING Identifierat behov Oidentifierade behov
- 29. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat behov behov Oidentifierade behov
- 30. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Oidentifierade behov
- 31. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Iteration Konceptuell Oidentifierade design behov Utvärderad Detaljerad design design
- 32. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Iteration Konceptuell Oidentifierade design behov Utvärderad Detaljerad design design Accepterad lösning
- 33. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Iteration Konceptuell Oidentifierade design behov Utvärderad Detaljerad design design Levererad Accepterad lösning lösning
- 34. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Iteration Konceptuell Oidentifierade design behov Utvärderad Detaljerad design design Förstådd Levererad Accepterad lösning lösning lösning
- 35. FRÅN BEHOV TILL LÖSNING Identifierat Prioriterat Användningsscenario behov behov & designkoncept Användning Iteration Konceptuell Wow! Ledtid: design 1-5 dagar Utvärderad Detaljerad design design Förstådd Levererad Accepterad lösning lösning lösning
- 36. joakim holm AGILE SOFTWARE DEVELOPER & COACH +46 70 773 76 29 joakim.holm@adaptiv.se blog: jockeholm.wordpress.com twitter: jockeholm
Notas del editor
- Det här talet ska handla om användarupplevelse, men inte "Wow, vilken jävla resa"-typen av upplevelse utan den lite mer seriösa, tråkiga formen från affärslivet, när vi har ett jobb att sköta och kunder som väntar på oss och förväntar sig god service. Jag vill t.ex. att radiologen här ska ha en känsla av transparens, dvs hon behöver inte tänka på hur hon ska göra för att systemet ska bli nöjt; hon kan koncentrera sig på att ställa rätt diagnos så snabbt som möjligt.
- Kommer ni ihåg att agila processer ska vara empiriska, dvs baseras på erfarenheter från verkligheten? Jag menar att utan användare kan vi inte få någon riktigt empirisk process. Vi måste utgå från användningen i verkligheten för att maximera affärsnyttan.
- Framgångarna för agila metoder är fantastiska och jag ser ingen annan väg framåt idag. Men ingenting är ju fullkomligt. Med erfarenhet inser man att det finns luckor i det agila tänkandet. Jag kallar dem för de agila "blinda fläckarna", för många verkar tyvärr vara blinda för dem. Jag har själv varit i "superagila" projekt där vi känt att vi gjort allt "rätt" och ändå har kunder och användare blivit arga på oss för att vi inte levererade det de behövde. Vi hade förväxlat rörelse med framsteg. Här kommer två exempel på blinda fläckar som relaterar till det här...
- Nr 1: De flesta agila processer startar från en enkel representation av krav, en story. Men var kommer den ifrån? Att svara "en product backlog" eller "en produktägare" genererar bara fler frågor. Var fick dom den ifrån? Det kanske är magi inblandat? Och allvarligt talat, produktägare, det är ju en rätt naiv idé? Det känns som en typisk "vi fattar inte riktigt det här men om vi gör någon ansvarig så händer det säkert bra saker utan att vi behöver blandas in". Låt oss vara överens om att det finns en ganska komplicerad process där bakom som vi teammedlemmar oftast inte kan och förstår så mycket om. Och tyvärr; det finns inga magiska User Stories. Men agila processer beskrivs som om de fanns.
- Nr 2: I alla beskrivningar av agila processer som jag har läst avslutas alltid utvecklingen med att vi lägger över programmet på en produktionsserver, dvs vi driftsätter. Continuous Deployment är ett hett område. Men en driftsättning skapar ju inte någon affärsnytta. Det är bara ett nödvändigt men ej tillräckligt krav. Det vi inte tänker på är att någon faktiskt måste använda funktionen som vi har skapat. Om ingen använder den var vårt arbete till ingen nytta, faktiskt helt meningslöst. Och för att kunna använda en funktion måste en användare t.ex. veta om att den finns och veta hur de ska använda den, inse att de har nytta av den och verkligen ha det. Det är alltså ganska mycket jobb kvar när vi kopierat WAR:en till applikationsservern...
- Varför ser vi inte det här slöseriet? Ett skäl till det, tror jag, är våra mätetal och visualiseringar. Användarna och nyttan finns liksom utanför storytavlan, till vänster - och till höger... Så allt är Scrums fel? Näe, knappast.
- Varför ser vi inte det här slöseriet? Ett skäl till det, tror jag, är våra mätetal och visualiseringar. Användarna och nyttan finns liksom utanför storytavlan, till vänster - och till höger... Så allt är Scrums fel? Näe, knappast.
- I Kanban ser det lika illa ut. Det ska ju täcka in hela processen, men tyvärr! Möjligen får vi in lite fler kolumner på tavlan, till exempel analys, men analys av vad? Och återigen hittar vi produktionssättning till höger. Och det här exemplet är ändå rätt bra, ofta slutar det med Test eller Ready to Ship eller liknande trams. Man verkar ha glömt att i TPS/Lean börjar och slutar allt med kunderna.
- Vi måste alltså förstå våra målgrupper, förstå vad de vill uppnå och koppla dessa saker till vad verksamheten vill få ut. Om vi kan hjälpa användarna att nå rätt mål hjälper vi även hela organisationen. Affärsnytta utvinns först vid användning. Här har vi t.ex. identifierat att om en radiolog kan ställa rätt diagnos snabbare så bidrar det till kortare vårdköer.
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Halvtidssummering: Det påstås att agila metoder är empiriska, men vi missar att vi borde utgå från kunderna: - Vi vet att vi ska maximera feedback, men den viktigaste kommer från användningen. - Vi vet att vi ska maximera ROI, men nyttan uppstår inte förrän någon använder en funktion. - Vi vet att vi ska optimera helheten, men helheten kan väl ändå inte vara "från story till server", utan snarare ungefär "från behov till användning".
- Så hur ska vi komma till rätta med det här? Ännu fler saker att lära sig? Oroa er inte, det behövs inte. Det finns redan specialister på affärsnytta genom användning, som har läst i åratal på högskolan och har lång erfarenhet. De har olika namn. Ibland kallas "UX:are" (User Experience), ibland, det lite kärvare, "användbarhetsnissar". Oavsett namn kan hjälpa oss att designa användarupplevelsen. Och allt vi behöver göra är att ta in dem i värmen. Här är en bild som visar vad användarupplevelse handlar om. Som ni ser är hela basen att tillfredsställa rätt behov hos rätt målgrupp. Det handlar alltså om att designa system för att få ut största möjliga verksamhetsnytta - inte främst "GUI" som somliga tycks tro. Jag är övertygad om att ett tätare samarbete med UX-kollegorna, där vi hjälper dem att förstå agilt tänkande, skulle vara mycket fruktbart.
- Jag tänkte avsluta med att ge mitt förslag på hur en "tilluxad" (om ordvitsen ursäktas), agil arbetsmodell skulle kunna se ut. Jag tänkte utgå ifrån en annan framgångsrik, empirisk arbetsmodell, nämligen den vetenskapliga metoden: 1. Observera verkligheten 2. Dra slutsatser och forma en hypotes 3. Utforma ett experiment 4. Genomför experimentet. Repetera. Det här är ju en empirisk process så det borde ju likna en agil modell för systemutveckling...
- Jag tänkte avsluta med att ge mitt förslag på hur en "tilluxad" (om ordvitsen ursäktas), agil arbetsmodell skulle kunna se ut. Jag tänkte utgå ifrån en annan framgångsrik, empirisk arbetsmodell, nämligen den vetenskapliga metoden: 1. Observera verkligheten 2. Dra slutsatser och forma en hypotes 3. Utforma ett experiment 4. Genomför experimentet. Repetera. Det här är ju en empirisk process så det borde ju likna en agil modell för systemutveckling...
- Jag tänkte avsluta med att ge mitt förslag på hur en "tilluxad" (om ordvitsen ursäktas), agil arbetsmodell skulle kunna se ut. Jag tänkte utgå ifrån en annan framgångsrik, empirisk arbetsmodell, nämligen den vetenskapliga metoden: 1. Observera verkligheten 2. Dra slutsatser och forma en hypotes 3. Utforma ett experiment 4. Genomför experimentet. Repetera. Det här är ju en empirisk process så det borde ju likna en agil modell för systemutveckling...
- Jag tänkte avsluta med att ge mitt förslag på hur en "tilluxad" (om ordvitsen ursäktas), agil arbetsmodell skulle kunna se ut. Jag tänkte utgå ifrån en annan framgångsrik, empirisk arbetsmodell, nämligen den vetenskapliga metoden: 1. Observera verkligheten 2. Dra slutsatser och forma en hypotes 3. Utforma ett experiment 4. Genomför experimentet. Repetera. Det här är ju en empirisk process så det borde ju likna en agil modell för systemutveckling...
- Jag tänkte avsluta med att ge mitt förslag på hur en "tilluxad" (om ordvitsen ursäktas), agil arbetsmodell skulle kunna se ut. Jag tänkte utgå ifrån en annan framgångsrik, empirisk arbetsmodell, nämligen den vetenskapliga metoden: 1. Observera verkligheten 2. Dra slutsatser och forma en hypotes 3. Utforma ett experiment 4. Genomför experimentet. Repetera. Det här är ju en empirisk process så det borde ju likna en agil modell för systemutveckling...
- Fel! Så här ser det typiskt ut idag om vi mappar över detta till systemutveckling. Visst, vi designar experiment i form av nya produktinkrement som vi levererar ut till våra användare. Men resten då? - Att inte utgå från våra kunder, användarna, och deras behov är precis som att designa ett vetenskapligt experiment utan att först observera verkligheten och försöka förstå den. - Att inte gå ut till kunderna och förstå verkningarna av vår programvara är som att inte observera utfallet av experimentet och inte dra några slutsatser. Jag menar alltså att vi fuskar rätt rejält med empirin.
- Låt oss titta på hur det kan se ut om vi verkligen menar det när vi säger att vi har en empirisk process. Jag tänkte att vi kunde följa ett behov genom värdeströmmen. Vi startar hos en prioriterad målgrupp, radiologerna. En radiolog har ett oidentifierat, kanske t.o.m. omedvetet, behov.
- Genom workshops, kontextuella intervjuer och andra verktyg lyckas vi identifiera behovet av att kunna filtrera bilder efter typisk fysisk densitet hos olika organ. Vi noterar det i listan av förslag till produktförbättringar.
- För att något mer ska ske måste behovet prioriteras. Eftersom korrekt diagnos är ett prioriterat användningsmål blir filtreringen uppflyttad. Med nyttobaserad prioriterade mellan mål och målgrupper kan produktledningen systematiskt prioritera mellan olika förbättringsförslag.
- Filtreringen analyseras nu närmare och olika förslag på lösningar utvärderas. Målet är inte en komplett analys. Det viktiga här är att på bättre förstå behovet så att vi framöver löser rätt problem. Här kan tekniker som workshops med pappersprototyper användas. Vi inser här att tre vanliga, förinställda filter räcker.
- Nu vidtar mer tekniskt, praktiskt designarbete, inkl programmering. Det sker på vanligt sätt. Jag har här tydliggjort att vi börjar med en konceptuell design, detaljerar och utvärderar den efteråt. Dessa steg genomlöps givetvis många gånger för varje story.
- Vi bygger och överför lösningen till en testserver. Lösningen beskrivs och demonstreras för produktens intressenter. Radiologerna gillar enkelheten och snabbheten vid filterbytet. Produktledningen fattar beslut om driftsättning.
- Lösningen driftsätts i produktion, till största möjliga del ske med automatik. Filtreringen finns nu tillgänglig för användarna.
- Det sista steget innebär att göra användarna medvetna om att lösningen finns, vad den är tänkt för och hur de bäst kan använda den. Jag anser att utvecklingslaget även bör ansvara för detta. Detta här är ett ofta bortglömt steg och inte speciellt svårt om man jobbar så här.
- Den sista formen, användning av lösning, har nu nåtts. Vi har gått ifrån ett oidentifierat behov, till ett välgrundat förslag på lösning av detsamma. Givetvis måste vi nu uppskatta effektiviteten i vår lösning och ev köra cykeln ett par varv till. Jag tänker mig att ett varv i cykeln tar någon dag upp till en vecka. Sen tar vi nästa behov. Jag menar att det här sättet att arbeta är grymt effektivt. Främsta skälet till det är att cykeln börjar och slutar med användningen. Oavsett hur ni vill designa er process rekommenderar jag er att utgå från det. Jag ser fram emot att höra era erfarenheter i framtiden.