Agil användbarhetsutveckling för handhållna enheter TNM082, VT2014, FÖ2 Idag Agil utveckling Scrum Förväntningar En helt ny utmaning. Det ska inte vara som andra kurser Företag har oka erfarenhet inom agil utveckling som krav Mycket kul al programmera i Android, känns mer aktuellt än andra planormar Kul al utveckla mobilapp Göra användarvänliga appar Mycket resurser Qll metoderna inte bara slutprodukten Gå ner på djupet i agil metodik Lära sig mer om al jobba iteraqvt. AL projektet ska vara lärorikt och intressant Jobba i större projektgrupp än Qdigare. EffekQvt grupparbete Farhågor För lite kurslileratur Jobbiga labbar Schemakrockar AL mil schema skiljer sig från andras så al jag får jobba själv Heldagsjobb i kombinaqon med andra kurser och åtaganden. Tidskrävande så al man inte hinner med. Programmeringen Inte läst programvaruutvecklingsmetodik. Hur stor påverkan har det? AL det skiljer sig mycket i gruppen. AL man tolkar det agila på olika säl, al det inte blir något flyt i processen Stor klyka i utvecklingssyke (uppstod i PUM kursen) Hamna i grupp där drivkraken skiljer sig åt, leder oka Qll bråk och mer jobb för vissa. 1
2014-02-03 Agila utvecklingsmetoder Agile är engelska och betyder smidig, vig, lä+rörlig. Agil systemutveckling är el samlingsnamn för el antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lälrörliga metoder. Jämfört med Qdigare valenfallsmodeller representerar de mer flexibla säl al arbeta. Sekvensiell vs. överlappande utveckling Krav Design Kod Agila utvecklingsmetoder Agile är engelska och betyder smidig, vig, lälrörlig. Agil systemutveckling är el samlingsnamn för el antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lälrörliga metoder. Jämfört med Qdigare valenfallsmodeller representerar de mer flexibla säl al arbeta. Test Istället för att göra en sak i taget......gör Scrumteam lite av allting hela tiden Metoderna följer i stort sel samma värderingar, principer och synsäl. Source: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 1986. 2
Manifest för Agil systemutveckling Individer och interakqoner framför processer och verktyg Fungerande programvara framför omfalande dokumentaqon Kundsamarbete framför kontraktsförhandling Anpassning Qll förändring framför al följa en plan Agila metoder Scrum Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas http://agilemanifesto.org/iso/sv/ http://www.agilealliance.org/ Scrum Ordet "scrum" är en term från sporten rugby, och är den täta axel mot axel- formaqon teamet använder för al föra bollen framåt när den säls i spel. De japanska managemenaorskarna Hirotaka Takeuchi och Ikujiro Nonaka myntade ulrycket. De tyckte al rugby var en bra liknelse ekersom el tvärfunkqonellt team samarbetar för al göra klart produkten på samma säl som el rugbylag spelar Qllsammans för al föra bollen uppför planen. Scrum har Qllämpats sedan Qdigt 1990- tal och formaliserades 1995. skapades ursprungligen av Jeff Sutherland och Ken Schwaber. Scrumguiden https://www.scrum.org/scrum-guide?gclid=cleslom_pbwcfcppcgod_aqaja Historia Scrumguiden dokumenterar Scrum såsom det utvecklats och underhållits i drygt tjugo år av Jeff Sutherland och Ken Schwaber. Andra källor Qllhandahåller mönster, processer och insikter om hur tekniker, hjälpmedel och verktyg komplelerar deras scrumramverk. Översä+ning Denna guide har översals från den engelska originalversionen Qllhandahållen av Ken Schwaber och Jeff Sutherland. Guiden är översal av ChrisQna Skaskiw och granskad av Henrik Berglund, Joakim Holm och Andreas Hägglund. 3
Srum Scrum är: LäLvikQgt LäL al förstå Extremt svårt al bemästra Just like you don t really know what its like to be someone else unql you ve walked however many miles in his or her shoes, you might not fully understand Scrum unql you implement it yourself. But as you read this book, you will begin to understand what Scrum really feels like and how you might feel using Scrum in your organizaqon (Schwaber & Beedle, 2004). KursliLeratur Essen<al Scrum: A Prac<cal Guide to The Most Popular Agile Process. Rubin S.K. 2013. (307SEK) Agile SoKware Development With Scrum. Schwaber, K. & Beedle. M. 2008. (474SEK) Agile Project Management With Scrum. Schwaber, K. & Beedle. M. 2004. (235SEK) Föreläsningsmaterial och annat material hemsida Scrum Scrum baserar sina ruqner på el iteraqvt, inkrementellt skelel. Krav/önskemål representeras som punkter i en produkt backlogg Produkten växer fram (designas, kodas och testas) i sprintar (sprintbacklog) Den lägre cirkeln representerar en iteraqon av akqviteter i utvecklingen som sker eker varandra. Resultatet/output av varje iteraqon är el inkrement (Qllägg) av produkten. Den övre cirkeln representerar den dagliga granskningen som sker under en iteraqon i vilken medlemmarna i teamet träffas för al granska varandras akqviteter och göra nödvändiga anpassningar. IteraQonen drivs av en lista med önskemål och cykeln upprepas Qll produkten är klar. Använder el antal akqviteter och regler för al skapa en flexibel miljö för al leverera projekt. Inga specifika tekniska arbetssäl föreskrivs. 4
Scrum Enligt en valenfallsmodell kan köparen av el hus kan inte flyla in förrän hela huset är färdigställt. Scrum är istället en inkrementell process. VVS, el etc. färdigställs i el rum och sedan i de andra medans de blir färdigbyggda. Då kan köparna flyla in så snart de har så många rum de behöver Qll en början. Sedan byggs resten vid behov. Scrum låter sina kunder utveckla mjukvara på det sälet. Delar av funkqonalitet levereras Qll köparen så al dennes verksamhet/ organisaqon kan börja använda delar av systemet Qdigt i utvecklingscykeln. Medan de använder systemet och får erfarenhet av det så kan de bestämma vilka delar av systemet som ska konstrueras och i vilken ordning och använda dessa delar ekerhand de blir färdiga. Scrum Scrum leder utvecklingen längs en opqmal väg som sträcker ut sig under Qden som projektet utvecklas. Scrum är el säl al fördela arbetsuppgiker i Qden med bibehållet fokus på levererad affärsnyla. Därför erbjuder Scrum helt enkelt el ramverk och en uppsälning metoder som gör allqng synligt. DeLa gör al Scrums utövare vet exakt vad som händer och kan göra kontroller och justeringar direkt för al säkerställa al el projekt går mot de önskade målen. Scrums ramverk Ramverket består av: Scrumteam roller AkQviteter möten Artefakter styr arbetet och ger överblick Regler binder samman roller, händelser och artefakter och främjar relaqonen och interakqonen mellan dessa. Scrum team - roller Direkt engagerade i utvecklingen Produktägare Utvecklingsteam Scrummästare De som inte är direkt engagerade i utvecklingen Intressenter (Stakeholders) Användare Chefer Varje beståndsdel av ramverket har el specifikt syke och är väsentlig för framgångsrik användning av Scrum. 5
Produktägaren En utsedd person som har ylersta ansvaret al representera kundens intressen Definierar produktens funkqonalitet och prioritet Godkänner eller förkastar arbetsresultat Den enda person som är ansvarig för produktens backlogg, vilket innebär: förklara backloggens delar ordna dessa så al mål och uppdrag kan nås försäkra sig om värdet av teamets arbete Produktägaren En utsedd person som har ylersta ansvaret al representera kundens intressen Definierar produktens funkqonalitet och prioritet Godkänner eller förkastar arbetsresultat Den enda person som är ansvarig för produktens backlogg, vilket innebär: förklara backloggens delar ordna dessa så al mål och uppdrag kan nås försäkra sig om värdet av teamets arbete Tar emot, hanterar och prioriterar önskemål om Qllägg och ändringar för en produkt. Produktägaren svarar på frågor från utvecklingsteamet om vad som skall byggas och hjälper teamet al anskaffa nödvändig informaqon från verksamheten. Produktägaren svarar inför verksamheten på frågor om systemets funkqonalitet och prioriteringar. Utvecklingsteam Bör bestå av 3(5)- 9 personer TvärfunkQonellt har alla kompetenser som behövs och behöver inte förlita sig Qll någon utanför teamet det finns därför inga i förväg definierade roller utan medlemmarna bestämmer allt ekersom vem som ansvarar för vad Utvecklingsteam Bör bestå av 3(5)- 9 personer TvärfunkQonellt har alla kompetenser som behövs och behöver inte förlita sig Qll någon utanför teamet det finns därför inga i förväg definierade roller utan medlemmarna bestämmer allt ekersom vem som ansvarar för vad Utvecklingsteamet är självorganiserande. planerar och väljer själva hur arbetet uaöras snarare än al andra utanför teamet gör det säla upp mål och specificera arbetsresultat Ansvarar för resultatet, kvaliteten på uaört arbete Modellen är designad för al opqmera flexibilitet, kreaqvitet och produkqvitet 6
Scrummästare Ansvarar för al teamet fungerar och är produkqvt Är en tjänande ledare för scrumteamet Fungerar som coach för teamet. Ska underläla arbetet. Ska inte likställas med projektledare utvecklingsteamen är och skall vara självorganiserande Avlägsnar hinder för utvecklingsteamet Säkerställer al teamen arbetar enligt scrumprocessen Synkroniserar mellan aktörer Möjliggör täl samarbete mellan alla roller och funkqoner Scrummästare För produktägaren Förstå och prakqsera agilitet Vägleda vid scrumakqviteter om det ekerfrågas eller behövs Tydligt kommunicera vision, mål och poster från backloggen Qll teamet HiLa tekniker för effekqv hantering av produktbackloggen Lära teamet al skapa tydliga och koncisa poster Qll produktbackloggen För organisaqonen Planera införande Leda och coacha vid införande Etc. ScrumakQviteter Sprint (iteraqon) Sprintplaneringsmöte Dagligt scrummöte Sprintgranskning demonstraqon Sprintåterblick Sprint Sprint Arbetet delas in i sprintar (iteraqoner, delleveranser). En sprint är el bestämt Qdsintervall där el mål ska uppnås på el fokuserat säl av utvecklingsteamet. En sprint är mellan 3 och 30 dagar lång. Varje sprint är el projekt som varar max 30 dagar. Likt projekt är syket med en sprint al åstadkomma något så det är vikqgt al en sprint allqd resulterar i en fullt fungerade produkt, ngt klart. Varje sprint har en definiqon av vad som ska byggas, en design och en flexibel plan som guidar processen dit, och en resulterande produk 7
Sprint Sprintplaneringsmöte Varje sprint inleds med en planeringssession (sprint planering) och avslutas med en granskning av de utlovade ändringarna (sprintgranskning). Under sprinten sker dagligen utvärdering av gårdagen och planering av dagen (daglig scrum). Som sista punkt i en sprint äger en förbälringsakqvitet rum (sprintåterblick). Under en sprint: OmfaLningen kan klargöras och omförhandlas mellan produktägaren och utvecklingsteamet under Qden man lär sig. Utvecklingsteamets komposiqon är konstant, ändras inte. Planeringssession En plan över det arbete som ska uaöras Skapas av hela teamet gemensamt För el 30 dagars projekt tar det 8h, minskar för mindre projekt. Består av två delar som besvarar följande frågor: vad ska göras, vad ska levereras eker sprinten,? input här är backlog (önskemål/krav), resultat från Qdigare sprintar, Qdigare prestaqon, förväntad arbetskapacitet av teamet under sprinten,. el mål säls som säger vad som ska uppnås genom implementaqon av backlog och det ger också stöd Qll teamet al se varför de bygger den här delen. hur ska arbetet som behövs uaöras? skapar en sprint backlog av delar från produktbackloggen plus planen för hur dessa ska levereras eker valt arbete bestämmer teamet hur funkqonaliteten ska byggas Qll el done/klart inkrement av produkten. Planering En missuppfalning som lever kvar kring lälrörliga metoder är al de inte har Qllräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta el nyl projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. EKersom vi planerar så mycket behöver vi vara mycket effekqva planerare. Scrum People employing Scrum apply common sense every Qme they find the work veering off the path leading to the desired results. Yet most of us are used to using prescripqve processes those that say do this, then do that, and then do this that we have learned to disregard our common sense and instead await instrucqons (Schwaber & Beedle, 2004). Sunt förnuk är en kombinaqon av erfarenhet, övning, ödmjukhet, förstånd och intelligens. http://scrumtipsblogg.blogspot.se/2008/09/vad-sprintplanering-och-glassinkp-har.html 8
Dagligt scrummöte Dagliga avstämningsmöten, ca 15 min långa. Äger allqd rum på samma plats och vid samma Qd (oavsel om alla kommer). Produktägaren, användare etc. är välkomna på dessa möten men dessa personer får enbart lyssna. Scrum- mästaren håller i mötet och syket är al: skapa överblick, sqmulera interakqon/kommunikaqon, se Qll al processen fungerar, Qdigt idenqfiera eventuella problem eller hinder i sprinten, underläla arbetet, undvika onödiga möten. Dagligt scrummöte På det dagliga mötet ska alla i utvecklingsteamet kort svara på nedanstående tre frågor. - Vad har jag gjort sedan förra mötet? - Vad ska jag göra fram Qll nästa möte? - Finns det något hinder i min väg? På dessa möten försöker man dock inte lösa större problem utan det är endast el informaqonsmöte. Finns det behov av problemdiskussion eller liknande så ordnar teamet el nyl möte med berörda parter. Dagligt scrummöte VikQgt al tänka på! Mötet handlar INTE om statusrapportering Qll Scrummästaren utan om al synliggöra och diskutera åtaganden inför kollegor. Scrummästarens roll är al se Qll al dessa möten: äger rum håller Qden Sprintgranskning, demonstraqon Gransknings och demonstraqonsmöte av sprint, ca 4 Qmmar långt. Varje Sprint avslutas med en demonstraqon där fungerande programvara visas inför en större grupp. DeLa möte hålls på den sista dagen i sprinten där produktägare, kunder, användare etc. informeras om vad teamet utvecklat. Scrum- mästaren leder mötet och det bör var så informellt som möjligt, dvs inte kräva större förberedelser. SyKet med mötet är al det är el arbetsmöte där frågor, diskussioner och förslag uppmuntras. Fokus ligger dock i al informera om vad teamet gjort i sprinten. 9
Sprintgranskning, demonstraqon Sprintgranskning.. Under granskningen redovisas först status för de i sprinten inplanerade sakerna, däreker demonstreras klar funkqonalitet. SyKet är al få in granskningskommentarer från alla deltagare. Speciellt är man intresserad av al veta vad som är klart och inte. DäreKer redovisar produktägaren sina planer för framqden i form av sin produktbacklog och även denna granskas av alla deltagare. Resultatet av en sprintgranskning är en ny och uppdaterad produktbacklog som avspeglar alla deltagares bästa uppfalning om hur man ligger Qll och vad som ska göras härnäst. Ger god input Qll ekerföljande sprintplaneringsmöten. På dela möte bestäms även när nästa planeringsmöte ska hållas. Sprintåterblick Återblicksmöte av sprint, ca 3 Qmmar långt. DeLa möte är det sista mötet i sprinten och här går scrum- mästaren, produktägaren och teamet igenom vad som gål bra respekqve mindre bra så al man kan förbälra sig Qll nästa sprint. Hålls eker sprintgranskning och innan nästa sprintplanering. Möjlighet för teamet al inspektera sig själva och göra en plan för förbälringar Qll nästa sprint. Följande tre frågor besvaras: - Vad bör vi fortsäla al göra (bevara)? - Vad bör vi sluta al göra (undvika)? - Vad bör vi pröva al göra (pröva)? Sprintåterblick Scrum Scrums hjärta ligger i iteraqonen. Teamet ser över önskemålen, den teknologi som finns Qllgänglig, och utvärderar sina egna färdigheter och förmågor. Man bestämmer sedan i kollekqvet hur man ska bygga funkqonaliteten, modifierar angreppssälen dagligen när man stöter på nya komplikaqoner, svårigheter och överaskningar. Man avgör vad som behöver göras, och hur och väljer lämpligaste säl al göra det på. Det är den här iteraqva och kreaqva processen som utgör Scrums hjärta. 10
Scrum - artefakter Produktbacklogg Sprintbacklogg Burn- down chart/statusgraf Inkrement Produktbacklogg I scrum finns det inte en klassisk kravspecifikaqon utan man har istället en backlogg. Ägs och hanteras av produktägaren. innehåll, Qllgänglighet, ordning. En backlogg är kort sagt en prioriterad och levande lista med önskemål. Det finns ingen begränsning på antal önskemål. I stället används prioritering. Ju högre prioritet, desto bälre specificerat ska ändringsönskemålet vara. DeLa innebär al i el projekt kan önskemål som är aktuella vid projektets start falla bort om de prioriteras ned under projektets gång och nya önskemål kan också läggas Qll. Sprintbacklogg Scrumtavla Den del av en produktbacklogg som utvecklingsteamet åtar sig al implementera under en sprint samt den plan som de formulerat för hur de ska göra det. En lista med uppgiker och en uppskalning av Qd det går åt för en person al sluaöra en uppgik. VikQgt al det är teamet som väljer vad och hur mkt de ska göra ekersom det är de som är ylerst ansvariga för al fullfölja det. 11
Statusgraf Statusgraf Statusgraf Visar hur mycket arbete som återstår för teamet under sprinten. Dag för dag markerar man hur mkt som återstår av det Qdsplanerade arbetet. Diagrammet visar tydligt i vilken takt man bränner av de kvarvarande Qmmarna/poängen (eller dylikt) av en sprint. Inkrement Teamet levererar el inkrement av funkqonalitet vid varje sprint. Summan av alla delar i produktbacklogg som gjorts färdiga under en sprint och Qdigare sprintar. Vid slutet av en sprint måste det nya inkrementet vara klart (done) användbart skick och uppfylla definiqonen av klar som teamet gjort Klart måste förstås av alla, tydlig definiqon Det styr/stöder val av delar från backlogg! 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 Qll produkten först och främst utan Qll människorna som ska producera den. Som kollar på hur får vi människor al producera effekqvt och må bra. Agilt är mänskligt!. http://leif.ershag.se/224/varfor-agile-utveckling-passar-manniskor/ 12
Varför agil utveckling passar människor Människor är vanedjur Människor är lata Människor är sociala Människor gillar belöningar Är Scrum bara en metod för mjukvaruutveckling? Inte alls! Metoden kan anpassas för alla möjliga typer av projekt t.ex. QdningsprodukQon eller utveckling av medicinsk teknik. Scrum har använts framgångsrikt i allt från bokförfalande Qll brädspels- utveckling och semesterplanering. http://leif.ershag.se/224/varfor-agile-utveckling-passar-manniskor/ Är Scrum bara en metod för mjukvaruutveckling? Nu programmeras arbetslivet om. (AKonbladet 2012-02- 02). Programmerarkulturen revoluqonerar hur vi arbetar Hur vi organiserar arbetet det är slut på Qden då några få tänker och resten uaör externa belöningar fungerar mycket dåligt för al driva på människor gemenskap ger däremot resultat 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 organisaqoner. 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 http://www.aftonbladet.se/kultur/article14308259.ab http://jimmyjanlen.wordpress.com/2012/09/06/agil-hr-hur-fungerar-det/ 13
Är Scrum bara en metod för mjukvaruutveckling? Agil HR Fördelar ur el HR perspekqv Agila metoder inspirerar Qll al tänka i helt nya banor kring hur vi samarbetar, rekryterar, säler mål och ger feedback. Är Scrum bara en metod för mjukvaruutveckling? Företag utan chefer och struktur? Structure happens http://www.hrbloggen.se/2012/03/vad-ar-agil-hr.html Se Handbook for new employees på: http://jimmyjanlen.wordpress.com/2012/09/06/agil-hr-hur-fungerar-det/ http://www.valvesoftware.com/jobs/ Är Scrum bara en metod för mjukvaruutveckling? Build projects around moqvated individuals. Give the team the environment and support they need, and trust them to get the job done. Business analysts, managers, developers and testers must work together daily throughout the project. The best architectures, requirements, and designs emerge from self organizing teams. Se Handbook for new employees på: http://jimmyjanlen.wordpress.com/2012/09/06/agil-hr-hur-fungerar-det/ http://www.valvesoftware.com/jobs/ 14
Referenser Schwaber & Beedle, K. 2004. Agile Project Management With Scrum. Rubin, K.S. 2013. EssenQal Scrum. Scrum Guiden: Den definiqva guiden Qll Scrum: Spelets regler. 2013. hlps://www.scrum.org/scrum- guide? gclid=cleslom_pbwcfcppcgod_aqaja (länken finns också snart på kurshemsidan under LiLeratur.). Tack vi ses på Qsdag nästa vecka!. 15