Idag. Camilla Forsell TNM082 VT2013 TNM082, Camilla Forsell. Camilla Forsell TNM082 VT2013 TNM082, Camilla Forsell

Transkript

1 Agil användbarhetsutveckling för handhållna enheter TNM082, VT2013, FÖ2 Idag Agil utveckling Scrum Agila utvecklingsmetoder Agile är engelska och betyder smidig, vig, lährörlig. Agil systemutveckling är eh samlingsnamn för eh antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lährörliga metoder. VaHenfallsmodeller Va#enfallsmodellen är en sekvenmell systemutvecklingsprocess där man ser framstegen som eh flöde (som eh vahenfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstrukmon, test, produkmonssähning och underhåll. Tanken är ah varje steg ska vara helt klart och bedömas innan man går vidare Mll nästa steg. Metoderna följer i stort seh samma värderingar, principer och synsäh. Jämfört med Mdigare vahenfallsmodeller representerar de mer flexibla säh ah arbeta. VaHenfallsmodeller Modellen har sina röher i Mllverknings- och byggindustrin där det är mycket kostsamt ah införa ändringar sent i processen - om inte omöjligt. EH exempel som oua används på vahenfallsmodellen brukar vara ah bygga eh hus. Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för ah ta fram specifikamoner i form av olika dokument för ah få söka bygglov. DäreUer byggs huset enligt specifikamonen. Då byggnamonen påbörjats är arkitekten frikopplad och inga ändringar görs. EUer byggnamonen sker inflyhning och driu och underhåll av fasmgheten påbörjas. VaHenfallsmodeller Fördelar: Fungerar bra i projekt som är väldefinierade, förutsägbara och där det är osannolikt ah det blir större förändringar. Kostnadskontroll, beställaren (den som betalar) kan besluta i varje steg huruvida projektet ska startas, fortsäha, avslutas eller läggas på is. EH projekt ska kunna återupptas med hjälp av de dokument som redan gjorts. Resursplanering eller upphandling kan göras mellan stegen. Om kravspecifikamonen och designen är Mllräckligt bra så ska vem som helst kunna implementera systemet. Det som levereras är testat och är kvalitetssäkrat. 1

2 VaHenfallsmodeller Nackdelar: VaHenfallsmodellen hanterar egentligen inte förändringar. EH förändringsförslag (Mlläggsbeställning) måste gå igenom flera steg för ah genomföras. VaHenfallsmodeller Kri6k VaHenfallsmodellen har fåh mycket krimk och de flesta hävdar idag ah det är bevisat via undersökningar ah det inte fungerar för ah utveckla it- system. Det blir mycket dokumentamon. Mycket av det är nödvändigy, annan dokumentamon kanske inte kommer ah läsas. OUast är it- system mycket mer komplexa än vad eh hus är ah bygga så denna modell kan bara användas Mll viss del i projekt för it- system TradiMonell utveckling visualiserad VaHenfallsmodeller Kri6k VaHenfallsmodellen har fåh mycket krimk och de flesta hävdar idag ah det är bevisat via undersökningar ah det inte fungerar för ah utveckla it- system. Modernare metoder menar ah man istället borde likna systemutveckling vid eh gemensamt lärande, där beställaren och leverantören Mllsammans lär sig om varandras världar och gemensamt bygger en passande lösning i flera steg (iteramoner). Vad går fel i utvecklingsprojekt? Vad går fel i utvecklingsprojekt? Man kan läh få uppfahningen ah de flesta it- projekt misslyckas. Dessvärre verkar bilden stämma, åtminstone om vi får tro The Standish Group, eh amerikanskt företag som regelbundet granskar projekt från hela världen och ställer samman en rapport med det talande namnet The CHAOS Report

3 10 framgångsfaktorer I sin genomlysning listar Standish Group Mo framgångsfaktorer för lyckade projekt. Dessa är: 1. DelakMga slutanvändare 2. Ledningsstöd 3. Tydliga affärsmål 4. Känslomässig mognad 5. Gör bara det som euerfrågas 6. Flexibel process 7. Kunniga projektledare 8. Kunniga medarbetare 9. HandlingskraU 10. Adekvata verktyg Vad går fel i utvecklingsprojekt? Därför floppade projekten: Tre svenska it- fiaskon under lupp Av Liv Marcks von Würtemberg För dyrt, för sent och för dåligt. Forskarna på KTH har tagit en 6# på tre skandalomsusade it- projekt och re# ut vad som gick sne# och vad man kunde ha gjort annorlunda. CIO Sweden är ett månadsmagasin för strategiska beslutsfattare inom IT. Tidningens devis är "länken mellan IT och affärer" och syftet är att belysa den mer affärsmässiga sidan av IT och att fungera som stöd och beslutsunderlag för svenska CIO:er (egentligen strategiska IT-chefer). Vad går fel i utvecklingsprojekt? Levereras aldrig eller för sent Dyrare än beräknat Låg kvalitét Saknar funkmoner eller har onödiga funkmoner man vet inte vad man ska göra, funkmoner utan prioritet Dålig användbarhet man klarar inte uppgiuen Vad går fel i utvecklingsprojekt? Förändring (allt förändras) Verksamhet Önskemål/krav Teknik Vad beror det på? Vad går fel i utvecklingsprojekt? Hur hanterar man problemen? Andra problem It systemen blir alltmer komplexa vilket leder Mll ah färre personer i ledningsposimon är beredda ah säha sig in i hur de fungerar. konsulter anlitas som kan it men inte verksamheten de skall stödja. Mjukvara är komplex och ogripbar (intangible) För stora system/projekt försöker göra allt på en gång Trög process och brist på återkoppling 3

4 The frustramon of everyday life Antag att Du skulle bygga hus på de osäkra grunder som råder i systemutvecklingsvärlden. Du vill ha ett kök på Hur ska vi nå hit? m 2 med diskbänk, blandare med duschfunktion, spis med häll, mikrovågsugn, kyl/frys etc. När vi gör slutbesiktningen av vårt kök får vi en rejäl överraskning. Det visar sig att vattenblandaren sitter på en vägg och diskbänken på en annan. Dessutom finns inget avlopp under diskbänken. Elanslutning saknas för mikrovågsugn. Dörr saknas mellan kök och matsal. Kranen låg i projektet vatten som ingick i delprojektet VVS, diskbänken hanterades i projektet köksutrustning som ingick i delprojekt snickeri och all eldragning ingick i ett separat delprojekt. Mycket som inte var självklart togs för givet och projektgrupperna har tydligen inte samarbetat tillräckligt. I verkligheten hade ovanstående knappast kunnat inträffa, eftersom de flesta vet hur ett kök fungerar. I systemutveckling är problemområdet dock komplext, abstrakt och på förhand ofta mindre känt för inblandade personer. Köksexemplet är hämtat från skriften Krav på krav från Sveriges verkstadsindustrier, där också nedanstående travestering av den kända bilden om gungan förekommer. Den visar hur det bör se ut Figur 1. Hur hanterar man problemen? Agila metoder! Om system syftet med kravhantering Kravhantering syftar till att ta fram en kravspec/beställning av det system, som skall köpas eller tillverkas. Ett system är en komplex abstrakt artifakt som kan variera i storlek och komplexitet, alltifrån fiskeklubbens medlemsregister i ordförandens PC till flygbolagets världsomspännande biljettbokningssystem på Internet. Rent akademiskt brukar man ofta referera till följande två definitioner av systembegreppet: Schöderbeck: Ett system är en mängd objekt. Det finns samband mellan objekten, deras attribut och omgivningen. Tillsammans bildar detta en helhet. IEEE: En samling komponenter, organiserade för att utföra en speciell funktion eller en mängd funktioner. Vad är agila metoder? Ramverk med värden och principer. Agil systemutveckling är eh samlingsnamn för eh antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lährörliga metoder. Metoderna följer i stort seh samma värderingar, principer och synsäh. Jämfört med Mdigare vahenfallsmodeller representerar de mer flexibla säh ah arbeta. Copyright ProjektStegen Sverige AB. 2 Alla rättigheter förbehålles. Agila utvecklingsmetoder Grundtankarna bakom agile bygger på ah göra kunden/användaren nöjd med det som utvecklas genom eh mycket nära samarbete under hela utvecklingsmden med täta och regelbundna möten mellan utvecklare och beställare/mohagare. Det agila synsähet anser ah det ouare är människor och kommunikamon än verktyg och formella dokument som löser problem under utvecklingsarbetet. Agila utvecklingsmetoder En annan central grundtanke är ah minimera risken för ah en stor del av eh system befinner sig i eh halvfärdigt läge och inte kan leverera nyha. EH agilt arbetssäh gör det möjligt för beslutsfahare ah få eh bähre underlag inför beslut om ah Mllföra yherligare resurser Mll eh projekt. Det finns självutvärderingar för ah avgöra om eh projekt utvecklar agilt (Nokia Test, Karlskrona Test, Agility measurement index). Arbetet bedrivs inkrementellt och iteramvt vilket innebär ah regelbundna mindre leveranser sker och ah saker löpande utvärderas och kan ändras för ah möta nya krav och önskemål. 4

5 Manifest för Agil systemutveckling Fyra nyckelprinciper: Individer och interakmoner framför processer och verktyg. Fungerande programvara framför omfahande dokumentamon. Kundsamarbete framför kontraktsförhandling. Anpassning Mll förändring framför ah följa en plan. Manifest för Agil systemutveckling Vi finner bättre sätt att utveckla programvara genom att utveckla själva och hjälpa andra att utveckla. Genom detta arbete har vi kommit att värdesätta: Individer och interakmoner framför processer och verktyg Fungerande programvara framför omfahande dokumentamon Kundsamarbete framför kontraktsförhandling Anpassning Mll förändring framför ah följa en plan Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer. Manifest för Agil systemutveckling Individer och interakmoner framför processer och verktyg Fungerande programvara framför omfahande dokumentamon Kundsamarbete framför kontraktsförhandling Anpassning Mll förändring framför ah följa en plan 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 Manifest för Agil systemutveckling What is the Alliance? The Agile Alliance is a nonprofit organizamon with global membership, commihed to advancing Agile development principles and pracmces. Agile Alliance supports those who explore and apply Agile principles and pracmces in order to make the souware industry more producmve, humane and sustainable. We share our passion to deliver souware beher everyday. Agile systemutveckling Manifest för Agil systemutveckling Agile SoUware Development is, at its core, a system of principles rather than a parmcular model or paradigm. These ideas, espoused by the members of the Agile Alliance, and documented in the Agile Manifesto have given rise to a number of souware development processes that capture the principles of flexibililty, customer interac6on, produc6vity, and individuality. An ever- increasing demand for high quality souware products delivered in a relamvely short Mmeframe has created a necessity for flexibility in requirements. As industry has begun to realize the increasing necessity for "agility" in souware engineering, many companies have begun experimenmng with and adapmng these new methodologies to their own processes. In the world of academia, researchers are now seeking collaborators in industry to establish the validity of agile methods as new "best pracmce" techniques, while some educators have begun instrucmng students in agile development methods along with tradimonal souware methods. Many interest groups, conferences, and consul6ng firms have also emerged in support of Agile, fostering the growing support for this new approach to souware development. The Agile movement is not an6- methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentamon, but not hundreds of pages of never- maintained and rarely- used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definimon of the term hacker. We hope that our work together as the Agile Alliance helps others in our profession to think about souware development, methodologies, and organizamons, in new more agile ways. If so, we have accomplished our goals/ The Agile Alliance

6 Tolv grundprinciper Agila metoder Vår högsta prioritet är ah Mllfredsställa kunden genom Mdig och konmnuerlig leverans av värdefull mjukvara. Förändrande krav är välkomna, även sent i utvecklingen. Agila processen skördar förändring Mll kundens konkurrenskrauighet. Leverera fungerande programvara oua med Mdsskala från eh par veckor Mll eh par månader, med en förkärlek Mll den kortare Mdsskalan. Affärsfolk och utvecklare måste arbeta Mllsammans dagligen under hela projektet. Bygg upp projektet runt momverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem för ah få jobbet gjort. Den mest effekmva metoden för ah förmedla informamon Mll och inom eh utvecklingsteam är konversamon på plats mellan individerna (face- to- face). En fungerande programvara är det huvudsakliga måhet på framsteg. Agila processer främjer en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en jämn utvecklingstakt på obestämd Md. KonMnuerlig uppmärksamhet på teknisk kvalitet och god design ökar flexibiliteten. Enkelhet - konsten ah maximera mängden arbete som inte görs - är vikmgt. De bästa arkitekturer, krav och design framträder ur självorganiserande team. Teamet ser över med jämna mellanrum hur man ska blir mer effekmva, sedan finjusteras det och man anpassar sih beteende däreuer. Feature driven development (FDD) Extreme programming (XP) AdapMve souware development Dynamic Systems Development Method (DSDM) Crystal Lean souware development Kanban Scrum Agila metoder Scrum (Schwaber o Sutherland) Scrum Ordet "scrum" är en term från sporten rugby, och är den täta axel mot axel- formamon teamet använder för ah föra bollen framåt när den sähs i spel. De japanska managemenuorskarna Hirotaka Takeuchi och Ikujiro Nonaka myntade uhrycket och tyckte rugby var en bra liknelse euersom eh tvärfunkmonellt team samarbetar för ah göra klart produkten på samma säh som eh rugbylag spelar Mllsammans för ah föra bollen uppför planen. Scrum har Mllämpats sedan Mdigt tal och formaliserades skapades ursprungligen av Jeff Sutherland och Ken Schwaber. Scrum EH ramverk inom vilket man kan angripa komplexa, adapmva problem, medan man produkmvt och kreamvt levererar produkter med högsta möjliga värde. Scrum är inte normamv (föreskrivande): det går inte beskriva vad man ska göra i varje situamon. Det används för komplext arbete där det är omöjligt ah förutsäga allt som inträffar. Många människor som är projektledare/projektansvariga har lärt sig eh determinismsk MllvägagångssäH för projekthantering som använder väldigt detaljerade planer, gantscheman och arbetsscheman. Den exakta motsatsen Mll Scrum. Sådana verktyg kämpar mot eh projekts naturliga dynamik. Scrum People employing Scrum apply common sense every Mme they find the work veering off the path leading to the desired results. Yet most of us are used to using prescripmve 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 instrucmons (Schwaber, 2004, s. xvii). Sunt förnuu är en kombinamon av erfarenhet, övning, ödmjukhet, förstånd och intelligens. 6

7 Scrum Scrum är eh processramverk som har använts för ah hantera komplex produktutveckling sedan Mdigt 1990 tal. Scrum är inte en process eller teknik för ah bygga produkter; det är snarare eh ramverk inom vilket ni kan utnyhja olika processer och tekniker. Scrum tydliggör den relamva effekmviteten i era produktstrategier och hos era utvecklingsmetoder så ah ni kan göra förbähringar. Srum Scrum är: LäHvikMgt LäH ah förstå Extremt svårt ah bemästra Just like you don t really know what its like to be someone else unml you ve walked however many miles in his or her shoes, you might not fully understand Scrum unml 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 organizamon (Scwaber, 2004, s. xix). Scrum Scrum - skeleh Scrum leder utvecklingen längs en opmmal väg som sträcker ut sig under Mden som projektet utvecklas. Scrum är eh säh ah fördela arbetsuppgiuer i Mden med bibehållet fokus på levererad affärsnyha. Därför erbjuder Scrum helt enkelt eh ramverk och en uppsähning metoder som gör allmng synligt. DeHa gör ah Scrums utövare vet exakt vad som händer och kan göra kontroller och justeringar direkt för ah säkerställa ah eh projekt går mot de önskade målen. Scrum skeleh Scrum baserar sina rumner på eh iteramvt, inkrementellt skeleh. Den lägre cirkeln representerar en iteramon av akmviteter i utvecklingen som sker euer varandra. Resultatet/output av varje iteramon är eh inkrement (Mllägg) av produkten. Den övre cirkeln representerar den dagliga granskningen som sker under en iteramon i vilken medlemmarna i teamet träffas för ah granska varandras akmviteter och göra nödvändiga anpassningar. IteraMonen drivs av en lista med önskemål och cykeln upprepas Mll produkten är klar. Scrum Enligt en vahenfallsmodell kan köparen av eh hus kan inte flyha in förrän hela huset är färdigställt. Scrum är istället en inkrementell process. VVS, el etc. färdigställs i eh rum och sedan i de andra medans de blir färdigbyggda. Då kan köparna flyha in så snart de har så många rum de behöver Mll en början. Sedan byggs resten vid behov. Scrum låter sina kunder utveckla mjukvara på det sähet. Delar av funkmonaliteh levereras Mll köparen så ah deras verksamheter/ organisamoner kan börja använda delar av systemet Mdigt 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 euerhand de blir färdiga. 7

8 Scrum hjärta Scrums hjärta ligger i iteramonen. Teamet ser över önskemålen, den teknologi som finns Mllgänglig, och utvärderar sina egna färdigheter och förmågor. Man bestämmer sedan i kollekmvet hur man ska bygga funkmonaliteten, modifierar angreppssähen dagligen när man stöter på nya komplikamoner, svårigheter och överaskningar. Man avgör vad som behöver göras, och hur och väljer lämpligaste säh ah göra det på. Det är den här kreamva processen som utgör Scrums hjärta. Scrums ramverk Ramverket består av: Scrumteam roller AkMviteter möten Artefakter styr arbetet och ger överblick Regler binder samman roller, händelser och artefakter och främjar relamonen och interakmonen mellan dessa. Varje beståndsdel av ramverket har eh specifikt syue och är väsentlig för framgångsrik användning av Scrum. 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 Produktägaren En utsedd personsom har yhersta ansvaret ah representera kundens intressen. Tar emot, hanterar och prioriterar önskemål om Mllägg och ändringar för en produkt. Produktägaren måste vara en fysisk person. Produktägaren svarar på frågor från utvecklingsteamet om vad som skall byggas och hjälper teamet ah anskaffa nödvändig informamon från verksamheten. Produktägaren svarar inför verksamheten på frågor om systemets funkmonalitet och prioritering. Den enda person som är ansvarig för produkt backlog, vilket innebär: förklara backloggens delar. ordna dessa så ah mål och uppdrag kan nås. försäkra sig om värdet av teamets arbete. Utvecklingsteam Bör bestå av 3(5)- 9 personer. TvärfunkMonellt har alla kompetenser som behövs och behöver inte förlita sig Mll någon utanför teamet. det finns därför inga i förväg definierade roller utan medlemmarna bestämmer allt euersom vem som ansvarar för vad. Utvecklingsteamet är självorganiserande. planerar och väljer själva hur arbetet uuöras snarare än ah andra utanför teamet gör det. säha upp mål och specificera arbetsresultat Ansvarar för resultatet, kvaliteten på uuört arbete. Modellen är designad för ah opmmera flexibilitet, kreamvitet och produkmvitet. Scrummästaren Ansvarar för ah teamet fungerar och är produkmvt. Säkerställer ah teamen arbetar enligt scrum- processen Se Mll ah Scrums värderingar och principer följs rigoröst Synkroniserar mellan aktörer Avlägsnar hinder för utvecklingsteamet Möjliggör täh samarbete mellan alla roller och funkmoner Fungerar som coach för teamet. Ska underläha arbetet. Ska inte likställas med projektledare utvecklingsteamen är och skall vara självorganiserande. 8

9 ScrumakMviteter Sprint (iteramon) Sprintplaneringsmöte Dagligt scrummöte Sprintgranskning demonstramon Sprintåterblick Scrum - händelser Sprint Arbetet delas in i sprintar (iteramoner, delleveranser). En sprint är eh bestämt Mdsintervall där eh mål ska uppnås på eh fokuserat säh av utvecklingsteamet. En sprint är mellan 3 och 30 dagar lång. Varje sprint inleds med en planeringssession (Sprint planning) och avslutas med en granskning av de utlovade ändringarna (Sprint review). Under sprinten sker dagligen Daily scrums. Som sista punkt i en sprint äger en förbähringsakmvitet rum (Sprint retrospec5ve). Sprint Sprintplaneringsmöte Varje sprint är eh projekt som varar max 30 dagar. Likt projekt är syuet med en sprint ah åstadkomma något så det är vikmgt ah en sprint allmd resulterar i en fullt fungerade produkt, ngt klart. Varje sprint har en definimon av vad som ska byggas, en design och en flexibel plan som guidar processen dit, och en resulterande produkt. Under en sprint: Inga ändringar sker som påverkar sprintens mål. OmfaHningen kan klargöras och omförhandlas mellan produktägaren och utvecklingsteamet under Mden man lär sig. Mål avseende kvalitet minskar inte. Utvecklingsteamets komposimon är konstant, ändras inte. Planeringssession En plan över det arbete som ska uuöras. Skapas av hela teamet gemensamt. För eh 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 euer sprinten,? input här är backlog (önskemålen), resultat från Mdigare sprintar, förväntad arbetskapacitet av teamet under sprint, Mdigare prestamon. eh mål sähs som säger vad som ska uppnås genom implementamon av backlog och det ger också stöd Mll teamet ah se varför de bygger den här delen. hur ska arbetet som behövs uuöras? euer valt arbete bestämmer teamet hur funkmonaliteten ska byggas Mll eh done/klart inkrement av produkten. skapar en sprint backlog av delar från product backlog plus planen för hur dessa ska levereras. Dagligt scrummöte Dagliga avstämningsmöten, ca 15 min långa. Äger allmd rum på samma plats och vid samma Md (oavseh om alla kommer). Scrum- mästaren håller i mötet och syuet är ah smmulera interakmon, överblick samt ah Mdigt idenmfiera eventuella problem eller hinder i sprinten. Kunder, användare och produktägaren är välkomna på dessa möten men dessa personer får enbart lyssna. 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 Mll 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 eh informamonsmöte. Finns det behov av problemdiskussion eller liknande så ordnar teamet eh nyh möte med berörda parter. 9

10 Sprintgranskning, demonstramon Gransknings och demonstramonsmöte av sprint, ca 4 Mmmar långt. Varje Sprint avslutas med en demonstramon där fungerande programvara körs inför en större grupp. DeHa möte hålls på den sista dagen i sprinten där kunder, användare och produktägare 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. SyUet med mötet är ah det är eh arbetsmöte där frågor, diskussioner och förslag uppmuntras. Fokus ligger dock i ah informera vad teamet gjort i sprinten. På deha möte bestäms även när nästa planeringsmöte ska hållas. Sprintgranskning, demonstramon Sprintgranskning.. Under granskningen redovisas först status för de i sprinten inplanerade sakerna, däreuer demonstreras klar funkmonalitet för produktägare, kunder och andra inbjudna intressenter. SyUet är ah få in granskningskommentarer från alla deltagare. Speciellt är man intresserad av ah veta vad som är klart och inte. DäreUer redovisar produktägaren sina planer för frammden i form av sin produktbacklog och även denna granskas av alla deltagare. Ger god input Mll euerföljande sprint planeringsmöten. Resultatet av en sprintgranskning är en ny och uppdaterad produktbacklog som avspeglar alla deltagares bästa uppfahning om hur man ligger Mll och vad som ska göras härnäst. Sprintåterblick Återblicksmöte av sprint, ca 3 Mmmar långt. DeHa 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åh bra respekmve mindre bra så ah man kan förbähra sig Mll nästa sprint. Möjlighet för teamet ah inspektera sig själva och göra en plan för förbähringar Mll nästa sprint. Följande tre frågor besvaras: - Vad bör vi fortsäha ah göra (bevara)? - Vad bör vi sluta ah göra (undvika)? - Vad bör vi pröva ah göra (pröva)? Scrum - artefakter Produktbacklogg Sprintbacklogg Burn- down chart Increment Produktbacklogg I scrum finns det inte en klassisk kravspecifikamon utan man har istället en backlogg. Ägs och hanteras av produktägaren. innehåll, Mllgä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ähre specificerat ska ändringsönskemålet vara. DeHa innebär ah i eh 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 Mll. Sprintbacklogg Den del av en produktbacklogg som utvecklingsteamet åtar sig ah implementera under en sprint samt den plan som de formulerat för hur de ska göra det. En lista med uppgiuer och en uppskahning av Md det går åt för en person ah sluuöra en uppgiu. VikMgt ah det är teamet som väljer vad och hur mkt de ska göra euersom det är de som är yherst ansvariga för ah fullfölja det. 10

11 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 Mdsplanerade arbetet. Diagrammet visar tydligt i vilken takt man bränner av de kvarvarande Mmmarna av en sprint. Inkrement Summan av alla delar i produktbacklogg som gjorts färdiga under en sprint och Mdigare sprintar. Teamet levererar eh inkrement av funkmonalitet vid varje sprint. Vid slutet av en sprint måste det nya inkrementet vara klart (done) användbart skick och uppfylla definimonen av klar som teamet gjort Done måste förstås av alla, tydlig definimon Det styr/stöder val av delar från backlogg! Scrum - teori Scrum grundar sig på empirisk processtyrningsteori, eller empirism. Empirismen säger ah kunskap kommer av erfarenhet och av beslutsfahande som baseras på det som är känt. Scrum använder eh iteramvt, inkrementellt MllvägagångssäH för ah opmmera förutsägbarhet och hantera risk. Varje implementamon av empirisk processtyrning vilar på tre pelare: transparens, granskning och anpassning. Scrum - teori Transparens Alla vikmga aspekter av processen måste vara synliga för de som är ansvariga för resultatet. DeHa kräver ah dessa aspekter är definierade i en gemensam standard så ah alla delar en gemensam förståelse av det man ser. EH gemensamt språk måste delas av alla deltagare när man pratar om processen. En gemensam definimon på klar måste delas av de som uuör arbetet och de som ska acceptera det. Scrum - teori Granskning Användare av Scrum måste oua granska scrumartefakter samt vägen mot eh mål, för ah upptäcka oönskade avvikelser. Granskningarna bör inte ske så oua ah 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 Mll arbetet. Scrum - teori Anpassning Om en eller flera aspekter hos processen avviker från det som är acceptabelt (rimliga gränser) och resultatet (målet) kommer ah bli oacceptabelt 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 ah minimera yherligare avvikelser. Scrum föreskriver fyra formella Mllfällen för granskning och anpassning: akmviteter: Sprintplaneringsmöte Dagligt scrummöte Sprintgranskning Sprintåterblick 11

12 Referenser Schwaber, K Agile Project Management With Scrum. Rubin, K.S EssenMal Scrum. Scrum Guiden: Den definimva guiden Mll Scrum: Spelets regler. Oktober 2011 (finns snart på kurshemsidan). Förväntningar Gå in på djupet i en agil metod och följa den strikt i projektet Djupare förståelse för agila processer Kunskaper om användbarhet för handhållna enheter (mobiler) ah utveckla för dessa Bredd på material och utvecklingsmiljö Föreläsningar som ger många prakmska instrukmoner så det är läh ah veta hur man Mllämpar det i projektet, läha ah konkret koppla Mll projektet AH lärarna är närvarande och kontaktbara AH det inte är en kurs där man ska lära sig ah arbeta i grupp det ska vi kunna nu Få en känsla av hur det fungerar ute i arbetslivet Hur det är ah jobba med eh projekt Mllsammans med eh företag EH projekt så likt arbetslivet som möjligt Givande projekt med eh resultat man kan visa upp utan ah skämmas Farhågor Inga det mesta kommer ah vara nyh Inga PUM var ganska allmän, projektet öppet För likt PUM AH föreläsningarna blir flummiga ah man lika gärna kan läsa in slidsen och skippa föreläsningarna (tråkiga/inte givande föreläsningar), ej relevanta fakta Detaljerad utanmllkunskap typ definimoner av ord Mll tentan AH labb och miniprojekt inte är relevanta eller ah de är för tunga, nära inpå tentan AH det man lär sig inte är frammdssäkert Hela dagar under projektet, ah Mden inte ska räcka Mll För stora projektgrupper ojämn fördelning av arbete pga roller (ambimonsnivå, inte jobbar bra ihop) svårt ah sysselsäha 10 pers jämfört med 4 hamna i en miljö gruppen inte behärskar ah projektet misslyckas Tack vi ses på onsdag nästa vecka! (Msdag 5 feb utgår). 12