Prosessmodeller og smidig programvareutvikling

Transkript

1 24/01/17 INF1050: Systemutvikling 24. januar 2017 Prosessmodeller og smidig programvareutvikling Professor Dag Sjøberg INF1050/ / Dag Sjøberg Slide 1 Smakebit på mastergradskurset Smarte prosesser og smidige metoder i systemutvikling (ny versjon av INF5181 Prosessforbedring og smidige metoder i systemutvikling ) INF1050/ / Dag Sjøberg Slide 2 1

2 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 3 Reell prosess versus modell av prosess Systemutviklingsprosess (= faktisk, reell prosess): de aktivitetene som utføres i et utviklingsprosjekt Prosessmodell (=formell prosess) (kalles også gjennomføringsmodell) En abstrakt, forenklet representasjon av en prosess Normativ (preskriptiv) beskriver en prosess slik noen mener den bør være (vanligste betydning) Deskriptiv beskriver en prosess slik vi mener vi utfører den INF1050/ / Dag Sjøberg Slide 4 2

3 24/01/17 Modell versus virkelighet Ceci n'est pas une pipe INF1050/ / Dag Sjøberg Slide 5 Formell versus reell prosess Det vi sier vi gjør eller det vi bør gjøre Prosessbeskrivelse INF1050/ / Dag Sjøberg Det vi gjør Prosessutførelse Slide 6 3

4 Nivåer av prosessmodeller Generelle prosessmodeller (fossefall, RUP, Scrum etc.) Definerte prosessmodeller (formell prosess) Firma-spesifikke prosessmodeller Prosjekt/gruppe-spesifikke prosessmodeller Prosess-samsvar ( Process compliance ) Reell prosess Systemutviklingsprosess INF1050/ / Dag Sjøberg Slide 7 Hvordan tilpasse prosesser? Prosesser må tilpasses ingen prosjekter er like Mange faktorer påvirker prosessen Hva kan tilpasses? Faser/aktiviteter, roller, ansvarsforhold, utforming/frekvens på rapporter og gjennomganger Hvordan tilpasse? Identifiser prosjektomgivelser utviklingsstrategi, risiko, krav, applikasjonsområde, type kunde etc. Innhent synspunkter fra utviklere, brukere, kunder Definer prosesser, aktiviteter og roller Begrunn og dokumenter tilpasningene INF1050/ / Dag Sjøberg Slide 8 4

5 Myndighetene anbefaler felles prosjektmodell Direktoratet for forvaltning og IKT (DIFI) anbefaler at offentlige virksomheter skal bruke en felles prosjektmodell, Ulempe Sjelden at samme modell passer for alle type virksomheter Lite smidig modell (Prince2) Fordel Læring på tvers av etater INF1050/ / Dag Sjøberg Slide 9 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 10 5

6 Fossefallsmodellen Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance I prinsippet går man ikke tilbake til tidligere hovedaktiviteter før systemet er satt i drift. INF1050/ / Fra Dag Ian Sjøberg Sommerville Slide 11 Kjennetegn ved fossefallsmodellen Plandrevet, dvs. utviklingen styres av planer. Separate faser Vanskelig å tilpasse endringer i brukerkrav underveis Best ved godt forståtte krav og når lite sannsynlig med mye endringer underveis Men få systemer har stabile krav Brukes mest i store prosjekter som gjerne utvikles på ulike steder. Plandrevet utvikling enklere å koordinere arbeidet Men brukes også i små, godt forståtte prosjekter (jfr. de 4 bedriftene som lagde samme system) INF1050/ / Dag Sjøberg Slide 12 6

7 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 13 Inkrementer og iterasjoner i systemutvikling Et inkrement er et tillegg i funksjonaliteten et aspekt ved systemet En iterasjon er en syklus i utviklingen et aspekt ved prosessen Et nytt inkrement utvikles gjennom en ny iterasjon En ny iterasjon kan også forbedre kvaliteten på samme funksjonalitet, dvs. man lager ikke noe nytt inkrement, men bare forbedrer det eksisterende systemet INF1050/ / Dag Sjøberg Slide 14 7

8 Inkrementell utvikling Systemet utvikles gradvis i form av nye inkrementer som blir lagt til. Hvert inkrement evalueres før utviklingen av neste inkrement starter Evalueringen gjøres av en bruker- eller kunderepresentant ( product owner ) Viktigste krav utvikles først Når utviklingen av et inkrement er startet, så fryses kravene til det inkrementet. Krav til senere inkrementer kan fortsatt endres Vanlig tilnærming i smidige metoder INF1050/ / Dag Sjøberg Slide 15 Inkrementell installering Istedenfor at hele systemet leveres til kunden på én gang, leveres ett inkrement av gangen. % funksjonalitet installert Måned INF1050/ / Dag Sjøberg Slide 16 8

9 Fordeler ved inkrementell utvikling og installering Kostnadene ved endrede brukerkrav reduseres sammenlignet med fossefallsmodellen da delene som må endres, er mindre Enklere å få tilbakemeldinger fra kunden på det som har blitt utviklet Lettere å se hvor mye som er utviklet så langt Raskere levering av deler av systemet gir verdi for kunden raskere enn ved fossefallsmodellen Den prioriterte funksjonaliteten blir testet mest Lavere risiko for total prosjektfiasko INF1050/ / Dag Sjøberg Slide 17 Utfordringer ved inkrementell utvikling og installering Store prosjekter og systemer krever en relativt stabil arkitektur som inkrementene og teamene må forholde seg til, dvs. arkitekturen kan ikke utvikles i inkrementer Strukturen til systemet har en tendens til å bli stadig verre etter hvert som inkrementer legges til Derfor stadig vanskeligere å foreta endringer hvis ikke ressurser brukes på re-strukturering (re-faktorering) INF1050/ / Dag Sjøberg Slide 18 9

10 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 19 Prototyping Prototype: en foreløpig versjon av et system utviklet for å utforske: kravene til et system alternative brukergrensesnitt ulike måter å teste systemet på Potensielle fordeler: bedre match mot brukernes faktiske behov bedre brukskvalitet bedre design INF1050/ / Dag Sjøberg Slide 20 10

11 Utvikling ved bruk av prototype Prototypen bør fokusere på områder av systemet som ikke er godt forstått Det finnes egnede språk og verktøy INF1050/ / Dag Sjøberg Slide 21 Throw-away prototype Protypen bør skrotes etter at den lagd og brukt for dårlig basis for et produksjonssystem Vil kunne være umulig å møte ikke-funksjonelle krav (f.eks. ytelse, pålitelighet og sikkerhet) Prototyper er normalt udokumenterte Strukturen til prototyper er vanligvis degradert gjennom raske endringer INF1050/ / Dag Sjøberg Slide 22 11

12 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 23 Rational Unified Process (RUP) Ikke en konkret prosessmodell, men et rammeverk for å bygge arkitektur/uml-modeller (se senere forelesninger) Programvarebedrifter eller team kan ta utgangspunkt i RUP for å skreddersy en modell for sin utvikling Benytter seg av prinsipper fra prosessmodellene beskrevet tidligere i forelesningen Vanligvis beskrevet med fokus på faser, disipliner (aktiviteter) og anbefalt god praksis INF1050/ / Dag Sjøberg Slide 24 12

13 Fire faser i RUP Hver fase er iterativ med Phase resultater iterationsom utvikles i inkrementer Inception Elaboration Construction Transition Innledning/idé (lag business case) (inception) Lag overordnet målsetting, behovsanalyse, budsjett, prosjektplan Identifisere funksjonelle krav og modellere use cases (brukstilfeller) Utdypning (elaboration) Fortsett med å forstå problemområdet, lag use cases Start design av arkitektur, lag arkitektur prototype Ferdigstill prosjektplanen Konstruksjon (construction) Design-programmer-test, typisk i flere iterasjoner Installering/driftssetting (transition) Overfør systemet til sitt produksjonsmiljø og sett det i drift; gi nødvendig opplæring til sluttbrukerne og vedlikeholdere; valider systemet i forhold til kvalitetskrav spesifisert i innledningen etc. INF1050/ / Dag Sjøberg Slide 25 Anbefalte praksiser i RUP Utvikle systemet i iterasjoner I hver iterasjon, legg til et nytt inkrement. Først lag de inkrementene som kunden har prioritert høyest Sørg for god håndtering av krav Dokumenter kundekrav nøye og sørg for dokumentasjon av endringer i kravene Bruk komponent-basert arkitektur Organiser systemets arkitektur som en mengde gjenbrukbare komponenter Lag visuelle modeller av programvaren Bruk grafiske UML-modeller for å presentere statiske og dynamiske sider ved systemet Verifiser kvaliteten Sjekk at programvaren tilfredsstiller organisasjonens kvalitetsstandarder Kontroller endringer i programvaren Bruk endringshåndteringsverktøy og konfigurasjonsstyringsverktøy INF1050/ / Dag Sjøberg Slide 26 13

14 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 27 Gjenbruksbasert utvikling Eksisterende programvare gjenbrukes i varierende grad i utviklingen av nye systemer Komponentbasert utvikling Samling av komponenter i en pakke som del av komponentrammeverk som.net eller J2EE eller andre typer komponent-biblioteker Service-orientert (tjenesteorientert) utvikling Web-services som er utviklet i henhold til en standard og som kan kalles fra andre steder Service-orientert arkitektur (SOA): Forelesning 28. februar INF1050/ / Dag Sjøberg Slide 28 14

15 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 29 Behov for smidighet Den klassiske ingeniørtilnærmingen med fokus på planlegging og dokumenter (jfr. fossefall) har vist seg ofte å ikke være egnet Derfor er smidige metoder blitt vanlige Vektlegging av kode fremfor (omfattende) design og dokumentasjon Vektlegging av samarbeid med kunde fremfor kontraktsforhandlinger Raskere levering av kode og raske endringer tilpasset endrede brukerkrav INF1050/ / Dag Sjøberg Slide 30 15

16 Plandrevne (tunge) prosesser Smidige (lette) prosesser Prosessaktivitetene planlagt på forhånd. Progresjon måles i henhold til planen En tung prosess inkluderer mange aktiviteter og ofte roller. Krever formelle, detaljerte og konsistente prosjektdokumenter Ofte for-tunge, dvs. vektlegger aktiviteter som gjøres tidlig i prosessen (planlegging, analyse & design) Planleggingen gjøres litt etter litt (inkrementelt) Enklere å endre prosessen for å tilpasse endrede krav fra kunden Fokuserer mer på fundamentale prinsipper (f.eks. kontinuerlig testing ). Har færre formelle dokumenter og er ofte mer iterative INF1050/ / Dag Sjøberg Slide 31 En samling software-guruer i 2001: Agile Manifesto 12 prinsipper* * og INF1050/ / Dag Sjøberg Slide 32 16

17 Agile Manifesto 2001 (forts.) * og INF1050/ / Dag Sjøberg Slide 33 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 34 17

18 Ekstrem programmering (XP) Ekstrem ved at: Hele systemet kan bygges opp til flere ganger daglig Inkrementer av systemet leveres til kunden annenhver uke Alle tester må kjøres før hver bygging* Byggingen aksepteres bare hvis testene er vellykkede *Bygging: Alle komponentene til systemet kompileres og linkes til hverandre og til data og biblioteker som er nødvendige for å lage et kjørbart system INF1050/ / Dag Sjøberg Slide 35 Praksiser i XP Praksis Inkrementell planlegging Små releaser Enkelt design Test-først utvikling Refaktorering Parprogrammering Kollektivt eierskap Kontinuerlig integrasjon Holdbart tempo Kunde på stedet Beskrivelse Kravene skrives som brukerhistorier som typisk tilsvarer en utviklingsoppgave. Hvilke som skal inkluderes i en release blir bestemt ut fra prioritet og tilgjengelig tid. Lag først det minste settet av funksjonalitet som gir verdi for kunden. Lever hyppig nye inkrementer med funksjonalitet. Bare design så mye som strengt tatt nødvendig. Bruk et automatisk testrammeverk til å skrive tester for ny funksjonalitet FØR funksjonaliteten selv implementeres. Forbedre koden kontinuerlig når muligheter for forbedring oppdages. Programmer i par. Alle par skal jobbe på og ta ansvar for alle deler av koden ikke ha lokale eksperter på deler av koden. Umiddelbart etter at en oppgave er ferdig, må den tilhørende koden integreres i hele systemet. Alle enhetstester må kjøres. Ikke jobb mye overtid fordi konsekvensen er dårligere kode og lavere produktivitet i lengden. Representant for sluttbruker eller kunde bør være tilgjengelig for utviklingsteamet hele tiden. INF1050/ / Dag Sjøberg Slide 36 18

19 Brukerhistorie (user story) Én eller flere setninger som beskriver hva brukeren av et system ønsker å få ut av systemet på formen: Som en <rolle> ønsker jeg <funksjon> for å oppnå <verdi> Kort beskrivelse, passer på et kort eller gul lapp INF1050/ / Dag Sjøberg Slide 37 Refaktorering (omstrukturering) Se etter forbedringsmuligheter og implementer dem selv om ikke umiddelbart behov for dem Koden mer forståelig og enklere å endre, og mindre behov for dokumentasjon (mer vedlikeholdbar) Noen endringer krever at arkitekturen omstruktureres (kostbart) Eksempler på refaktorering Reorganisering av klassehierarki for å fjerne duplisert kode Forbedre navn på attributter og metoder Erstatte kode med kall til metoder i et programbibliotek INF1050/ / Dag Sjøberg Slide 38 19

20 Parprogrammering To programmerere utvikler kode sammen: Fører skriver på tastaturet Navigatør observerer arbeidet til føreren og ser etter feil og svakheter ser etter alternativer noterer ting som må gjøres slår opp referanser Kan brukes uavhengig av smidige metoder INF1050/ / Dag Sjøberg Slide 39 Hva er kost-nytten ved parprogramming? Sommerville skriver i boka s. 70: However, studies with more experienced programmers (Arisholm et al., 2007*; Parish et al., 2004) did not replicate these results. They found that there was a significant loss of productivity compared with two programmers working alone. Dette eksperimentet vil bli gjennomgått på metode-forelesningen 18. april *E. Arisholm, H.E. Gallis, T. Dybå and D.I.K. Sjøberg. Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise, IEEE Transactions on Software Engineering 33(2): 65-86, 2007 INF1050/ / Dag Sjøberg Slide 40 20

21 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 41 Prosessfokuserte metoder Fokus på prosjektledelse av iterativ utvikling fremfor mer tekniske praksiser To hovedretninger 1. Velg noen prioriterte oppgaver og jobb med dem i faste tidsintervaller (tidsbokser*) med definerte oppstarts- og avslutningsaktiviteter (Scrum) 2. Fokuserer på at oppgaver skal flyte uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige (Kanban) *Tidsboks: en fast tidsperiode som et gitt arbeid skal være ferdig innenfor INF1050/ / Dag Sjøberg Slide 42 21

22 Scrum analogi fra rugby INF1050/ / Dag Sjøberg Slide 43 Scrum tre faser Planleggingsfasen: overordnede mål for prosjektet etableres og programvarearkitekturen designes Gjennomføringsfasen: en serie med iterasjoner (kalt sprint ), der hver iterasjon leverer et inkrement av systemet Avslutningsfasen: nødvendig dokumentasjon som hjelpfunksjoner og brukermanualer fullføres, og man oppsummerer hva man har lært i prosjektet INF1050/ / Dag Sjøberg Slide 44 22

23 Scrum I sprint-planleggingsmøtet evalueres oppgavelisten (backlog) som er en samling av brukerhistorier. Mål for sprinten settes inkl. prioriteter og risiko. Kunden kan sette nye krav el. gi nye oppgaver Gjennomføring Utviklingsteam og kunde velger egenskaper og funksjonalitet som skal utvikles i sprinten Planlegging Outline planning and architectural design Input: Product backlog liste av arbeidsoppgaver (Work Items) som skal utføres i prosjektet Resultatene evalueres mot målene som ble satt i sprint-planleggingsmøtet, og presenteres for kundene ( retrospective ) Assess Review Select Develop Sprint cycle 2-4 uker (tilsv. iterasjon i XP) Avslutning Project closure Lag dokumentasjon (hjelpefunksjoner, brukermanualer) og oppsummer hva man lærte Design, koding, testing. Utviklingsteamet isoleres fra kunden og organisasjonen, dvs. all kommunikasjonen skjer via Product Owner/ Scrum Master for å unngå forstyrrelser INF1050/ / Dag Sjøberg Slide 45 Visualisering Noter en oppgave eller arbeidspakke på en gul lapp og sett den på en tavle User stories US5 US4 US3 US1 US2 INF1050/ / Dag Sjøberg Slide 46 23

24 (Antatte) fordeler ved Scrum Systemet blir delt opp i en mengde forståelige og håndterbare deler Ustabile krav hindrer ikke progresjon i prosjekt-gjennomføringen Hele teamet observerer hva som skjer i prosjektet, og kommunikasjon innen teamet blir god Kundene får inkrementer levert til avtalt tid og får fortløpende tilbakemelding på hvordan deler av systemet fungerer Tillit mellom kunder og utviklere etableres tidlig og en positiv kultur skapes Kryss-funksjonelle team (kompetansene på ulike områder finnes innen teamet) sikrer framdrift og reduserer risiko Mer om teamarbeid i Scrum på forelesningen 14. mars INF1050/ / Dag Sjøberg Slide 47 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 48 24

25 Prosessprinsipp: Timeboxing versus task-boxing / task-flyt Scrum Ikke alltid greit å dele inn oppgaver eller features av systemet tilpasset sprintene, f.eks. vedlikehold, videreutvikling og support Kanban Definerer et sett med oppgaver eller features og lever så snart man er ferdig. Oppgaver skal flyte uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige ( oppgaveboksing ) INF1050/ / Dag Sjøberg Slide 49 Flytbasert utvikling INF1050/ / Dag Sjøberg Slide 50 25

26 Fokus på flyt Flyt av materialer, folk og penger: arbeidskraft var billig, hadde nok folk, OK om folk i periode ikke hadde noe å gjøre Tilpasset høyden til hva de kunne produsere ikke omvendt Tett samarbeid mellom arkitekter, bygningsarbeidere og underleverandører Erfarne arbeidere Fast pris kontrakt Fokus på materialflyt (500 lastebiler om dagen) ingen mellomlagring Dekobling (modularisering): ulike systemer skulle være uavhengige Tid var penger: Hver dag forsinket kostet $ ($ i dag) INF1050/ / Dag Sjøberg Slide 51 Kanban Fokus på gjennomstrømningshastighet på arbeidspakkene = antall brukerhistorier (features) implementert per tidsenhet Begrense antall arbeidspakker som det jobbes med i parallell (WIP = Work In Progress) for å hindre flaskehalser Antakelse: Jo høyere WIP, jo saktere flyter arbeidspakken gjennom arbeidsprosessene Når en pakke er ferdig, kan man etterspørre en ny som man begynner å jobbe med (pull) Slakk i tidsplanen er OK, dvs. en utvikler vil kunne vente hvis det optimaliserer overordnet flyt Mindre fokus på estimering INF1050/ / Dag Sjøberg Slide 52 26

27 24/01/17 Forskjell på Scrum-tavle og Kanban-tavle Max WIP From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009 INF1050/ / Dag Sjøberg Slide 53 Fordeler ved Kanban Flaskehalser i prosessen blir synlige Fokus på å bli ferdig med oppgaver som hindrer gjennomstrømning fremfor å begynne på flere oppgaver som vil hope seg opp Kan drive smidig utvikling uten å bruke tidsbokser Spesielt for drifts- og supportoppgaver og vedlikeholdsoppgaver vil veldefinerte sprinter ofte ikke gi mye mening Gunstig der det er svært vanskelig å estimere oppgavene INF1050/ / Dag Sjøberg Slide 54 27

28 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 55 Kanban en teknikk fra Lean (slank) produksjon INF1050/ / Dag Sjøberg Slide 56 28

29 24/01/17 Lean den japanske skolen, primært Toyota Kontinuerlig læring og forbedring (Kaizen) Forbedre helheten, dvs. ikke sub-optimalisere Ved feil, stopp samlebåndet og finn årsaken til feilen fremfor å samle og rette opp alle feil i bolker Kundefokus Respekt for mennesker Fokus på flyt ( flow ) Just-in-time -prinsippet: Ikke lag noe før noen etterspør det, dvs. et sug (pull) etter nye ting, ikke pådytting ( push ) Unngå sløsing ( waste ) INF1050/ / Dag Sjøberg Slide 57 Waste Alt som krever ressurser og som ikke gir verdi for kunden tid arbeidsinnsats rom lager (unngå mellomlagring) utstyr penger Verdi = det kunden ønsker og er villig til å betale for INF1050/ / Dag Sjøberg Slide 58 29

30 Resultat Toyota færrest feil og raskest produksjon Skyldes også hard jobbing De mest produktive bedriftene brukte færrest ressurser på ledelse og administrasjon ( lean management ) INF1050/ / Dag Sjøberg Slide 59 Den norske/nordiske modellen Selvstyrte (autonome) team Læring, redundans/jobbrotasjon Medvirkning og arbeidsmiljø Livskvalitet Samarbeid ledelse, arbeidstakerorganisasjoner og myndigheter Hydro, Volvo og mange flere B. Gustavsen, T.U. Quale, B.A. Sørensen, M. Midtbø og P.H. Engelstad. Innovasjonssamarbeid mellom bedrifter og forskning den norske modellen. Gyldendal 2010 INF1050/ / Dag Sjøberg Slide 60 30

31 Bilproduksjon vs. programvareutvikling Bilindustri er produksjon av fysiske produkter, mens programvareutvikling fokuserer på kode (tekst) Likevel, lean-prinsippene kan anvendes i programvareutvikling Lean management er et hett tema i mange sektorer som ikke driver produktutvikling Offentlig forvaltning (f.eks. helsevesen, universiteter) Privat sektor INF1050/ / Dag Sjøberg Slide 61 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Rational Unified Process (RUP) Gjenbruksbasert utvikling Kap. 3 Begreper og prinsipper innen smidig utvikling Programmeringsfokuserte smidige metoder Ekstrem programmering (XP) Prosessfokuserte smidige metoder Tidsboksbasert (Scrum) Flytbasert (Kanban) Lean systemutvikling Oppsummering smidige metoder Quiz - Kahoot INF1050/ / Dag Sjøberg Slide 62 31

32 Utfordringer ved smidige metoder Vanskelig å opprettholde kundens interesse i prosjektet hele tiden Krever ekstra tid å stadig gjøre endringer og opprettholde enkelhet Kontrakter kan være et vanskelig tema (se forelesning 4. april) INF1050/ / Dag Sjøberg Slide 63 Utfordringer ved utvikling av store systemer Hvordan skalerer smidige metoder i store, langvarige prosjekter med mange utviklingsteam som kanskje jobber distribuert, kanskje innen ulike kulturer og tidssoner med hvert sitt del-system som skal kommunisere med hverandre? Krav til kommunikasjon mellom del-systemer vanskeliggjør fleksibilitet og inkrementell utvikling. Lite fokus på integrering av del-systemer. Store systemer tar lang tid å utvikle. Vanskelig å ha fokuserte team hele tiden som kjenner prosessen og produktet godt. Folk begynner i andre prosjekter og jobber. Store systemer har mange interessenter vanskelig å involvere alle utviklingsprosessen vanskelig å prioritere mellom ulike krav Design og system-dokumentasjon viktig i store systemer, ikke bare kode. INF1050/ / Dag Sjøberg Slide 64 32

33 Merk: Sommerville diskuterer ikke flytbasert utvikling (Kanban) Temaet er likevel viktig INF1050/ / Dag Sjøberg Slide 65 Oppsummering Det å jobbe smart, dvs. ha gode og effektive arbeidsprosesser vil alltid være et aktuelt tema Smidige metoder er kommet for å bli; finnes mange måter å være smidig på Mer om smidig i forelesningen om prosjektledelse 14. mars og studier av smidig utvikling 18. april INF1050/ / Dag Sjøberg Slide 66 33

34 Quiz Kahoot INF1050/ / Dag Sjøberg Slide 67 34