Agil användbarhetsutveckling för handhållna enheter TNM082, VT2015, FÖ1 Idag IntrodukEon Formaliteter Kursinnehåll InspiraEonJ Formaliteter Personal Camilla Forsell (föreläsningar, projekt, kursansvarig/examinator) camilla.forsell@liu.se Kopparhammaren 2 (K2) plan 2, rum 2031 Formaliteter Är du registrerad och med på maillistan? Per Lind (laboraeon, projekt) perli379@student.liu.se Lesley BornhoX (kursadministraeon) lelsey.g.bornhox Kopparhammaren 2 (K2) plan 2, rum 2036 Formaliteter Kurshemsida h]p://www.itn.liu.se/grundutbildning/kurs/tnm082?l=svitn/ utbildning/grundutbildning/kurser/tnm082 Via ITNs hemsida/grundutbildning/kurser (googla inte!) Mål (Kursplan) Mål Kursen syxar Ell a] ge en god förståelse för hur användarcentrerad utveckling bedrivs, specifikt i förändringsbenägna projekt, med fokus mot applikaeoner för handhållna enheter, exempelvis mobiltelefoner och surfpla]or. 1
Mål (Kursplan) Mål: Studenten skall exer genomgången kurs kunna: Tillämpa formella principer för agila utvecklingsmetoder Integrera användbarhetsutveckling med övriga delar inom agil systemutveckling Tillämpa formella principer för mobil interakeonsdesign Designa och programmera enkla grafiska Ellämpningar för handhållna enheter Bedriva fältstudier för kartläggning av e] problemområde inom interakeonsdesign Genomföra en användaranalys och en behovsanalys samt modellera och dokumentera dessa Formellt ueöra användningstest både med och utan användare Mål (Kursplan) Mål: Dessutom ska projektarbetet lära studenten a]: Skapa enkla och kreaeva lösningar Ell komplicerade problem. Kommunicera och fungera socialt i e] team. Ta och ge återkoppling på e] konstrukevt och givande sä]. Vara öppen för konenuerliga förändringar. Reflektera över ueört projektarbete och föreslå förbä]ringar runt metod och resultat. OrganisaEon (Kursplan) Kursinnehåll: Användbarhetsutveckling: Användarcentrerad systemutveckling, målgruppsanalys, personas, prototyping. Användbarhetsutvärdering: KvanEtaEva och kvalitaeva användningstest. InterakEonsdesignmetodik: Brainstorming, storyboards, kreaevitetsövningar. Agil utveckling: Parprogrammering, testdriven utveckling och omfaktorisering. Li]eratur Föreläsningsmaterial och annat material hemsida Kursli]eratur EssenEal Scrum: A PracEcal Guide to The Most Popular Agile Process. Rubin S.K. 2013. Agile SoXware Development With Scrum. Schwaber, K. & Beedle. M. 2008. Agile Project Management With Scrum. Schwaber, K. & Beedle. M. 2004. OrganisaEon (Kursplan) OrganisaEon: Kursen pågår hela vårterminen. Kursen består av föreläsningar, seminarier (nu workshop), projekeörberedelse och programmeringsuppgix i period 1 och projektarbete i period 2. Projektet i period 2 bedrivs under flera heldagar varje vecka i en och samma laboraeonssal. Formaliteter Kursstruktur VT1 v4-10: Föreläsningar och workshop Agil systemutveckling, Srum (Camilla) Användbarhet, sem utvärdering sem (Camilla) sem Inför projekt (Camilla) Hur maskiner kommunicerar (Pierangelo DellAqua),,,, Programvaruutvecklingsmetodik (KJ)? 1 Workshop (Camilla) miniprojekt Gäseöreläsning, introdukeon av projekt (Combitech) v11 Redovisning/examinaEon av projekeörberedelse (Camilla) v8-10: 2 LE/lab Android, mobilprogrammering (Per) plus 1 extra Ellfälle för redovisning,,,, 2
Kursstruktur VT1 Förberedelser inför vt2 Projekeörberedelse Gruppindelning (personer/grupp?) Roller Projekthantering gruppkontrakt, behov av kompetensutveckling. metoder för dokumentaeon, kommunikaeon, testning, versionshantering etc. ExaminaEon SkriXligt och muntligt, ca 15min per grupp Kursstruktur VT2 Förberedelser inför vt2 Projekeörberedelse Combitech besöker i slutet av vt 1 introdukeon av företaget presentaeon av projekt Kursstruktur VT2 Schemaförslag v13-14, 16-22 Mån 9-11, Combitech, Lkpg schemalagt 8-12 för resed och undvika schemakrock planering, demonstraeon etc. Es och tors 8-17 heldagar i labsal V 21 eller 22 redovisning ExaminaEon (Kursplan) ExaminaEon: VT1 SkriXlig tentamen (U, 3-5) (? mars) ProgrammeringsuppgiX (U,G) Projekeörberedelse (U,G) (redovisning v 11) VT2 ProjektuppgiX (U,G) (görs i samarbete med Combitech AB, Lkpg, v 13-14, 16-22 redovisning v 21 eller 22) 3 hp 1 hp 2 hp 6hp Kursvärdering 2013-2014 2013 Svarsfrekvens 36 % (10/28) Medelvärde 4.3 (av 5.0) 2014 Svarsfrekvens 44 % (16/36) Medelvärde 5.0 (av 5.0) Kursvärdering KURT 2013 Fritextsvar Om kursen som helhet har jag yberligare ab säga: Jä]ebra genomförd kurs! Tydligt a] examinatorn vill något med kursen! Jag jobbar som summer intern på Netlight ConsulEng i år och är, tack vare kursen, den som har bäst koll på hur man arbetar med agil systemutveckling. De]a även fast de andra sommarjobbarna hunnit längre i deras utbildning. Agila metoder är något som andra universitet verkar ha svårt a] lära ut. SamEdigt är det en mycket exertraktad erfarenhet hos arbetsgivare. A] en kurs är så bra som denna är ovanligt och den kan bara bli bä]re i och med bytet av examinator. Den kommer bli ännu bä]re nästa år. 3
Kursvärdering KURT 2013-2014 Om kompetensutvecklingen som kursen bidragit Gll har jag yberligare ab säga: Kursen har bidragit enormt mycket Ell min personliga utveckling. Jag har känt mig väldigt säker på mi] sommarjobb där vi jobbar med systemutveckling i scrum. Om examinagonen har jag yberligare ab säga: Tentamen borde vara en U/G- dugga exer halva första perioden. Projektet borde komma igång direkt exer de]a. Om kursen som helhet har jag yberligare ab säga: För lite första perioden och lite mycket andra perioden. Kursvärdering 2014 ExaminaGon Bra med tentan innan projektarbetet Jä]ebra upplägg med teoreesk del följt av prakesk del. Labb borde vara 2hp med lite mer bra- a]- kunna grejer för android LaboraEonerna kan gå mer på djupet och bli fler Lite abrupt slut- en diskuterande rapport kring hur det agila arbetet gå] och vilka tankar man har kan finnas med som examinaeonsdel VT1 för lä] vad gäller förhållandet mellan arbetsinsats och betyg - VT2 är bä]re på det sä]et Kursvärdering 2014 Undervisningskvalitet/Kompetensutveckling Bra föreläsningar, anpassade och lärorika Föreläsningarna och tentan innan projektet har bidragit Ell mer agil utveckling Jag har lärt mig otroligt mycket om agil utveckling som jag förmodligen kommer ha stor ny]a av i frameden Jag har lärt mig programmera i android, från a] inte kunna någoneng/ /Ell a] ha ganska god uppfa]ning om hur systemet fungerar Jä]ebra med möten varje vecka med företaget Kursvärdering 2014 Undervisningskvalitet/Kompetensutveckling Välstrukturerad kurs, tydliga krav, bra föreläsningar med tydligt och bra innehåll! Roligt arbetssä]. Kursvärdering 2014 Om kursen som helhet Fler pla]or behövs för a] underlä]a utvecklingsarbetet. En pla]a per grupp är alldeles för lite Borde bli tydligare från kursansvarig hur det ska fungera när vissa elever inte kan vara med på de Emmar som kursen är schemalagd. Har någon svårt a] vara med de dagar som är schemalagda och istället jobbar mycket hemma så förloras hela agiltänket lite. Stor arbetsbörda i vt2 och ganska lite i vt1 Börja projektet Edigare Olika systemutvecklingsprocesser I e] systemutvecklingsprojekt ska man i e] antal steg: ta fram behov och krav på systemet designa konstruera införa- implementera testa utvärdera och följa upp konenuerligt underhålla och utveckla 4
TradiEonell systemutveckling visualiserad Va]enfallsmodeller VaBenfallsmodellen är en sekveneell systemutvecklingsprocess där man ser framstegen som e] flöde (som e] va]enfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstrukeon, test, produkeonssä]ning och underhåll. Tanken är a] varje steg ska vara helt klart och bedömas innan man går vidare Ell nästa steg. Va]enfallsmodeller Modellen har sina rö]er i Ellverknings- och byggindustrin där det är mycket kostsamt a] införa ändringar sent i processen - om inte omöjligt. E] exempel som oxa används på va]enfallsmodellen brukar vara a] bygga e] hus. Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för a] ta fram specifikaeoner i form av olika dokument för a] få söka bygglov. DäreXer byggs huset enligt specifikaeonen. Då byggnaeonen påbörjats är arkitekten frikopplad och inga ändringar görs. EXer byggnaeonen sker infly]ning och drix och underhåll av fasegheten påbörjas. Va]enfallsmodeller Fördelar: Fungerar bra i projekt som är väldefinierade, förutsägbara och där det är osannolikt a] det blir större förändringar. Kostnadskontroll, beställaren (den som betalar) kan besluta i varje steg huruvida projektet ska startas, fortsä]a, avslutas eller läggas på is. E] projekt ska kunna återupptas med hjälp av de dokument som redan gjorts. Resursplanering eller upphandling kan göras mellan stegen. Om kravspecifikaeonen och designen är Ellräckligt bra så ska vem som helst kunna implementera systemet. Det som levereras är testat och är kvalitetssäkrat. Va]enfallsmodeller Nackdelar: OXast är it- system mycket mer komplexa än vad e] hus är a] bygga så denna modell kan/bör bara användas Ell viss del i projekt för it- system. Va]enfallsmodellen hanterar egentligen inte förändringar. E] förändringsförslag (Elläggsbeställning) måste gå igenom flera steg för a] genomföras. Va]enfallsmodeller KriGk Va]enfallsmodellen har få] mycket kriek och de flesta hävdar idag a] det är bevisat via undersökningar a] det inte fungerar för a] utveckla it- system. Det blir mycket dokumentaeon. Mycket av det är nödvändigt, annan dokumentaeon kanske inte kommer a] läsas. 5
Vad kan gå fel i utvecklingsprojekt? Vad går fel i utvecklingsprojekt? Man kan lä] få uppfa]ningen a] många it- projekt misslyckas. Stämmer det? Dessvärre verkar bilden stämma, åtminstone om vi får tro The Standish Group, e] 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 Vad går fel i utvecklingsprojekt? Vad går fel i utvecklingsprojekt? Därför floppade projekten: Tre svenska it- fiaskon under lupp Av Liv Marcks von Würtemberg (forskning inom industriell informaeon och kontrollsystem på KTH) För dyrt, för sent och för dåligt. Forskarna på KTH har tagit en GB på tre skandalomsusade it- projekt och reb ut vad som gick sneb och vad man kunde ha gjort annorlunda. http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp 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 Inte det man behövde Saknar funkeoner eller har onödiga funkeoner man vet inte vad man ska göra, funkeoner utan prioritet Dålig användbarhet man klarar inte uppgixen Vad beror det på? 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? 20 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 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 Ell a] färre personer i ledningsposieon är beredda a] sä]a sig in i hur de fungerar trög process och brist på återkoppling Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rätt. Figur 1. 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. 6
Va]enfall vs. flexibla metoder KriGk Va]enfallsmodellen har få] mycket kriek och de flesta hävdar idag a] det är bevisat via undersökningar a] det inte fungerar för a] utveckla it- system. Modernare metoder menar a] systemutveckling bör vara en mer flexibel process och e] kunskapsutbyte bör ske Gemensamt lärande där alla (beställare, leverantör, användare) Ellsammans lär sig om varandra (behov, kunskaper etc.) och gemensamt bygger e] passande system/en passande lösning i flera steg (iteraeoner) 10 framgångsfaktorer I sin genomlysning listar Standish Group Eo framgångsfaktorer för lyckade projekt. Dessa är: 1. DelakEga slutanvändare 2. Ledningsstöd 3. Tydliga affärsmål 4. Känslomässig mognad 5. Gör bara det som exerfrågas 6. Flexibel process 7. Kunniga projektledare 8. Kunniga medarbetare 9. HandlingskraX 10. Adekvata verktyg Agil systemutveckling Agile är engelska och betyder smidig, vig, lä]rörlig. Agil systemutveckling är e] samlingsnamn för e] antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lä]rörliga metoder. Metoderna följer i stort se] samma värderingar, principer och synsä]. Jämfört med Edigare metoder/modeller representerar de mer flexibla sä] a] arbeta. Va]enfall vs. agila metoder Manifest för Agil systemutveckling Fyra nyckelprinciper: Individer och interakeoner framför processer och verktyg. Fungerande programvara framför omfa]ande dokumentaeon. Kundsamarbete framför kontraktsförhandling. Anpassning Ell förändring framför a] följa en plan. (Delvis misslyckade) http://agilemanifesto.org/iso/sv/ http://www.agilealliance.org/the-alliance/the-agile-manifesto/ 7
Agila utvecklingsmetoder Grundtankarna bakom agilt bygger på a] göra kunden/användaren nöjd med det som utvecklas genom e] mycket nära samarbete under hela utvecklingseden med täta och regelbundna möten mellan utvecklare och beställare/mo]agare. Det agila synsä]et anser a] det oxare är människor och kommunikaeon än verktyg och formella dokument som löser problem under utvecklingsarbetet. Agila utvecklingsmetoder En annan central grundtanke är a] minimera risken för a] en stor del av e] system befinner sig i e] halvfärdigt läge och inte kan leverera ny]a. E] agilt arbetssä] gör det möjligt för beslutsfa]are a] få e] bä]re underlag inför beslut om a] Ellföra y]erligare resurser Ell e] projekt. Arbetet bedrivs inkrementellt och iteraevt vilket innebär a] regelbundna mindre leveranser sker och a] saker löpande utvärderas och kan ändras för a] möta nya krav och önskemål. Tolv grundprinciper Agila metoder Vår högsta prioritet är a] Ellfredsställa kunden genom Edig och konenuerlig leverans av värdefull mjukvara. Förändrande krav är välkomna, även sent i utvecklingen. Agila processen skördar förändring Ell kundens konkurrenskraxighet. Leverera fungerande programvara oxa med Edsskala från e] par veckor Ell e] par månader, med en förkärlek Ell den kortare Edsskalan. Affärsfolk och utvecklare måste arbeta Ellsammans dagligen under hela projektet. Bygg upp projektet runt moeverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem för a] få jobbet gjort. Den mest effekeva metoden för a] förmedla informaeon Ell och inom e] utvecklingsteam är konversaeon på plats mellan individerna (face- to- face). En fungerande programvara är det huvudsakliga må]et 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 Ed. KonEnuerlig uppmärksamhet på teknisk kvalitet och god design ökar flexibiliteten. Enkelhet - konsten a] maximera mängden arbete som inte görs - är vikegt. 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 effekeva, sedan finjusteras det och man anpassar si] beteende därexer. Feature driven development (FDD) Extreme programming (XP) AdapEve soxware development Dynamic Systems Development Method (DSDM) Crystal Lean soxware development Kanban Scrum Scrum Scrum är e] ramverk för mjukvaruutveckling och en projektledningsmetodik. Scrum är som schack. Enkla regler, svårt a] spela. (Henrik Kniberg). http://computersweden.idg.se/2.2683/1.187184/scrum-ar-som-schack 8
Användbarhet Människa- dator interakeon (MDI), Människa- system interakeon (MSI) etc. Användbarhet? Användbarhet Användbarhet Förstå grunderna inom användbarhet utvärdering metoder, processer Och lära er att använda dem användarcentrerad utveckling/design designa för god användbarhet planera och utföra utvärderingar/tester E] användbart system Modeller Mycket enkelt ubryckt!: Tillåter användaren a] fokusera på sina (arbets)uppgixer Innehåller relevant informaeon och funkeonalitet Är intuievt och naturligt a] lära sig Är effekevt i sin dagliga användning Är a]rakevt Designers modell Designer Användares modell Användare Kan jag göra det jag behöver / vill? Kan jag göra det på e] bra sä]. Utan större ansträngning, felfri], kosnadseffekevt, etc. Upplevde jag användningen som rolig semulerande och utan obehag? Om JA på samtliga: 100 % användbarhet!!! System Systembild 9
Modeller Norman ser det hela som kommunikaeon/interakeon mellan två parter: Användaren och Designern. KommunikaEonen sker genom systembilden. Man kan säga a] designerns jobb delas upp i två problem enligt denna modell: A] förstå användarens mentala modell och skapa en bra designmodell uefrån denna kunskap. A] bygga en systembild som är konsekvent och klart och tydligt förmedlar denna modell Ell användaren. Modeller Vi skapar dessa mentala modeller för hur något ska användas genom Edigare erfarenheter, träning och handledning. Norman (2013). En mental modell för e] objekt skapas i stort se] genom a] utvärdera dess möjliga "handlingar" och dess visuella struktur. Med a] utvärdera dess möjliga "handlingar" menas: Vad kan man göra med objektet? Exempelvis om vi vill öppna en dörr så kan olika dörrhandtag utlysa olika möjliga handlingar, likaså kan olika knappar/kontroller etc. i e] gränssni]. Norman, D. 2013. The Design of Everyday Things. Modeller Hemsidor Användarcentrerad systemdesign E] sä] a] förhålla sig Ell utveckling och Ellse a] resultatet blir användbart. Jan Gulliksen & Bengt Göransson, 2002. Användarcentrerad systemdesign: en process med fokus på användare och användbarhet. http://www.usabilitypartners.se/om-anvandbarhet/iso-standarder 10
Användarcentrerad systemdesign Användare De som kommer a] interagera med systemet Inte de som beställer systemet Det finns inget subsetut för rikega användare Centrerad Användarna involveras akevt under hela processen Användarna ska inte vara passiva och bara tycka Ell om färdiga lösningar, de ska vara med och ta fram dem Design All design leder fram Ell en produkt Design är främst en process Design kan också vara en representaeon av en produkt under procesen Användarcentrerad systemdesign Det finns fyra vikega användarcentrerade designakeviteter som ska planeras och äga rum för a] införliva användbarhetskrav i utvecklingsprocessen. Dessa är: a] förstå och specificera användningssammanhanget a] specificera användarnas krav a] ta fram designlösningar som möter användarnas krav a] utvärdera designlösningar mot krav Jan Gulliksen och Bengt Göransson, 2002. Användarcentrerad systemdesign: en process med fokus på användare och användbarhet. Vad påverkar designen? Följande faktorer har vikeg påverkan på designen: Kunskap om användningssituationen Kunskap om användarna Gränssnitt Jan Gulliksen & Bengt Göransson, 2002. Användarcentrerad systemdesign: en process med fokus på användare och användbarhet. Kunskap om människa-dator interaktion (MDI) och design Kunskap om de tekniska förutsättningarna Vad minns ni ifrån TNM040? 11
Användbarhet ny (?) Användbarhet ny (?) Context of use Energy capabilities Connectivity Processing capabilities Data input/output methods Screen size Screen resolution Tack vi ses på torsdag nästa vecka! (Esdag utgår) 12