Kravsammanställning. Förstudie verksamhetsstödjande. Drift & Förvaltning. Affärs-/ processutveckling. Analys & Design. Konstruktion Test Införande

Transkript

1 Erik Borälv Informationsteknologi Uppsala universitet 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»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 #2 Business modeling Usability Design Requirements Analysis & design Implementation Test Deployment Configuration & Change Management: Overview Project Management Environment #3 1

2 Diskussion 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 utveckla och producera kod enligt en annan metod som bättre passar oss? 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? #4 Lyckade/misslyckade IT-projekt % 20% 40% 60% 80% 100% Lyckade Nedlagda Delvis misslyckade #5 För vem utvecklar vi? Kvalité A Kvalité B Funktionalitet Funktionalitet #6 2

3 Fel i systemutvecklingsprojekt? Dålig 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å? #7 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 #8 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! Alltså är det vår kompetens som avgör om det blir bra #9 3

4 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) #10 nyckelprinciper Fungerande system före fullständig dokumentation Kundsamarbete före kontraktsförhandlingar Reagera på förändringar före att följa planer Individer och kommunikation före processer och verktyg The Manifesto, 2000, # #12 4

5 Manifesto Principles 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. Business people and developers must work together throughout the project. 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. 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 #13 Kostnad för förändringar Kostnad Förr Nu Tid i projektet #14 Effektivast ansikte-till-ansikte Communication Effectiveness Paper 2 people on Videotape 2 people at whiteboard 2 people on phone Richness of communication channel #15 5

6 Verktyg, välj rätt byggnad "Make sure there are whiteboards and coffee corners all over the building. (IBM) #16 Är detta en utvecklingsprocess? #17 Vad är extremeprogrammering? 1. Rå hacking utan metod. Mer eller mindre kaotiskt. 2. Strukturerad hacking med fokus på programmering och att leverera buggfria program. 3. En avsiktlig och disciplinerad process för att utveckla fungerande system efter kundens önskemål #18 6

7 Bygger på praxis och väletablerade metoder. Kent Beck (2000) Senaste trenden i software engineering Användbarhet och ACSD är möjligen ett frågetecken XP bakgrund #19 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 #20 Mål med XP-processen Utveckla system som kunden vill ha, fungerar tekniskt och levereras när det behövs. Kan ändras efter nya och ändrade kundkrav även sent i projektet Dvs vi reducerar riskerna med en process som är Enkel & lätt, Snabbrörlig & anpassningsbar och rolig för projektgruppen #21 7

8 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 #22 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 #23 Grundläggande aktiviteter Kodning Kod är den enda nödvändiga artefakten. Testning Det som inte kan bevisas fungera i tester fungerar inte heller. Lyssna utvecklare vet inget om verksamheten. Design (teknisk) arkitektur och kod växer fram, och genom Refaktorering intern omstrukturering av kod utan att yttre beteende förändras #24 8

9 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) #25 XP, del 1 + Få artefakter + Begriplig process + Enkelhet både hos system och utvecklingsmodell + Människor i projektet är viktigare än processen + Ingen övertid Enbart för systemutvecklare Okänd metod #26 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 #27 9

10 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 #28 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 #29 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 #30 10

11 Exempel godisautomat Betalning Acceptera all sorts betalning #1 Färskt godis Ska bara sälja färskt godis #2 Kommunikation #3 Kommunicera med kunden för att undvika fel Lagerhantering Ska automatiskt begära ny leverans innan varan tar slut # #31 Prioritera och splitta user stories Betalning Acceptera mynt #1.1 Betalning Acceptera sedlar Betalning Acceptera kort Betalning Acceptera betalning med mobiltelefon #1.2 #1.3 # #32 Planeringsspelet Story card #33 11

12 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 #34 Är användarcentrerad? For me, UCD is an iterative process whose goal is the development of usable systems, achieved through involvement of potential users of a system in system design. Karat, J. (1996) #35 Är användarcentrerat? Nej? Nackdelar: Fokus på kodning, teknik och att leverera program, men saknar tydligt fokus på användbarhet och ACSD. Involverar kunder, inte nödvändigtvis representativa användare Svårt för användarna att formulera krav Användarna i en gisslansituation Små inkrement - ingen helhetssyn på design av interaktionen #36 12

13 Ä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 Anpassningsbar process Fokus på människor, inte processer #37 Lästips och XP Manifesto for Software Development. Modeling and extreme Programming ngxp.htm Is Design Dead? Martin Fowler Beck, K. (2000). Extreme Programming Explained: Embrace Change #38 Lästips ACSD William Hudson: Adopting UCD within an agile process Larry Constantine: Process Agility and Software Usability Armitage: Are Methods Good for Design? se kursens länksida #39 13