Agil användbarhetsutveckling för handhållna enheter TNM082, VT2015, FÖ3

Transkript

1 Agil användbarhetsutveckling för handhållna enheter TNM082, VT2015, FÖ3 Scrum Fyra ben som Scrum står på Självorganiserande team TvärfunkHonella team Prioriterade akhviteter i en produktbacklogg IteraHv utveckling 1

2 Scrums tre pelare Scrum använder el iterahvt, inkrementellt HllvägagångssäL för al ophmera förutsägbarhet och hantera risk. Scrum vilar på tre pelare: transparens granskning anpassning Scrumguiden. Transparens Alla vikhga aspekter av processen måste vara synliga, transparenta, för dem som ansvarar för resultaten. För al uppnå transparens krävs al dessa delar är definierade i en gemensam standard så al alla som tar del av resultaten får en gemensam förståelse för det man ser. Till exempel: el gemensamt språk måste användas av alla deltagare när man talar om processen; och en gemensam definihon av "klart måste delas av de som uuör arbetet och de som accepterar arbetsresultatet. 2

3 Transparens Artefakter Scrumtavla (tydligt och vikhgt arbetsredsakp!) Backloggar AkHviteter Dagligt scrummöte Visar status! Granskning Användare av Scrum måste o\a granska scrumartefakter samt vägen mot el mål, för al upptäcka oönskade avvikelser. Granskningarna bör inte ske så o\a al de kommer i vägen för arbetet. De är mest givande när de noga och regelbundet uuörs av skickliga granskare i anslutning Hll arbetet. 3

4 Anpassning Om en granskare ser al en eller flera aspekter av en process avviker utanför acceptabla gränser och den resulterande produkten inte kan accepteras, så måste man justera processen eller det material som man arbetar med. En anpassning måste göras så snart som möjligt för al minimera ylerligare avvikelse. Teamets granskning och anpassning? Granskning och anpassning Scrum har fyra formella gransknings- och anpassningshllfällen: Sprintplaneringsmöte Dagligt scrummöte Sprintgranskning/sprintdemonstraHon Sprintåterblick 4

5 Process Produktägaren och teamet bestämmer Hllsammans vad som ska utvecklas. Vilken funkhonalitet som ska in och hur den ska se ut och användas. Baseras på: backlogg Hdigare sprint resultat (inkrement) hashghet teamets kapacitet Vad? Vad är en backlogg och en sprintlogg? En lista med krav och el urval krav Hur beskrivs krav? 5

6 Användarhistoria - User story 6

7 Användarhistoria En användarhistoria är en kort beskrivning i vardagligt språk av vad en användare vill uppnå. Användarhistoria Som <roll> gäst Vill jag <mål/önskan/händelse> göra en reservahon 7

8 Användarhistoria För al kunna jämföra och prioritera nyla mellan olika krav förtydligas en historia med en kort förklaring Hll varför det finns el behov av kravet (sy\e) Som <roll> Vill jag <mål/önskan/händelse> För al <sy\e> Användarhistoria För al kunna jämföra och prioritera nyla mellan olika krav förtydligas en historia med en kort förklaring Hll varför det finns el behov av kravet (sy\e) Som <roll> Vill jag <mål/önskan/händelse> För al <sy\e> Som gäst Vill jag göra en reservahon Så al jag kan bo på hotellet På det viset ser alla (gruppen och produktägaren) inte bara själva kravet utan även orsaken Hll al det är vikhgt 8

9 Användarhistoria En grundidé är al varje historia ska vara kort och få plats på en post- it lapp. Nummer/ID Prioritet EsHmerad Hd/insats, Prioritera krav/användarhistorier Vem gör det enligt Scrums teori? 9

10 Prioritet Börja med det nyhgaste först NyLa kan beskrivas som den funkhonalitet och de krav som slutanvändaren väntar mest på, det vill säga, har mest nyla av. EL första steg kan vara al göra en grov indelning exempelvis från modellen DSM (Dynamic Systems development Model) som fål namnet MoSCoW. Must have (måste ha) Should have (ska ha) Could have (Kan ha) Won t have this Hme (vill inte ha den här etappen/sprinten) Prioritet Tekniken används för al inte behöva höra al allt är vikhgt av produktägaren. Kan bestämma al produktägaren får som mest Hlldela M (måste ha) Hll 50% av kraven S (Ska ha) Hll 25% C (could have) Hll 25% 10

11 Prioritet Prioritering kan användas för al ange relahoner (eller beroenden) mellan krav Exempelvis: Krav 1, 14 och 21 är alla måste ha och leveransen (resultatet) är inte särskilt mycket värd om el av dessa krav inte ingår Tydlighet i prioritering är Hll hjälp inför slutet av en sprint (etapp) om man är tveksam Hll vad som bör göras (vid Hdsbrist exempelvis). Även om krav 20 står näst på tur enligt listan så vet man al 21 hänger ihop med 1 och 14 och måste bli färdig för al det ska vara nyla med sprintens resultat. Användarhistorier Kan innehåller (för) lite informahon och kan då behöva brytas ned i mindre delar. Tillsammans med produktägaren gå igenom bakgrund och sy\e och skapa uppgi\er. Under sprintplanning när Hden uppskalas beskrivs programmeringsuppgi\er etc. som behövs. IdenHfiera hur en användarhistoria ska bekrä\as, hur produktägaren ska validera den. De måste vara testbara. 11

12 Användarhistorier - uppgi\er Användarhistorier - uppgi\er 12

13 Användarhistorier - uppgi\er Gustavsson, T. (2013). Agil Projektledning. Andra säl - Historik Inom RUP (RaHonal Unified Process) finns något som kallas Use cases (användningsfall). Beskriver hur olika typ av funkhonalitet ska användas av olika roller i el it- system. Beskriver en viss sorts användare, viss typ av funkhonalitet, och ordningen för hur funkhonaliteten ska ingå i systemet. KriHk risk för för mycket dokumentahon Hdigt i el projekt Användarhistorier är en läl variant 13

14 Ett use case modellerar ett antal steg, definieras av interaktioner mellan en roll (actor) och ett system med syftet att uppnå ett mål. (Unified Modelling Language - UML) 14

15 Användarhistoria Som besökare vill jag kunna se de senaste twilringarna från företaget direkt på startsidan. Denna funkhon är vikhg e\ersom den gör al jag få all kommunikahon från företaget samlad på en plats och inte missar något. Acceptanskriterier Webbplatsens startsida visar de 3 senaste tweetsen. Tweetsen visas inom 15 minuter från al de twilrades. Om en tweet raderas ska den inte visas på webbplatsen. Länkar i tweetsen ska fungera. Kommentarer Lägg även en "Följ oss på TwiLer"- knapp i anslutning Hll tweetsen. Scrumtavla 15

16 Scrumtavla Kanban Agila metoder kallas ibland för lälvikhga metoder just för al de är mindre föreskrivande än tradihonella metoder. Både Scrum och Kanban är väldigt adaphva, men relahvt sel är Scrum mer föreskrivande än Kanban. Scrum har fler begräsningar och ger därmed mindre utrymme för alternahv. EL exempel är al Scrum föreskriver Hdsbegränsade iterahoner. Det gör inte Kanban. Man jobbar inte i etapper (sprint i Scrum) Istället för uppstart (sprintplanering) lägger produktägaren Hll krav löpande i ej påbörjat kolumnen när de dyker upp. Kniberg & Skarin. Kanban och Scrum: Få det bästa av två världar. 16

17 Kanban En princip i Kanban är al man ska agera snabbt så fort el beslut är falat, varje akhvitet ska sluuöras så snart som möjligt Fokuserar på en mer detaljerad projeklavla (analys, design, utveckling, test etc.) Förhindrar al lappar (användarhistorier/uppgi\er) fastnar i påbörjat- kolumnen Givet maxantal för antal lappar per kolumn (exempelvis 2) Kanban Vanligt al man ändå försöker få Hll fördelarna med etapptänket och använder mycket av det som finns inom Scrum. Regelbundna träffar med produktägaren (1ggr per vecka) för al diskutera krav som lagts Hll VikHgt med regelbundenhet för förtydliganden, HdsuppskaLning etc. Presentera delresultat (varannan vecka) Erfarenhetsmöten (varje vecka) Kniberg & Skarin. Kanban och Scrum: Få det bästa av två världar. 17

18 EsHmat av arbete Es?mat ger en bild av: Hur mycket arbete kan vi uuöra under en viss Hd? Hur mycket har vi uuört? Hur mycket har vi framför oss? Det finns olika säl al eshmera på men storleken på uppgi\en påverkas allhd av: Hur svår den är och Hur omfalande den är Olika enheter Enheter: Story points T- shirt storlekar XS, S, M, L, XL Bananer Tid (Hmmar, dagar) Etc. Hur många ( ) klarar vi av under en sprint? Svårt al uppskala första gången men man måste börja någonstans! 18

19 Planeringspoker (Hd) Teknik för al genomföra HdsuppskaLningar. Teamet gör individuella HdsuppskaLningar under tystnad genom al använda "spelkort" med förangivna siffror. Däre\er diskuterar gruppen de HdsuppskaLningar som är mest avvikande. En iterahv eshmeringsmetod Planeringspoker Tidses?mat Varje deltagare får en kortlek där varje kort har el eshmat Siffrorna representerar det antal Hmmar som deltagaren uppskalar al en akhvitet kommer ta al sluuöra. 1,2,3,5,8,13,21,34,45? Kaffe Långa hopp mellan varje steg alla måste bestämma sig för anhngen det ena eller det andra värdet. Gruppen slipper långa diskussioner kring om 20 eller 22 är räl värde (e\ersom den exakta siffran ändå inte går al förutsäga) Det handlar trots allt om uppskalningar, relahva uppskalningar. 19

20 Planeringspoker Någon läser en användarhistoria och den diskuteras kort Varje deltagare väljer el kort som representerar hans eller hennes eshmat Alla kort vänds sa al eshmaten visas samhdigt Diskutera skillnader (framförallt ylerligheterna, högst och lägst) FortsäL Hlls eshmaten konvergerar Övning Hur lång Hd tar det al skriva el namn för hand på en papperslapp? 20

21 Planeringspoker Första gången 1. IdenHfiera uppgi\er som är Sma (läl) Medium (medel) Stora (svår) 2. Välj ut en medium som alla känner Hll 3. SäL den Hll exempelvis 5 4. Använd som baseline Planeringspoker Varför planeringspoker fungerar Lägger tonvikten på relahva eshmat Håller eshmat inom en storleksordning Allas åsikt får komma Hll tals De som eshmerar måste mohvera sina eshmat Det går fort Det är roligt 21

22 Planeringspoker Färdiga kortlekar Papper Appar J Grupparbete och grupptryck Hur vikhgt är det al allas åsikter får komma Hll tals? Lägger tonvikten på relahva eshmat Håller eshmat inom en storleksordning Allas åsikt får komma Hll tals De som eshmerar måste mohvera sina eshmat Det går fort Det är roligt 22

23 Konformitet Socialpsykologisk term som betecknar al en individ ger e\er för en grupps förväntningar och uppfalningar (Solomon Asch). Auktoriteter Ibland gör vi saker vi normalt inte skulle göra (av samvetsskäl) när vi lyder en auktoritet. 23

24 HasHghet/velocity ED annat verktyg är has?ghet (velocity) HasHghet är el mål på hur mycket teamet får gjort under en iterahon (sprint i Scrum ). HasHghet är vad som fakhskt gjordes under sista iterahonen (summan av avklarade eshmat) inte vad som var planerat. Gör teamet 10 användarhistorier som har 8 Hmmar under en iterahon är teamets hashghet 80 Hmmar. (Beror på enhet man använder frö eshmat) HasHghet är alltså el mål på hur mycket som blev klart i en sprint mappat mot den enhet man uppskalade kraven med. I Scrum kan hashghet mätas i olika enheter och varje användarhistoria har el visst värde (beroende på dess komplexitet). Första veckan ger lite informahon (men är nödvändig för al ge grund för jämförelse). Däre\er blir teamet bälre på al uppskala Hd och därmed bälre på al förutsäga sin hashghet. HasHghet/velocity Innebär maximal hashghet maximal produkhvitet? 24

25 HasHghet/velocity Innebär maximal hashghet maximal produkhvitet? Nej. Försöker man maximera hashgheten kan det innebära det motsala för teamet istället, man kanske med testning och acceptans, samarbete med produktägaren, struntar i al fixa buggar etc. Kan eventuellt ge en kortvarig posihv effekt men o\ast en negahv på längre sikt. Målet är inte maximal hashghet utan snarare ophmal hashghet över Hd, många faktorer är vikhga exempelvis kvaliteten på slutprodukten (varje inkrement). HasHget/ Velocity 25

26 Teamets kapacitet Ni är 9 i gruppen, ni har 2 dagar i labbet a 8h, är er kapacitet 9x2x8=144h? Nej, al planera så fungerar inte! HasHghet, Hllgängliga Hmmar? annat? Teamets kapacitet För al räkna ut en realishsk kapacitet (från totalt Hllgänglig kapacitet) används en fokus faktor. Fokus faktorn representerar teamets förmåga al fokusera på arbetet utan distrakhoner. MulHplicera total kapacitet med en fokusfaktor och du får en rimlig uppskalning av den Hd/förmåga som finns Hllgänglig de effekhva Hmmar som kan förväntas av teamet. Ligger exempelvis runt 0,6 0,8. Ni är 9 i gruppen, ni har 2 dagar i labbet a 8h, fokusfaktor 0.6, er kapacitet blir 9x2x8x0,6=86,4h. Se exempelvis: Henrik Kniberg. Scrum and Xp from the Trenches. 26

27 Arbetsmängd - RäL arbetsmängd är avgörande Fördelar med ad ed team tar på sig räd mängd arbetet är: De kan göra ed starkt åtagande. EL starkt åtagande betyder al teamet tror på och äger sin egen plan. Man har tagit på sig en utmanande mängd arbete, men inte för mycket. Man kan med gol självförtroende säga al man kommer al leverera det man tagit på sig. Arbetsmängd - RäL arbetsmängd är avgörande Man kan leverera med kvalitet. EL team som har för mycket al göra måste hila någon sorts venhl al venhlera genom. Den allra vanligaste venhlen är produktens kvalitet. Man sänker helt enkelt kvalitetsambihonerna. Det funkar på kort sikt, men är fullständigt förödande på lång sikt. EL team som har tagit på sig räl mängd arbete för en Hd, i Scrum en sprint, har tagit på sig den mängd arbete man kan göra med upprälhållande av hög kvalitet. Det betyder al man inte behöver ta genvägar för al nå målet. Vi vet ju alla al ordspråket är sant: genvägar äro senvägar. Mjukvaruutveckling är inget undantag. 27

28 Arbetsmängd - RäL arbetsmängd är avgörande Moralen förblir hög. I vilket team tror du arbetsmoralen är högst? I teamet som har pressats al ta på sig för mycket arbete, kanske med mohvahonen al "stretch goals" är bra för dem, eller i teamet som under tankfull dialog inbördes och med produktägaren vridit och vänt på arbetet som behöver göras för al hila räl mängd för den kommande sprinten? Min satsning blir på teamet som lagt sin egen ribba. Arbetsmängd - RäL arbetsmängd är avgörande Misslyckande betyder något. Tänk dig el team som av någon anledning övertygas om al ta på sig mer arbete än de själva tror al de kommer al klara av. Tänk dig sedan al de träffas i en sprintåterblick för al prata om varför de inte lyckats leverera enligt plan. Vad tror du al de kommer al säga? Självklart kommer man al peka ut den press man utsals för som orsaken Hll al man inte levererat enligt plan. Tänk dig nu el team som själva väljer ut hur mycket arbete man kommer al klara av den närmaste månaden. Tänk dig nu al även dela team misslyckas, och därför i sin sprintåterblick diskuterar dela. Det kommer al vara lälare för dela team al vända Hllbaks samtalet Hll den egna rollen i misslyckandet. Därför kommer de al kunna lära sig från sil misslyckande. 28

29 Arbetsmängd - RäL arbetsmängd är avgörande Den goda hälsan består. Jag arbetade med el team på Arbetsmiljöverket vid el Hllfälle. En morgon när jag väntade i recephonen på al insläppt bläddrade jag i en publikahon från myndigheten. En siffra stack ut i stahshken som presenterades: al det var så många som led av problem orsakade av al man inte hade kontroll över sin egen arbetssituahon. Det är ju inte så konshgt egentligen - självklart är det stressande al förväntas kunna åstadkomma mer än vad som är realishskt. Det gäller oavsel om man utvecklar mjukvara eller inte. Varför tror vi al det är en bra affär för våra företag al försöka pressa ut mer än vad som är möjligt ur varandra? Arbetsmängd - RäL arbetsmängd är avgörande Så för ad summera: Scrum handlar om al lära sig vad man kan åstadkomma genom al själv få möjligheten al pröva sina vingar. Det lärandet kan inte komma Hll stånd om situahonen kompromeleras av el aldrig så välment tryck al göra mer än vad görararen tycker är möjligt. Du kan välja själv: anhngen får du lite, lite, mer just nu, Hll priset av osäkra åtaganden, dålig kvalitet, låg moral, försvarsmekanismer som förhindrar lärande och dålig hälsa - eller så får du mycket mer på långt sikt, plus leveranssäkerhet, hög kvalitet, hög moral, ständigt lärande och hälsa. 29

30 Är Scrum bara en metod för mjukvaruutveckling? Inte alls! Metoden kan anpassas för alla möjliga typer av projekt t.ex. HdningsprodukHon eller utveckling av medicinsk teknik. Scrum har använts framgångsrikt i allt från bokförfalande Hll brädspels- utveckling och semesterplanering. Är Scrum bara en metod för mjukvaruutveckling? Nu programmeras arbetslivet om. (A\onbladet ). Programmerarkulturen revoluhonerar hur vi arbetar. Hur vi organiserar arbetet det är slut på Hden då några få tänker och resten uuör. belöningar fungerar mycket dåligt för al driva på människor. gemenskap ger däremot resultat. arbeta i mindre team i el rimligt men utmanande tempo med stor variahon, korta feedbackloopar och med inbyggt lärande 30

31 Den scrummande konsulten AL agile spril sig som en löpeld de senaste åren måste ha varit svårt al missa för alla i branschen. Men nu börjar agile sprida sig utanför själva projekten in i andra delar av organisahoner. Hur skulle t.ex. en agil HR (personalavdelning) fungera och arbeta? Hur skulle el företag fungera utan chefer och struktur? Det finns en hel del spännande läsning al ta del av på nätet Utan chefer och struktur handbok för nyanställda 31

32 Varför agil utveckling passar människor Människor är vanedjur - vi gillar ad känna igen 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 Hlls vi har el röl test, sen kod Hlls testet blir grönt, sen test igen och så fortsäler cirkeln runt runt. Vi ställer oss i el dagligt scrummöte varje morgon, samma Hd. För al få feedback och hjälpa varandra. Vi gör dela varje dag, så al det blir en vana. Vi börjar varje sprint med sprintplanering, vi avslutar med demonstrahon och återblick. RuHner. Vanor. Varför agil utveckling passar människor Människor är lata Jag vet al iaf jag är lat. Därför passar Hmeboxing mig väldigt bra. En sprint, ju kortare den är desto bälre, tvingar mig al vara effekhv Hdigare. Jag vet al jag kommer al behöva visa al jag har gjort något redan om två veckor. Jag vet i ärlighetens namn al jag måste redogöra redan imorgon, på det dagliga scrummötet, varför jag inte är klar. Scrum mohverar mig al motarbeta min lata natur. Jag tror inte jag är ensam om al påverkas av det här. 32

33 Varför agil utveckling passar människor Människor är sociala Människor fungerar bäst i grupp. Det är ingen som motsäger al vi är flockdjur och jag tror al vi funkar bäst på det sälet. Det är därför vi säler ihop team och låter teamen vara stabila. På det sälet kan vi lära oss av varandra, både genom al 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 EL av mina favoritcitat, jag vet inte varhfrån det kommer dock, är Programmers are like puppies, just not as mature.. Enbart denna punkt är egentligen nog för mig för al jag ska förespråka scrum och andra agila metoder. Vi har så många feedbackloopar där man kan känna al man har bidragit och gjort något. AllHfrån al få skrynkla ihop en lapp som är klar, Hll al få dema en färdig user story är belöningar. AL få se el test gå ifrån röl Hll grönt är en belöning. Jag tror al om vi skulle analysera hjärnakhviteten hos en programmerare som jobbar testdrivet skulle vi se seratonin- utsöndringar varje gång alla tester visar grönt, det är en enorm Hllfredsställelse. AL få flyla den sista post it- lappen Hll done; det är en enormt skön känsla av seger. Man vinner nånhng och man har gjort det som el lag. 33

34 Varför agil utveckling passar människor Agila metoder är mänskliga Allt dela sammantaget tycker jag visar på al agila metoder är framtaget med människan i fokus. Det är inte en process som ser Hll produkten först och främst utan Hll människorna som ska producera den. Som kollar på hur får vi människor al producera effekhvt och må bra. Agilt är mänskligt! 34