Erik Borälv Main Entry: ag ile Pronunciation: 'a-j&l, -"ji(-&)l Function: adjective Etymology: Middle French, from Latin agilis, from agere to drive, act 1:marked by ready ability to move with quick easy grace <an agile dancer> 2:having a quick resourceful and adaptable character <an agile mind> - ag ile ly /-j&(l)-le, -"ji(l)-le/ adverb Informationsteknologi Uppsala universitet 2006-11-23 #2 Business modeling Usability Design Requirements Analysis & design Implementation Verksamhet Teknik Mål med verksamhet Förbättra verksamhet med hjälp av IT Leverera funktion till efterfrågad kvalitet inom budget och på tid Affärs-/ processutveckling Förstudie verksamhetsstödjande IT Kravsammanställning Analys & Design Konstruktion Test Införande Drift & Förvaltning Test Deployment Configuration & Change Management: Overview Project Management Environment»Att ge verksamheten ITverktyg så att målen kan uppnås. Se möjligheter till effektiviseringar och andra positiva effekter kvalitet i användningatt leverera ett IT-verktyg som uppfyller kraven«återkoppla 2006-11-23 #3 2006-11-23 #4 Frågor Egenskaper Vad menar vi med användarcentrering, i termer av kod och utveckling? Finns det? I så fall, hur kan vi nå det målet? Träffar utvecklare också användare? Metod Kan vi producera kod enligt en annan metod som bättre passar utvecklare? Hur ska man få utveckling och kodning till att bli visionärt, flexibelt och innovativt? Attityd Vad är bra system? Vad gör att system vi bygger är bra? Lyckade/misslyckade IT-projekt 1994 1996 1998 2000 16 27 26 28 31 28 23 40 0% 20% 40% 60% 80% 100% Lyckade Nedlagda Delvis misslyckade 53 46 49 33 2006-11-23 #5 2006-11-23 #6 1
Fel i systemutvecklingsprojekt? Låg användbarhet Annat: Levereras aldrig eller för sent Dyrare än beräknat Låg kvalitet Saknar funktioner eller har onödiga funktioner Vad beror det på? Kvalité För vem utvecklar vi? A Kvalité Funktionalitet Funktionalitet B 2006-11-23 #7 2006-11-23 #8 Upphandling KUNDEN LEVERANTÖREN Krav Analys: behov Analys: tid & pengar Offert Andra problem i systemutveckling Trög process och brist på återkoppling För mycket fokus på processen För stora system/projekt försöker göra allt på en gång. Funktionsrika system för många / fel funktioner utan prioritet. 2006-11-23 #9 2006-11-23 #10 Vad är Agila processer? Ramverk med värden och principer FDD Modeling (Ambler) Adaptive Software Development (Highsmith) Crystal (Cockburn) Scrum extreme Programming (Beck) DSDM (Stapledon) Manifesto Principles, 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 2006-11-23 #11 2006-11-23 #12 2
Manifesto Principles, 2 Är detta en utvecklingsprocess? Working software is the primary measure of progress. processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity-the art of maximizing the amount of work not done-is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 2006-11-23 #13 2006-11-23 #14, nyckelprinciper Fungerande system före fullständig dokumentation Kundsamarbete före kontraktsförhandlingar Reagera på förändringar hellre än att följa planer Individer och kommunikation före processer och verktyg Kostnad Kostnad för förändringar Förr Nu www.agilemanifesto.org Tid i projektet 2006-11-23 #15 2006-11-23 #16 Effektivast ansikte-till-ansikte Communication Effectiveness Paper 2 people on email Videotape 2 people at whiteboard 2 people on phone Richness of communication channel 2006-11-23 #17 2006-11-23 #18 3
Verktyg, välj rätt byggnad "Make sure there are whiteboards and coffee corners all over the building. (IBM) Scrum Ken Schwaber till Financial Times: Scrum is different, he says, as it "takes people out of cubicles and puts them in a room with whiteboards. http://www.controlchaos.com/module/ft.php 2006-11-23 #19 2006-11-23 #20 Bygger på praxis och väletablerade tekniker. Kent Beck (2000) En trend i software engineering Användbarhet och ACSD är möjligen ett frågetecken XP bakgrund extreme Programming (XP) Definition: A software methodology is the set of rules and practices used to create computer programs. A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly. A lightweight methodology has only a few rules and practices or ones which are easy to follow. 2006-11-23 #21 2006-11-23 #22 Vad är extremt? Test är bra testa hela tiden, testa före kodning. Låt användarna testa (enhetstest, testa-först, funktionell test) Kodgranskning är bra granska kod hela tiden (parprogrammering) Iterativ utveckling är bra arbeta i korta iterationer Enkelhet är bra enklast möjliga lösningar, enkla artefakter, enkla metoder Prata med användare är bra låt användare och utvecklare dela rum. extreme Programming (XP) Förändringarna har förändrats Verksamhet förändras hela tiden, alltså bör även systemen göra det Ett nytt sätt att utveckla system Kontinuerliga förändringar! Testdriven process 2 x personer = 1 dator Inga dokument sparas Gemensamma ståmöten Långsiktig planering är osäker, alltså låter man bli sånt 2006-11-23 #23 2006-11-23 #24 4
XP-processen i praktiken Ett system utvecklas iterativt inkrementellt, dvs fungerande system levereras stegvis med mer och mer funktionalitet. Varje sådan fas i utvecklingen kallas en leveranscykel (release cycle) och pågår 3-4 månader. Utgår från användarberättelser (user stories) Användarberättelser (user stories) Något som kunden vill att systemet ska göra. Berättelser ska vara testbara (Beck 2000). Kommunikationssätt utvecklare användare 2006-11-23 #25 2006-11-23 #26 + Få artefakter + Begriplig process + Enkelhet både hos system och utvecklingsmodell + Människor i projektet är viktigare än processen + Ingen övertid XP, del 1 Enbart för systemutvecklare Okänd metod XP, del 2 Att tänka efter ger bättre kvalité än att göra nu Fel: kvalité har med riktig användning att göra, inte planerad användning. T.ex. snabbast ta första tunnelbaneuppgången än den rätta Att göra rätt sak från början är billigare än att rätta i efterhand Fel: troligtvis behövs saken inte alls, om den sedan behövs gör man det då. Dokumentation är viktig att spara Fel: den är så dålig att den inte är värd något 2006-11-23 #27 2006-11-23 #28 XP, del 3 Planera noga för viktiga saker Fel: om framtiden är oklar, och du kan fixa saker i efterhand, varför införa något som man misstänker kan vara bra? Välj bästa lösningen Fel: välj enklaste lösningen, för den är ändå bra nog (och enklare att ändra) Se framåt Fel: gör endast vad du vet, inget mer XP, del 4 Koda, testa sedan att det blev rätt Fel: gör test först, koda sedan Många rader kod/dag, och många funna fel i ett test är bra Fel: få rader går snabbare att skriva, noll antal fel vore bättre 2006-11-23 #29 2006-11-23 #30 5
Vad är rätt uppgång, enligt XP? Planeringsspelet Story card 2006-11-23 #31 2006-11-23 #32 Beräkna arbetsinsats & prioritera användarberättelser Vad jag tror på 1. Viktigast av allt är att hantera förändring Att välkomna förändring; kräver kunskap, förberedelse, lite mod, etc 2. Det är viktigare att göra rätt än allt 3. Allt hänger på de inblandade personerna 4. Det spelar ingen roll hur man gör så längre det blir bra 5. Fungerande kod är grunden till användbarhet Simplicity the art of maximizing the amount of work not done is essential. 2006-11-23 #33 2006-11-23 #34 Vad jag tror på Viktigast av allt är att hantera förändring Med rätt verktyg så går det Det är viktigare att göra rätt än allt Var aldrig nöjd, bevaka inte dina grejer Allt hänger på de inblandade personerna Var duktig på det du gör! Det spelar ingen roll hur man gör så längre det blir bra Det är inte du som avgör när det är bra Fungerande kod är grunden till användbarhet Förenkla i överkant, till en början i alla fall Varför metoder överhuvudtaget? Varför har vi utvecklingsmetoder? 2006-11-23 #35 2006-11-23 #36 6
Metod kvalité? Är det metoder som ger bra system? säger nej - det är personerna i projektet som ger bra resultat. Alltså bör metoder göra andra saker än fokusera på resultatet! Om ej metod! Vad då istället? Är kreativitet svaret? Skapande av nånting helt nytt (okänt för en själv) Nytt sätt att göra nånting Återanvändning av produkt/metod inom nytt område Åstadkomma förändrat synsätt Avsiktligt eller av en slump Alla är kreativa! 2006-11-23 #37 2006-11-23 #38 Teorin kring kreativitet Ett antal stadier man går igenom Förberedelse - problemformulering Inkubation lägga problemet åt sidan Insikt - inspiration Verifiering och genomförande Förutsättningar Måste förstå problemet Behärska teknik bortse från tekniska detaljer Motivation, uthållighet Koncentration Självdisciplin Men hårt arbete är inte en säker väg till rätt resultat Fysiska aktiviteter som t.ex. att promenera inspirerar fria tankar Att göra något helt annat för en stund kan häva låsningar 2006-11-23 #39 2006-11-23 #40 Bodystorm http://ideo.com/about/methods/ 2006-11-23 #41 2006-11-23 #42 7
Var är användaren? 2006-11-23 #43 2006-11-23 #44 2006-11-23 #45 2006-11-23 #46 Att bli bra på testning 2006-11-23 #47 2006-11-23 #48 8
Är användarcentrerat? Nej? Nackdelar: Fokus på kodning, teknik och att leverera program, men saknar explicit fokus på användbarhet Involverar kunder, inte nödvändigtvis representativa användare Svårt för användarna att formulera sina behov Små inkrement - ingen helhetssyn på design av interaktionen 2006-11-23 #49 2006-11-23 #50 Är användarcentrerat? Ja, kanske? Fördelar: Användarberättelser, skrivs och testas av användare Direkt kommunikation med användare Prototyper & enkla designrepresentationer Iterativt & inkrementell utveckling Kontinuerlig test & utvärdering av riktiga system av utvecklare och riktiga användare Förändring är möjligt & naturligt Fokus på människor, inte processer Lästips och XP Extreme Programming http://www.extremeprogramming.org/ Manifesto for Software Development. http://www.agilealliance.org/ Modeling and extreme Programming http://www.agilemodeling.com/essays/agilemodeli ngxp.htm Is Design Dead? Martin Fowler http://martinfowler.com/articles/designdead.html 2006-11-23 #51 2006-11-23 #52 Lästips ACSD William Hudson: Adopting UCD within an agile process http://www.syntagm.co.uk/design/articles/ucdxp03.pdf Larry Constantine: Process Agility and Software Usability http://www.foruse.com/articles/agiledesign.pdf 2006-11-23 #53 9