Agil användbarhetsutveckling för handhållna enheter TNM082, VT2016, FÖ2 Idag Agila metoder Förväntningar AF projektet ska bli kul och af man ska få fokusera en del på användbarhet i projektet. BäFre på af leda projekt och förutsäga hur lång Kd det tar af utveckla en produkt. AF lära mig hur man arbetar agilt på rikkgt. BäFre på af Kllämpa agila metoder inom systemutveckling. BäFre på af arbeta effekkvt i grupp. AF få kunskap om hur man hanterar projekt som går fel. Få bäfre erfarenhet av utveckling mot mobila enheter. Utveckling i android och/eller ios. Välja vad vi vill utveckla inom ganska fria ramar. Jobbar gärna med scrum som i kandidaten men hoppas på lite fokus på andra agila metoder också. Farhågor AF jag får ef projekt som är tråkigt. AF kursen är ytlig och blir en repekkon av kandidatarbetet. AF projekrörberedelsen bara blir en tråkig rapport likt kandidaten. AF teoridelen ska vara väldigt lik kandidaten. AF det kan vara svårt af uppfylla kundens krav i projektet. AF arbeta i projekt Era erfarenheter Av modeller, metoder, processer säf af arbeta Teori och prakkk Fördelar Nackdelar Vad fungerar bra? Vad är det som (owa/läf) går fel (om något) Vad saknas? Känns för mycket/för lite? TradiKonell projektmodell med indelning i projekraser. Även en modell av agilt arbete. 1
VaFenfallsmodell Va#enfallsmodellen är en sekvenkell systemutvecklingsprocess där man ser framstegen som ef flöde (som ef vafenfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstrukkon, test, produkkonssäfning och underhåll. Tanken är af varje steg ska vara helt klart och bedömas innan man går vidare Kll nästa steg. Analys Kravspec. Design KonstrukKon IntegraKon Test Utvärdering InstallaKon Underhåll Ger svar på vad projektet ska åstadkomma. Här fastställs vilka målen är med projektet och vilken nyfa resultatet ska ha. Här definieras projektets ramar som anger gränser för Kd, kostnad och omfång. Frågor som ska besvaras: Varför ska projektet genomföras? Vilken nyfa fås genom af projektet genomförs? När startas genomförandet och när är det tänkt af projektet ska avslutas? Hur mycket pengar (Kd eller andra resurser) ska investeras? Vad ska göras? Ger svar på hur projektet ska genomföras. Fem nivåer av planering: Vision Färdplan Leveransplan Etapplan Daglig plan Fem nivåer av planering: Vision Visar projektets slutmål Färdplan Översiktlig bild av när olika projektresultat ska vara färdiga, utan af garantera datum eller detaljer. Är näst ewer visionen den mest långsikkga planeringen och bör inte gå in på detaljer. Leveransplan Innehåller exakta Kdsgränser och vikkga datum (milstolpar). Kan göras flera gånger (och visa den Kdsperiod som projektet för Kllfället har nyfa av af kommunicera exakta datum kring). Etapplan En etapp innebär ef eller flera mindre ufalade delmål. För varje etapp ska projektet sluröra/leverera ef specifikt resultat. Slutdatum är heligt och justeras inte, istället anpassas (vid behov) arbetet och vissa akkviteter stryks. Daglig plan Här genomförs projektet för andra gången. Under planeringsfasen genomförs det i teorin men här genomförs det på rikkgt. Agila metoder lywer fram två områden avseende genomförande av projekt. Processen som beskriver hur vi ska arbeta dag för dag. PrakKska frågor för effekkvare projektarbete (och framgång). VikKgt och tydligt verktyg är projekfavlan (ej påbörjat, påbörjat, klart) 2
När projektet är genomfört måste owa resultatet överlämnas Kll en annan part. Den nyutvecklade produkten överlämnas Kll produkkonsavdelningen som påbörjar Kllverkning. AF avsluta ef projekt innebär owa två moment: Överlämning av projektresultat (Kll någon som får ansvaret för af det används, utvecklas, sköts om) EWerarbete (lämna Kllbaka resurser som material, människor, rapportera slutsatser och erfarenheter från projektet) Beslut vid fasövergångar För varje fasövergång finns owa en beslutspunkt. Det innebär af exempelvis styrgrupp, beställare etc. måste fafa två beslut: 1. Ska nästa fas påbörjas? 2. Ska föregående fas avslutas? EF beslut? (af avsluta en fas för af påbörja nästa) eller två? Många betraktar det här som e# beslut. För af få bäfre kontroll på ef projekt och dess resurser finns en fördel i af dela upp beslutet i två delar. Beslut vid fasövergångar För varje fasövergång finns owa en beslutspunkt. Det innebär af exempelvis styrgrupp, beställare etc. måste fafa två beslut: 1. Ska nästa fas påbörjas? 2. Ska föregående fas avslutas? EF beslut? (af avsluta en fas för af påbörja nästa) eller två? Betraktar man fasövergången som två beslut kan man, som svar på ovanstående frågor, besluta: 1. Ja, vi påbörjar nästa fas. 2. Nej, x behöver förbäfras innan vi kan avsluta den föregående fasen. Flexibilitet vid fasövergångar VaFenfallsmodell Genom af tänka i termer av faser och genom användandet av beslutspunkter får projekt owa god struktur och möjlighet Kll god styrning. Genom tydliga steg kan man avsluta en fas innan nästa påbörjas Enklare af ha ef begränsat område af fokusera på, än af hantera flera/många på en och samma gång. Det finns också risker med ef sådant synsäf, exempelvis af man får en förenklad uppfafning om projekt som något som går i prydliga, exakta steg och om projekt inte förlöper (enligt plan) så är det ef tecken på ef misslyckande-af det sköts dåligt. Va#enfallsmodellen är en sekvenkell systemutvecklingsprocess där man ser framstegen som ef flöde (som ef vafenfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstrukkon, test, produkkonssäfning och underhåll. Tanken är af varje steg ska vara helt klart och bedömas innan man går vidare Kll nästa steg. Analys Kravspec. Design KonstrukKon IntegraKon Test Utvärdering InstallaKon Underhåll 3
SammanfaFning Denna brist i synsäf på projekt - som en serie disknkta faser är en av de saker som fåf den agila rörelsen af vända sig mot det tradikonella säfet af driva projekt, inom mjukvaruutveckling såväl som inom andra områden. Inom systemutvecklingsbranshen har det uppståf en motreakkon mot Kll tradikonella metoder för projektledning/utveckling. Deltagare har känt sig hindrade snarare än hjälpta av befintliga metoder. Upplevdes som stakska och tröga. De sökte ewer säf af fortsäfa producera it-system med hög kvalitet och med någon form av projektledning som gav dem rikkgt stöd. Metodutvecklare började därför leta ewer tekniker som skulle kunna hantera större flexibilitet, det vill säga möjligheten af förändra krav löpande men med bibehållen kontroll och kvalitet. UKfrån defa behov formades de agila metoderna. Vad kan gå fel i utvecklingsprojekt? Man kan läf få uppfafningen af många it-projekt misslyckas. Stämmer det? Dessvärre verkar bilden stämma, åtminstone om vi får tro The Standish Group, ef 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. http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp Därför floppade projekten: Tre svenska it-fiaskon under lupp Av Liv Marcks von Würtemberg (forskning inom industriell informakon och kontrollsystem på KTH) För dyrt, för sent och för dåligt. Forskarna på KTH har tagit en G# på tre skandalomsusade it-projekt och re# ut vad som gick sne# och vad man kunde ha gjort annorlunda. http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp (Delvis misslyckade) 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). 4
Levereras aldrig eller för sent Dyrare än beräknat Låg kvalitét Levererar inte det man behövde Saknar funkkoner eller har onödiga funkkoner man vet inte vad man ska göra, funkkoner utan prioritet Dålig användbarhet man klarar inte uppgiwen Vad beror det på? Förändring (allt förändras) verksamhet önskemål/krav teknik Andra problem konsulter anlitas som kan IT men inte verksamheten de skall stödja, bristande kompetens i flera led för stora system/projekt man försöker göra allt på en gång mjukvara är komplex och ogripbar, system blir alltmer komplexa vilket leder Kll af färre personer i ledningsposikon är beredda af säfa sig in i hur de fungerar trög process och brist på återkoppling TradiKonell systemutveckling visualiserad Hur ska vi nå hit? Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rätt. 10 framgångsfaktorer VaFenfall vs. agila metoder I sin genomlysning listar Standish Group Ko framgångsfaktorer för lyckade projekt. Dessa är: 1. DelakKga slutanvändare 2. Ledningsstöd 3. Tydliga affärsmål 4. Känslomässig mognad 5. Gör bara det som ewerfrågas 6. Flexibel process 7. Kunniga projektledare 8. Kunniga medarbetare 9. HandlingskraW 10. Adekvata verktyg (Delvis misslyckade) 5
Agil systemutveckling Agile är engelska och betyder smidig, vig, läfrörlig. Agil systemutveckling är ef samlingsnamn för ef antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade läfrörliga metoder. Jämfört med Kdigare metoder/modeller representerar de mer flexibla säf af arbeta. Metoderna följer i stort sef samma värderingar, principer och synsäf. Agil systemutveckling Handlar om flexibilitet och en strävan af hela Kden förbäfra sif projektarbete. Åstadkoms genom korta etapper som består av cykler av af planera, uröra, kontrollera och därewer handla ukfrån dragna slutsatser. I agila projekt ruckar man inte på etappernas längd och tack vare af arbetet delas upp i etapper blir det Kdigt synligt om resultatkrav och Kdsramar är rimliga. Handlar inte om projektledare som beslutsfafare utan om af få gruppen af leda ef projekt genom af få mandat af vara självgående. Finns en projektledare blir dennes huvudfokus istället af undanröja hinder för af få gruppen af bli så effekkv och framgångsrik som möjligt. Agil systemutveckling Benämningen agil kom Kll 2001. 17 metodutvecklare samlades i skidorten Snowbird, Utah, för af diskutera det som då kallades läfrörliga eller läfvikkga metoder. Gemensamt namn och gemensamma värderingar ansågs vikkga. Begreppet Agile blev det framröstade förslaget. I Sverige är ordet agil (försvenskat) den vedertagna benämningen för metoderna. Individer och interakkoner framför processer och verktyg. Fungerande programvara framför omfafande dokumentakon. Kundsamarbete framför kontraktsförhandling. Anpassning Kll förändring framför af följa en plan. http://agilemanifesto.org/iso/sv/ http://www.agilealliance.org/the-alliance/the-agile-manifesto/ Individer och interakkoner framför processer och verktyg. Hur projektgruppen är sammansaf och hur personerna kan samarbeta måste föregå vilka processer och verktyg som gruppen behöver. Om processer och verktyg skulle vara vikkgare än individer och interakkoner skulle projektgruppen allkd följa en ufalad mall för den exakta processen och för de givna verktygen oavsef gruppsammansäfningen. Det betyder af i de fall något går snef skulle gruppen kunna luta sig Kllbaka och säga Vadå? Vi följde ju bara processen. Det kan ni inte hålla oss ansvariga för?. Den här punkten innebär alltså a# projektgruppen anvsarar för a# arbetet uiörs med bästa möjliga process och verktyg. Det betyder inte af agila projekt inte kan följa en ufalad process, det betyder bara af projektdeltagarna är ansvariga för a# göra de modifieringar av eller avsteg från processen som behövs för a# bli så framgångsrika som möjligt. 6
Fungerande programvara framför omfafande dokumentakon. Det vikkga är af se Kll af resultat produceras löpande i projektet. Arbetet delas in i korta cykler (etapper) och varje etappstart ger möjlighet Kll kontroll och förändring. I varje arbetscykel är strävan af leverera ef delresultat som är så färdigt som möjligt. Man siktar alltså inte in sig på en enda leverans långt fram i Kden, där resultatet först då ska bli användbart. Istället ska projektgruppen leverera användbart resultat löpande under hela projektet. Det gör af mogvagonen inom gruppen ökar då man ser löpande resultat. Andra (beställare, kund etc.) kan också se vilka resultat som uppnåfs vid slutet av varje etapp. EF litet avslut vid varje etapp gör det också möjligt a# avsluta projektet när som helst. Kundsamarbete framför kontraktsförhandling. De flesta vill hellre ha ef fungerande kundsamarbete än kontraktsförhandlingar. I undersökningar kring framgångsfaktorer i projekt hamnar allkd kund- och/eller beställarsamarbete i topp. Det har man vetat länge inom projektledning så vad är då specifikt eller nyf inom det agila? TradiKonellt har man bara pratat om a/ kundsamarbete är vikkgt men inte hur det ska uppnås. Inom agilt arbete däremot, görs ef stopp i varje arbetscykel, då projektgruppen visar upp det delresultat som åstadkommits och låter kunden se, känna på och diskutera projektresultatet. DeFa görs med jämna mellanrum (som mest med en månad) vilket gör af kunden under hela projektet är närvarande och har möjlighet a# påverka projektet. De 12 agila principerna Anpassning Kll förändring framför af följa en plan. Inom agila projekt utgår man ifrån af det är lönlöst af försöka förutse exakt hur allkng blir i framkden. Man förutser af planer som skrivs innan ef projekt startas trologtvis kommer af behöva justeras alltewersom projektresultat växer fram, ewersom omvärlden förändras och kunden eller beställaren löpande får insikter kring hur projektresultat ska bli ännu bäfre. Förändringar är naturliga och vägen Kll utmärkta projektresultat är inte af spendera yferligare en månad? på af planera projektet utan ha en process som möjliggör, och även välkomnar, förändring. Det innebär dock inte af dessa kan ske hur som helst i ef projekt. Det kan leda Kll kaos och inetkvitet. Den agila principen är a# leta ejer behov av, och förslag på, förändring vid varje stopp som de återkommande arbetscyklerna innebär. Om varje cykel är Kllräckligt kort kan projektgruppen arbeta effekkvt utan förändring så länge den varar, men det är Kllåtet med löpande förändring. För af förtydliga det agila manifestet, som visar agila värderingar, beskrevs 12 principer som skulle visa hur värderingarna ska ewerlevas. I sin ursprungsform kretsar principerna kring begrepp som programvara och utvecklare ewersom de urormades av metodutvecklare inom it. Dessa termer kan ersäfas med de mer generella termerna projektresultat och projektdeltagare, vilket visar af tankegångarna kan Kllämpas på projekt även inom andra områden. De 12 agila principerna En anpassningsbar metod 1. Vår högsta prioritet är af Kllfredsställa kunden genom Kdig och konknuerlig leverans av värdefull programvara (värdefullt projektresultat). 2. Förändrande krav är välkomna, även sent i utvecklingen. Agila metoder utnyfjar förändring Kll kundens konkurrensfördel. 3. Leverera fungerande programvara owa (värdefullt projektresultat), med ef par veckors Kll ef par månaders mellanrum, ju oware desto bäfre. 4. Verksamhetskunniga och utvecklare (projektdeltagare) måste arbeta Kllsammans dagligen under hela projektet. 5. Bygg projekt runt mokverade individer. Ge dem den miljö och det stöd de behöver, och lita på af de får jobbet gjort. 6. KommunikaKon ansikte mot ansikte är det bästa och effekkvaste säfet af förmedla informakon, både Kll och inom utvecklingsteamet (projektgruppen). 7. Fungerande programvara (användbart projektresultat) är främsta måfet på framsteg. 8. Agila metoder verkar för hållbarhet. Sponsorer, utvecklare (projektmedlemar) och användare ska kunna hålla en jämn utvecklingstakt (arbetsbelastning) på obestämd Kd, under obegränsad Kd. 9. KonKnuerlig uppmärksamhet på förstklassig teknik och god design stärker anpassningsförmåga. 10. Enkelhet - konsten af maximera mängden arbete som inte görs - är grundläggande. 11. Bäst arkitektur, krav och design (projektresultat) växer fram med självorganiserande team. 12. Med jämna mellanrum reflekterar teamet över hur det kan bli mer effekkvt och justerar (anpassar) sif beteende därewer. Fler och fler företag inom vif skilda branscher anammar de agila värderingarna i mer eller mindre renlärig form. De 12 principerna är inte odelbara och kan variera i betydelse beroende på bransch och typ av projekt. AF anamma ef agilt förhållningssäf behöver inte innebära af man Kllämpar samtliga 12 principer. 7
Principerna ger vägledning I viss mån låter det agila manifestets 12 förklarande principer som vanligt sunt förnuw. Men det sunda förnuwet brister owa (erfarenheter från tradikonellt bedrivna/ledda projekt). Förlorat fokus, glömmer af ta in åsikter från verksamhetsnära personer, man glömmer bort vad användbart resultat är. Ändrade krav från beställaren mofas med förvåning och motstånd trots af risk för förändrade omständigheter är verklighet för alla projekt. Etc. Agila metoder AdapKve sowware development Feature driven development (FDD) Dynamic Systems Development Method (DSDM) Crystal Lean sowware development Extreme programming (XP) Kanban Scrum A# ha principer som dessa formulerade hjälper alla involverade i projektet a# bli medvetna så a# fel kan rä#as Gll innan de egentligen uppstå#. Scrum Tack vi ses på Ksdag nästa vecka! (nu på torsdag har Per introdukkon Kll laborakon) Referenser: Gustavsson, Tomas (2013). Agil projektledning. Sanoma utbildning. 8