Idag. Lean. Att känna till den bakgrunden är en nyckel till att förstå de agila principerna. Lean

Transkript

1 Agil användbarhetsutveckling för handhållnaenheter, FÖ5 (6) Idag Information om Combitech Agila metoder Användbarhet/användarcentrerat arbete Bakgrund De agila metoderna har utvecklats som en motreaktion till traditionell utveckling, projektledning etc. och med värderingar i Leansom inspiration och förebild. Att känna till den bakgrunden är en nyckel till att förstå de agila principerna Lean Arbetssättet kallas i Japan Toyota productionsystems (TPS) och har i resten av världen fått namnet Lean (efter engelskans smärt, slimmad, fettsnål). Efter andra världskriget tvingades Toyota (och många andra japanska företag) att hitta effektiva och billiga lösningar för att konkurrera med resten av världen. Lösningar som kostade så lite som möjligt Få ut så mycket som möjligt från varje liten arbetsgrupp (snarare än att koordinera mängder av männsikor) Tomas Gustavsson (). Agil projektledning. Lean Agila metoder har hämtat mycket inspiration från den japanska bilindustrin, dess värderingar och tekniker och inte minst deras metoder för att få ut så mycket som möjligt med små resurser. Det räcker inte bara med att uppnå flexibilitet (som de agila metoderna skapades för) det behövs även effektivitet och det är styrkan i de metoder som kallas Lean. Lean Att arbeta enligt Lean innebär att anamma ett antal värderingar. De som överför Lean till mjukvaruindustrin (Mary och Tom Poppendieck) har valt ut de viktigaste och de ger en god summering av vad Lean innebär: Eliminera slöseri Fokus på lärande Skjut på åtagande Leverera snabbt Respektera människor Optimera helheten 1

2 Kanban Kanban är en japansk term för "skylt" eller "tavla" som anger "tillgänglig kapacitet (för arbetet)". Kanbanär ett sätt att signalera eller synliggöra materialbehov i industriproduktion. Kanban är ett begrepp i inom just- in- time (JIT) produktion, där den används som ett schemaläggningssystem för att tala om vad som ska produceras, när man ska producera den, och hur mycket som ska produceras. Har använts inom Lean produktion sedan länge och inom mjukvaruindustrin sedan början av talet. Kanban Visualisera arbetsflödet dela upp arbetet, skriv varje enhet på ett kort och placera på tavla använd namngivna kolumner för att illustrera var varje enhet befinner sig i arbetsflödet Begränsa WIP (work in progress) sätt gränser till hur många uppgifter som kan påbörjas i varje del av flödet Mäta lead time led tid tid att färdigställa en uppgift optimera processen för att göra tiden så liten och förutsägbar som möjligt Scrum vs Kanban Båda är adaptiva Scrum är mer föreskrivande, har mer begränsningar och därmed färre öppna möjligheter. Aktiviteter, arftefakter, roller, regler. En scrumtavla ser ut (ungefär) så här under olika stadier av en sprint. När sprinten är slut rensas tavlan - alla lappar etc. tas bort. Scrum föreskriver tidsbestämda iterationer, Kanbangör det inte. I Kanban kan man välja när man vill planera, göra förbättringar och släppa fungerande prgramvara. Aktiviteterna kan göras regelbundet (demo varje måndag) eller vid behov (demo när vi har något meningsfullt att visa/släppa). I Kanban är tavlan normalt sett beständig, man rensar den inte för att sedan börja om på nytt. Scrum vs. Kanban Scrum föreskriver 3 roller, Kanban inga roller alls. Det innebär dock inte att du inte bör ha några roller, bara att du inte måsta ha det. Scrum begränsar WIP per iteration/unit of time, Kanbanper tillstånd i arbetsflödet. 2

3 Scrum vs. Kanban I Scrum ska en uppgift få plats (kunna slutföras) inom en viss tid (en sprint) i Kanbankan den sträcka sig över en längre tid. Alla kolumner bör ha en begränsning Scrum vs. Kanban I Scrum ändrar man inte i pågående sprint, i Kanbanär det ok så länge det finns plats i en kolumn. Vill man lägga til något (exemeplvis en användarhistoria i Scrum) läggs den i produktloggen och tas med i nästa sprint. I Kanban kan den sättas direkt i To do om plats finns, eller om något tas bort. I Scrum får produktägaren inte röra tavlan, i Kanban bestämmer man hur man vill göra. Extrem programmering (XP) Scrum och Kanban fokuserar på hantering, organisation, medan XP fokuserar främst på tillämpning av programmering, tekniska mekanismer (förbättra kodens kvalitét, misnka fel och brister i koden). Kombinationen är bra! Extrem programmering (XP) XP (Kent Beck m. fl) är en iterativ lättviktsmetod för projektteam som utvecklar programvara som antingen är vagt specificerad eller där förutsättningarna kan ändras utan förvarning. Extrem programmering XP tar det sunda förnuftet och drar det till sin spets. XP lovar två saker: Att programmerarna varje dag ska få hålla på med något meningsfullt, slippa bemöta otäcka situatuoner ensamma och att de får ta besluten de kan ta bäst själva. Att kund och ledning får ut mesta möjliga värde ur varje programmeringsvecka. Att de får se resultat under utvecklingens gång och att de ska kunna ändra projektets riktning när det behövs. 3

4 Extrem programmering (XP) XP baseras på fem värderingar: kommunikation, enkelhet, återkoppling, mod och respekt. Det är viktigt att ha en kund på plats så att kontinuerlig kommunikation mellan utvecklarna och kunden är möjlig. Kunden som är på plats har möjlighet att bestämma vadsom ska uppfyllas av systemet (krav på systemet) och i vilken ordning dessa ska prioriteras (så att de viktigaste kraven hanteras först). Enkelhet fås genom kontinuerlig omstrukturereing (refaktorering) samt att skapa minimalt med dokument och annat som inte är kod eller en del av det slutgiltiga systemet. Extrem programmering (XP) Kontinuerliga enhetstester och många delleveranser av systemet ger god återkoppling. Kommunikation är viktigt för återkopplingen då kunden på plats löpande gersynpunkter (återkoppling) på systemet. När något inte ärspeciellt populärt, men ändå mest rätt att göra krävs det mod. Det innebär egentligen att alla inblandade projektmedlemmar ska vara ärliga med vad de kan och inte kan göra. Respekt innebär bland annat att visa respekt för medarbetare såväl som sig själv. Man skall visa respekt för andra medarbetares kod och inte göra ändringar om man inte genomfört goda tester. Extreme programming (XP) Fyra basaktiviteter XP 12 tillämpningar/sedvänjor (som stöttar de 5 värderingarna) Planeringsspelet - Funktionalitet i nästa leverans bestäms genom prioriterade verksamhetsberättelser och tekniska bedömningar. Små leveranser - Systemet levereras i små inkrementella versioner. Metafor - En enkel beskrivning av hur systemet ska fungera. Enkel design - Genom att hålla koden enkel blir ävendesignen enkel. Ta bort komplexitet från koden kontinuerligt när den upptäcks. Testning Tester skrivs innan koden utvecklas. Programmerare skriver tester som testar och validerar koden, acceptanstest med kund. Omstrukturering av kod - Ta kontinuerligt bort identiska (dubbletter) och komplexa kodbitar. XP 12 tillämpningar/sedvänjor (som stöttar de 5 värderingarna) Parprogrammering - Programmerare arbetar i par vid en dator. En skriver koden medan den andre granskar koden. Gemensamt ägarskap - Alla har rätt att ändra i all kod, skriven av dem själva eller någon annan. Kontinuerlig integration - När en implementationsuppg ift är utförd byggs systemet och integereras med den redan färdiga koden. Detta kan ske flera gånger per dag. 40- timmars arbetsvecka - Programmerare tänker och därmed arbetar bättre utvilade och team- motivation är viktigt. Kund på plats - Kunden arbetar med utvecklarna på heltid för att kunna svara på frågor, definiera systemet och skriva tester. Kodstandard - Konsekvent kodstandard som alla programmerare följer. Roller i XP Projektledare (koordinerar kommunikation inom gruppen och mot utsidan, bokar möten, ser till att de sker och dokumenterar) tar med sig information tilbaka, passar vidare till spåraren, berättar inte för folk vad de ska göra, när det ska vara färdigt eller kollar hur det går) Kund (skriver verksamhetsberättelser- användarhist orier, prioriterar etc.) Användare (hjälper till att skriva och välja ut användarhistorier, har domänkunskapen under projektet) Interaktionsdesigner (bestämmer den övergripande metaforen, skriver användarhistorier, utvärderar, framhäver användares åsikter, agerar brygga mellan programmerare och verklighet med hjälp av personas och mål). 4

5 Roller i XP Programmerare (bedömer uppgifter, hur lång tid de kommer ta, implementerar uppgifter och enhetstester) Arkitekt (letar efter och fixar stora omfaktoriseringar, skriver systemtest, ansvarar för teststrategier, implementerar uppgifter) Testare (implementerar oc h kör funktionstest, illustrerar resultat i grafer, ser till att alla är medvetna om resultat) Spårare (går runt och frågar alla hur det går, tar tag i sådant som v erk ar spåra ur, ordnar möten, frågar andra om hjälp etc.) Tränare (ser allting, ser till att projektet håller sig extremt, hjälper till med vad som helst) Motton Det finns några slagord eller motton som XP- utvecklare arbetar efter: Gör det så enkelt som möjligt - Funktioner bör implementeras på det sätt som är enklast möjligt. Koden ska fungera som den ska punkt. Mottot "en och endast en gång" bör följas då koden hålls enkel. En och endast en gång - Information om hur en del av mjukvaran fungerar bör endast finnas på ett ställe. Dubbletter av kod bör refaktoriseras direkt. Du kommer inte att behöva det - Utveckla endast det som behövs för tillfället, med andra ord utveckla inte för framtiden utan endast föridag. Att läsa Användbarhet och UX Hur gör man? Användarcentrerat arbete Viktiga faktorer som påverkar utveckling/design: Kunskap om användningssituationen Kunskap om användarna Gränssnitt Kunskap om människa-dator interaktion (MDI), kognitiv psykologi och design Kunskap om tekniska förutsättningar 5

6 Användarcentrerat arbete Analys Användare, behov, uppgifter, mål Målgrupp Typiska användare (otypiska användare) Behov/krav/uppgifter Definiera Kartlägg Personas Scenarios Användarhistorier Personas Mall för personas En persona är imaginär bild av en användarroll. Personas kanhjälpa alla i projektet att förstå behov och användarmål. Vad vill just den här personan göra här? De är en bra hjälp när man prioriterar funktioner och innehåll. Om den föreslagna funktionen inte är användbar förnågon avproduktens personas så bör den troligtvis inte utvecklas. En persona bör beskrivas tillräckligt väl så att alla i teamet känner att de vet det mesta om den personen/kan föreställa sig den. Skapa personas krävermer än att bara ger ett namn till en användarroll. Ofta använder man också ett foto. -material-och-guider/mall-for-att-skapa-personas Scenarier Ett scenario är en beskrivning av en människas interaktion med ett system. När och hur ska man använda scenarier? Scenarier är lämpliga för att beskriva systeminteraktion ur en användares perspektiv. Scenarier hjälper till att fokusera designen på användarens krav, vilka skiljer sig från tekniska eller affärsmässiga krav. De är särskilt användbara när man behöver ta bort fokus från tekniken, i syfte att öppna upp designmöjligheter, eller när du behöver se till att tekniska eller budgetmässiga begränsningar inte åsidosätter aspekter av användbarhet utan särskild hänsyn. Använd scenarier under design för attsäkerställa att alla deltagare förstår och samtycker till den, samt för attspecificera exakt vilken interaktionen systemet måste stödja. Översätt (och bryt ned) scenarier i uppgifter för att utveckla, genomföra inspektioner, acceptanstester och användartester. Scenarier Hurskriver man ett scenario? För att skriva ett scenario, behöver du en grundläggande förståelse för de uppgifter som ska stödjas av systemet. Du måste också ha en förståelse för användarna och användningssammanhanget. Scenarier kan härledas från data som samlats in under genom olika undersökande datainsamlingsaktiviteter. Om du inte har tillgång till sådana uppgifter, kan du skriva scenarier baserade på förkuns kaper eller din " bästa gissning, föruts att att scenarierna kommer att bli föremål för granskning av användare innan de används som grund för att fatta designbeslut. Ett scenario beskriver på ett enkelt språk den interaktion som behöver ske. Det är viktigt att undvika hänvisningar till teknik, förutom där teknik utgör en designbegränsning som skall bekräftas. Ett scenario innehåller hänvisningar till alla aspekter som är relevanta för interaktionen, även om de befinner sig utanför den nuvarande omfattningen av tekniken. Sådana hänvisningar kanomfatta kulturella och attitydmässiga frågor. Exempelvis kan det faktum att Anna ständigt avbryts av telefonsamtal vara lika relevant som vilken mjukvaruplattfor m hon använder. När du har skrivit ett scenario, granska det och ta bort eventuella referenser till system eller tekniker som inte har saklig grund. Till exempel, uttalandet " kunden identifierar sig " är lämpligt, medan " kunden knappar in sin 4 - siffriga PIN- kod " är det inte ( om inte PIN- koden är ett icke förhandlings bart krav på systemet). Du bör också låta användare granska ett scenario för att säkerställa att det är representativt för den verkliga världen. 6

7 Prototyping Varför prototypa? Ett hjälpmedel att kommunicera kring i utvecklingsteamet Ett sätt att själv testa idéer De ger ett stöd för reflektion Intressenter kan se, hålla i (?), interagera med något/prototypen större förståelse Ett redskap för utvärdering Prototyper besvarar frågor, och ger stödi valet mellan förslag Är den här idén möjlig? Går den att förstå? Går den att producera för den tänkta plattformen? Design Prototyping Avgöra kvalitet Prova funktionalitet Besluta om krav/behov Hitta svagheter Testa prestanda och utseende Prova sekvenser Grafisk kommunikation Finna problem/svårigheter tidigt Design Vad man man designa/prototypa med? Pappersprototyper ok eller larvigt? Snygga system är förföriska? Klara system hämmar användaren? Klara system är dyra att förändra? Utvärdering Vad vill man veta med utvärderingen? Förstå användare och användning Uppfyller designen användarnas behov? Jämföra designförslag Medel att nå ett uppsatt mål Kontrollera att standarderföljs Fördelar med papper: Snabbt, annat slukar tid Ser inte klart ut Rätt fokus, ingen klagar på detaljer Lätt att ändra Mer dynamiskt än många tror Utvärdering (och för analys/förståelse!) Intervju, enkät, fokusgrupper, tänka högt, observation Experiment (kontrollerade mätningar) Expertgranskning/inspektion/kritisk analys Användbarhetsmål - allmänt Effektiv attanvända (gerönskad effekt) Har god nytta Lätt att lära Lätt att komma ihåg Säker att använda Tillfredsställande att använda Tydliga och mätbara definitioner! 7

8 Användbarhetsmål Erhåll krav frånanvändare/beställare Generalisera dem Skapa användbarhetsmål- (kriterierföracceptans/godkännande) Något mätbart/testbart Kvalitativa användbarhetsmål Kallas iblandbrukskvalitéerdå de ärviktiga förbruketav systemet Kvantitativa mätbara mål Kallas ibland användbarhetsmått Ta reda på hur dessa kanoch bör mätas Detärenbartfantasinsom sättergränser Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rätt. Användbarhet ny (?) Användbarhet ny (?) Context of use Energy capabilities Connectivity Processing capabilities Data input/output methods Screen size Screen resolution igning-for-mobile-part-1-information-architecture/ Användbarhet Användbarhet handlar (inte bara) om hur lätt en produkt eller ett system är att använda. Den internationella standarden, ISO gerriktlinjerför användbarhetoch definierar det som: "Den grad i vilken användare i ett givet sammanhang kan bruka en produkt för att uppnå specifika mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt." Användbarhet Användbarhet handlar följaktligen om: Ändamålsenlighet - kan användarna uppnå det de behöver genom att använda produkten? Effektivitet - vilken är resursåtgången (t.ex. i tid, kognitiv belastning)? Tillfredsställe lse - vadtycker de om sin interaktion med produkten? Och dessa faktorer påverkas alltidav: Användarna - vilka använder produkten? t.ex. är de erfarna användare eller nybörjare? Deras mål - vad försöker användarna göra med produkten - stödjer den vad användarna vill göra? Användningssituationen (eller 'sammanhanget') - varoch hur används produkten? 8

9 Användbarhet När man designar för en telefon/platta måste man tänka på att, och hur dessa, ska hållas i handen, det handlar inte bara om vad som visas på skärmen. Lärbarhet. Hur lätt är det att lära s ig anv ända något, att utföra en uppgift förs ta gången? Effektivitet. Hur effektiv är det att använda när man väl lärt sig hur? Fel. Hur v anligt är det att man gör fel oc h hur är det att återhämta s ig från dessa? Minnesbarhet. Hur enkelt det är att komma ihåg hur man använder något efter ett uppehåll i användningen Tillfredsställelse. Hur trev ligt är det att anv ända? (Jacob Nielsen, En människas fingertopp är ca 16-20mm. (När vi använder en touchskärm är det som att navigera med en prinskorvj ). Kontroll för att ändra layout är för liten för att man ska kunna trycka på den/träffa den med säkerhet. Tänk på: Storlek (1x1cm rekommenderas, oftast mindre i standarder för olika plattformar ) Mellanrum TESTA Knapparna är tillräckligt stora men det är för litet mellanrum mellan dela och edit. Undvik att det här händer! Knappar med bra storlek och bra mellanrum. Hur vi når information på en skärm Hur vi når information på en skärm Placera sådant som används ofta längst ned (överst i Android för att undvika att man trycker på fysiska knappar istället). Placera sådant som är viktigt/intressant/som ska ske just nu där det är lätt att nå, och gör kontrollerna stora. Placera saker som inte görs så ofta på ställen som är svårare att nå. Gör medvetet vissa saker svåra att göra. Tex sådant som ändrar information, tar bort information etc. Tänk på var du placerar information/navigering. Ska vara lätt att se och nå, synas tydligt och inte döljas av fingrar. Heller inte vara jobbigt att använda. Tänk på att det vi når lätt kanske vi inte ser lätt! Placera knappar som inte används ofta/som ger allvarliga fel på ställen som är svåra att nå. 9

10 Riktlinjer Är Scrum baraen metod för mjukvaruutveckling? Inte alls! Metoden kan anpassas för alla möjliga typer av projekt och Scrum har använtsframgångsrikt i allt från tidningsproduktion, bokförfattande till brädspels- utveckling och semesterplanering. Är Scrum baraen metod för mjukvaruutveckling? Nu programmeras arbetslivetom. (Aftonbladet ). Programmerarkulturen revolutionerar hur vi arbetar. Hur vi organiserar arbetet det är slut på tiden då några få tänker och resten utför. belöningar fungerar mycketdåligt för attdriva på människor. gemenskap ger däremot resultat. arbeta i mindre team i ett rimligt men utmanande tempo med stor variation, korta feedbackloopar och med inbyggt lärande Den scrummande konsulten Att agile spritt sig som en löpeld de senaste åren måste ha varit svårt att missa för alla i branschen. Men nu börjar agile sprida sig utanför själva projekten in i andra delar av organisationer. Hur skulle t.ex. en agil HR (personalavdelning) fungera och arbeta? Hur skulle ett företag fungera utan chefer och struktur? Det finns en hel del spännande läsning att ta del av på nätet (en blogg om vad HR kan lära av Agile och Lean) Utan chefer och struktur handbok för nyanställda Varför agil utveckling passar människor Människor är vanedjur - vi gillar att kännaigen oss i det vi gör Scrum och agile utveckling förespråkar många loopar. Från den minsta, i testdriven utveckling, där vi skriver test tills vi har ett rött test, sen kod tills testet blir grönt, sen test igen och så fortsätter cirkeln runt runt. Vi ställer oss i ett dagligt scrummötevarje morgon, samma tid. För att få feedback och hjälpa varandra. Vi gör detta varje dag, så att det blir en vana. Vi börjar varje sprint med sprintplanering, vi avslutar med demonstration och återblick. Rutiner. Vanor. 10

11 Varför agil utveckling passar människor Människor är lata Jag vet att i alla fall att jag är lat. Därför passar timeboxing mig väldigt bra. En sprint, ju kortare den är desto bättre, tvingar mig att vara effektiv tidigare. Jag vet att jag kommer att behöva visa att jag har gjort något redan om två veckor. Jag vet i ärlighetens namn att jag måste redogöra redan imorgon, på det dagliga scrummötet, varför jag inte är klar. Scrum motiverar mig att motarbeta min lata natur. Jag tror inte jag är ensam om att påverkas av det här. Varför agil utveckling passar människor Människor är sociala Människor fungerar bäst i grupp. Det är ingen som motsäger att vi är flockdjur och jag tror att vi funkar bäst på det sättet. Det är därför vi sätter ihop team och låter teamen vara stabila. På det sättet kan vi lära oss av varandra, både genom att man kan ställa frågor vid t.ex. de dagliga scrummötena och även genom parprogramming. Varför agil utveckling passar människor Människor gillar belöningar Ett av mina favoritcitat, jag vet inte vartifråndet kommer dock, är Programmers are like puppies, just not as mature.. Enbart denna punkt är egentligen nog för mig för att jag ska förespråka scrum och andra agila metoder. Vi har så många feedbackloopar där man kan känna att man har bidragit och gjort något. Alltifrån att få skrynkla ihop en lapp som är klar, till att få dema en färdig user story är belöningar. Att få se ett test gå från rött till grönt är en belöning. Jag tror att om vi skulle analysera hjärnaktiviteten hos en programmerare som jobbar testdrivet skulle vi se seratonin- utsöndringar varje gång alla tester visar grönt, det är en enorm tillfredsställelse. Att få flytta den sista post it- lappen till done; det är en enormt skön känsla av seger. Man vinner nånting och man har gjort det som ett lag. Varför agil utveckling passar människor Agila metoder är mänskliga Allt detta sammantaget tycker jag visar på att agila metoder är framtaget med människan i fokus. Det är inte en process som ser till produkten först och främst utan till människorna som ska producera den. Som kollar på hur får vi människor att producera effektivt och må bra. Agilt är mänskligt! Att läsa mer att kolla Sök på Henrik Kniberg och Kanban för exempelvis: Kanban vs. Scrum Kanban and Scrum making the most of both Tack! Vi ses på torsdagens workshop