om prosesser - ntnu · 2012-08-24 · om prosesser side 6 av 22 opphavsrett: forfatter og...
TRANSCRIPT
Opphavsrett: Forfatter og Stiftelsen TISIP
Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag
Om prosesser Tore Berg Hansen
Lærestoffet er utviklet for faget IFUD1019 Objektorientert systemutvikling
1. Om prosesser Resymé: Denne leksjonen handler om utviklingsprosesser. Den gir en introduksjon til prosessbegrepet. Vi ser på
hvorfor det er viktig med en definert prosess ved utvikling av programvare. Eksempler på prosesser som er
beskrevet i litteraturen blir gjennomgått. Det blir lagt spesiell vekt på Unified Process (UP).
Innhold 1.1. DEFINISJONER ....................................................................................................................................... 2 1.2. INTRODUKSJON ..................................................................................................................................... 2 1.3. UTVIKLINGSPROSJEKTETS AKTIVITETER ............................................................................................... 3 1.4. ITERATIV OG INKREMENTELL UTVIKLING.............................................................................................. 5 1.5. SMIDIGE UTVIKLINGSMETODER ............................................................................................................ 6 1.6. EKSEMPLER PÅ ITERATIVE OG INKREMENTELLE UTVIKLINGSPROSESSER .............................................. 6
1.6.1. Generelt ........................................................................................................................................... 6 1.6.2. The Unified Process ........................................................................................................................ 6 1.6.3. Ekstrem Programmering ............................................................................................................... 11 1.6.4. DSDM ............................................................................................................................................ 12 1.6.5. Scrum ............................................................................................................................................ 14
1.7. DEN PERSONLIGE PROSESSEN .............................................................................................................. 16 1.8. OM PROSESSER OG PROSESSFORBEDRING ........................................................................................... 17
1.8.1. Et rammeverk ................................................................................................................................ 17 1.8.2. Den definerte prosessen ................................................................................................................ 20 1.8.3. Kanban og slank ............................................................................................................................ 20
1.9. LESESTOFF TIL DENNE LEKSJONEN ...................................................................................................... 21 1.10. LITTERATUR ....................................................................................................................................... 21
Om prosesser side 2 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
1.1. Definisjoner
Aktivitet (eng activity) En mengde arbeid som må utføres.
Arbeidsstykke (eng work
package)
En spesifikasjon av det arbeid som må utføres for å gjøre
ferdig en aktivitet eller oppgave. Det omfatter
arbeidsprodukter som skal leveres, ressurser, forventet
varighet, akseptansekriterier, ansvarlige og andre
eventuelle spesielle forhold som det må tas hensyn til.
Oppgave (eng task) Den minste enhet av arbeid som kan defineres og styres i
et prosjekt
Utviklingsprosess En fasedelt oppdeling av trinn og aktiviteter som utføres
fra unnfangelsen av en ide til idriftsetting og vedlikehold.
Egentlig en abstraksjon i form av en modell som i denne
sammenheng beskriver aktivitetene ved utvikling av
programvare.
1.2. Introduksjon
Dagens mennesker er helt avhengige av godt fungerende programvare. Vi støter nesten daglig
på systemer som enten er rene programvaresystemer eller systemer hvor programvare er en
svært kritisk del av systemet. Avhengig av hvilket arbeid vi har, bruker vi mange hjelpemidler
og verktøy for å gjøre en effektiv jobb. Mange av disse hjelpemidlene og verktøyene er
programvaresystemer. I hjemmet har vi en rekke apparater. Noen av disse apparatene trenger
vi i husholdningen (kjøleskap, mikrobølgeovner, komfyrer). Andre apparater brukes til
underholdning (tv, radio, video). De fleste av oss kan heller ikke unnvære
telefon/mobiltelefon og bil. Og med Internett handler vi, betaler regninger og finner
informasjon om snart nesten det meste. Sikker transport enten det skjer med fly, buss eller båt
er avhengig av programvaresystemer.
Det dette betyr er at programvaresystemer blir både større og mer komplekse. Det gjør igjen
at de som skal utvikle disse programvaresystemene stilles overfor store utfordringer.
Utviklerne trenger støtte av metoder, verktøy og god praksis for å kunne håndtere den økende
størrelse og kompleksitet. Dette er grunnleggende nødvendig fordi vi erfarer at svært mange
utviklingsprosjekter er problematiske. Alt for ofte overskrides tids og kostnadsrammer.
Brukerne får ikke det de har forventet. Noe av årsaken til problemet er mangel på en definert
utviklingsprosess. Man må strukturere arbeidet. Dvs. at man må arbeide etter en
prosessmodell. Med utgangspunkt i prosessmodellen skreddersys en prosess for det aktuelle
utviklingsprosjektet. En definert prosess skal gi grunnlag for
Om prosesser side 3 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
- å finne frem til det arbeid som må gjøres og dele det opp
- å følge opp fremdrift
- planlegging av ressurser
- estimering av tid og kostnader
- å finne betingelsene for at en aktivitet kan starte
- å spesifisere produkter fra hver aktivitet
- å spesifisere teknikker som skal brukes i hver aktivitet
- å samle erfaring
En prosessmodell er likevel bare et element i et vellykket utviklingsprosjekt. Vi skal derfor
før vi diskuterer noen aktuelle prosessmodeller, kort se hvilke elementer som må være på
plass for at et utviklingsprosjekt skal bli vellykket.
1.3. Utviklingsprosjektets aktiviteter
Vi kan dele et utviklingsprosjekt inn i tre hovedgrupper av aktiviteter:
- Prosjektstyring
Planlegging
Organisering
Bemanning
Ledelse
Kontroll
- Programvare system engineering
Problemdefinisjon
Analyse av løsninger
Prosessplanlegging
Prosesskontroll
Evaluering av ferdig produkt
- Programvare engineering
Design av programvaren
Koding
Enhetstest
Integrasjon av enheter
Aktivitetene under prosjektstyring utfører vi i alle typer prosjekter. Det å få på plass og
kontrollere en prosess hører inn under systemaktivitetene. Det er aktiviteter som vi utfører
enten vi skal utvikle utelukkende programvare eller programvaren er en del av et større
system med både programvare og maskinvare. Den siste gruppen av aktiviteter er kun knyttet
til programvare. Prosjektstyringsaktivitetene er ikke tema for dette kurset. Et overordnet
ramme for dette kurset er objektorientering. Vi skal derfor se på aktiviteter i de to siste
gruppene som må spesialiseres i en objektorientert sammenheng. Vi starter med prosesser,
som derfor er tema for resten av denne leksjonen.
Om prosesser side 4 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Det er beskrevet en rekke prosessmodeller. Det første forsøk på å lage en prosess for utvikling
av programvare resulterte i den velkjente fossefallsmodellen.
Figur 1 En utforming av fossefallsmodellen.
Den finnes i forskjellige varianter. Man kan finne forskjellig antall faser og navn på faser.
Men hovedprinsippet er at man gjør seg ferdig med en fase før neste begynner. Erfaringer fra
et utall prosjekter viser at dette sjelden er mulig i praksis. Det skjer stadig at krav endrer seg
under veis. Det tar for lang tid før brukere får et produkt å forholde seg til. Flere
undersøkelser har også vist at en av de aller viktigste årsaker til fiasko er manglende
forståelse av kravene til systemet som utvikles. Svaret fra dem som sverger til en eller annen
form for fossefallsmodell er å legge ned enda mer arbeid i analysen av krav. Men det er
fåfengt. Virkeligheten er ikke slik. Det er umulig å fremskaffe alle krav på forhånd.
Svakhetene med fossefallsmodellen har gitt opphav til andre modeller. En forbedring er
spiralmodellen [1]. Men heller ikke den gir den nødvendige fleksibilitet for utvikling av
objektorienterte systemer. Det er viktig at en prosess både kan kontrolleres og måles og at den
samtidig tillater utviklerne å være kreative. Basert på erfaringer om hva som virker og ikke
virker, er det etter hvert blitt utbredt enighet om en del ”beste praksiser”. Disse beste praksiser
er:
- iterativ og inkrementell utvikling
- tidlig kontroll med risikofaktorer
- kontinuerlig involvering av brukere og andre interessenter
- tidlig etablering av en arkitektur for programvaresystemet
- kontinuerlig verifikasjon av kvalitet
- use case som tråd i utviklingsprosessen
- visuell modellering av programvare
Forandringsanalyse
analyse
Analyse
Utforming
Realisering
Imple-mentering
Forvaltning og drift
Avvikling
Om prosesser side 5 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
- opptatthet av krav
- praktisering av endringskontroll og konfigurasjonsstyring
Det viktigste er den første praksisen, iterativ og inkrementell utvikling, fordi den legger på en
måte grunnlaget for de andre. Vi skal i de etterfølgende kapitler se på noen prosessmodeller
basert på disse praksisene. Vi starter med Unified Process (UP). Det gjør vi fordi læreboken
[12] bruker den som eksempelmodell og ramme rundt de forskjellige utviklingsaktivitetene.
Forfatterens begrunnelse for å bruke UP som eksempelmodell er at den er en iterativ
prosessmodell, at praksisene i UP gir en struktur for å forklare objektorientert analyse og
design og at den er fleksibel og kan brukes på en smidig måte.
1.4. Iterativ og inkrementell utvikling
En iterativ og inkrementell utviklingsprosess består av en rekke iterasjoner som til slutt ender
opp med det endelige system. Denne overordnete filosofien kan gi opphav til prosesser med
forskjellig antall faser. Likedan kan graden av formalisme variere. Men et hovedpoeng er at
ettersom kravene ikke er fullstendig kjente på forhånd, må denne kunnskap fremskaffes under
veis. Man leverer systemet i inkrementer. Hvert inkrement realiserer deler av systemets
funksjonalitet, samtidig som man får mer kunnskap om systemet og risikoene man står
overfor. Et inkrement er i seg selv er ”miniprosjekt” som leverer et kjørbart system. Brukerne
får presentert håndfaste resultater tidlig og i en jevn strøm og kan gi stadig tilbakemelding om
systemet tilfredsstiller forventningene. Det endelige systemet bygges dermed i inkrementer
ved at det legges til ny funksjonalitet etter hvert.
Hvert inkrement vil inneholde innsamling av krav, analyse, design, implementasjon og test.
Filosofien har en parallell i Shewhart/Deming syklusen for kontinuerlig forbedring som er
sentral innenfor total kvalitets tenkningen. Denne syklusen har fire faser:
1. Planlegg hva som skal gjøres.
2. Gjør det.
3. Sjekk resultatet.
4. Handle og start en ny syklus
Om prosesser side 6 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Anvendt på utviklingsprosessen blir det som i Figur 2 som er hentet fra [2].
Figur 2 Inkrementell og iterativ utvikling.
1.5. Smidige utviklingsmetoder
Smidig (engelsk: agile) utvikling er et begrep som er blitt vanlig i den senere tid. Det finnes
ingen entydig definisjon av begrepet. Ofte brukes det som et synonym for iterativ og
inkremetell utvikling. Det vil si at smidige metoder er karakterisert ved iterasjoner med fast
lengde og evolusjonær utvikling og kjapp og fleksibel reaksjon på endringer. Begrepet dukket
antagelig opp ved etableringen av «Agile Alliance». Det står litt om det i kapittel 2.6 i boken
til Larman[12].
1.6. Eksempler på iterative og inkrementelle utviklingsprosesser
1.6.1. Generelt
Vi vil ikke i denne leksjonen trekke frem en prosess som den ”riktige”. Den prosessen finnes
neppe. Prosesser må velges slik at de passer til den kulturen som er i bedriften og hvor det tas
hensyn til et utviklingsprosjekts størrelse og type. Det utvalget prosesser som presenteres kan
brukes som maler som kan tilpasses produkttype og egne ønsker og behov.
Den informasjon man kan hente i litteraturen om forskjellige prosesser er ikke like detaljert.
Noen forfattere nøyer seg med å beskrive de forskjellige faser i prosessen uten å gå detaljert
inn på aktiviteter og produkter. Andre gir detaljerte beskrivelser av de aktiviteter som skal
utføres i den enkelte fase med angivelse av hvilke resultater hver aktivitet skal gi. Mange
nøyer seg med retningslinjer og erfaringer. Man kan også registrere motsetninger mellom
anbefalinger gitt av forskjellige forfattere.
1.6.2. The Unified Process
Historien
For å få det hele i et perspektiv skal vi se kort på historien. Mange sett av metoder og
tilhørende notasjoner er lansert i forbindelse med den objektorienterte ”bølge” som har slått
Revider
risikovurderingen
Definer iterasjoner med
høyeste risiko Planlegg og utvikle
iterasjonen
Vurder iterasjonen
Risiki eliminert Revider prosjektplaner
Initielle risiki
Initielt prosjektomfang
Iterasjon
N
Om prosesser side 7 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
over oss. Tre av de mange pionerer innen feltet er James Rumbaugh, Grady Booch og Ivar
Jacobson. De har bidratt med hver sine metoder. Rumbaugh med OMT (Object Modelling
Technique) [6], Booch [7] med sine spesielle klasse og objektdiagrammer og verktøyet
Rational og Jacobson [5] med Use Case og metoden/verktøyet Objectory . Disse slo seg for
noen år tilbake sammen. Et av resultatene er UML (Unified Modeling Language) som er et
notasjonsspråk, dvs. det redskapet man trenger når man skal visualisere forskjellige sider av et
objektorientert system. UML forener OMT, Booch og Objectory. Det ser ut som de har
vunnet notasjonskrigen og at UML har blitt det allment aksepterte notasjonsspråket. Det er nå
en standard i regi av organisasjonen OMG (Object Management Group). UML er nå i versjon
2.0 utvidet med ideer fra andre av de mest kjente aktørene rundt objektorientering som Meyer,
Wirfs_Brock, Shlear-Mellor, Gamma og andre.
Et annet resultat av samarbeidet mellom de tre (amigos) er verktøyet Rational Rose. Det
markedsføres og videreutvikles av IBM. Det har en høy pris og rimeligere alternativer finnes
nå. Et verktøy kan ikke stå alene. Det må være en støtte for det arbeidet som gjøres i
utviklingsprosessen. Samarbeidet mellom de tre amigos resulterte i en prosessmodell som har
fått betegnelsen Unified Process (opprinnelig kalt Objectory Process). Den overordnede
filosofi for denne prosessen er inkrementell og iterativ utvikling. Det er utgitt en bok som
Jacobson [8] er hovedforfatter for, hvor prosessen beskrives. De som kun trenger en oversikt
over prosessen kan lese i bl.a [2] og [9]. Prosessen omtales ofte som Rational Unified Process
(RUP) fordi firmaet Rational (nå overtatt av IBM) støtter prosessen med verktøy.
Prosessen
The Unified Process (UP) er en livsløpsmodell som skal være godt egnet for bruk sammen
med UML. UML er imidlertid ikke avhengig av noen spesiell prosess. Heller ikke er UP
avhengig av noe spesielt notasjonsspråk. Imidlertid har UP og UML utviklet seg sammen og
involvert noen av de samme personer. Målet med denne prosessen, som med alle andre
livsløpsprosesser, er å sørge for produksjon av programvare av høy kvalitet som tilfredsstiller
brukerkravene innenfor forutsigbare tids- og budsjettrammer. Prosessen skal kunne
skreddersys til å passe mange forskjellige prosjekter og organisasjoner.
Prosessen legger vekt på at det skal produseres og vedlikeholdes modeller i stedet for
dokumenter. Den er arkitektursentrert. Med det menes at det tidlig i prosessen må lages en
grunnleggende arkitektur. Denne arkitekturen skal være robust for å kunne videreutvikles i
iterasjon etter iterasjon. Prosessen er Use Case drevet (Jacobsons bidrag [5]) og produserer
objektmodeller under veis. Det legges vekt på at prosessen skal bidra til å redusere risiko og
fremme kvalitet på sluttproduktet. Risikovurdering og kvalitetsvurdering er bygget inn i
prosessen. Fasene i prosessen er vist i figur 3.
Om prosesser side 8 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Figur 3
De fire fasene utgjør til sammen en livssyklus for programvaren. Hver fase ender i en
milepæl. Man itererer seg gjennom hver fase. Dette utgjør tidsdimensjonen i modellen.
Dette gjøres i de forskjellige fasene:
- Oppstart (inception på engelsk). Her skal man legge grunnlaget for prosjektet. Det vil si å
finne frem til suksesskriterier, vurdere risikoer, estimere ressursbehov og utforme en grov
tidsplan med faser og milepæler. Prototyper er nyttige i denne fasen.
- Detaljering (elaboration på engelsk). Problemdomenet analyseres. Man skal iterativt
implementere en arkitektur, detaljere neste iterasjon og søke eliminere de største
risikoelementene. Hovedkravene til systemet skal beskrives.
- Konstruksjon (construction på engelsk). Her implementers gjennom en rekke iterasjoner
og inkrementer lavrisikoelementene i systemet. Man finner flere krav og
akseptansekriterier. Design detaljeres og systemet inplementeres og testes.
- Overlevering (transition). Systemet leveres til brukerne. Dette vil typisk være en beta-
versjon av systemet.Ved at systemet tas i bruk kan nye krav og problemer dukke opp som
gjør at livsløpet må startes på nytt.
Et viktig poeng er at dette ikke er en sekvensiell prosess som ligner på en fossefallsprosess
hvor man starter med å definre alle krav. Oppstartsfasen er ikke en kravanalysefase. Slutten
av hver fase ender i en milepæl. Hver fase i prosessen kan deles i flere iterasjoner. En
iterasjon er et fullstendig utviklingsløp som skal resultere i et frislipp (release) som enten er
internt eller eksternt. Hvert slikt frislipp er en kjørbar del av systemet som er under utvikling.
Det endelige systemet blir gradvis komplettert etter hver iterasjon. Dvs. hver iterasjon bringer
frem et nytt inkrement av systemet. Iterasjonene i hver fase har forskjellig fokus. I den første
fasen vektlegges å få frem kravene, deretter vektlegges analyse og design. Under konstruksjon
er det implementasjon som vektlegges. Man kan si at prosessen har to dimensjoner som vist i
Figur 4.
Oppstart Detaljering Overlevering
Konstruksjon
1 3 ... 2
Om prosesser side 9 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Iter
#1
Oppstart
Innledende iterasjoner
Detaljering Konstruksjon Overføring
Iter
#m
Iter
#1
Iter
…
Iter
#n
Iter
#1
Iter
…
Iter
…
Faser (tidsdimensjonen)
Disipliner
(aktivitetsdimensjonen)
Virksomhetsmodellering
Krav
Analyse og design
Implementasjon
Test
Deployment
Konfig & endringsstyring
Prosjektstyring
Omgivelser
Iter
#1
Oppstart
Innledende iterasjoner
Detaljering Konstruksjon Overføring
Iter
#m
Iter
#1
Iter
…
Iter
#n
Iter
#1
Iter
…
Iter
…
Faser (tidsdimensjonen)
Disipliner
(aktivitetsdimensjonen)
Virksomhetsmodellering
Krav
Analyse og design
Implementasjon
Test
Deployment
Konfig & endringsstyring
Prosjektstyring
Omgivelser
Figur 4
Disiplinene (tidligere kalt workflows) representerer aktiviteter som må utføres. Hver disiplin
har i tillegg et sett artefakter. Et poeng er at hver iterasjon inneholder nesten alle aktiviteter,
men med forskjellig omfang og at man arbeider med de samme artefakter. Det vil si at
artefaktene til å begynne med stadig endres, men etter hvert vil de konvergere mot en stabil
tilstand. F.eks. så vil kravene være flytende i oppstartsfasen og i begynnelsen av
detaljeringsfasen. Hovedpoenget er at man gjennom iterasjoner med tilbakemelding fra
brukere kommer frem til sikrere og sikrere krav. Også i de senere faser kan det bli endringer,
men etter hvert færre og færre. Et hovedmål med detaljeringsfasen er å få på plass en
arkitektur for programvaresystemet. Arkitekturen er det fundamentet og rammen som skal gi
grunnlaget for et kvalitetssystem. Vi kommer tilbake til temaet arkitektur i en senere leksjon.
I UP defineres disse disipliner:
- Virksomhetsmodellering er aktiviteter for å modellere forretningsprosesser. Målet er å få
frem kunnskap om de virksomhetsområder som det skal utvikles programvare for. På den
måten bygger man bro mellom systemutviklere og de som skal bruke systemene. Disse
aktivitetene vil være forskjellige avhengige av hvilken type virksomhet det dreier seg om.
- Krav. Her er målet å komme frem til hva programvaresystemet skal gjøre. Man skal frem
til funksjonelle krav uttrykt ved use case og ikke-funksjonelle krav. Det utarbeides en
visjon for systemet og aktører identifiseres.
Om prosesser side 10 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
- Gjennom analyse og design beskriver man hvordan systemet skal realiseres. Man
fastlegger en arkitektur, hvilke objekter programvaren skal bestå av, eventuelt database,
nettverk og desslike.
- Implementasjon omfatter aktiviteter for å realisere systemet. Koding av klasser utføres.
Systemet organiseres i delsystemer og komponenter. Enheter testes.
- Deployment er aktivitetene for å produsere et frislipp (relesase) og levere programvaren til
sluttbruker. Det kan inkludere planlegging og gjennomføring av betatester og
konvertering av eksisterende programvare og data.
- Konfigurasjons og endringsstyring skal sikre at de forskjellige artefakter ikke er i konflikt
med hverandre. Man må ha kontroll med oppdateringer, endringer, versjoner, varianter og
frislipp av programvaren. Dette er ikke praktisk mulig å få til uten automatiserte verktøy.
- Prosjektstyring er gjennomgående aktiviteter hvor man planlegger og følger opp
progresjonen i prosjektet.
- Omgivelsesdisiplinen er aktiviteter for å få på plass det som trengs for å støtte
gjennomføringen av prosjektet. Man skal finner frem og tilrettelegge nødvendig verktøy
og tilpasse prosessen til det aktuelle prosjekt.
Etter første gjennomløp av de fire hovedfasene har man utviklet første versjon av systemet.
Nye generasjoner produseres ved nye løp gjennom hovedfasene. Det er dette som ligger i
begrepet evolusjonær utvikling.
I løpet av prosessen fremstilles flere modeller. Disse er:
- Domenemodell som plasserer systemet i sin kontekst.
- Use Case modell som utgjør de funksjonelle kravene.
- Modell over ikke-funksjonelle krav.
- Analysemodell som gir en implemetasjonsuavhengig arkitektur (her aner vi Jacobson).
- Designmodell
- Prosessmodell som viser samtidighet og synkroniseringsmekanismer.
- Deployment modell som viser topologien for maskinvaren som systemet skal kjøre på.
- Komponentmodell viser hvordan systemet fysisk settes sammen.
- Testmodell.
Det er fremstillingen av disse modellene som står sentralt i senere leksjoner i dette faget.
UP blir av enkelte påstått å være en tung og lite smidig prosess. Etter mitt syn er det en
feilaktig oppfatning. En grunn til denne oppfatningen kan være at UP med tilhørende verktøy
er kommersialisert av IBM til en prosessmodell som kalles Rational Unified Process (RUP).
De fleste av aktivitetene og artefaktene i RUP er valgfrie. De som skapte UP ville lage en
smidig (agile UP) prosess som kan tilpasses og være så «lett» som ønskelig. Det vil si at man
velger ut det minimum av aktiviteter og artefakter som er hensiktsmessig i et gitt prosjekt og
vektlegger tidlig programmering fremfor dokumentasjon. Man lager heller ikke en detaljplan
for hele prosjektet i starten. Detaljplanlegging gjøres iterasjon for iterasjon. Modellering
gjøres etter prinsippene for smidig modellering. Mer om det i neste leksjon.
Om prosesser side 11 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
1.6.3. Ekstrem Programmering
Generelt
Extreme Programming (XP) er en prosessmodell som har fått en god del oppmerksomhet i
den senere tid. Hovedpoenget for de som står bak er at for å utvikle god programvare må man
føre ut i det ekstreme det som er nedfelt som de beste praksiser. Han som står bak er Kent
Beck. Ideene er forklart i [13]. Her følger en kort presentasjon av prosessen.
Hva er ekstremt?
Kent Beck skriver følgende om hva som er det ekstreme:
- Hvis koderevisjoner er bra, må vi revidere kode hele tiden. To programmere må arbeide
sammen hele tiden. (Pair programming)
- Hvis testing er bra, skal alle teste hele tiden, også kundene.
- Hvis det å designe er bra, må det være noe enhver holder på med hver dag.
- Hvis enkelhet er bra, skal systemet være i den enkleste form som støtter ønsket
funksjonalitet.
- Hvis arkitektur er viktig, skal alle arbeide med å definere og raffinere arkitekturen hele
tiden.
- Hvis integrasjonstesting er viktig, så skal man integrere og teste mange ganger hver dag.
- Hvis korte iterasjoner er bra, gjør man iterasjonene virkelig korte – sekunder, minutter og
timer, ikke uker, måneder og år.
Videre skriver han at XP, i tillegg til en del andre ting, er en morsom måte å utvikle
programvare på. Den skiller seg ut fra andre prosesser ved
- ved tidllig, konkret og kontinuerlig tilbakemelding fra korte sykluser
- inkrementell planlegging som tidlig frembringer en grov overordnet plan som skal
utvikles videre gjennom livsløpet
- fleksibel implementasjon av funksjonalitet i takt med endrede behov
- bruk av automatiske tester skrevet av programmerere og kunder for tidlig å fange opp
defekter
- muntlig kommunikasjon, tester og kildekode for å kommunisere strukturen for og
hensikten med systemet
- basering på en evolusjonær design prosess som varer så lenge systemet varer
- tett samarbeid mellom programmere med gjennomsnittlige ferdigheter
- praksiser som for programmere instinktivt føles riktige i det daglige og som tjener
prosjektene på lang sikt.
Det som er innovativt med XP er
- Alle gjennomprøvde praksiser settes under en paraply.
Om prosesser side 12 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
- At man sikrer at praksisene følges så nøye som mulig.
- At man sikrer at alle som er involvert støtter hverandre på best mulig måte.
En god del av dette finner man igjen i UP. Felles er fokusering på å kontrollere risikofaktorer
gjennom iterasjon. I UP legger man stor vekt på visuelle modeller for å kommunisere
forskjellige sider av systemet. I XP er muntlig kommunikasjon og kildekode det sentrale.
1.6.4. DSDM
Bakgrunn
DSDM står for Dynamic Systems Development Method. Det er altså en utviklingsmetode,
men begrepet assosieres også med et konsortium, DSDM-Consortium. Konsortiet ble etablert
i 1996 i England. Stifterne kom fra både store og små bedrifter i IT-industrien. Senere har
konsortiet fått medlemmer i flere land både i Europa og i Nord-Amerika, men er ennå ikke
etabler i Norge.
Motivasjonen for etableringen var de problemer vi tidligere har omtalt som typiske for
programvareindustrien med forsinkede prosjekter og overskridelser av budsjetter. Konsortiet
skal ikke tjene penger, men sørge for å dyktiggjøre medlemmene. Inntektene kommer fra
medlemskontingenter. Det konkrete resultatet fra arbeidet i konsortiet er DSDM som
utviklingsmodell eller det er kanskje riktigere å si at det er et rammeverk for en lettvekts og
smidig (agil) utvikling av programvaresystemer. Man kan godt si at konsortiet har som mål å
bidra til å fjerne oppfatningen om at smidig utvikling er noe som bare hackere holder på med.
Samtidig mente man at det var helt nødvendig med alternativer til fossefallsmodellen med de
åpenbare svakheter den har.
Prinsippene
DSDM-rammeverket beskriver en prosessmodell basert på prinsippet om iterativ og
inkrementell utvikling. Det inneholder også en del artefakter som skal lages i løpet av en
utviklingsprosess. Men bortsett fra disse overordnede prinsipper gir ikke modellen detaljerte
anvisninger for hvordan utviklingsarbeid skal drives. Det vil si at rammeverket skal tilpasses
det aktuelle utviklingsprosjektet og at dette kan gjennomføres etter mange forskjellige
paradigmer. Man kan altså følge et tradisjonelt funksjonsorientert paradigme så vel som
objektorientering og sågar extreme programming. Det siste er kan hende naturlig ettersom
både XP og DSDM er påvirket av den smidige (agile) bevegelsen. En introduksjon til DSDM
finner vi i Stapleton [18].
Rammeverket er basert på disse ni prinsippene:
1. Aktiv brukermedvirkning er uomtvistelig.
2. Grupper som praktiserer DSDM må ha stor grad av selvstyre. Det vil si at gruppen må
ha fullmakt til å fatte vidtrekkende beslutninger.
3. Fokus er på hyppig levering av produkter.
4. For at det som leveres skal aksepteres må det vise sin nytte for virksomheten som skal
ha programvaren.
5. Iterativ og inkrementell utvikling er nødvendig for at man skal oppnå en riktig løsning.
6. Alle endringer som gjøres er reversible.
7. Krav fastsettes (is base lined) på et høyt nivå.
Om prosesser side 13 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
8. Testing er integrert gjennom hele livsløpet.
9. Det er essensielt at det er et tett samarbeid og samspill mellom alle interesseparter.
Det er konsortiets oppfatning at alle disse prinsippene må følges hvis resultatet skal bli et
kvalitetssystem.
Modellen
DSDM-rammeverket deler et utviklingsprosjekt inn i syv faser. Eller hvis man skal være mer
presis så er det to faser som ikke er knyttet direkte til utvikling og fem utviklingsfaser. Det er
en forprosjektfase (pre-project phase) hvor man sikrer at prosjektet får en sunn forankring og
en etterprosjektfase (post-project phase) hvor man summerer opp erfaringer og sikrer at den
leverte løsning fortsatt er operativ. Figur 5 viser utviklingsfasene i DSDM.
Business study
Feasibility
Functional model iteration
Implementation
Design and bild iteration
Agree schedule
Create
Functional
prototype
Review prototype
Identify
Functional
prototype
Identify
Design prototypes
Agree
schedule
Create design
prototype
Review
Design
prototype
Implement
Review
business
User approved and
User guidelines
Train
users
Figur 5 Utviklingsfasene i DSDM
Modellen kalles populært for tre pizzaer og en ost. Osten viser to lineære faser. De iterative
og inkrementelle faser utgjøres av de tre pizzaer. Den første delen av osten er forstudien hvor
man gjør de tradisjonelle tingene for å få en overordnet vurdering av ønsket funksjonalitet og
løsningsmuligheter samt grove kostnads- og ressursestimater. I business study analyseres
virksomheten og grunnlaget for videreføring av prosjektet legges. Så følger tre iterative faser
som man kan gå frem og tilbake mellom. I Functional model iterasjonen detaljeres det
arbeidet som ble startet i business modelling. Man starter arbeidet med en evolusjonær
prototyp. Høynivåarkitekturen fastsettes. Man itererer gjennom denne fasen inntil man har
skaffet nok informasjon om funksjonaliteten som ønskes slik at man kan gå over i design and
build, hvor systemet videreutvikles slik at det kan overføres til virksomheten i
implementasjonsfasen. DSDM tillater, i god smidig stil, endringer hvis ny kunnskap tilsier
det. Derfor piler frem og tilbake mellom pizzaene.
Om prosesser side 14 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Et viktig element i DSDM er MoSCoW-reglene. MoSCoW er et akronym for prioritering av
krav. Som konsortiet selv skriver er de to o-ene satt inn for moro skyld. De andre bokstavene
står for:
Must have – de krav som er helt nødvendige for at systemet skal kunne brukes i
det hele tatt.
Should have – er krav som ville blitt satt som nødvendige hvis tidsrammene ikke
er for stramme, men som man i første omgang kan klare seg uten.
Could have – er krav man kan klare seg uten i det inkrementet man er inne i.
Want to have but will not have this time round – er krav som kan vente til
eventuell videreutvikling av systemet.
Det viktige med MoSCoW-reglene er de danner basisen for beslutninger som skal gjøres i en
bestemt timebox. Og timeboxing er et viktig redskap for alltid å levere i tide og innenfor
busjett. Det betyr at i en timebox er man ikke opptatt av aktiviteter, men at noe skal leveres
etter hver timebox. I en timebox, som kan være mellom to og seks uker lang, skal man ha
både Must have og Should have krav. Slik kan man ha krav som kan kastes ut hvis ting av
uforutsette årsaker ikke skulle gå som opprinnelig planlagt i en timebox.
Av andre ting som vektlegges i DSDM er at lange arbeidsdager ikke skal være normen. Målet
er å arbeide normale arbeidsdager og bruke kvelder og helger til rekreasjon og avkobling.
1.6.5. Scrum
Bakgrunn
Det kan se ut som Scrum nå er det mest populære smidige prosessrammeverk. Det ble
formalisert av Ken Schwaber og Jeff Sutherland i begynnelsen av 1990-tallet. Begrepet
Scrum er hentet fra sporten Rugby hvor selvstyrte team jobber tett sammen mot et felles mål.
Scrum er et iterativt, inkrementelt rammeverk. Det kan brukes på prosjekter og
produktutvikling, spesielt programvareutvikling. Et av de sentrale poengene i Scrum er at
prosessen deles opp i iterasjoner av fast lengde. En slik iterasjon kalles en Sprint. En Sprint
gis en lengde på fra en til fire uker. Det er et poeng at en sprint ikke er for lang. Da vil det gå
for lang tid før nødvendig tilbakemelding fra brukere og andre interessenter kan gis. En Sprint
kan heller ikke være for kort. Da vil ikke teamet rekke å gjøre noe nyttig arbeid. Det mest
vanlige er derfor en sprintlengde på 14 dager. Du finner en introdusjon til Scrum i [14].
Prinsippene
Figur 6 viser flyten i en Scrumprosess. Det sentrale er Sprinter. Disse har en fast varighet
gjennom hele prosjektet. Det mest vanlige er to uker slik at teamet får tid til å gjøre noe
fornuftig arbeid samtidig som det er kort tid mellom hver tilbakemelding om prosjektet og
produktets status.
Om prosesser side 15 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Figur 6 Prosessflyten
Tallet 3 går igjen. Det er tre artefakter, tre roller og tre seremonier. De tre artefaktene er
produktkø, sprintkø og «burndown chart». Produktkø og sprintkø består av brukerfortellinger
(user stories). En brukerfortelling er et krav formulert i noen få setninger. Produktkøen
inneholder alle kjente krav til systemet som skal utvikles. Sprintkøen inneholder kravene som
skal realiseres i den forestående sprinten. Resultatet av sprinten er et kjørbart inkrement av det
totale systemet. Det kjørbare inkrementet skal om mulig kunne brukes og gi nytte for
oppdragsgiver. Et burndown chart er et diagram som viser gjenstående arbeid i sprinten. Det
oppdateres hver dag.
De tre rollene er produkteier, scrummaster og scrumteam. Produkteier er kunden eller
alternativt en kundekontakt, og har ansvaret for å få laget brukerfortellingene. Scrumteamet er
de som gjør arbeidet i sprintene. Størrelsen er 5 – 9 personer med tverrfaglig kompetanse. De
er selvstyrte. Scrummaster er en fasilitator som skal hjelpe scrumteamet til å nå sine mål.
Han/hun er ikke en prosjektleder i tradisjonell forstand ettersom teamet er selvorganiserende
og selvstyrt. I en sprint skal teamet arbeide uforstyrret. Scrummaster skjermer teamet ved å
være kontaktpunktet mot produkteier og bidrar ellers til at teamet følger reglene for Scrum.
De tre seremoniene er sprintplanleggingsmøtet, det daglige scrummøte og
sprintrevisjonsmøtet. Sprintplanleggingsmøtet gjøres i forkant av hver sprint. Her bestemmes
hvilke brukerfortellinger fra produktkøen som skal realiseres i den kommende sprinten.
Produkteier prioriterer, mens teamet estimerer hvor mange brukerfortellinger det vil klare å
realisere. På det daglige sprintmøtet, også kalt «stand up» møtet, rapporterer hvert
teammedlem sin status. Det gjøres ved at scrummaster stiller tre spørsmål til hvert
teammedlem – Hva gjorde du i går? Hva planlegger du å gjøre i dag? Hvilke hindringer ser
du for deg? Møtet skal være kort. Det betyr at problemer som avdekkes ikke løses i dette
møtet. I stedet vil det ved behov berammes møter for problemløsning. På standupmøtet
oppdateres burndown kartet.
Sprintrevisjonsmøtet holdes ved slutten av hver sprint. Poenget er å finne ut hvor man står.
Møtet er todelt. I den første delen får interessentene presentert produktet og kan gi
tilbakemelding. Den andre delen er en såkalt retrospektiv hvor teamet analyserer selve
prosessen for å finne mulige områder for forbedring ved gjennomføringen av fremtidige
Om prosesser side 16 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
sprinter. Læring og forbedring er sentralt i Scrum. Møtet skal derfor få frem hva som gikk
galt, hva som gikk bra og hvilke forbedringstiltak som må tas med til neste sprint.
Sprintgjennomføring
Arbeidet i Scrum skjer altså i sprinter med sine roller og seremonier. Det visuelle
hjelpemiddel til å følge med på det som skjer er en enkel oppgavetavle på en vegg. Det
fortutsetter at teamet jobber sammen daglig i det samme rommet.
Figur 7 Oppgavetavle
Figur 7 viser et eksempel på en oppgavetavle. Den viser på en enkel måte tilstanden til
Srumprosjektet. Vi ser en tavle (white-board) med Post-It lapper. De hvite lappene er
brukerfortellinger. En brukerfortelling kan være delt opp i flere oppgaver. De er representert
med de gule lappene. En brukerfortelling kan være i en av tre tilstander illustrert med de tre
kolonnene: Ikke påbegynt (Not checked out), under arbeid (Checked out) og ferdig (Done).
På det aktuelle tidspunktet ser vi at en brukerfortelling er ferdig, en oppgave fra en
brukerfortelling betående av tre oppgaver er under arbeid. Det vil si at brukerfortellingen er
delvis påbegynt. En brukerfortelling er ennå ikke startet.Til venstre ser vi et «burn down»
kart. Den prikede linjen viser det idelle forløp. Verd slutten av sprinten skal alle
brukerfortellinger være realisert ved at gjentående arbeidsmengde er null. Den blå linjen viser
virkelig gjenstående arbeidsmengde. Det ser ut som prosjektet så langt går som planlagt fordi
den virkelige linjen stort sett følger den ideelle. De gule lappene til venstre er oppgaver som
ikke var planlagt, men blir avdekket i løpet av sprinten. De hvite lappene til venstre er
brukerfortellinger som kan påbegynnes hvis arbeidet i sprinten går raskere enn planlagt.
1.7. Den personlige prosessen
Ideen om den personlige prosessen er lansert av Watts S. Humphrey. Hans poeng er at
profesjonelle programvareutviklere må kunne levere programvare av høy kvalitet innenfor
avtalte tids- og kostnadsrammer. Dette oppnås ved at den enkelte utvikler definerer sin egen
personlige utviklingsprosess. Gjennom erfaring med prosessen og enkle målinger, tar man
sikte på stadig å forbedre prosessen. Man blir kjent med sine styrker og svakheter og hvor
Om prosesser side 17 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
man kan forbedre seg. En definert prosess som følges, fører til at man får et stadig bedre
grunnlag for å gjøre gode estimater. En skisse av den personlige prosessen er vist i Figur 8.
Scripts
Planlegging
Design
Kod
Kompiler
Test
Post Mortem
LoggerLogger
Plan
sammendrag
Krav
Ferdig produkt
Retnings-
linjer
Plan
Resultater
Tid
Defekter
Prosjekt og prosess data
Sammendragsrapport
Scripts
Planlegging
Design
Kod
Kompiler
Test
Post Mortem
LoggerLogger
Plan
sammendrag
Krav
Ferdig produkt
Retnings-
linjer
Plan
Resultater
Tid
Defekter
Prosjekt og prosess data
Sammendragsrapport
Figur 8
1.8. Om prosesser og prosessforbedring
1.8.1. Et rammeverk
De prosesser som er beskrevet foran er med et unntak laget av personer som er først og fremst
opptatt av metoder for objektorientert utvikling av programvare. Unntaket er den personlige
prosessen. Humphrey [3] [4] arbeider ved Software Engineering Institute (SEI) ved Carnegie
Mellon Universitetet i USA. I det miljøet er de opptatt av utviklingsprosesser i sin
allminnelighet og sammenhengen mellom kvaliteten på prosessen og de produkter som er
resultatet av prosessen. Fokus på prosesser blir et annet, enn når prosessen blir noe man
legger på en utviklingsmetode.
SEI har utviklet et rammeverk som skal hjelpe virksomheter i å forbedre sine
utviklingsprosesser. Det startet med at amerikanske myndigheter, spesielt forsvaret, ønsket
metoder for å kunne vurdere om leverandører var i stand til å gjennomføre utvikling av
programvare med nødvendig kvalitet. Bakgrunnen for dette var igjen de mange problemer
med forsinkelser, kostnadsoverskridelser og problemer med kvaliteten på levert programvare
som man stadig opplevde. For å gjøre historien kort, så ble resultatet det som nå er kjent
under betegnelsen Capability Maturity Model (CMM).
CMM er basert på sunn praksis som har vist seg å fungere i vellykkede organisasjoner. Det
har i seg elementer som skal hjelpe utviklerne til stadig å forbedre utviklingsprosessen.
Om prosesser side 18 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
Kunnskapen er hentet inn gjennom erfaringer fra både statlige og offentlige virksomheter (i
USA) i tillegg til en rekke andre kilder. Dette er nærmere beskrevet i bla [10] og [11].
Et av elementene i CMM er at virksomheter som ønsker å forbedre sine prosesser gjør det
gjennom en langsiktig forbedringsprosess. I denne prosessen1 skal virksomheten gå gjennom
flere nivåer. Hvert nivå representerer en forbedring i forhold til nivået under. Det er fem
nivåer. Disse er vist i Figur 9 og betegnes som modenhetsnivåer.
Initiell
Repeterbar
Definert
Styrt
Optimalisert
Initiell
Repeterbar
Definert
Styrt
Optimalisert
Figur 9
Det som karakteriserer utviklingsprosessene til virksomheter på det initielle nivå er:
- ad hoc
- tilfeldig og kaotisk
- suksess avhengig av spesielt begavede enkeltpersoner
- suksess vil ikke nødvendigvis kunne gjentas
Det finnes ikke noe stabilt miljø som gjør at virksomheten kan inngå forpliktende avtaler om
tids og kostnadsrammer eller kvaliteten på de produkter som utvikles. Men det betyr ikke at
slike virksomheter ikke kan levere utmerkede produkter - av og til. Det er eksempler på at
grupper bemannet med meget dyktige, entusiastiske og effektive utviklere har levert
innovative produkter. Men noe av hensikten med å ha definerte prosesser er at selv middels
1 Legg merke til at man har prosesser for å forbedre prosesser!
Om prosesser side 19 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
utviklere skal kunne levere gode produkter; om ikke eksepsjonelle; om igjen og om igjen. Det
er nettopp det som karakteriserer andre ingeniørvirksomheter.
Neste nivå er det repeterbare. Her er noen nøkkelområder på plass:
- styring av økonomi, tid og funksjonalitet
- kan gjenta suksess med nye prosjekter av samme type som tidligere prosjekter
Det vil si at man har på plass de nødvendige retningslinjer for å kunne planlegge og følge opp
prosjekter. Man tar vare på erfaringer og data om kostnader og varighet fra tidligere
prosjekter. Disse erfaringene og dataene er grunnlaget når nye prosjekter planlegges. Tidligere
suksess kan gjentas (repeteres).
På definert nivå har man en utviklingsprosess som består av aktiviteter som er dokumenterte,
standardiserte og integrerte. Alle prosjekter følger en skreddersydd versjon av
standardprosessen. En gruppe er gitt ansvaret for aktiviteter knyttet til arbeidet med å forbedre
prosessen. Det eksisterer et opplæringsprogram som skal gi ledere og utviklere de nødvendige
kunnskaper og ferdigheter. Prosessen kalles definert fordi det er på plass kriterier for start og
avslutning av et prosesstrinn. Det er etablert standarder og retningslinjer for hvordan arbeidet
skal utføres. Det er lagt inn rutiner for verifikasjon. Kostnader og ressursbruk er under
kontroll.
Karakteristisk for det styrte nivå er at man gjennomfører målinger på produkt og prosess.
Produkter og prosesser kan uttrykkes gjennom tall som sier noe om kvaliteten. Prosessen er
under statistisk kontroll. Man kan si at prosessen er kvantifiserbar og forutsigbar. Det er mulig
å forutsi resultater innenfor kvantifiserbare grenser og man kan skille ut uvanlige hendelser
fra normal variasjon i prosessen. Når slike avvik fra det normale inntrer er man i stand til å
aksjonere for å korrigere situasjonen.
Når man har nådd det øverste nivå er man i stand til å gjøre stadige forbedringer gjennom
tilbakemelding fra prosessen. Alle i virksomheten er opptatt av kontinuerlig forbedring av
utviklingsprosessen. Man er i stand til å handle proaktivt, ikke reagere i ettertid. Det vil si at
man har så god innsikt i prosessen at man kan forutsi nytten og konsekvensene av å ta i bruk
ny teknologi og de endringer man gjør. Forhindring er sentralt. Feil som gjøres analyseres og
årsaker blir funnet slik at feil ikke gjentas. Kontinuerlig forbedring er stikkordet for det
optimaliserende modenhetsnivå.CMM legger opp til at virksomheter skal arbeide seg oppover
i modenhet. Nøkkelen til suksess ligger i å gå alle trinnene. Det er en langsiktig utfordring.
Man kan ikke hoppe over noen av nivåene. Man må være etablert på et nivå før man kan
begynne arbeidet for å nå neste nivå.CMM er et abstrakt rammeverk. Det betyr at man
beskriver hva som forventes av utviklingsprosessen på hvert nivå, ikke hvordan prosessen
detaljert utformes på hvert nivå. Hvert modenhetsnivå er karakterisert ved nøkkelområder og
nøkkelvirksomheter innenfor hvert nøkkelområde. Innenfor hvert nøkkelområde settes det
mål som skal oppnås.
Etter hvert har det kommet CMM-er for forskjellige områder bl.a. systems engineering, SE-
CMM, i tillegg til CMM for programvareutvikling SE-CMM, som vi har beskrevet foran.
Man har derfor kommet frem til at det er hensiktsmessig å integrere flere av disse modellene
slik at man får en enhetlig struktur og felles terminologi. Dette tiltaket har resultert i CMMI,
en integrert CMM og hvor arbeidet med prosessforbedringsmodeller er samlet.
Om prosesser side 20 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
1.8.2. Den definerte prosessen
De fleste vil innse behovet for en definert utviklingsprosess for programvare. I arbeidet med å
definere en prosess er det to krav som må tilfredsstilles.
- Prosessen må være standardisert
- Prosessen må være fleksibel
Standardisering er nødvendig for å være forutsigbar. Fleksibilitet må til fordi prosjekter er
forskjellige og det må være rom for kreativ utfoldelse som kan lede til innovasjoner.
Forskjellige virksomheter har forskjellige behov. Forskjellige typer programvare krever
forskjellige prosesser. Utviklernes dyktighet vil også variere og vil bestemme valg av prosess.
1.8.3. Kanban og slank
Vi har i tidligere kapitler skrevet om smidige prosesser og gitt eksempler på smidige
prosessrammeverk som UP, Ekstrem programmering, DSDM og Scrum. I dette kapitlet skal
vi kort se litt på de prinsippene som ligger bak og som kan begrunne hvorfor smidige
prosesser fungerer. Vi tar det med under overskriften prosessforbedring fordi kontinuerlig
forbedring er et viktig element.
Prinsipppene har sitt utgangspunkt i slanktankegangen (engelsk: lean). Slankprinsippene har
fått generell stor oppmerksomhet innen industrien vesten (også Norge) de senere årene.
Grunnen til det er at man har ønsket å finne ut hvorfor spesielt japansk bilindustri har hatt så
stor suksess. Det er Toyotas produsjonssystem som har fattet interessen fordi Toyota har vist
at de kan produsere biler med høy kvalitet på en meget effektiv måte. Begreper som kanban
og kaizen ser man også ofte i faglitteraturen. Kanban er signalkort som brukes i
produksjonsprosessen for å signalisere ledig kapasitet. Kaizen betyr kontinuerlig forbedring
på japansk.
Også folk innen programvareutvikling har sett til Japan og slanktankegangen. De som lanserte
smidige prosesser er klart influert. Et eksempel er pionerene Mary og Tom Poppendieck. De
har skrevet flere bøker om temaet. I [15] lanserer de syv prinsipper basert på
slanktankegangen som de argumenterer for at man skal følge i
programvareutviklingsprosesser. Disse syv prinsippene i kortform er:
1. Eliminer sløsing. Sløsing er sikt som ikke gir verdi for kunden. Still spørsmål ved om
alt papirarbeidet er nødvendig.
2. Sørg for kontinuerlig læring. God programvare er resultat av stadig læring gjennom
prøving og feiling.
3. Vent med beslutninger så lenge som mulig. Beslutninger blir bedre når de er basert på
fakta og ikke spekulasjoner. Det må derfor legges inn muligheter for å endre. Det skjer
gjennom korte iterasjoner.
4. Lever så raskt som mulig. Kunder vil ha resultater raskt. Kjør korte sykluser med
design-implementasjon-tilbakemelding-forbedring.
Om prosesser side 21 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
5. Deleger beslutningsmyndighet til teamet. La de ta beslutningene som føler problemene
på kroppen.
6. Bygg inn integritet. Med integritet menes at systemene må tilfredstille krav fra kunder
og brukere. Samtidig man sikre at systemenes interne oppbygning er slik at de lett kan
vedlikeholdes, tilpasses og utvides. Valg av arkitektur er viktig.
7. Se helheten. Ikke optimaliser delsystemer. Unngå at forskjellige eksperter kun er
opptatt av å perfeksjonere sin del av systemet.
Om kanban skriver David J. Anderson [17]:
Kanban er et begrep som omfatter Toyotas produksjonssystem og kontinuerlig
forbedring.
kanban (med liten k) er et signalkort. Han bruker virtuelle signalkort for å kontrollere
arbeidsflyten i utviklingsprosesser.
Kanban (med stor K) er samlebegrepet for metoder for evolusjonær, inkrementell
prosessforbedring.
Kanban er altså ikke et prosessrammeverk, men en samling prinsipper for prosessforbedring.
Man starter med den prosessen man er vant med og illustrerer verdiflyten i prosessen fra ide
til ferdig system. Så bruker man kreative verktøy til å finne trinn i prosessen som kan
ellimineres eller forbedres slik at flyten blir bedre. For å illustrere prosessen bruker man en
form for oppgavetavle med kolonner for de forskjellige trinnene, som beskrevet i kapitlet om
Scrum. En slik Kanbantavle kan ha flere kolonner enn den som brukes i SCRUM. Oppgavene
i prosessen illustreres med post-it lapper.
Som dere skjønner er slank og kanban omfattende temaer. Prosesser og prosessforbedring er
ikke hovedtema i dette kurset, men er introdusert for å sette utviklingsaktivitetene i en større
sammenheng. De som er spesielt interesserte i smidige prosesser, slankprinsippene og kanban,
kan se i litteraturen, for eksempel bøkene til Mary og Tom Poppendieck [15], Alan Shalloway
m.fl. [16] og David J. Andersen [17]. Alle bøkene er tilgjengelige som e-bøker. Det er også
mye tilgjengelig stoff på nettet.
1.9. Lesestoff til denne leksjonen
Kapittel 1 og 2.
1.10. Litteratur
1. Berry W. Boehm, ”A Spiral Model of Software Development and Enhancement”, IEEE
Computer, Mai 1998.
2. Terry Quantrani, ”Visual Modeling with Rational Rose and UML”, Addison-Wesley
1998, ISBN 0-201-31016-3.
3. Watts S. Humphrey, ”Introduction to the Personal Software Process”, Addison-Wesley
1997, ISBN 0-201-54409-7.
4. Watts S. Humphrey, ”A Dicipline for Software Engineering”, Addison-Wesley 1995,
ISBN 0-201-54610-8.
Om prosesser side 22 av 22
Opphavsrett: Forfatter og Stiftelsen TISIP
5. Ivar Jacobson & al., ”Object-Oriented Software Engineering, A Use Case driven
Approach”, Addison-Wesley 1992, ISBN 0-201-54435-0.
6. James Rumbaugh & al, ”Object-Oriented Modeling and Design”, Prentice Hall 1991,
ISBN 0-13-630054-5
7. Grady Booch, ”Object-Oriented Analysis and Design, Benjamin/Cummings 1994, ISBN
0-8053-5340-2.
8. Ivar Jacobson, Grady Booch, James Rumbaugh, ”The Objectory Software Development
Process”, Addison Wesley 1999, ISBN 0-201-57169-2.
9. Martin Fowler and Kedall Scott, ” UML Distilled”, Addison Wesley 1997, ISBN 0-201-
32563-2.
10. Watts S. Humphrey, ”Managing the Software Process”, Addison-Wesley 1989, ISBN 0-
201-18095-2.
11. Mark C. Paulk & al, ”The Capability Maturity Model: Guidelines for improving the
Software Process”, Addison-Wesley 1995, ISBN 0-201-546664-7.
12. Craig Larman, “Applying UML and Patterns, An Introduction to Object-Oriented
Analysis and Design and Iterative Development”, Prentice Hall 2005, ISBN 0-13-148906-
2.
13. Kent Beck, “extreme Programming explained”, Addison-Wesley 2000, ISBN 0-201-
61641-6.
14. http://www.goodagile.com/scrumprimer/scrumprimer.pdf
15. Mary Poppendiec og Tom Poppendieck, “Lean Software Development, An Agile
Toolkit”, Addison-Wesley 2003, ISBN 0321-15078-3.
16. Alan Shalloway & al, “Lean-Agile Software Development, Achieving Enterprise Agility”,
Addison-Wesley 2010, ISBN 978-0-321-53289-3.
17. David J. Anderson, “KANBAN, Successful Evolutionary Change for Your Technology
Business”, Blue Hole Press 2010, ISBN 978-0-9845214-1.
18. Jennifer Stapleton, “DSDM: Business Focused Development”, DSDM Consortium 2003,
ISBN 978-0-321-11224-8.