Agil användbarhetsutveckling för handhållna enheter TNM082, VT2013, FÖ3 Idag Scrum Från backlogg Gll sprint backlogg i detalj Scrum Produkt backlog Krav/önskemål representeras som punkter i en produkt backlogg Produkten växer fram (designas, kodas och testas) i sprintar Varje sprint föregås av ep sprintplaneringsmöte Utvecklingen i varje sprint styrs av en sprint backlogg Detta är produkt backloggen Krav Listar allt önskad arbete i projektet Helst utryckt så ap varje punkt har ep värde för produktens användare eller kunder Anger ep esgmat av arbetet Prioriteras av produktägaren Prioriteringar ses över inför varje ny sprint Produkt backlog exempel Backlog punkt Estimat Låta en gäst göra en reservation 3 Som gäst vill jag kunna avboka en reservation. 5 Som gäst vill jag kunna ändra datum på en reservation. 3 Som hotelpersonal vill jag kunna köra en RevPAR rapport (revenueper-available-room) 8 Förbättra felhantering 8... 30... 50 Prioritering Produktägaren och teamet bestämmer Gllsammans vad som ska utvecklas. Vilken funkgonalitet som ska in och hur den ska se ut och användas. Baseras på: backlogg Gdigare sprint resultat (inkrement) hasgghet teamets kapacitet 1
Resultat av mötet: sprintmål Sprintmål En kort beskrivning av huvudfokus för sprinten vad som ska levereras Kan vara kvalitagva mål också Databas Application Se till att applikationen kan köra även på SQL Server (utöver Oracle) Bioteknik Kunna genomföra populationsgenetiska studier Gruppen Förbättra våra dagliga scrummöten Sprint backlog exempel Resultat av mötet: sprintmål sprintbacklogg med krav (user stories) och associerade uppgizer där finns alla detaljer Sprinplaneringsmöte Teamkapacitet Produkt backlog Marknadsläget Aktuell produkt Sprintprioritering Analysera och utvärdera produkt backlog Välj sprint mål Bestäm hur sprintmålet ska uppnås (design) Skapa sprint backlog med uppgifter från produkt backlog punkter(user stories / funktioner. Estimera sprint backlog i timmar Sprint Mål (klart) Sprint backlog Resultat av mötet: sprintmål sprintbacklogg med user stories (krav) och associerade uppgizer där finns alla detaljer TradiGonellt är det här en projektledare kliver fram och säger vem som ska göra vad. I scrum bestämmer teamet det själva Det är bara teamet som kan bestämma vad de kan göra (nästa gång)!! Eventuell förhandling med produktägaren antalet esgmerade Gmmar vs. kapacitet, prioritet 2
Klart/done I Scrum är en funkgon klar när: FunkGonen fungerar som den ska för användaren, som därför kan använda den nya funkgonaliteten för ap uppnå sina mål och lösa sina problem. FunkGonen är testad så ap det går ap göra ep tryggt upalande om produktkvaliteten. Buggar som hipats under testningen har fixats inom ramen för sprinten ( what happens in the sprint stays in the sprint ). FunkGonen är implementerad i välskriven kod som går ap jobba vidare med. Det enda säpet ap uppnå Scrums krävande klardefinigon sprint ezer sprint är ap bryta ned arbetet i små fristående delar, och utveckla delarna en i taget. En user story är en kort beskrivning i vardagligt språk av vad en användare vill göra och uppnå. Som användare Vill jag logga in Så ap jag kan använda det här systemet As a role I want something So that I get a benefit Som <roll> vill jag <mål/önskan/händelse> för ap <syze> Huvudsaklig metod för ap beskriva krav är ep snabbt sä( a( hantera kravställning utan ap behöva skapa formella kravspecifikagoner och administragvt arbete för ap hålla dessa uppdaterade. User Stories, diskussionerna kring dessa samt acceptanskriterierna blir det som ersäper designspecen (som används i mycket annan utveckling). Huvudsaklig metod för ap beskriva krav Produktägaren skriver alla user stories Den personen är bäst lämpad för ap känna Gll önskad funkgonalitet Den personen är bäst lämpad för ap skriva på verksamhetens språk gör det möjligt för denne ap prioritera stories utezer deras värde och kostnader för verksamheten gör det möjligt ap välja stories inför varje iteragon/sprint Teamet kan hjälpa produktägaren men ansvaret för ap skriva user stories måste ligga hos denne. kan också skrivas av utvecklare för ap beskriva icke- funkgonella krav (säkerhet, prestanda, etc.). kan komplepreras med flödesdiagram och UML etc. 3
En user story har flera sy6en: Beskriva en användares behov Bidrar Gll beskrivningen av produkten Är ep planeringsunderlag Underlag för diskussioner En grundidé är ap varje story ska vara kort och få plats på en post- it lapp. Den kan användas för a( beskriva: En funkgonalitet En egenskap på systemet Buggfixar Prioritet - en backlogg är organiserad i termer av priorite EsGmerad Gd/insats indikagon på hur mycket som krävs för ap uiöra en user story ID unikt för varje user story. SyZet är ap det ska gå ap spåra varje user story, koppla ihop den med olika test. För ap en produkt backlogg inte ska bli för detaljerad tänker och skriver man oza user stories på Epicnivå (Epic = stor user story) är oza stora och innehåller lite informagon så de behöver brytas ned i mindre delar. Tillsammans med produktägaren gå igenom bakgrund och syze och skapa uppgizer. Under sprintplanering när Gden uppskapas beskrivs programmeringsuppgizer, design etc. som behövs. IdenGfiera hur en user story ska bekräzas, hur produktägaren ska godkänna en user story. De måste vara testbara. Teamet väljer punkter från produkt backlog som de anser sig kunna hinna klart i en sprint Sprint backlog skapas UppgiZer idengfieras och varje uppgiz esgmeras (1 16 Gmmar) Görs gemensamt i teamet För ap en produkt backlogg inte ska bli för detaljerad tänker och skriver man oza user stories på Epicnivå (Epic = stor user story) är oza stora och innehåller lite informagon så de behöver brytas ned i mindre delar. Tillsammans med produktägaren gå igenom bakgrund och syze och skapa uppgizer. Som semester-planerare vill jag kunna se foton från hotellen. Koda (8 hours) Designa (4) Skriv test (4) Koda (6) Uppdatera prestandatester (4) Under sprintplanering när Gden uppskapas beskrivs programmeringsuppgizer, design etc. som behövs. IdenGfiera hur en user story ska bekräzas, hur produktägaren ska godkänna en user story. De måste vara testbara. 4
Acceptanskriterier Innan en user story implementeras ska acceptanskriterier skrivas för ap se Gll ap målen med en user story uppfylls. Acceptanskriterier är de krav som måste uppfyllas för ap en user story ska bedömas som fullständig. Acceptanskriterier är oerhört vikgga i Scrum ezersom det är dessa som preciserar vad en produktägare förväntar sig och vad teamet behöver uiöra/fullfölja. User story Som besökare vill jag kunna se de senaste twipringarna från företaget direkt på startsidan. Denna funkgon är vikgg ezersom den gör ap jag få all kommunikagon 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 ap de twiprades. 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å TwiPer"- knapp i anslutning Gll tweetsen Storlek och Gd Alla user stories esgmeras/uppskapas, man bestämmer hur stora de är, hur lång Gd de kommer ap ta ap uiöra Först i produkt backloggen för ap esgmera ep helt projekt Teknik för ap genomföra esgmeringar av arbete (Gmmar, dagar, storypoints) Teamet gör individuella esgmeringar under tystnad genom ap använda "spelkort" med förangivna siffror. DäreZer diskuterar gruppen de esgmeringar som är mest avvikande. Och därezer i sprint backloggen för ap esgmera en delleverans/sprint/inkrement Mike Cohn (2005). Agile Estimating and Planning Så här spelas planeringspoker Varje teammedlem får en uppsäpning med kort. På korten står siffror som motsvarar hur lång Gd utvecklingen kommer ap ta. Vanliga valörer är 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 poäng och vet ej. En mötesmoderator väljer ut ep krav/en User Story ap esgmera Den som bäst känner Gll det som ska esgmeras beskriver det Teamet diskuterar och ställer frågor för ap få en bäpre förståelse Varje teammedlem gör ep eget esgmat genom ap välja ep kort utan ap visa för de andra. Varje deltagare gör esgmatet genom ap välja det kort ur sin kortlek som bäst stämmer in på den esgmerade Gden. Alla visar sina kort samgdigt. Om esgmaten är signifikant olika, mogvierar de som lagt det högsta och lägsta esgmatet sina val EZer ap noteringar gjorts som kan vara av värde för den kommande utvecklingsarbetet så gör deltagarna en ny GdsuppskaPning med hjälp av korten. I de flesta fall blir de mycket mer enade denna andra gång. Om depa inte inträffar, upprepas processen yperligare gånger Glls dess ap esgmaten konvergerar. Det är inte nödvändigt ap hela gruppen har samma siffra på korten ezersom målet är en kvalificerad bedömning snarare än en exakt precision. Kortlek har siffrorna 0,1,2,3,5,8,13,20,40 och 100. Anledningen Gll ap det är så många små tal och så få höga tal är ap akgviteter ska vara relagvt små (ta ca 1-2 dagar ap genomföra). Ju större en akgvitet beräknas vara desto större osäkerhet innebär det. Har man många akgviteter på 20, 40 eller Gll och med 100 poäng bör man istället bryta ner dem Gll mindre akgviteter. Vad betyder då poängen? Är det Gmmar, dagar? Story points (storlekspoäng) Godtyckligt värde som mäter/anger hur stor/svår en user story är. (Komplexitet, okänd etc.). Representerar en ideal dag utan störningar Kan inte direkt relateras Gll Gmmar, behövs en referensuppgiz för varje team för ap avgöra vad som är 3, 5... De föregående två stegen reepteras 5
Storypoints används oza för ap uppskapa produkt backlogg vid planering av hela projektet, som stöd för prioritering och vid val Gll sprintbacklogg. Man mäter varje story relagvt varandra. När teamet sedan ska bryta ner user stories från produktbackloggen Gll konkreta uppgizer i sprintbackloggen måste uppgizer mätas i fakgsk Gd. Man kan då spela planeringspoker och säpa story points på uppgizerna och sedan räknat om dessa Gll Gmmar. Eller bara säpa Gmmar på de olika uppgizerna direkt. Det förespråkas ap man ska, även på uppgizsnivå, dra nypa av allas input i esgmaten men vissa menar ap om man har en databasexpert i teamat som säger ap en uppgiz tar fyra Gmmar så är det bara ap säpa fyra Gmmar på den uppgizen. Tanken med metoden är ap gruppens resultat blir bäpre än individernas tack vare de synergieffekter som uppstår när gruppen resonerar och driver på varandra mot resultat. Fördelar: Varje deltagare tänker själv under tystnad. DePa minskar risken ap påverka andra deltagare. Alla gruppdeltagare är delakgga i GdsuppskaPningen. Deltagarna får djupare kunskaper genom ap esgmaten diskuteras öppet. ArbetssäPet är iteragvt ezersom esgmeringen upprepas vid behov. EsGmaten baseras på gruppens konsensus i stället för en individs åsikter. Det är ep roligt säp ap esgmera Gd ezersom det Glltalar kreagvitet och tävlingsinsgnkt och skapar engagemang runt uppgizen. Nackdelar: Det finns en risk ap man tror ap man har konsensus när man egentligen saknar informagon för ap kunna göra en korrekt bedömning. Konformitet Socialpsykologisk term som betecknar ap en individ ger ezer för en grupps förväntningar och uppfapningar. Salomon Asch gjorde i mipen av 1900- talet ep experiment för ap se om man kunde få vanliga människor ap hävda något de själva inte tror är sant endast pga. det sociala trycket en grupp utövar. Grupptryck Velocity /hasgghet Faktorer som påverkar grupptryck: Vid en variagon av Asch experiment visade det sig ap många fler blev självständiga i sina bedömningar om de inte behövde stå ensamma mot gruppen. Då man gav försökspersonen en kumpan som också gav ep korrekt svar så sjönk deras konformitet avsevärt. Den egna självbilden har visat sig spela roll för om vi faller för grupptryck eller inte. Personer med en dålig självuppfapning faller i ökad utsträckning för sociala tryck ezersom ap det styrker deras relagon Gll gruppen. De måste visa sig vara värdiga medlemmar för ap verkligen Gllhöra gruppen. Personligheten hos individen och gruppens storlek är som många säkert vet också vikgga. Exempelvis personligheter som i högre grad ezersträvar beröm och undviker straff faller läpare för gruppens vilja och en grupp på 10 personer utövar ep större tryck än en på 4 personer. EP annat planeringsverktyg är hasgghet. HasGghet är ep måp på hur mycket teamet får gjort under en sprint. HasGghet är det som fakgskt blev gjort under den sista sprinten inte vad som var planerat ap göras. (fakgsk hasgghet vs. uppskapad hasgghet) I Scrum mäts det i story points (idela dagar) eller i fakgska Gmmar. Varje krav i scrum är en story. Varje story har poäng/gmmar. Varje user story Glldelas ep esgmat (antal story points) beroende på dess komplexitet. Om ep team gör sex user stories á 8 story points, är teamets hasgghet helt enkelt 48. Vilka medlemmarna i gruppen är har också visat sig vara vikggt. Grupper där hög- status personer och personer som är vikgga för oss ingår i påverkar oss i högre grad än andra grupper. 6
Velocity/hasGghet Velocity Påverkas av Teamets storlek Hinder AvbroP Sprintlängd Hur väl man esgmerar Fokusfaktor/effekGvitetsfaktor När man GdsesGmerar räcker det inte ap räkna med ap man har full arbetskraz. Sjukdom, oplanerat arbete, ofungerande teknik, felsökning och buggfixning etc. kan påverka den Gd som esgmeras. DePa måste också/är bra ap ha med i beräkningarna. Fokusfaktor/effekGvitetsfaktor En fokusfaktor används för ap få fram hur mycket av Gllgänglig Gd som teamet fakgskt kan spendera på verkligt arbete i en sprint. Fokusfaktor består av en fast och en rörlig del. Fast del är standardmöten kopplade Gll metoden, (releaseakgviteter, drizsäpning etc.). Rörlig del är all Gd som inte går ap hänföra Gll den fasta faktorn. Tex extra möten, resgd etc. som påverkar den Gd teamet spenderar på ap färdigställa funkgonalitet i pågående sprint. Fokusfaktor/effekGvitetsfaktor Beräkna fokusfaktor För ap få fram en passande fokusfaktor kan man kolla på en Gdigare sprint. Fokus faktor = fakgsk hasgghet/ Gllgängliga mans- dagar Hantering av sprint backlog Sprintlogg är alla de uppgizer som ska göras för ap transformera delar/ önskningar i backloggen Gll färdigt inkrement. Individer tar på sig uppgizer själva. UppgiZer Glldelas aldrig. UppskaPad återstående Gd uppdateras dagligen. Tillgängliga mans- dagar * fokus faktor = uppskapad hasgghet. Henrik Kniberg. Scrum and XP from the Trenches. How we do Scrum. Sidan 27. 7
Statusgraf / burndown chart Estimated work remaining 70 Burndown 60 50 40 30 20 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Days I ett s.k. burndown chart markerar man dag för dag hur mycket som återstår av det tidsplanerade arbetet. Diagrammet visar tyd ligt i vilken takt man bränner av de kvarvarande timmarna av en sprint. Hantering av sprint backlog Sprintbacklog kan modifieras under en sprint uppgizer kan tas bort eller läggas Gll vid behov av teamet endast Alla teammedlemmar kan lägga Gll, ta bort, samt ändra uppgizer i sprint backloggen. nya uppgizer upptäcks under sprinten. saker tar längre Gd än beräknat sjukdom etc. Uppdatera GdsuppskaPning på återstående arbete ezer hand som det klarnar. Kniberg. XP and Scrum from the Trenches. Sidan 52. Sprint Läs! Sprintbackloggen ska vara Gllgänglig och synlig hela Gden. Henrik Kniberg. Scrum and XP from the Trenches. How we do Scrum. Finns på kurshemsidan under Literatur. http://www.crisp.se/konsulter/henrik-kniberg 8
Inför projektet Träffar Combitech på onsdag Bestämma projekt, antal träffar på Combitech, start av projekiörberedelser. Boka dag då Combitech kommer Gll föreläsning. Troligen v9. Gruppindelning Parallella kurser under VT2 (schemakrockar) Om du vill vara Scrummästare eller Gruppansvarig så skriver du ja ezer något av alternagven och sedan svarar du på de andra rollerna också. BlankeP för gruppindelning kommer upp på hemsidan under kursnyheter, jag vill ha in den så snart som möjligt, jag påminner via mail. Scrummästare Scrummästare Främja/förbäPra kommunikagon Se Gll ap processen fungerar Upptäcka och hantera störningsmoment Främja snabba beslut UnderläPa arbetet Undvika onödiga möten Vid dagligt scrummöte är det scrummästaren som ser Gll ap mötet äger rum och ap det håller Gden Främja/förbäPra kommunikagon Se Gll ap processen fungerar Upptäcka och hantera störningsmoment Främja snabba beslut UnderläPa arbetet Undvika onödiga möten Vid dagligt scrummöte är det scrummästaren som ser Gll ap mötet äger rum och ap det håller Gden Scrummästaren leder arbetet och är ansvarig för a( teamet fungerar väl och för kontakter med produktägaren (Combitech). Combitech föreslår a( man är Scrummästare halva perioden dvs 3 veckor (men ni betämmer själva inom gruppen). Gruppansvarig Gruppansvarig är ansvarig för surfplapan (skriver under utlåningskontrakt), uppkoppling och är kontaktperson för gruppen gentemot lärare (Camilla och Henry). Det kan innebära mailkontakt, boka möten, ansvara för ap samla in dokumentagon inför projekiörberedelsen etc. Gruppansvarig är man under hela perioden. Gruppindelning Roller. Under varje roll ringar du in hur gärna du vill vara det på skalan 1-3 där 1 är mkt gärna. (Spelar det ingen roll så väljer du 1 på alla alternagv). Programmerare, ange också eventuella styrkor och/eller svagheter GUI designer (intresserad av ap jobba med både den visuella designen och interakgonen där bakom, men givetvis programmerare också) Grafiker (tecknare, rita grafik på frihand) Övrigt: (exempelvis om du gärna vill ha en och samma roll eller om du gärna vill byta) 9
Vi ses på tosdag (Pierangelo). How do machines communicate 10