Download - > Grundläggande processmodeller
![Page 1: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/1.jpg)
1
<< Processmodeller >>
Grundläggande processmodeller
• Koda och fixa• Vattenfall• Iterativ och inkrementell
– Lättrörlig (agile)
![Page 2: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/2.jpg)
2
<< Processmodeller >>
Koda och fixa
• 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…)
KodaKoda
FixaFixaKravspec(frivilligt)Kravspec(frivilligt)
Leverans(kanske)
Leverans(kanske)
![Page 3: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/3.jpg)
3
<< Processmodeller >>
Vattenfallsmodellen
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
FÖRVALTNINGFÖRVALTNING
V
V
V
V
V
K
Kod
I
D
T
![Page 4: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/4.jpg)
4
<< 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…
K
Kod
I
D
T
![Page 5: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/5.jpg)
5
<< 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
[DeGrace 1990]
K
Kod
I
D
T
![Page 6: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/6.jpg)
6
<< 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?
[DeGrace 1990]
K
Kod
I
D
T
![Page 7: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/7.jpg)
7
<< Processmodeller >>
Vattenfall - problem
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
FÖRVALTNINGFÖRVALTNING
V
V
V
V
V
Pengar eller tid slu
t
Resultat = Inget
K
Kod
I
D
T
![Page 8: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/8.jpg)
8
<< Processmodeller >>
Vattenfall - problem
Hög
Tid
Krav
Design
Impl
Test
DriftsättnLåg
Kunskap om projektet
Beslutens påverkan på projektet
”De viktigaste besluten fattas när kunskapen om projektet är som
sämst”
”De viktigaste besluten fattas när kunskapen om projektet är som
sämst”
[Wenell 2001, s 48, modif]
K
Kod
I
D
T
![Page 9: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/9.jpg)
9
<< Processmodeller >>
När upptäcks och möts risker?Risk
Tid
Risknivå sjunker sent
Krav
Design
Impl
Test
Driftsättn
Vattenfall
K
Kod
I
D
T
![Page 10: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/10.jpg)
10
<< 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
[DeGrace 1990, Boehm 2000 s 8, (kompilator tillagt)]
K
Kod
I
D
T
![Page 11: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/11.jpg)
11
<< Processmodeller >>
Hur komma åt problemen med vattenfallsmodellen?
Iterativt & inkrementellt
Fritt efter: [Weinberg 1982 s 93]
Vattenfallsmodellen
Dela upp problemet i mindre bitar och lös bit för bit (“Divide and conquer”)
A B
Kom
ple
xit
et
Problemstorlek
Förvirring
ProblemstorlekA B
Kom
ple
xit
et
X
Förståelse Förståelse
K
Kod
I
D
T
![Page 12: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/12.jpg)
12
<< Processmodeller >>
Iterativ och inkrementell utveckling
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
Iteration 1
Iteration 2
Iteration n
…
FÖRVALTNING
FÖRVALTNING
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
KRAVKRAV
DESIGNDESIGN
KOD & TESTKOD & TEST
INTEGRATIONINTEGRATION
Iteration 3
(iteration = upprepning)Tid
Litet system Större system
Ännu större systemFärdigt system
KD
KT
I
![Page 13: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/13.jpg)
13
Risk
Tid
Risknivåsjunker tidigt
Iterativ
Krav
Design
Impl
Test
Driftsättning
<< Processmodeller >>
Attackera (möt) riskerna
1) Det är hit jag vill komma snabbt!=> feedback!
2) Därför måste jag vänta med lite av detta
KD
KT
I
![Page 14: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/14.jpg)
14
Risk
Tid
VattenfallIterativ
[Kroll 2003, fig 2.1]
Riskminskning
<< Processmodeller >>
Riskreducering
KD
KT
I
![Page 15: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/15.jpg)
15
Pengar eller tid slut
…
FÖRVALTNING
FÖRVALTNING
KK
DD
K & TK & T
II
KK
DD
K & TK & T
II
KK
DD
K & TK & T
II
KK
DD
K & TK & T
II
System att driftsätta (begränsat
)
Litet system Större system
Färdigt system
<< Processmodeller >>
Iterativ och inkrementell utveckling – fördel
KD
KT
I
![Page 16: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/16.jpg)
16
<< 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
[Kroll 2003]
KD
KT
I
![Page 17: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/17.jpg)
17
<< 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
While (System Not Ready) {
Lite på kraven
Lite design
Lite kod och testning
Integrering
}
Förvaltning
Ingen uppföljning – allt flyter
KD
KT
I
![Page 18: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/18.jpg)
18
<< 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
KD
KT
I
![Page 19: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/19.jpg)
19
<< Processmodeller >>
Ta grepp om den iterativa processen – exempel RUP
Etablering Konstruktion ÖverlämningFörber.
Faser
Krav
Analys & Design
Implementation
Test
Utvecklingsmiljö
Driftsättning
Kärndiscipliner
Stödjande discipliner
Iterationer
initial iter.#1
iter.#2
iter.#n
iter.#n+1
iter.#n+2
iter.#m
iter.#m+1
Konfig- och ändringshantering
Verksamhetsmodellering
Projektledning
KD
KT
I
![Page 20: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/20.jpg)
20
<< Processmodeller >>
Vad används i industrin?
• Undersökning om 104 projekt från 2001-2002 – 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
[Cusumano 2003]
KD
KT
I
KD
KT
IK
Kod
I
D
T
![Page 21: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/21.jpg)
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.
[www.agilesweden.org]
![Page 22: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/22.jpg)
22
<< Processmodeller >>
Spektrum mellan feedbackdriven (lättrörliga) och förutsägelsedriven (”plandrivna”)
Vattenfall,Rigidakontrakt
Milstolpe-plan-driven model
Milstolpe-risk-driven model
Adaptiv mjukvaru-utveckling
Hackare XPCrystal Clear
Lättrörliga (agile) metoder
Rational Unified Process (RUP)
Förutsägelse-driven
Feedback-driven
[Boehm 2002, modifierad]
Kod ifokus
Dokument
i fokus
För långt hit KAOS! <=
För långt hit => Rigiditet
Lättrörlig ”Plandriven”
![Page 23: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/23.jpg)
23
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.
Förenklat/omarbetat från: [www.agilesweden.org]
Agile
![Page 24: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/24.jpg)
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
![Page 25: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/25.jpg)
25
Eliminera slöseri
[Liker 2004, Fig 3-1: Waste in a truck chassis assembly line]
Gör bara sånt som ger värde för en kund,
och gör det utan fördröjning. [Brandberg 2004]
Gör bara sånt som ger värde för en kund,
och gör det utan fördröjning. [Brandberg 2004]
Lean
![Page 26: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/26.jpg)
26
Fördröj åtaganden
Lean
• Ö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.
[http://www.poppendieck.com/]
![Page 27: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/27.jpg)
27
Leverera snabbt
Lean
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 vetmer vad de behöver
Vi får återkoppling tidigare => mer pålitlig återkopplingvi lär oss mer
[Poppendieck 2003, page xxvi]
![Page 28: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/28.jpg)
28
Respektera människor
Lean
• 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
[Poppendieck 2003, page xxvii]
![Page 29: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/29.jpg)
29
Extreme Programming ärett 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”
[Beck 2004, kapitel 1]
XP
![Page 30: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/30.jpg)
Extreme Programming (XP)
DESIGNDESIGN
KODNINGKODNING
TESTTEST
Visa - LYSSNAVisa - LYSSNA
[Beck 2000]
XP
![Page 31: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/31.jpg)
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!
XP
[Beck 2000 s xv]
![Page 32: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/32.jpg)
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
XP
[Beck 2000 s xv]
![Page 33: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/33.jpg)
Fyra av varandra beroende variabler
Funktionalitet
Kvalité
(Utvecklings)tid
Kostnad
Produkt
[Beck 2000]
XP
![Page 34: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/34.jpg)
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]
XP
![Page 35: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/35.jpg)
35
XP Primära Sedvanor
[Beck 2004 chapter 7]
– Sit together
– Whole team
– Informative workspace
– Energized work
– Pair programming
– Stories
– Weekly cycle
Quarterly cycle
Slack
Ten-minute build
Continuous integration
Test-first programming
Incremental design
Generally safe to introduce one at a time, or in any order[http://www.xp123.com/xplor/xp0502/index.shtml]
XP
![Page 36: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/36.jpg)
36 Från kurs 2i1074 IT Projekt, del 2 - Tekniker för mjukvaruutveckling vt 2005
Sitt tillsammansXP
![Page 37: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/37.jpg)
37
Fig 10-1Agile Software Development. Evaluating the Methods for Your Organization [Artech House 2005]
Sitt tillsammansXP
![Page 38: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/38.jpg)
38
<< Example of XP Primary Practices >>
Informative workspace
http://www.scissor.com/resources/teamroom/ assessed 2006-02-01
XPInformativ arbetsyta
![Page 39: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/39.jpg)
39 Från kurs 2i1074 IT Projekt, del 2 - Tekniker för mjukvaruutveckling vt 2005
Informativ arbetsytaXP
![Page 40: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/40.jpg)
40
Informativ arbetsyta
[Poppendieck 2003, fig 4.1]
XP
![Page 41: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/41.jpg)
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]
CC
![Page 42: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/42.jpg)
42
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
[Cockburn 2005, kapitel 2]
CC
![Page 43: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/43.jpg)
<
43
Crystals Clears strategier & tekniker
• Exploratory 360°• Early Victory• Walking Skeleton• Incremental Rearchitecture• Information Radiators
[Cockburn 2005, kapitel 3]
CC
• Metodutformning• Reflektionsseminarier • Blitz Planning• Delphi uppskattning • Dagliga stå-upp möten • Lättrörlig interaktionsdesign• Processminiatyr• Sida vid sida programmering • Burn Charts
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”
![Page 44: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/44.jpg)
44
Reflektionsseminarium
Behåll dessa
Pröva dessa
Problem
Behåll dessaTyst tid (kl 9-12)
Dagliga möten
Pröva dessaPartestning
”Böter” för avbrott Programmerarna hjälper testarna
ProblemFör många avbrottLeverans av buggig kod
[Cockburn 2005, fig 3-6 modif]
CC
![Page 45: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/45.jpg)
45 [Cockburn 2005, kapitel 3]
Reflektera 15-60 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.
ReflektionsseminariumCC
![Page 46: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/46.jpg)
46
• 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
Dagliga stå-upp möten
[Cockburn 2005, kapitel 3, modifierat]
CCCC
![Page 47: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/47.jpg)
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
![Page 48: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/48.jpg)
Lathund8 hörnstenar som
bygger ett IT-projekt!?
(”Use Case” = Krav tills vidare)
![Page 49: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/49.jpg)
Lathund8 hörnstenar som
bygger ett IT-projekt!?
(”Use Case” = Krav tills vidare)
![Page 50: > Grundläggande processmodeller](https://reader036.vdocuments.pub/reader036/viewer/2022062308/56812a53550346895d8da4a8/html5/thumbnails/50.jpg)
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