<< Processmodeller >> Grundläggande processmodeller

En presentation över ämnet: "<< Processmodeller >> Grundläggande processmodeller"— Presentationens avskrift:

1 << Processmodeller >> Grundläggande processmodeller
Koda och fixa Vattenfall Iterativ och inkrementell Lättrörlig (agile) 1

2 << Processmodeller >> Koda och fixa
Kravspec (frivilligt) Leverans (kanske) Hanterar inte problemen vid utveckling Kan ändå användas ibland: Ingen overhead => snabb. Kräver ingen process kunskap => oerfaren personal kan användas Användbar för små subprojekt där koden strax skall kastas (GUI-prototyp…) 2

3 << Processmodeller >> Vattenfallsmodellen
K Kod I D T << Processmodeller >> Vattenfallsmodellen KRAV V DESIGN V KOD & TEST V INTEGRATION V FÖRVALTNING V 3

4 << Processmodeller >> Vattenfallsmodellen
K Kod I D T << Processmodeller >> Vattenfallsmodellen Också känd som: Den klassiska livscykelmodellen ”Once-through” “Big bang integration”. Sekventiell process Processen flödar bara i en riktning, varav namnet vattenfall. Det *går* att gå tillbaka, men det kostar. Processen är byggd på att man inte får en chans till att revidera innevarande steg senare varför man lägger ned mycket energi på att få allt rätt från början innan man går till nästa steg… 4

5 << Processmodeller >> Vattenfall - positivt
K Kod I D T << Processmodeller >> Vattenfall - positivt Indelning i discipliner (=faser) => möjligt att dela upp arbete mellan utvecklare. Arbetsuppdelningen => utvecklare kan specialisera sig. Seniora utvecklare i de tidiga faserna => juniora utvecklare kan vara produktiva… i de senare faserna 5 [DeGrace 1990]

6 << Processmodeller >> Vattenfall - problem
Utvecklingsprocesser (kurs 6B3023) K Kod I D T << Processmodeller >> Vattenfall - problem Förståelse för problemet nås ofta först efter vi börjat med lösningen Krav är vanligen ofullkomliga; ”I Know It When I See It” (IKIWISI)… Osynlig produkt till slutet av projektet. Fokus på projektet (dokument) ej på produkten (kod). Slutanvändarens feedback kommer för sent Det tar lång tid innan problem syns Seniora utvecklarna drar vidare efter de tidiga faserna… vem skall då de juniora fråga? 6 [DeGrace 1990] Leif Hedegård 6

7 << Processmodeller >> Vattenfall - problem
K Kod I D T << Processmodeller >> Vattenfall - problem KRAV V DESIGN Pengar eller tid slut V Resultat = Inget KOD & TEST V INTEGRATION V FÖRVALTNING V 7

8 << Processmodeller >> Vattenfall - problem
K Kod I D T << Processmodeller >> Vattenfall - problem ”De viktigaste besluten fattas när kunskapen om projektet är som sämst” Hög Kunskap om projektet Krav Design Beslutens påverkan på projektet Impl Test Driftsättn Låg Tid 8 [Wenell 2001, s 48, modif]

9 << Processmodeller >> När upptäcks och möts risker?
Kod I D T << Processmodeller >> När upptäcks och möts risker? Risk Krav Vattenfall Risknivå sjunker sent Design  Impl Test Driftsättn Tid 9

10 << Processmodeller >> Vattenfall - användningsområde
K Kod I D T << Processmodeller >> Vattenfall - användningsområde Kan användas när: kraven är väl kända och arkitekturen är väl känd och det finns tillräckligt med kalendertid för att arbeta sekventiellt Exempel på rimligt användande: anpassning av en produkt ur en produktlinje till en viss kund utveckling av en kompilator 10 [DeGrace 1990, Boehm 2000 s 8, (kompilator tillagt)]

11 Vattenfallsmodellen Iterativt & inkrementellt A X B A B
Utvecklingsprocesser (kurs 6B3023) K Kod I D T << Processmodeller >> Hur komma åt problemen med vattenfallsmodellen? Vattenfallsmodellen Iterativt & inkrementellt Förvirring Komplexitet Komplexitet Förståelse Förståelse A X B A B Problemstorlek Problemstorlek Dela upp problemet i mindre bitar och lös bit för bit (“Divide and conquer”) 11 Fritt efter: [Weinberg 1982 s 93] Leif Hedegård 11

12 << Processmodeller >> Iterativ och inkrementell utveckling
KT I << Processmodeller >> Iterativ och inkrementell utveckling Iteration 1 Iteration 2 Iteration 3 Iteration n F Ö R V A L T N I N G KRAV KRAV KRAV KRAV DESIGN DESIGN DESIGN DESIGN … KOD & TEST KOD & TEST KOD & TEST KOD & TEST See also Crystal Clear book at page 206 INTEGRATION INTEGRATION INTEGRATION INTEGRATION Litet system Större system Ännu större system Tid Färdigt system (iteration = upprepning) 12

13 << Processmodeller >> Attackera (möt) riskerna
KT I << Processmodeller >> Attackera (möt) riskerna Risk Risknivå sjunker tidigt Iterativ  2) Därför måste jag vänta med lite av detta Krav Design Impl Test Driftsättning 1) Det är hit jag vill komma snabbt! => feedback! Tid 13

14 << Processmodeller >> Riskreducering
KT I << Processmodeller >> Riskreducering Risk Riskminskning Vattenfall Iterativ Tid 14 [Kroll 2003, fig 2.1]

15 System att driftsätta  (begränsat)
<< Processmodeller >> Iterativ och inkrementell utveckling – fördel K D KT I Pengar eller tid slut F Ö R V A L T N I N G K D K & T I K D K & T I K D K & T I K D K & T I … Litet system Större system System att driftsätta  (begränsat) Färdigt system 15

16 Lämpar sig för kravförändringar
KT I << Processmodeller >> Iterativ och inkrementell utveckling som svar på problem med vattenfallsmodellen Lämpar sig för kravförändringar Slår bara fast de kraven som ska byggas närmaste framtiden Kontinuerlig integration => tidigare feedback på arkitektur/designmissar tidigare användarfeedback: ”Rätt produkt?” lättare hitta orsak till buggar Risker upptäcks/fixas under tidiga integrationer 16 [Kroll 2003]

17 Processen riskerar bli svårstyrd / osynlig, inga naturliga milstolpar
KT I << Processmodeller >> Iterativ och inkrementell utveckling kan vara svårstyrd Processen riskerar bli svårstyrd / osynlig, inga naturliga milstolpar While (System Not Ready) { Lite på kraven Lite design Lite kod och testning Integrering } Förvaltning Ingen uppföljning – allt flyter 17

18 << Processmodeller >> Ta grepp om den iterativa processen
K D KT I << Processmodeller >> Ta grepp om den iterativa processen Styr upp hela processen Faser med milstolpar/grindar i XP = release Iterationer inom faserna Styr upp varje iteration I XP = fast längd (”timebox”) + iterationsplanering i början av varje iteration 18

19 Stödjande discipliner
K D KT I << Processmodeller >> Ta grepp om den iterativa processen – exempel RUP Etablering Konstruktion Överlämning Förber. Faser Krav Analys & Design Implementation Test Utvecklingsmiljö Driftsättning Kärndiscipliner Stödjande discipliner Iterationer initial iter. #1 #2 #n #n+1 #n+2 #m #m+1 Konfig- och ändringshantering Verksamhetsmodellering Projektledning 19

20 << Processmodeller >> Vad används i industrin?
Utvecklingsprocesser (kurs 6B3023) K D KT I << Processmodeller >> Vad används i industrin? Undersökning om 104 projekt från indikerar: 64% inkrementell & iterativ 36% vattenfallsmodell Deltagande företag inkluderar Från Indien: Motorola India Electronics, Infosys, Tata Consulting, and Patni Computing Från Japan: Hitachi, NEC, IBM Japan, NTT Data, SRA, Matsushita Electronics, Omron, Fuji Xerox, and Olympus Från USA: IBM, Hewlett-Packard, Sun Microsystems, Microsoft, Siebel Systems, AT&T, Fidelity Investments, Merrill Lynch, Lockheed Martin, TRW, and Micron Technology Från Europa: Siemens, Business Objects, och Nokia K D KT I K Kod I D T Subcycles (%) India: 79.2, Japan: 44.4 USA: 54.8, Europe: 86.4, Total: 64.4 20 [Cusumano 2003] Leif Hedegård 20

21 << Processmodeller – Lättrörligt >> Lättrörlig (agile) utvecklingsprocess
Grundtanken med lättrörlig utveckling är att i en föränderlig värld krävs utvecklingsmetoder som hanterar förändring som en del av verkligheten, inte sådana som blundar för förändringar eller som försöker reglera bort dem. Fler regler kommer inte ge oss fler lyckade mjukvaruprojekt. Vi behöver flexibilitet - inte rigididet. 21 [

22 Dokument i fokus Kod i fokus
Utvecklingsprocesser (kurs 6B3023) << Processmodeller >> Spektrum mellan feedbackdriven (lättrörliga) och förutsägelsedriven (”plandrivna”) Adaptiv mjukvaru- utveckling Milstolpe- risk-driven model Milstolpe- plan-driven model Vattenfall, Rigida kontrakt XP Crystal Clear Hackare Feedback-driven Förutsägelse-driven Lättrörliga (agile) metoder ”Plandriven” Lättrörlig Rational Unified Process (RUP) Dokument i fokus Kod i fokus Also characteristics for plan driven; heavy overhed Also characteristics for agile; low overhed För långt hit KAOS! <= För långt hit => Rigiditet 22 [Boehm 2002, modifierad] Leif Hedegård 22

23 Principer för lättrörlig utveckling:
Agile Principer för lättrörlig utveckling: Viktigast är att göra kunden nöjd Välkomna kravförändringar Verksamhetskunniga och utvecklare arbetar tillsammans Självgående och ansvarstagande individer Kommunikation ansikte mot ansikte Fungerande produkt/system är det främsta måttet på framsteg. Agile verkar för uthållig utveckling Teknisk elegans och bra design Enkelhet - konsten att göra rätt saker, varken mer eller mindre. Självorganiserande team Gruppen utvärderar och anpassar regelbundet sitt arbetssätt för att förbättra sin effektivitet. 23 Förenklat/omarbetat från: [

24 Lättrörlig utveckling är ett samlingsbegrepp för ett antal metoder:
Lean software development Extreme programming Crystal Clear DSDM SCRUM MSF Agile ... Denna föreläsning har exempel härifrån 24

25 Eliminera slöseri Lean
Lättrörliga metoder (Kurs 6B3023) Lean Eliminera slöseri 08/04/2017 Gör bara sånt som ger värde för en kund, och gör det utan fördröjning. [Brandberg 2004] Partially Done Work The big problem here is that you might have no idea whether or not it will eventually work. Extra Processes Is all that paperwork really necessary? Extra Features Every bit of code increases complexity and is a potential failure point. Task Switching The fastest way to complete two projects that use the same resources is to do them one at a time Waiting Motion Handoff of an artifact is fraught with opportunities for waste... Documents do not contain all the information that the next person in the line needs to know Defects Find them as soon as possible => test immediately, integrate often and release to production as soon as possible 25 [Liker 2004, Fig 3-1: Waste in a truck chassis assembly line] Leif Hedegård 25

26 Fördröj åtaganden Lean
Lättrörliga metoder (Kurs 6B3023) Lean Fördröj åtaganden 13/08/06 Överge idén att det är en god idé att starta utveckling med en komplett specifikation Beroenden Systemarkitektur bör medge tillägg av valfri egenskap vid valfritt tillfälle Behåll valmöjligheter Tänk på kod som ett experiment – gör den ändringstolerant. Planlägg irreversibla beslut till “the Last Responsible Moment” Lär så mycket som möjligt innan irreversibla beslut tas. Partially Done Work The big problem here is that you might have no idea whether or not it will eventually work Extra Processes Is all that paperwork really necessary? Extra Features Every bit of code increases complexity and is a potential failure point. Task Switching The fastest way to complete two projects that use the same resources is to do them one at a time Waiting Motion Handoff of an artifact is fraught with opportunities for waste... Documents do not contain all the information that the next person in the line needs to know Defects Find them as soon as possible => test immediately, integrate often and release to production as soon as possible 26 [ Leif Hedegård 26

27 [Poppendieck 2003, page xxvi]
Lättrörliga metoder (Kurs 6B3023) Lean 08/04/2017 Leverera snabbt Gör det möjligt att komprimera ”the value stream” => Vi kan fördröja beslut => Kunder kan bestämma sig senare, när de vet mer vad de behöver Vi får återkoppling tidigare => mer pålitlig återkoppling vi lär oss mer 27 [Poppendieck 2003, page xxvi] Leif Hedegård 27

28 [Poppendieck 2003, page xxvii]
Lättrörliga metoder (Kurs 6B3023) Lean 08/04/2017 Respektera människor Människorna i frontlinjen kombinerar kunskapen om detaljerna med kraften av många tankar Eftersom beslut tas sent och exekveringen är snabb, är det inte möjligt för en central ledning att detaljstyra arbetarnas aktiviteter 28 [Poppendieck 2003, page xxvii] Leif Hedegård 28

29 Extreme Programming är
XP Extreme Programming är ett sätt att utveckla mjukvara och fokuserar på: Excellent användning av programmeringstekniker Tydlig kommunikation Lagarbete (teamwork) att komma förbi ”Jag vet bättre än alla andra och därför behöver jag bli lämnad ensam för att vara den bästa” 29 [Beck 2004, kapitel 1]

30 Extreme Programming (XP)
DESIGN Visa - LYSSNA KODNING TEST [Beck 2000]

31 Integrationstest är viktigt…
XP Tag vanliga ”sunda förnufts-principer” och använd dem extremt => namnet. Kodgranskning är bra… granska ständigt (parprogrammering)! Testning är bra… testa ständigt (bygg testerna först) Integrationstest är viktigt… integrera och testa flera gånger varje dag! [Beck 2000 s xv]

32 Små iterationer är bra…
XP Tag vanliga ”sunda förnufts-principer” och använd dem extremt => namnet. Design är viktig… designa dagligen (refactoring)! Enkelhet är bra… var nöjd med det enklaste som fungerar! Arkitektur är viktig… alla jobbar med att förfina arkitekturen ständigt! Små iterationer är bra… gör iterationerna korta [Beck 2000 s xv]

33 Fyra av varandra beroende variabler
XP Fyra av varandra beroende variabler Funktionalitet Kvalité Kostnad Produkt (Utvecklings)tid [Beck 2000]

34 Fyra av varandra beroende variabler
XP Fyra av varandra beroende variabler Regel: kunden bestämmer värdet på 3 variabler utvecklarna säger sedan vad värdet på den 4:e variabeln blir Risk: kunden vill optimera alla 4 Risken undviks genom att göra variablerna synliga => medvetna val. [Beck 2000, kapitel 4]

35 XP Primära Sedvanor XP Sit together Whole team Informative workspace
Lättrörliga metoder (Kurs 6B3023) XP Primära Sedvanor XP 08/04/2017 Generally safe to introduce one at a time, or in any order [ Quarterly cycle Slack Ten-minute build Continuous integration Test-first programming Incremental design Sit together Whole team Informative workspace Energized work Pair programming Stories Weekly cycle Sit Together: but "tearing down the cubicle walls before the team is ready is counter-productive" Whole Team: a cross-functional team. Informative Workspace: a workspace that meets human needs, and a place for big visible charts. Energized Work: a reinterpretation of "40-hour week" and "sustainable pace" Pair Programming Stories: "units of customer-visible functionality." And, "Every attempt I've seen to computerize stories has failed to provide a fraction of the value of having real cards on a real wall." Weekly Cycle: an iteration: plan, write tests & code. Quarterly Cycle: plan a quarter using themes. Slack: include things that can be dropped if you get behind. Ten-Minute Build: automatically build and test everything. Continuous Integration Test-First Programming Incremental Design Source: 35 [Beck 2004 chapter 7] Leif Hedegård 35

36 Lättrörliga metoder (Kurs 6B3023)
Sitt tillsammans XP 08/04/2017 36 Från kurs 2i1074 IT Projekt, del 2 - Tekniker för mjukvaruutveckling vt 2005 Leif Hedegård 36

37 Sitt tillsammans XP Fig 10-1
Agile Software Development. Evaluating the Methods for Your Organization [Artech House 2005] 37

38 http://www.scissor.com/resources/teamroom/ assessed 2006-02-01
Lättrörliga metoder (Kurs 6B3023) Informativ arbetsyta XP 08/04/2017 << Example of XP Primary Practices >> Informative workspace 1 Customer — Just out of frame to the left sat the product manager, aka the XP customer. 2 Current stories — This week's stories were listed here with a detailed breakdown and notes. 3 Techie to-dos — Open technical issues. 4 End-of-iteration meeting agenda — Including metrics. 5 General-purpose whiteboard space — Erased regularly. 6 Main story card board — Included cards recently completed, upcoming, and unscheduled. 7 Developer workstations — Two dual-headed stations, facing each other. 8 Old story card board — Cards completed more than a few months ago. 9 Continuous integration server — Just out of frame to the right; played sounds on success and failure. 38 assessed Leif Hedegård 38

39 Informativ arbetsyta XP 39
Lättrörliga metoder (Kurs 6B3023) XP 08/04/2017 Informativ arbetsyta 39 Från kurs 2i1074 IT Projekt, del 2 - Tekniker för mjukvaruutveckling vt 2005 Leif Hedegård 39

40 Informativ arbetsyta XP 40 [Poppendieck 2003, fig 4.1]
Lättrörliga metoder (Kurs 6B3023) XP 08/04/2017 Informativ arbetsyta 40 [Poppendieck 2003, fig 4.1] Leif Hedegård 40

41 Crystal Clear karakteristik
CC Crystal Clear karakteristik Familjen av Crystal-metoder: fungerar även med fasta pris projekt utvecklades inom fasta-pris projekt, som ofta offereras till för lågt pris, så projektgruppen måste vara mycket effektiv och kreativ för att bli klar i tid och inom budget Crystal har mer fokus på effektivitet än lättrörlighet Crystal uttrycker att kreativitet ihop med reflektion krävs för att nå framgång Crystal Clear är en metod inom Crystal-familjen avsedd för små projekt. Crystal Clear: passa samlokaliserade projektgrupper upp till cirka 8 personer kan ses som ett avslappnad alternativ till Extreme Programming [Cockburn 2005, förord (sid xix) och kap 4]

42 Crystals Clears egenskaper
CC Crystals Clears egenskaper Sju säkerhetsegenskaper att styra mot: Frekventa leveranser Reflektiv förbättring Osmotisk kommunikation Personlig säkerhet Fokus Enkel åtkomst till expertanvändare Teknisk miljö med: automatiserad testning, konfigurationshantering och frekvent integration Obligatoriska att använda i Crystal Clear 42 [Cockburn 2005, kapitel 2]

43 Crystals Clears strategier & tekniker
CC Crystals Clears strategier & tekniker Metodutformning Reflektionsseminarier Blitz Planning Delphi uppskattning Dagliga stå-upp möten Lättrörlig interaktionsdesign Processminiatyr Sida vid sida programmering Burn Charts Exploratory 360° Early Victory Walking Skeleton Incremental Rearchitecture Information Radiators < Använd vilka strategier, sedvänjor och tekniker du behöver från andra ställen som t ex från boken”Extreme Programming Explained”... Strategierna and teknikerna ovan är de som ”är ett bra start, rekommenderas av erfarna utvecklare, få människor verkar känna till, är enkla, och, mest av allt, är användbara” 43 [Cockburn 2005, kapitel 3]

44 Reflektionsseminarium
CC Reflektionsseminarium Behåll dessa Tyst tid (kl 9-12) Dagliga möten Pröva dessa Partestning ”Böter” för avbrott Programmerarna hjälper testarna Problem För många avbrott Leverans av buggig kod Behåll dessa Pröva dessa Problem 44 [Cockburn 2005, fig 3-6 modif]

45 Reflektionsseminarium
CC Reflektera minuter i hela teamet för att hitta sätt att förbättra arbetssättet. Gör det en gång i veckan, varannan vecka eller en gång i månaden. Behövs mer/oftare i början av ett projekt. 45 [Cockburn 2005, kapitel 3]

46 Dagliga stå-upp möten CC CC
Lättrörliga metoder (Kurs 6B3023) Dagliga stå-upp möten CC CC 08/04/2017 För att inte mötet ska bli långvarigt står man upp Detta tar var och en upp: (Vad gjorde jag igår?) Vad har jag planerat att arbeta med idag? Vad (kan) hindra(r) mig? Mötet ska inte användas för att lösa problem utan för att identifiera problem Bild från boken Extreme Programming for Web Projects [Addison Wesley 2002] 46 [Cockburn 2005, kapitel 3, modifierat] Leif Hedegård 46

47 Rekommendation för projekten
Veckoplanering (iterationsplanering) Reflektionsseminarium Morgonmöte Jobba i par (motsv parprogrammering) Hitta lösningar genom att jobba ”brett” och ”oberonde” (läxor?) sammanställ sedan värdera och analysera förslag besluta 47

48 Lathund 8 hörnstenar som bygger ett IT-projekt
Lathund 8 hörnstenar som bygger ett IT-projekt!? (”Use Case” = Krav tills vidare)

49 Lathund 8 hörnstenar som bygger ett IT-projekt
Lathund 8 hörnstenar som bygger ett IT-projekt!? (”Use Case” = Krav tills vidare)

50 Slutsatser Det finns problem
Processer hjälper till att motverka problemen Det gäller att välja => kunskap om processmodeller, metoder…; fördelar, nackdelar och till vad de passar är essentiella Varje processmetod/ramverk måste anpassas till: din egen organisation problemdomänen och ditt projekt 50