Agile. Frågor. Lyckade/misslyckade IT-projekt

Storlek: px

Starta visningen från sidan:

Download "Agile. Frågor. Lyckade/misslyckade IT-projekt"

Sebastian Ekström
för 5 år sedan
Visningar:

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

1 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 #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 # #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 % 20% 40% 60% 80% 100% Lyckade Nedlagda Delvis misslyckade # #6 1

2 Fel i systemutvecklingsprojekt? Orsaker? Låg användbarhet Man klarar inte uppgiften Levereras aldrig eller för sent Man vill inte Saknar funktioner eller har onödiga funktioner Man vet inte vad man ska göra Kvalité För vem utvecklar vi? A Kvalité B Funktionalitet Funktionalitet # #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 # #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 # #12 2

Manifesto Principles, 2 Är detta en utvecklingsprocess? Working software is the primary measure of progress. processes promote sustainable development.

Simplicity-the art of maximizing the amount of work not done-is essential. The best architectures, requirements, and designs emerge from self-organizing teams.

2007-11-29 #13 2007-11-29 #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

3 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 # #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 Tid i projektet # #16 Communication Effectiveness Effektivast ansikte-till-ansikte Paper 2 people on Videotape 2 people at whiteboard 2 people on phone Verktyg, välj rätt byggnad "Make sure there are whiteboards and coffee corners all over the building. (IBM) Richness of communication channel # #18 3

Scrum XP bakgrund 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.

A lightweight methodology has only a few rules and practices or ones which are easy to follow. 2007-11-29 #19 2007-11-29 #20 Vad är extremt?

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

4 Scrum XP bakgrund 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. Bygger på praxis och väletablerade tekniker. Kent Beck (2000) 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 Vad är extremt? extreme Programming (XP) 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. 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 # #22 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 # #24 4

Beräkna arbetsinsats & prioritera användarberättelser + Få artefakter + Begriplig process + Enkelhet både hos system och utvecklingsmodell + Människor i projektet är viktigare än processen + Ingen

Dokumentation är viktig att spara Fel: den är så dålig att den inte är värd något 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

5 Beräkna arbetsinsats & prioritera användarberättelser + 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 # #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 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 Vad är rätt uppgång, enligt XP? # #30 5

6 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? # #32 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 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! # #34 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 Gör detta under inkubation! 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 # #36 6

7 Bodystorm # #38 Var är användaren? # # # #42 7

Att bli bra på testning 2007-11-29 #43 2007-11-29 #44 Är användarcentrerat? Nej?

representativa användare Svårt för användarna att formulera sina behov Små inkrement - ingen helhetssyn på design av interaktionen 2007-11-29 #45

Fördelar: Användarberättelser, skrivs och testas av användare Direkt kommunikation med användare Prototyper & enkla designrepresentationer

naturligt Fokus på människor, inte processer Lästips Modeling and extreme Programming http://www.agilemodeling.com/essays/agilemodelingxp.

8 Att bli bra på testning # #44 Ä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 # #46 Ä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 Modeling and extreme Programming m Is Design Dead? Martin Fowler William Hudson: Adopting UCD within an agile process Larry Constantine: Process Agility and Software Usability # #48 8

Relevanta dokument

Agile. Frågor. Lyckade/misslyckade IT-projekt

Agile. Frågor. Lyckade/misslyckade IT-projekt 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