Prosessmodeller og smidig programvareutvikling

1/21/14 INF1050: Systemutvikling 22. januar 2014 Prosessmodeller og smidig programvareutvikling Professor Dag Sjøberg Slide 1 INF1050/ 22.1.2014 / Dag Sjøberg Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 2 1

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 Deskriptiv beskriver en prosess slik vi mener vi utfører den Normativ (preskriptiv) beskriver en prosess slik noen mener den bør være (vanligste betydning) INF1050/ 22.1.2014 / Dag Sjøberg Slide 3 Modell versus virkelighet INF1050/ 22.1.2014 / Dag Sjøberg Slide 4 2

1/21/14 Formell versus reell prosess Det vi sier vi gjør eller det vi bør gjøre Det vi gjør Prosessbeskrivelse Prosessutførelse Slide 5 INF1050/ 22.1.2014 / Dag Sjøberg Nivåer av prosessmodeller Generelle prosessmodeller (fossefall, spiral, RUP, Scrum etc.) Definerte prosessmodeller (formell prosess) Firma-spesifikke prosessmodeller Prosjekt/gruppe-spesifikke prosessmodeller Prosess-samsvar Reell prosess INF1050/ 22.1.2014 / Dag Sjøberg Systemutviklingsprosess Slide 6 3

Hvordan tilpasse prosesser? Prosesser må tilpasses ingen prosjekter er like Mange faktorer påvirker prosessen Hva kan tilpasses? Antall faser/aktiviteter, roller, ansvarsforhold, dokumentformater, formalitet/frekvens på rapporter og gjennomganger Hvordan tilpasse? 1. Identifiser prosjektomgivelser utviklingsstrategi, risiko, krav, applikasjonsområde, type kunde etc. 2. Innhent synspunkter fra utviklere, brukere, kunder 3. Definer prosesser, aktiviteter og roller 4. Dokumenter og begrunn tilpasningene INF1050/ 22.1.2014 / Dag Sjøberg Slide 7 Myndighetene anbefaler felles prosjektmodell For å sikre kvalitet anbefaler myndighetene at offentlige virksomheter skal bruke en felles prosjektmodell. Er det lurt? Ulempe Sjelden at samme modell passer for alle type virksomheter Fordel Læring på tvers av etater Se artikkel i Aftenposten: http://www.aftenposten.no/digital/nyheter/haper-klare-rad-skal-fafart-pa-digitaliseringen-7073514.html INF1050/ 22.1.2014 / Dag Sjøberg Slide 8 4

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 9 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/ 22.1.2014 / Fra Dag Ian Sjøberg Sommerville Slide 10 5

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 det er lite sannsynlig med mye endringer underveis Men få systemer har stabile krav Brukes mest i store prosjekter som gjerne utvikles på ulike steder. Plandreven utvikling gjør det enklere å koordinere arbeidet Men brukes også i små, godt forståtte prosjekter (jfr. de 4 bedriftene som lagde samme system) INF1050/ 22.1.2014 / Dag Sjøberg Slide 11 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 12 6

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/ 22.1.2014 / Dag Sjøberg Slide 13 Inkrementell utvikling Systemet utvikles gradvis i form av nye inkrementer som blir lagt til. Hvert inkrement evalueres før utviklingen av neste inkrement starter Vanlig tilnærming i smidige metoder Evalueringen gjøres av en bruker- eller kunderepresentant ( product owner ) INF1050/ 22.1.2014 / Dag Sjøberg Slide 14 7

Inkrementell installering Istedenfor at hele systemet leveres til kunden på en gang, leveres ett inkrement av gangen som tilsvarer en del av all funksjonalitet De viktigste kravene implementeres i de første inkrementene Når utviklingen av et inkrement er startet, så fryses kravene til det inkrementet, men kravene til senere inkrementer kan fortsatt endres INF1050/ 22.1.2014 / Dag Sjøberg Slide 15 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/ 22.1.2014 / Dag Sjøberg Slide 16 8

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/ 22.1.2014 / Dag Sjøberg Slide 17 Utviklingsstrategi Definer alle Krav først? Flere utviklingssykluser? Fossefall Ja Nei krav design kode test lever Inkrementell Ja Ja krav design design kode kode test test lever lever design kode Iterativ (evousjonær) Nei Ja krav krav design krav lever kode test lever test INF1050/ 22.1.2014 / Dag Sjøberg Slide 18 9

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / 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 og vedlikeholdbarhet reduserte utviklingskostnader INF1050/ 22.1.2014 / Dag Sjøberg Slide 20 10

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/ 22.1.2014 / 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/ 22.1.2014 / Dag Sjøberg Slide 22 11

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 23 Spiralmodellen Utviklingsprosessen er representert som en spiral istedenfor en sekvens med aktiviteter Hver runde i spiralen representerer en fase i prosessen, f. eks. kravspesifisering eller design Løkkene i spiralen velges etter behov. F.eks. kan man gå tilbake til tidligere aktiviteter Risikoanalyse: hva som kan gå galt, og med hvilken sannsynlighet og konsekvens, er vurdert og håndtert eksplisitt gjennom prosessen INF1050/ 22.1.2014 / Dag Sjøberg Slide 24 12

Boehm s spiral model of the software process Identifiser spesifikke mål for fasen Determine objectives, alternatives and constraints Plan next phase Evaluer prosjektet og planlegg neste fase REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototype 1 Concept of Operation S/W requirements Requirement validation Design V&V Service Analyser risiko og utfør aktiviteter for å redusere de viktigste Acceptance test Prototype 3 Operational protoype Simulations, models, benchmarks Product design Integration test Evaluate alternatives, identify, resolve risks Unit test Code Detailed design Develop, verify next-level product Design, koding (programmering) etc. INF1050/ 22.1.2014 / Fra Dag Ian Sjøberg Sommerville Slide 25 Bruk av spiralmodellen Blant de mest kjente, klassiske modeller hatt stor betydning i utviklingen av tankegangen rundt iterasjoner og risikovurderinger i systemutviklingsprosessen Men brukes sjelden i konkret systemutvikling INF1050/ 22.1.2014 / Dag Sjøberg Slide 26 13

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 27 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/ 22.1.2014 / Dag Sjøberg Slide 28 14

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/ 22.1.2014 / Dag Sjøberg Slide 29 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/ 22.1.2014 / Dag Sjøberg Slide 30 15

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 31 Gjenbruksbasert utvikling Eksisterende programvare gjenbrukes i større eller mindre grad 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 Selvstendige programvare-systemer som er utviklet for bruk i et spesielt miljø 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 12. mars INF1050/ 22.1.2014 / Dag Sjøberg Slide 32 16

Hvilken prosess er best? Sommerville skriver: There are no right or wrong software processes Ikke eksakt fagfelt; man mangler fortsatt sikker kunnskap om hvordan ulike prosesser fungerer i ulike situasjoner MEN: opplagt at noen prosesser er bedre enn andre avhengig av hva slags system som skal utvikles og i hvilken kontekst det skal foregå INF1050/ 22.1.2014 / Dag Sjøberg Slide 33 Quiz For å redusere belastningen på nettet Alle med mobiltelefon: Skru av nett-tilgang og bruk mobilnettet isteden De som har laptop og nettbrett, stopp alt nettbruk annet enn Kahoot Gå til kahoot.it på mobil, nettbrett, PC etc. Pass på at mobilen ikke lukker seg Tast inn Game pin Lag Nick name ). Brukernavnet sensitivt for små og store bokstaver. Navnet blir synlig Det samme brukernavnet må benyttes resten av semesteret De som blir kastet ut og må logge seg inn igjen, får nullet ut sin poengsum i øyeblikket, men etterpå blir resultatet likevel summert på samme navn INF1050/ 22.1.2014 / Dag Sjøberg Slide 34 17

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 35 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/ 22.1.2014 / Dag Sjøberg Slide 36 18

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/ 22.1.2014 / Dag Sjøberg Slide 37 En samling software-guruer i 2001: Agile Manifesto 12 prinsipper* *http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html INF1050/ 22.1.2014 / Dag Sjøberg Slide 38 19

Agile Manifesto 2001 (forts.) *http://agilemanifesto.org og http://agilemanifesto.org/iso/no/principles.html INF1050/ 22.1.2014 / Dag Sjøberg Slide 39 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 40 20

Ekstrem programmering (XP) Ekstrem ved at: Hele systemet kan bygges (rekompileres) 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/ 22.1.2014 / Dag Sjøberg Slide 41 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/ 22.1.2014 / Dag Sjøberg Slide 42 21

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/ 22.1.2014 / Dag Sjøberg Slide 43 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 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/ 22.1.2014 / Dag Sjøberg Slide 44 22

Parprogrammering - kan brukes uavhengig av smidig 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 45 INF1050/ 22.1.2014 / Dag Sjøberg Slide 45 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 9. 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/ 22.1.2014 / Dag Sjøberg Slide 46 23

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 47 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/ 22.1.2014 / Dag Sjøberg Slide 48 24

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/ 22.1.2014 / Dag Sjøberg Slide 49 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 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 kunden ( retrospective ) Gjennomføring Assess Select Review Develop Sprint cycle Tidsboks: 2-4 uker Utviklingsteam og kunde velger egenskaper og funksjonalitet som skal utvikles i sprinten 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 eller Scrum Master for å unngå forstyrrelser INF1050/ 22.1.2014 / Dag Sjøberg Slide 50 25

Visualisering Noter en oppgave eller arbeidspakke på en gul lapp og sett den på en tavle User stories US5 US4 US3 US1 US2 INF1050/ 22.1.2014 / Dag Sjøberg Slide 51 (Antatte) fordeler ved Scrum Systemet blir delt opp i en mengde forståelige og håndterbare deler Ustabile krav hindrer ikke progresjon i prosjektgjennomfø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 26. mars INF1050/ 22.1.2014 / Dag Sjøberg Slide 52 26

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 53 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/ 22.1.2014 / Dag Sjøberg Slide 54 27

Flytbasert utvikling INF1050/ 22.1.2014 / Dag Sjøberg Slide 55 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 $10 000 ($120 000 i dag) INF1050/ 22.1.2014 / Dag Sjøberg Slide 56 28

1/21/14 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/ 22.1.2014 / Dag Sjøberg Slide 57 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/ 22.1.2014 / Dag Sjøberg Slide 58 29

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/ 22.1.2014 / Dag Sjøberg Slide 59 Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 60 30

Kanban en teknikk fra Lean (slank) production INF1050/ 22.1.2014 / Dag Sjøberg Slide 61 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 Just-in-time -prinsippet: Ikke lag noe før noen etterspør det Komponentbasert produksjon (samme understell etc. på ulike biltyper) Kundefokus Unngå waste Fjerning av mellomlagring INF1050/ 22.1.2014 / Dag Sjøberg Slide 62 31

Waste Alt som krever ressurser tid arbeidsinnsats rom lager (unngå mellomlagring) utstyr penger som ikke gir verdi for kunden Verdi = det kunden ønsker og er villig til å betale for INF1050/ 22.1.2014 / Dag Sjøberg Slide 63 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/ 22.1.2014 / Dag Sjøberg Slide 64 32

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/ 22.1.2014 / Dag Sjøberg Slide 65 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/ 22.1.2014 / Dag Sjøberg Slide 66 33

Plan Kap. 2: Begrepet prosessmodell Prosessmodeller og prinsipper for utvikling Fossefallsmodellen Inkrementell og iterativ utvikling Prototyping Spiralmodellen 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 INF1050/ 22.1.2014 / Dag Sjøberg Slide 67 Utfordringer ved smidige metoder Vanskelig å opprettholde kundens interesse i prosjektet hele tiden Utviklerne vil kunne mangle det intense engasjement som kreves Vanskelig å prioritere endringer hvis mange interessenter (stakeholders) Krever ekstra tid å stadig gjøre endringer og opprettholde enkelhet Kontrakter kan være et vanskelig tema (se forelesning 23. april) INF1050/ 22.1.2014 / Dag Sjøberg Slide 68 34

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 som kan være vanskelig å involvere i utviklingsprosessen. Design og system-dokumentasjon viktig i store systemer, ikke bare kode. INF1050/ 22.1.2014 / Dag Sjøberg Slide 69 Merk: Sommerville diskuterer ikke flytbasert utvikling (Kanban) Temaet er likevel viktig INF1050/ 22.1.2014 / Dag Sjøberg Slide 70 35

Oppsummering Smidige metoder er kommet for å bli Finnes mange måter å være smidig på Mer om smidig i forelesningen om prosjektledelse 26. mars og studier av smidig utvikling 9. april. NF5181 Prosessforbedring og smidige metoder i systemutvikling INF1050/ 22.1.2014 / Dag Sjøberg Slide 71 Quiz INF1050/ 22.1.2014 / Dag Sjøberg Slide 72 36