Evaluering af tilpassede Scrum metoder

Størrelse: px
Starte visningen fra side:

Download "Evaluering af tilpassede Scrum metoder"

Transkript

1 Evaluering af tilpassede Scrum metoder Rapport Gruppe: 10 Jan Thorup Bjerg ( ) Dato: Abstract Scrum er en banebrydende metode og er på kort tid blevet den mest benyttede indenfor agil softwareudvikling. Men metoden bruges ikke altid helt i overensstemmelse med retningslinjerne, hvilket må ses som et udtryk for, at metodens elementer er stærke projektledelsesprincipper, som med fordel kan bruges i andre sammenhænge. Jeg har i dette studie analyseret og fortolket brug af Scrum i fire virksomheder, som arbejder med softwareudvikling, for at søge en forklaring på hvorfor Scrummetoden ofte bruges på forskellig vis. Undersøgelsen indikerede, at der var brug for et digitaliseret Scrumværktøj til understøttelse af atypisk Scrumbrug. Derfor har jeg på baggrund af analysen, eksisterende forskning i brugen af Scrum samt softwarearkitektoniske principper lavet en mockup prototype af et digitaliseret Scrumværktøj, som kan understøtte denne brug af Scrum. Page 1 of 69

2 Indhold 1 Motivation Indledning Kort om Scrum Agil udvikling og Scrum Kort om Scrum Scrummetoden og dens bestanddele Kanban Problemformulering Afgrænsninger Relateret arbejde Andre projekter Scrummer Det interaktive Scrum Board The Cooperative Task Board Diskussion af projekterne Eksisterende værktøjer SpiraPlan JIRA-Greenhopper Axosoft VersionOne Scrum-it Sammenfatning Metode Interviews Geeknight event Softwarearkitektur Arkitektur for et Scrumsystem Tactics Analyse og diskussion Interviews og event Interview med Birte, Logica Interview med Thomas, Vertica Interview med Henrik, Unifeeder Page 2 of 69

3 5.1.4 Interview med Svend, Alexandra Instituttet Geeknight om Distributed Scrum and Agile Udfordringer ved brug af Scrum Resultat af interviews Tilpasning af Scrum Hvad gør Scrum så populær? Brug af Scrum værktøjer Generisk Scrum prototype Systemkrav Funktionalitet Pervasive interaktion User Stories Interfaces Objekter Præsentation af prototypen Feedback på prototypen Konklusion Referencer Appendiks Interviewguide Interviewskema Mockup Prototype Page 3 of 69

4 1 Motivation 1.1 Indledning Formålet med dette studie er at bidrage med viden om brug af Scrum i forskellige virksomheder og hvilke Scrumværktøjer, de har valgt at benytte, samt at præsentere en værktøjsprototype til understøttelse af atypisk brug af Scrum. Studiet tager udgangspunkt i en undersøgelse af erfaringer fra fire virksomheder i Århusområdet, som bruger Scrum på hver sin måde. Erfaringerne er indsamlet vha. interviews med repræsentanter for disse virksomheder, samt forfatterens egne observationer om brug af Scrum hos Unifeeder. På baggrund af disse undersøgelser vil jeg søge at kombinere It-projektledelse, softwarearkitektur og pervasive computing i en værktøjsprototype, som kan understøtte atypisk brug af Scrum. Der er to hovedgrene indenfor forskning om udbredelsen af Scrum: studier i effekten af omlægning til Scrum og etnografiske studier af metodens introduktion i forskellige virksomheder ol. Der findes kun enkelte studier, som beskriver erfaringerne med Scrum og hvorledes denne proces understøttes (Kniberg, 2006). Heriblandt mangler der undersøgelser, som kortlægger virksomheders erfaringer mht. brug af Scrum i årene efter, at metoden er implementeret i virksomheden. Den øvrige del af studiet er organiseret som følger: Kapitel 2: En detaljeret problemformulering som beskriver de spørgsmål, som dette studie vil besvare. Kapitel 3: En gennemgang af relateret forskning og analyse af enkelte eksisterende værktøjer på markedet. Kapitel 4: Præsentation af den valgte metode. Kapitel 5: Gennemgang og diskussion af interviewdata på baggrund af eksisterende forskning om brug af Scrum samt Kanban. Derudover præsenteres et udkast til et digitaliseret Scrumværktøj. Kapitel 6: Præsentation af en generisk mockup prototype af et Scrumsystem. Kapitel 7: Konklusion Kort om Scrum Scrum er på kort tid blevet den mest udbredte udviklingsmetode inden for agil softwareudvikling (Sutherland & Schwaber, 2007; Hossain et al., 2009; Overhage et al., 2010). Men metoden er ofte tilpasset den kontekst eller empiri, hvori den indgår, som atypisk brug af Scrum. Mange softwarevirksomheder, som benytter Scrum metoden har ofte ændret noget i forhold til Sutherland & Schwaber s oprindelige metode. Denne opfattelse bekræftes bl.a. af videnskabelige artikler og eksisterende forskning inden for dette område (Overhage et al., 2010; Rising & Janoff, 2000). Page 4 of 69

5 I 2008 publicerede Salo og Abrahamsson en undersøgelse om brug af Scrum og XP i den europæiske softwareindustri. Af denne undersøgelse fremgår det bl.a. at Product Backloggen det mest benyttede Scrum element, men også at det er meget varierende i hvilket omfang, de andre Scrum elementer benyttes (Salo & Abrahamsson, 2008). Fig. 1. Brug af Scrumelementer i projekter (Salo & Abrahamsson, 2008). Selvom atypisk brug af Scrum ikke var undersøgelsens fokus, må ovenstående også ses som et udtryk for, at en del virksomheder ikke benytter Scrum i sit fulde omfang. Atypisk brug af Scrum, hvor metoden ikke bliver fulgt præcist, fordi en af metodens regler, ceremonier og artefakter ikke bliver benyttet, bliver også kaldt for Scrum-but (Scrum). En Scrum-but defineres med syntaksen (ScrumBut)(Reason)(Workaround) og de er hver især forskellige grunde til, at et team eller en organisation ikke umiddelbart kan drage fuldt udbytte af Scrum. Hver rolle, regel og timebox i Scrum er designet til at opnå de ønskede fordele eller løse kendte tilbagevendende problemer. Scrumbuts afslører en dysfunktion eller defekt, der bidrager til et problem, men som ikke umiddelbart kan afhjælpes. Ved at introducere Scrum-buts og derved ændre på Scrummetoden, usynliggøres dysfunktionen, så den ikke længere er til gene for teamet. Eksempel "(vi bruger Scrum, men...) (afholdelse af Daily Scrummøde hver dag er unødvendigt,) (så vi afholder kun et pr. uge)" (Scrum) Men hvor meget kan metoden egentlig ændres og stadig kaldes for Scrum? Ifølge The Scrum Guide er der kun mulighed for meget små ændringer, før der ikke længere er tale om Scrum: Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices (Sutherland & Schwaber, 2011, s.15). Men som jeg senere vil komme ind på i kapitel 5, er der ikke helt enighed om denne fortolkning og der er flere forskellige fortolkninger af, hvad Scrum er og hvad metoden, frameworket eller værktøjskassen kan bruges til. Ovenstående kan være et udtryk for, at alle, som bruger Scrum, ikke er helt afklaret omkring metoden og dens begrænsninger. Men det kan også være et udtryk for, at Page 5 of 69

6 nogle af de elementer, som indgår i metoden, er stærke projektledelsesprincipper, som med fordel kan bruges i mange andre sammenhænge, hvor der ikke nødvendigvis er tale om softwareudvikling (Nyboe et al., 2009). I forbindelse med brug af Scrumværktøjer er det iøjnefaldende, at de softwareproducenter, som lever af at udvikle digitaliserede systemer, ofte selv benytter lavpraktiske værktøjer. Det kan f.eks. være en tavle med små selvklæbende sedler, tegnede Burndown Charts og Excel ark (Kniberg, 2006; (Ericsson et al., 2011). Der findes en del software på markedet, som understøtter Scrumprocessen, men i flere tilfælde benyttes de kun, når en lavpraktisk løsning ikke længere er brugbare f.eks. ved distribuerede eller globaliserede Scrumteams (Hossain et al., 2009). Nogle af disse systemer bliver gennemgået senere i afsnit 3.2 Forskning viser, at administrative Scrumværktøjer skal være intuitive og indgå som naturlige del af Scrumprocessen for at blive accepteret og anvendt (Alexandra; Rubart & Freykamp, 2009). Men Scrum er underudforsket i forhold til metodens udbredelse. Det er hovedsagelig effekten ved at introducere Scrum i form af forøget produktivitet, kvalitet og kundetilfredshed, som er blevet undersøgt (Overhage et al., 2010). I andre tilfælde er der tale om etnografisk forskning med fokus på Scrumimplementeringsprocessen i en organisation (Marchenko & Abrahamsson). 1.2 Agil udvikling og Scrum I 90'erne var det almindeligt, at softwareudvikling blev baseret på en langsigtet udviklingsindsats med stabile og disciplinerede processer. I modsætning hertil var der en tendens til, at mange softwareprojekter blev berørte af hurtige ændringer i krav og uforudsigelig kompleksitet. Dermed opstod et behov for at opnå en balance mellem fleksibilitet og disciplin i udviklingen, hvilket blev grundlaget for den agile softwareudvikling (Pries-Heje, 2011). Agil udvikling er et paradigme inden for softwareudvikling, hvor man i modsætning til den klassiske softwareudvikling fokuserer på nogle agile principper: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan (agilemanifesto) Baggrunden for det agile paradigme skal bl.a. findes i nedenstående fejl og faldgruber, som er blevet identificeret i forbindelse med den klassiske vandfaldsmetode tilgang (Sutherland & Schwaber, 2007): Requirements are not fully understood before the project begins Users know what they want only after they see an initial version of the software Page 6 of 69

7 Requirements change often during the software construction process New tools and technologies make implementation strategies unpredictable Der findes en række forskellige anerkendte metoder til understøttelse af agil softwareudvikling: Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Crystal, Feature Driven Development (FDD), Agile Modeling, Kanban og Scrum, hvoraf Scrum er den mest udbredte. Visionen i de agile metoder er en mere lærende eller eksperimentel tilgang, hvor man typisk opdeler udviklingen i mindre iterationer, som i højere grad tillader ændringer, samt sikrer hurtigere fremdrift mht. eksekverbar kode (Rising & Janoff, 2000). Iterationerne indeholder de almindelige udviklingsaktiviteter: analyse, design, kodning og test (Pries-Heje, 2011). Hovedtemaerne i de agile udviklingsmetoder er hurtigere brugbar kode og tæt samarbejde: Agile methods stress two concepts: the honesty of working code and the effectiveness of people working together with goodwill (Highsmith & Cockburn, 2001, s.121). Hvor metoderne, udover at understøtte de agile principper, skal sikre struktur i forbindelse med udviklingen, for at undgå ad hoc eller cowboy coding (Highsmith & Cockburn, 2001). 1.3 Kort om Scrum Scrum er udsprunget af inspiration fra japansk best business practices baseret på Lean principper og team-building, som i 80 erne blev udviklet i japanske industrigiganter som f.eks. Honda og Toyota - og senere beskrevet af Takeuchi & Nonaka (Sutherland & Schwaber, 2007). Scrum blev udviklet i 90 erne af Jeff Sutherland og Ken Schwaber blandt andre. Metoden blev introduceret i forbindelse med et softwareprojekt hos Easel Corporation i 1993 (Sutherland & Schwaber, 2007) og første gang præsenteret for offentligheden ved OOPSLA konferencen i 1995 (Sutherland & Schwaber, 2011). Scrum er banebrydende og er på kort tid blevet den mest benyttede metode indenfor agil udvikling af komplekse softwareprodukter (agilemanifesto). Men i litteraturen varierer opfattelsen af, hvad Scrum er og hvordan det kan bruges f.eks. i hvilket omfang tilpasning er muligt. Dette ser vi nærmere på i afsnit Scrummetoden og dens bestanddele Begrebet Scrum stammer fra Rugby, hvor holdene samles i en klynge for at kæmpe om bolden og føre den videre frem på banen (Sutherland & Schwaber, 2007). I denne forbindelse bruges udtrykket som en metafor for, hvorledes et udviklingsteam (det ene hold) samarbejder om at få produktet (bolden) i mål. Page 7 of 69

8 Kort fortalt er Scrum en iterativ proces, hvor en iteration (kaldet et Sprint) normalt varer fra to til fire uger. Den ønskede funktionalitet er beskrevet i forretnings- eller almindeligt sprog i form af User Stories, som prioriteres i en Product Backlog af en Product Owner, der repræsenterer kundens synspunkter (Fig. 2). Den højest prioriterede funktionalitet bliver udvalgt som målet for udviklingen i et Sprint. Et Sprint starter med et Sprint Planning møde, hvor den udvalgte funktionalitet brydes op i mindre opgaver, som estimeres mht. udviklingstid. Under et Sprint mødes projektgruppen dagligt til et Daily-Scrum stand-up møde, som ofte finder sted foran et Scrum Board beklædt med sedler, der hver især repræsenterer en opgave. Mødet må ikke tage mere end 15 minutter og ledes af en Scrum Master, som er ansvarlig for processen og at teamet fungerer optimalt. Under mødet skal hvert teammedlem besvare tre spørgsmål: 1) Hvad han/hun har gennemført siden sidste møde 2) Hvad han/hun vil gennemføre inden næste møde 3) Hvilke hindringer der evt. er i vejen for, at han/hun kan gennemføre sit arbejde Hver gang en opgave er færdig, flyttes den på Scrum Boardet til en Done! kategori og registreres på et Burndown Chart, hvor man kan se status mht. løste opgaver i forhold til de i sprintet aktuelle/planlagte opgaver. Ved afslutningen af hvert Sprint skal der ved et Sprint Review møde normalt demonstreres en leverance i form af en eksekverbar version af værdi for kunden, som repræsenteres af en Product Owner. Afslutningsvis afholdes et Retrospektivt møde, hvor teamet ser tilbage og forsøger at lære af det netop afsluttede Sprint - f.eks. hvad der fungerede godt, hvad der ikke gjorde og hvilke forandringer, man med fordel kan introducere i det næste Sprint (Sutherland & Schwaber, 2007). Udover ovenstående indgår der i metoden en række regler, som understøtter processen, men som ikke vil blive gennemgået, da de ikke er relevante for nærværende studie. Fig. 2. Scrum processens bestanddele (agileforall.com). Page 8 of 69

9 I et Scrum team er der tre roller: 1. Product Owner - er ansvarlig for indhold og prioritering af Product Backlogen, og derved værdien af Scrum-teamets arbejde 2. Scrum Master - er ansvarlig for udvikling af teamet samt at processen er forstået og følges 3. Teamet - en gruppe på 5-9 udviklere som udfører arbejdet og former produktet De elementer, der bliver planlagt, som timeboxes omfatter: Sprintforløbet - en iteration af maksimum en måneds varighed som resulterer i en funktionel udvidelse af et frigivelsesklart produkt Release Planning - et møde, hvor man omformer vision til et produkt ved at planlægge og etablere nogle mål Sprint Planning - et op til 8 timer langt "hvad?" og "hvordan?" møde, hvor en iteration planlægges Sprint Review - et op til 4 timer langt møde, hvor det opnåede arbejdsresultat præsenteres, drøftes og vurderes Sprint Retrospective - et op til 3 timer langt effektiviserende møde, hvor Scrum Master tilskynder teamet til at revidere udviklingsprocessen Daily Scrum - et dagligt møde på op til et kvarter, som forbedrer kommunikationen og projektkendskabet I Scrum anvendes fire primære artefakter: 1. Product Backlog - en prioriteret liste over alt, hvad der kan være behov for i produktet (features, funktioner osv.) 2. Release Burndown Chart - angiver i tid summen af den forventede arbejdsindsats for den resterende Product Backlog for en releaseplan 3. Sprint Backlog - en liste over opgaver, der skal gennemføres i et sprint for at realisere dele af Product Backlogen 4. Sprint Burndown Chart - angiver i tid summen af de resterende opgaver i et Sprint Ovenstående er iht. Myllerups oversættelse af "The Scrum Guide" af Ken Schwaber and Jeff Sutherland (Myllerup, 2010). Scrum metoden stiller dog ingen specifikke krav til artefakternes indhold eller udseende. Et ofte benyttet redskab, som dog ikke er et element i Scrum metoden, er et Scrum Board (Fig. 3) - en oversigt, der bruges til at vise status over de opgaver, som indgår i det indeværende sprint. Normalt håndteres Sprint backloggen på Scrum Boardet ved, at den opsplittes i små sedler, som flyttes og skifter status f.eks. i forbindelse med Daily Scrum mødet. Page 9 of 69

10 Fig. 3. Illustration af et typisk Scrum board (Kniberg, 2006). 1.4 Kanban I dette studie vil Kanban, som alternativ agile softwareudviklingsmodel, blive gennemgået, fordi Kanban er speciel, idet den på flere punkter minder om Scrum. Kanban kan bruges selvstændigt eller sammen med Scrum, og kan derfor være et alternativ til Scrum (Boeg, 2011, s.15). Kanban, som på japansk betyder Visual Card, er baseret på et visuelt overblik, hvor man benytter en tavle (Fig. 4) på samme måde som i mange Scrumprojekter. Det er en industiel teknik, der går ud på at trække arbejde gennem hele dets livscyklus, så effektivt og ubesværet som muligt, ved at have fokus på flow og kontekst. Metoden er baseret på Just-In-Time og Lean produktionssytemet, hvor det er målet kun at producere det absolut nødvendige på det rigtige tidspunkt dvs. umiddelbart før brug. Page 10 of 69

11 Fig. 4. Kanban board (Ketil Jensen s blog). Metoden er ligesom Scrum også opstået i Japan og repræsenterer en mere direkte implementation af Lean principper end traditionelle agile metoder. Både Scrum og Kanban er letvægtsudviklingsmetoder, som mest benyttes i små eller mellemstore udviklingsorganisationer. I modsætning til Scrum er Kanban mindre formel og omfatter ikke krav til: udviklingsiterationer som sprints definerede roller som Scrum Master og Product Owner faste møder, såsom Daily Scrum, Sprintmøde, retrospektiv analyse eller demo af leveringer. krav mht. artefakter, som f.eks. Release Backlog. Kanban fokusere i stedet på visualisering af arbejdsgangen, begrænsning af igangværende arbejde og måling af lead time 1. Målet er at begrænse Work in progres, dvs. antallet af igangværende opgaver, så udviklingsteamet har ro til at fokusere på disse, hvilket skaber et konstant workflow og er med til at reducere lead times. Af samme årsag kan Kanban kombineres med Scrum og supplere de vigtigste principper herfra. Den mindre formelle tilgang til agil softwareudvikling har bl.a. medført, at Kanban er blevet en populær udvidelse til Scrum og XP (Boeg, 2011, s.11). 1 Gennemløbstiden for en opgave fra den anmodes/beskrives til den leveres. Page 11 of 69

12 2 Problemformulering Fokus for dette projekt er analyse og fortolkning af brugen af Scrum som udviklingsmetode. Derudover er målet også at søge en forklaring på, hvorfor Scrummetoden ofte bruges forskelligt samt at skabe et værktøj som kan understøtte atypisk Scrumbrug. Projektets problemformulering er defineret som følgende: Med udgangspunkt i interviews og eksisterende viden om brug af Scrum vil dette studie: a) Analysere og diskutere forskellig brug af Scrummetoden med hensyn til metodens ceremonier og værktøjer. b) Diskutere anvendte Scrumværktøjer/systemer med hensyn til hvordan de understøtter de analyserede Scrumløsninger. c) Anbefale softwarearkitektoniske principper, som kan implementeres i et digitaliseret værktøj til generisk understøttelse af Scrumprocessen. d) Lave en mockup prototype af et digitaliseret Scrumværktøj, som anvender de i pkt. c anbefalede principper. 2.1 Afgrænsninger Samarbejde og roller er vigtige elementer i Scrum, idet metoden fokuserer meget på teamwork, som ofte foregår i selvstyrende grupper. Det er dog et af de mere velbelyste områder indenfor Scrum. Litteraturen om emnet er imidlertid så stor, at Scrum teamwork er et studie i sig selv og er derfor blevet fravalgt i dette studie. Det samme gælder for kommunikation og de dertil knyttede kommunikationsværktøjer, som telefon, , Skype, videomødeudstyr osv. Problemstillinger i forbindelse med Scrum-of-Scrum, hvor Scrum benyttes i flere afdelinger eller teams samtidig, som arbejder sammen på et fælles projekt, vil heller ikke blive belyst. På grund af det omfattende teoretiske grundlag inden for projektledelse og softwareudvikling, behandles flere teoretiske områder kun overfladisk eksempelvis brugervenlighed og andre agile udviklingsmodeller. Til punkt d ville det have været interessant at lave en funktionel prototype eller et delvist implementeret Scrumsystem, som kunne afprøves på et par projekter. Men den løsning var desværre ikke realiserbar indenfor den berammede tid. Page 12 of 69

13 3 Relateret arbejde Scrum er den mest benyttede udviklingsmetode inden for agil softwareudvikling og derfor findes der naturligvis også en del eksisterende produkter samt enkelte projekter, hvor man har udviklet forskellige digitaliserede løsninger til understøttelse af Scrum. Der er begrænset litteratur, som beskæftiger sig med digitaliserede værktøjer. De fleste forskningsprojekter er typisk etnografiske studier, som omhandler implementering af Scrum i en organisation. I den forbindelse kommer man sjældent ind på de værktøjer, der benyttes. Men ofte er der tale om lavpraktiske værktøjer, som Excel og en tavle med post-it sedler. I dette kapitel beskrives og diskuteres et par eksisterende projekter, hvor man forsøger at understøtte Scrumprocessen lidt anderledes end i de eksisterende kommercielle produkter. Derudover beskrives udvalgte eksisterende produkter. 3.1 Andre projekter Herunder følger en beskrivelse af nogle relaterende projekter, som på forskellig vis understøtter Scrumprocessen Scrummer For et par år siden designede fire studerende fra RUC et digitaliseret Scrum Board (Scrummer) til et arkitektfirma, som i den daglige ledelse benyttede sig af en lavpraktisk tavle med sedler, hvorpå aktiviteter (arbejdspakker) fremgik. Arkitektfirmaets langsigtede planlægning blev håndteret i Microsoft Project. Scrummer er en interaktiv Smart Boardløsning til en konkret organisation og understøtter i varierende omfang fire grundelementer: Daily Scrum, Scrum Board, Planlægningstavle og Arkiv. Gruppen konkluderede, at Scrum også blev brugt udenfor softwareindustrien, samt at der eksisterer en væsentlig afstand imellem den i litteraturen teoretisk beskrevne Scrum og den praktiske brug af metoden (Nyboe et al., 2009, s.24). De erfarede også: at der i den praktiske brug af Scrum ofte benyttes flere og andre artefakter end de obligatoriske som f.eks. et Scrum Board (Nyboe et al., 2009, s.23). Gruppen påpegede en af udfordringerne ved et digitaliseret Scrum Board: Mere avancerede teknologi hæver ofte kompleksiteten - en kompleksitet, som et stående 15 min. Scrum møde ikke efterlader meget plads til (Nyboe et al., 2009, s.35). I deres analyse kom de frem til fire overordnede behov: intuitivt, nem tilgængelighed, commitment til Scrum og bedre historik. Men deres projekt Page 13 of 69

14 afslørede også, at Scrum Boardet kan have andre funktioner mht. personale eller ressourceobservation i forbindelse med f.eks. sygdom (Nyboe et al., 2009, s.38). Med hensyn til en interaktiv tavle konkluderede gruppen, at brugen var succesfuld: men ser samtidigt et stort fremtidigt potentiale for videreudvikling indenfor dette område (Nyboe et al., 2009, s.72). Derudover var det lykkedes for dem at fremstille en applikation, der indeholdt egenskaber, som arkitektfirmaets lavpraktiske model ikke omfattede. De formåede derved at skabe en merværdi med deres digitaliserede løsning. Gruppen stiller også spørgsmål ved: om man overhovedet bør ændre Scrum og under hvilke forudsætninger det kan gøres? (Nyboe et al., 2009, s.39). Dette spørgsmål diskuteres bl.a. ud fra Schwabers bog: The enterprise and scrum fra 2007, hvor gruppen peger på kulturelle forskelle mellem USA og Skandinavien f.eks. at metoden tilpasses i forhold til rollerne, hvor den mindre hierarkiske og autoritære skandinaviske struktur (Nyboe et al., 2009, s.20) påvirker diskursen bland teammedlemmerne og øvrige interessenter. Lignende erfaringer har man fra Finland, hvor man også har observeret mentale forskelle mellem amerikanere og skandinaver (Marchenko & Abrahamsson). Nyboe et al. får dog ikke rigtig besvaret spørgsmålet, men tilkendegiver dog: Ovenstående eksempel viser, mener vi, meget fint viser hvordan positive resultater kan opnås udelukkende ved implementering af nogle Scrum dele (Nyboe et al., 2009, s.40). Hvilket tyder på, at de trods alt mener, at de ændringer, som arkitektfirmaet har foretaget, er acceptable og giver værdi i deres kontekst Det interaktive Scrum Board På Alexandra Instituttet i Århus arbejder man i øjeblikket med et projekt, som omfatter et interaktivt Scrum Board. Her er omdrejningspunktet det lavpraktiske Scrum Board, hvor man prøver at forene det bedste fra to verdener, ved at lade udviklerne beholder deres gule Post-it sedler, men hvor ændringer på boardet registreres i et bagvedliggende computersystem (Fig. 5). Dette gøres ved brug af QR tags, webkamera og projektor. Page 14 of 69

15 Fig. 5. Det interaktive Scrum Board ( Baggrunden for ovennævnte løsning er erfaringer fra de daglige Scrum møder, som generelt fungerer bedst, når medarbejderne benytter Post-it sedler og en simpel tavle, fordi det giver god dynamik i mødet og holder fokus på det arbejde, som teamet i fælleskab skal løse. Man forsøger at løse den udfordring, at mange udviklere oplever de computerbaserede Scrumværktøjer som en ekstra dokumentationsbyrde, der ikke tilfører processen merværdi. Men samtidig er der fra projektledelsens side et behov for opfølgning og planlægning. De fleste eksisterende værktøjer tilbyder en masse features, der understøtter projektledelse, men for den enkelte udvikler opleves det som en administrativ byrde. I forbindelse med at opgaverne er flyttet over på en skærm, er en af de observationer, man har gjort at folk ender med at tale til skærmen eller projektlederen i stedet for til hinanden. En anden interessant observation i forbindelse med implementering af Scrum er, at det ikke passer til organisationens arbejdsgange og at man derfor er nødt til at justere metoden. Her er holdningen, at det er forkert at se disse Scrum-buts, som et but, da det jo netop er afgørende, at det passer til organisationens kultur, omstændighederne og de kunder, organisationen har. Ovenstående er baseret på oplysninger fra projektets hjemmeside samt korrespondansen med Alexandra Instituttet (Alexandra). Det interaktive Scrum Board er meget innovativ, men umiddelbart virker QR tags store og forstyrrende, da det er vanskeligt at se, hvilke opgaver de enkelte tags repræsenterer. Derudover er man nødt til at printe dem ud, hvilket bevirker, at man ikke kan oprette dem direkte ved Scrum Boardet. Page 15 of 69

16 3.1.3 The Cooperative Task Board Rubart og Freykamp har lavet en prototype af et digitaliseret Scrum Board (Fig. 6), hvor de henvender sig til distribuerede teams og fokuserer på enkelthed for at kunne understøtte principperne i det agile manifesto (se afsnit 1.2): A distributed team needs electronic tool support for daily scrum meetings. Such tool support should focus on simplicity to keep with the agile manifesto (Rubart & Freykamp, 2009 s. 2). Fig. 6. Cooperative Task Board View (Rubart & Freykamp, 2009). De argumenter også for et digitaliseret Scrumsystem, som et nyttigt værktøj i forbindelse med retrospektiv analyse, fordi et digitalt system kan gemme oplysninger om ændringer foretaget i løbet af et Sprint: A common problem with scrum sprints is that at their end not all tasks are completely done. An electronic tool, which supports change management and special reporting, can help to identify the reasons for this problem in a scrum retrospective (Rubart & Freykamp, 2009 s. 2). I lavpraktiske løsninger vil det i højere grad være Scrum Masterens opgave, at noterer ændringer f.eks. i forbindelse med Daily Scrum, hvilket kan få betydning for Scrum Masternes nærvær, når han under mødet skal tage notater. Resultatet kan være, at Scrum Masteren ikke får noteret baggrunden for en eventuel ændring, hvilket kan få betydning ved den efterfølgende retrospetive analyse Diskussion af projekterne Fælles for ovenstående løsninger er, at man forsøger at tænke lidt anderledes og få et digitaliseret værktøj til at indgå i Scrumprocessen på en intuitiv og naturlig Page 16 of 69

17 måde. Formålet er at understøtte Scrumprocessen på lige fod med de lavpraktiske løsninger, men samtidig opnå gevinsten ved datagenbrug og historik, som kan opdatere Burndown Charts automatisk, samt bruges i forbindelse med analyser og rapportering. En af fordelene ved digitaliserede Scrum Boards er også, at det kan ses og vedligeholdes af deltagerne, som arbejder i distribuerede teams eller bare arbejder hjemmefra en dag. Grunden til, at der stadig findes mange lavpraktiske løsninger, skal formodentlig ses som et udtryk for, at der ikke findes digitaliserede værktøjer, som understøtter alles behov på en tilfredstillende måde. For der findes allerede en del eksisterende avancerede systemer, som i bred udstrækning understøtter Scrumprocessen, hvilket vil fremgå af næste afsnit. 3.2 Eksisterende værktøjer I dette afsnit analyseres nogle af de kendte kommercielle Scrumværktøjer, som er udvalgt på bagrund af referencer i artikler og fra en OpenSpace debat, som beskrives i afsnit Analysen er foretaget på baggrund af virksomhedernes præsentationsmateriale samt egne, og i enkelte tilfælde, informanternes indtryk (fra interviews i afsnit 5.1). Det ville naturligvis give et mere nuanceret billede af disse værktøjer, hvis det havde været muligt at installere produkterne og afprøve dem på et aktuelt udviklingsprojekt. Ligeledes ville det også være interessant at analysere i hvilket omfang, systemerne lever op til forskellige kvalitetskrav samt arkitektoniske og ikke-arkitektoniske aspekter inden for Modifiability og Useability. Men det ville være et omfattende analysearbejde og ikke realiserbar indenfor den berammede tid. Derfor er den følgende karakteristik overvejende i relation til de ikkearkitektoniske aspekter for Modifiability og Useability SpiraPlan Inflectra tilbyder en række værktøjer til planlægning, test og samarbejde. SpiraPlan er deres værktøj til agil softwareudvikling og består af en web-løsning, som bl.a. understøtter Scrum, Kanban og Extreme Programming (XP) med værktøjer til: Requirements Management, Release Planning, Iteration Planning, Task Tracking, Bug Tracking og Source Code Integration. Inflectra mener, at tilpasning og konfiguration er afgørende for at sikre, at et system integrerer problemfrit med forretningsprocesser. SpiraPlan kan derfor konfigureres og tilpasses med brugerdefinerede egenskaber. Derudover hævder Inflectra, at de med SpiraPlan er blandt de førende på markedet sammen med AxoSoft og JIRA-Greenhopper. Et umiddelbart indtryk er dog, at produktet indeholder mange skærmbilleder med en hel del felter på og dropdownlister, som kræver meget brug af mus. Page 17 of 69

18 Fig. 7. Backlog planning view (fra Et af skærmbillederne er et virtuelt Scrum Board (Fig. 8), der virker anderledes og lidt uoverskuelig, sammenlignet lavpraktiske Scrum Board løsninger (Fig. 3). Fig. 8. Scrum Board view (fra Page 18 of 69

19 SpiraPlan tilbyder dog et godt oversigtsbillede (Fig. 9), hvor man kan følge med i hele projektet, hvilket må anses for at være et område, hvor lavpraktiske løsninger kommer til kort, da det vil kræve daglige registreringer at opnå samme overblik. Fig. 9. Project overview (fra JIRA-Greenhopper GreenHopper tilbyder modificerbare og fleksible arbejdsgange i forbindelse med agil projektledelse. Værktøjet er baseret på JIRA og understøtter Scrum, XP samt Kanban. Atlassian hævder, at GreenHopper er perfekt til at visualisere og forbedre eksisterende processer. Ud fra præsentationsvideoerne virker det letforståeligt og de generiske Scrum og Kanban Boards giver et godt overblik (Fig. 11). Det lader også til at næsten alle bevægelser skal foregå ved brug af mus, da der er meget drag-n-drop i skærmbillederne. Men det er uklart hvor godt disse funktioner understøttes på en trykfølsom skærm eller Smartboard. Page 19 of 69

20 Fig. 10. JIRA Task board ( Fig. 11. JIRA Kanban board ( Axosoft Axosoft tilbyder en webløsning baseret på HTML5, som dækker Scrum, Helpdesk og Wiki. OnTime Scrum, som er deres Scrummodul, understøtter IDE og SCM integration til Eclipse og Visual Studio. Det er muligt at tilpasse processer, felter og tekster. Derudover kan systemet afvikles på Smart phones og Tablet. Page 20 of 69

21 OnTime Scrum virker som et avanceret system med mange muligheder. Skærmbillederne er strukturerede og overskuelige, men indeholder meget data (Fig. 12, Fig. 13). Nedenstående er et eksempel på en Backlog, men skærmbilledet indeholder også en del andre oplysninger. Det ser dog ud til, at nogle af disse kan gemmes væk måske en konfigurationsmulighed (Fig. 12). Fig. 12. OnTime Project view ( Deres bud på et Scrum Board kan struktureres efter ønske mht. kolonner og filtrering. Derudover kan administrative processer konfigureres i workflows, så man eksempelvis er tvunget til at angive forbrugt tid i et pop-op vindue, når man flytter en opgave. Fig. 13. OnTime Visual Planning Board ( Page 21 of 69

22 3.2.4 VersionOne VersionOne er et samlet produkt, som kan tilpasses til at understøtte unikke behov i forbindelse med Scrum, Extreme Programming (XP), Kanban, DSDM og AgileUP. Uanset, om der er tale om et lille nystartet team, multi-teams eller flere programmer, hævder VersionOne selv, at have de bedste værktøjer, som benyttes af mere end teams i 170 lande. Umiddelbart virker VersionOne lidt tungt et administrativt system, som ikke har tænkt teamdeltagerne, som de primære brugere, men snarere Product Owners. Der er mange menuer og felter på skærmbillederne, som virker forvirrende og man skal klikke meget rundt for at udføre selv de mest almindelige handlinger, som f.eks. at oprette en opgave (Fig. 14). VersionOne er dog et af de produkter, som nævnes i andre sammenhænge (Kniberg, 2006; Uy & Rosendahl, 2008; Rayhan & Haque, 2008). Kniberg beskriver ikke sine erfaringer med VersionOne, men Uy & Rosendahl skiver om deres erfaringer i forbindelse med implementeringen hos Kelley Blue Book, hvor VersionOne erstattede en lavpraktisk Excel og SharePoint løsning. De beskiver ikke, i hvilket omfang VersionOne lever op til forventningerne, men i stedet at systemet er med til at skabe en ensartet håndtering af Scrumprocessen på tværs af 15 teams (Uy & Rosendahl, 2008). Rayhan & Haque kommer til den konklusion, at Excel og s ikke er særlige brugbare værktøjer i forbindelse med et distribueret Scrum team og skriver i den forbindelse lidt om deres brug af VesionOne og Basecamp. De skriver bl.a. at VesionOne ikke understøtter samarbejde ret godt og derfor vælger de et andet intuitivt system (Basecamp) til kommunikationsdelen. Til slut ender de dog med at udvikle deres helt eget værktøj (Scrumpad), fordi de undervejs vælger at bygge et timetracking modul, som kan integreres med Basecamp (Rayhan & Haque, 2008). Ovenstående skal måske ses som et tegn på, at systemet ikke helt levede op til deres behov. Fig. 14. Scrum Board ( Page 22 of 69

23 3.2.5 Scrum-it Scrum-it er et digitalt Scrum Board udviklet af BSgroup Technology Innovation AG, Schweiz ( og er i modsætning til de ovenstående kommercielle systemer en open source web-løsning. Værktøjet er baseret på JSP, Java og JavaScript, og bruger derudover en Tomcat web-server til afviklingen og en MySQL database server til databasen. Scrum-it understøtter Scrumprocessen med håndtering af elementer som projekter, teamdeltagere, sprints og user stories. Her er tænkt innovativt fra starten, idet man kan løse flere af opgaverne vha. en trykfølsom skærm. Derudover kan man forstørre opgaverne på boardet og flytte rundt på flere opgaver samtidig. Scrum Boardet og de øvrige skærmbilleder er holdt enkle og overskuelige, hvilket egner sig godt til præsentation på en storskærm foran teamet (Fig. 15, Fig. 16). Systemet understøtter dog ikke identifikation af, hvem der flytter en opgave, da én udvikler på forhånd er tilknyttet en opgave og det derfor kun er den registrerede udvikler, der håndterer opgaven. Fig. 15. Scrum Board ( Page 23 of 69

24 Fig. 16. Sprint setup ( Sammenfatning Umiddelbart minder de enkelte standardsystemer meget om hinanden og med undtagelse af Scrum-it, bærer de alle præg af at være mest velegnede til tastatur og mus. En af standardsystemernes forcer er, at de er med til at optimere Scrumprocessen ved at sætte retningslinjer for, hvorledes processen skal håndteres. Uy & Rosendahl beskriver bl.a., at de 15 teams før introduktion af VersionOne benyttede forskellige artefakter og strukturer, hvilket sandsynligvis er affødt af forskellige Scrum Masters eller Backlog Owners egne arbejdsmetoder. I modsætning hertil skal ses de individuelle lavpraktiske løsninger, som giver større frihed mht. Modifiability, idet de lettere kan tilpasses og understøtte lokale behov. I disse tilfælde er det i højere grad processen og konteksten, som dikterer værktøjerne end omvendt. De lavpraktiske løsninger er måske også et tegn på, at selv omfattende standardsystemer ikke opfylder alle krav mht. Useability og at de i nogle tilfælde kommer til kort over for individuelle behov. Hvis Scrumprocessen er så standardiseret, som den beskrives i The Scrum guide (Sutherland & Schwaber, 2011) burde standardsystemerne jo i princippet kunne opfylde alle behov. Page 24 of 69

25 4 Metode For at afklare hvorfor og i hvilket omfang Scrum metoden tilpasses lokale forhold (empiri) afholdes 4 interviews med repræsentanter fra softwarevirksomheder, som benytter Scrum i forbindelse med deres projekter. Derudover gennemgås og analyseres eksisterende viden og forskning indenfor området vha. videnskabelige artikler og fora på Internettet. Indsamling og udvælgelse af eksisterende forskning, som hovedsagligt består af videnskabelige artikler, er inspireret af Hossain et al s. beskrivelse af Kitchenham & Charters guidelines for conducting Systematic Literature Review (Hossain et al., 2009). Søgning af materiale er foretaget på følgende sites: IEEEXplore ( ACM Digital library ( Google Scholar ( Wiley InterSciene ( SpringerLink ( Der er overvejende søgt litteratur skrevet på engelsk og udvælgelsen er i modsætning til Hossain et al. foretaget af en enkelt person. 4.1 Interviews Der findes forskellige metoder, som kan bruges til at få et bedre indblik i andres brug af Scrum. Man kan f.eks. udføre eksperimenter eller observere, hvordan en organisation eller et team bruger Scrum. Valget blev i dette tilfælde at interviewe fire udviklere, som har erfaringer med Scrum fra forskellige virksomheder, idet de to andre metoder ikke umiddelbart var realiserbare. For ikke udelukkende at forholde mig til eksisterende forskning, men for at få et mere detaljeret kendskab til problemområdet mht. til forskellig brug af Scrum, valgte jeg at gennemføre fire kvalitative forskningsinterviews, også kaldet dybdeinterviews. De tre første interviews var med udviklere fra forskellige softwarevirksomheder og det sidste var med It-chefen fra et rederi med egen Itafdeling, hvor jeg selv arbejder. Alle de repræsenterede virksomheder benytter Scrum, men på forskellig vis. Det er målet med kvalitative forskningsinterviews, at få et bredt og nuanceret billede af interviewets tema: brug af Scrum (Kvale, 2006). Hovedformålet med mine interviews var at få indblik i forskellige virksomheders eksisterende Scrumløsninger, samt hvilke tanker, forudsætninger og udfordringer, der ligger til grund for deres løsninger. For eksempel hvilke elementer i Scrum Page 25 of 69

26 frameworket, man eventuelt har tilpasset, hvorfor, og hvordan man understøtter disse og i hvilket omfang, man er tilfreds med den nuværende løsning. Til undersøgelsen blev der brugt Semi-strukturede interviews, som er en velegnet og anerkendt metode til indsamling af empirisk information (Kvale, 2006). Derudover er metoden velegnet til interview af flere personer om samme emne (Kvale, 2006), som her, hvor 4 personer blev interviewet om deres erfaringer med Scrum. Et åbnet interview giver mulighed for, at intervieweren selv deltager aktivt i interviewet. En række prædefinerede spørgsmål nedskrevet i en interviewguide (appendiks 9.1) blev derfor udleveret et par dage før interviewene for at holde fokus og sikre et sammenligneligt grundlag til den efterfølgende diskussion af svarene. Denne fremgangsmåde sikrede, at informanterne fik mulighed for at forberede sig og indhente oplysninger, hvis de manglede viden om et område. Interviewguiden var dog stadig så åben, at der kunne spørges dybere ind til informanternes svar, såfremt dette blev skønnet særligt relevant. Udgangspunktet for spørgsmålene var Karl Tomms spørgsmålstyper, som er opdelt i fire kategorier: Lineære, Cirkulære, Refleksive og Strategiske spørgsmål (Tomm, 1988). I dette tilfælde var der naturligvis ikke tale om terapi som Tomm forsker i, men de ovennævnte spørgsmålstyper var velegnede til at fastlægge den rette ordlyd i spørgsmålene med det formål at opnå sammenlignelige svar. I stedet for at renskrive alle interviews, som er meget tidskrævende og derfor lå udenfor studiets rammer, blev de vigtigeste udsagn og pointer citeret eller fremhævet i teksten, og er vedlagt rapporten som vedhæftede filer. I den forbindelse var jeg meget opmærksom på ikke at "plukke" i interviewene og sammensætte udsagn på en sådan måde, at de blev citeret ud af kontekst og derved kunne komme til at fremstå ukorrekt i forhold til den oprindelige mening. De fire interviews blev herefter analyseret og diskuteret under inddragelse af eksisterende forskning. Andre brugbare metoder, som blev fravalgt var: En eksperimentel tilgang f.eks. ved at foretage nogle forsøg i forbindelse med et nyt projekt og efterfølgende evaluere resultatet. Det ville sikkert give en god forståelse af anvendeligheden, men også vanskeligt at opnå brugbare erfaringer inden for den berammede tid. Observation som "fluen på væggen" f.eks. i forbindelse med afholdelse af Sprint eller Daily Scrummøder. Det har desværre ikke været muligt at få en aftale på plads. 4.2 Geeknight event For at få en bredere emperi om brug af Scrum deltog jeg i et Geeknight event, som omhandlede Distributed Scrum and Agile. Jeg håbede, at jeg derigennem ville komme i kontakt med repræsentanter fra andre softwarevirksomheder, som kunne bidrage med mere viden om andre virksomheders brug af Scrum. Page 26 of 69

27 Ligedes ville jeg undersøge, hvilke værktøjer, de brugte og om, der i forbindelse med distribueret Scrum, var forskel på værktøjerne i forhold til Scrum når hele teamet er samlet lokalt. 4.3 Softwarearkitektur Arkitekturen er grundlaget for at opnå kvalitet i et softwaresystem. Bass et al. anbefaler nogle principper i form af Quality Attributes (QA), som kan hjælpe sofwarearkitekten med til at skabe kvalitet i arkitekturen, så den både lever op til de udvalgte kvalitetsattributter og ikke-funktionelle kvalitetskrav (Bass et al., 2006). Et andet vigtigt aspekt er funktionalitet, som er et softwaresystems evne til at udfører de opgaver, det er tiltænkt at skulle løse (Bass et al., 2006, s.71). Ikkefunktionelle kvalitetskrav er i den forbindelse krav, som ikke direkte har forbindelse til systemets funktionalitet, men som er mindst lige så vigtige, fordi de bl.a. sikrer, at funktionaliteten kan afvikles på en tilfredsstillende måde. Det kan f.eks. være systemets muligheder, tjenester og adfærd (Bass et al., 2006, s.71). Grundelementerne i Bass et al s principper er tactics, som indenfor QA kategorierne Availability, Modifiability, Performance, Security, Testability og Usability fungerer som byggeklodser, og i kombination danner et Architectural Pattern. Tactics er forskellige designvalg, som sikrer opfyldelse af funktionalitet og påvirker kvalitetsattributternes respons, og derved bidrager til den samlede arkitektoniske løsning i en strategi (architectural strategy) (Bass et al., 2006, s.100). For at sikre kvaliteten i de valgte arkitektoniske patterns kan man yderligere specificere scenarier (Quality Attributes Scenarios), hvor man med udgangspunkt i specifikke krav opstiller målbare scenarier, som systemet skal leve op til (Bass et al., 2006, s.75). Derudover findes der andre kvalitetskrav, som påvirkes af de arkitektoniske valg. Det kan f.eks. være forretningskrav (Business Qualities), hvor eksempelvis time-tomarket kan stille begrænsende krav mht. udviklingstiden, hvilket kan påvirke arkitektoniske valg i negativ retning. Hvis eksempelvis udviklingen forceres for at nå en deadline, kan det gå ud over systemets performance og kvalitet. Et andet eksempel er Projected lifetime of the system, som kan stille krav til produktets modificerbarhed, hvis man forventer en lang levetid (Bass et al., 2006, s.95). Men en god arkitektur er ikke alene nok til at sikre kvalitet i systemet - det afhænger også af implementationen af softwareelementerne samt kvalitetsattributternes indbydes påvirkning (Bass et al., 2006, s.73). For eksempel kan krav om høj modificerbarhed og høj performance være modstridende, fordi et højt abstraktionsniveau med flere lag kan påvirke afviklingen og få indflydelse på systemets performance. Derfor er arkitekten ofte nødt til at indgå kompromis mht. kravene (Tradeoffs). Page 27 of 69

28 4.3.1 Arkitektur for et Scrumsystem Alle softwaresystemer har en arkitektur og det er også tilfældet med et system, som kan understøtte Scrumprocessen. Overordnet set er kerneelementerne i Scrum en mængde estimerede opgaver af forskellig type (User Stories og Tasks), som inddeles i delmængder (Sprint) og skifter status efterhånden, som der bruges tid på dem (udvikling) og de færdiggøres (Done). A typical Scrum maintains a Scrum board showing columns of user stories, development tasks relating to each story, and the state of each development task and tests associated with each story. When a task is started a card is moved across the board into an open column. When code is complete it is move to the verification column and when fully tested is moved to a done column (Sutherland & Schwaber, 2007, s.100). I systemet, som skal kunne understøtte forskellige variationer af Scrumprocessen og måske på et senere tidspunkt kunne udbygges til også at understøtte Kanban, har jeg mht. arkitekturen valgt at fokusere på Modifiability og Useability, da dette er de primære kvalitets attributter for systemet. De øvrige kvalitetsattributter Availability, Performance, Security og Testability er naturligvis også vigtige, men ikke i så høj grad i denne kontekst, hvor der er få brugere (team på 5-9 deltagere), som arbejder sporadisk i et forholdsvis simpelt system med begrænset ansvar og tilgang. Vægten bør derfor ligge på konfigurations- og tilpasningsmuligheder, samt brugervenlighed i form af intuitiv understøttelse af Scrumprocessen. Useability og Modifiability består både af arkitektoniske og ikke-arkitektoniske aspekter. For Useability gælder det, at funktioner og kommandoer, som for eksempel Copy og Undo, der relaterer sig til systemets funktionalitet, er arkitektoniske aspekter, fordi deres virkemåde afhænger af forskellige elementers indbyrdes afhængigheder og placering. Brugergrænsefladens udseende er derimod et ikke-arkitektonisk aspekt, fordi der er tale om designvalg, som normalt ikke har nogen betydning for systemets arkitektur. Men disse valg har naturligvis stor betydning for brugernes oplevelse af systemet og er derfor også vigtige (Bass et al., 2006, s.73). Der er samspil mellem arkitektoniske og ikke-arkitektoniske aspekter i de tilfælde, hvor grænsefladen er afhængig af den funktionalitet, som systemet stiller til rådighed. For eksempel skal API et for det valgte programmeringssprog understøtte konfiguration af eksempelvis sprogvalg, navngivning af felter osv. for at disse arkitektoniske valg er brugbare. Modifiability handler i høj grad om de økonomiske omkostninger, der er forbundet med at foretage ændringer af et system. Her er de arkitektoniske aspekter eksempelvis den struktur, der er valgt i forbindelse med adskillelse af funktionaliteten, hvor et system anses for at være modificerbart, hvis en ændring kun involverer et minimum af elementer. Dette kan f.eks. opnås ved lav-kobling mellem elementerne (klasser), hvor man begrænser afhængigheder eller ved højsamhørighed, hvor man samler ansvaret. Begge designvalg er med til at begrænse omfanget af ændringer, i forbindelse med omstrukturering af koden. Men selve kodestilen, som er et ikke-arkitektonisk aspekt, har også stor betydning for modificerbarheden, hvis eksempelvis koden er vanskelig at forstå og derved problematisk at ændre (Bass et al., 2006, s.73). Page 28 of 69

29 Modifiability hænger også tæt sammen med en anden kategori Portability, som iht. Bass et al. ikke er en QA, men som også omhandler modificerbarhed i forhold til, at et system kan installeres og afvikles på forskellige platforme. I forbindelse med et Scrumsystem er portability interessant, idet man må formode at de forskellige organisationer, som benytter Scrum, sikkert også benytter forskellige platforme som Windows, Linux osv. Derfor er der også behov for at se på et andet forretningskrav Targeted marked, som netop omhandler hvor, og i hvilken udstrækning, man kan afsætte systemet (Bass et al., 2006, s.95). Set ud fra et forretningsmæssigt synspunkt kunne målet derfor være, at basere systemet på nogle platformsuafhængige løsninger, som f.eks. Web og JAVA. Ovenstående argumenter redegør således for, at der er mange aspekter og afvejninger, som skal tages i betragtning i forbindelse med valg af arkitekturen Tactics Inden for de valgte kvalitetsattributter Modifiability og Usability findes der en række tactics, som er designvalg, der kan implementeres og derigennem påvirke kvalitetsattributterne. De enkelte tactics er grupperet i forskellige kategorier afhængig af deres virkermåde og Bass et al. har valgt at inddele dem i et hierarki (Fig. 17). Modifiability tactics kan være med til at sikre, at ændringer i et system bliver så billige som muligt. Et af målene er at undgå, at ændringer breder sig (Prevent ripple effect) til andre moduler, som ikke er direkte forbundet hermed. Dette kan håndteres ved at begrænse kommunikationsmulighederne, uddelegere ansvar (Localize modifications) og kommunikerer via interfaces (Bass et al., 2006, s.106). Fig. 17. Modifiability tactics (Bass et al., 2006, s. 111). Page 29 of 69

30 Ovenstående taktikker er generel god skik inden for objektorienteret programmering, hvorimod den sidste gruppe inden for Modifiability Defer binding time, nærmer sig Usability, fordi man med Runtime registration og Configuration files tilbyder brugerne (eller systemadministratorerne) nogle værktøjer, der kan få systemet til at ændre adfærd, uden at det kræver indgriben fra en udvikler (Bass et al., 2006, s.110). Det kræver naturligvis, at variationerne i adfærden på forhånd er implementeret i systemet og det er netop her modificerbarheden bliver aktuel. I forbindelse med et Scrumsystem vil det være naturligt at fokusere på disse tactics, da systemet overordnet set skal have samme funktionalitet, men ofte med små ændringer, fordi den skal tilpasses lokale ønsker og forhold. Eksempler på dette kunne være opgavekategorier, statustyper og inddeling af felter/områder til: Not started, In progres og Done osv. Usability tactics forgrener sig i to kategorier. Den ene er Runtime tactics, som bl.a. omhandler brugerkommandoer som: save, cancel og undo, samt feedback til brugeren om, hvad systemet foretager sig (fremgår af Fig. 18 som Support User Initiative og Support System Initiative). Her skelner man mellem hvem, der tager initiativet om det er brugeren, systemet eller en kombination. Brugeren kan for eksempel starte en filoverførsel og systemet svarer med en meddelelse om, at overførslen er iværksat samt løbende status, som fortæller brugeren, hvornår processen forventes udført. Dette er et eksempel på en Maintain a model of the system tactic, idet systemet fortæller noget om sig selv hvor lang tid tager det for systemet at udfører handlingen (Bass et al., 2006, s.121). Fig. 18. Usability tactics (Bass et al., 2006, s.123). Lignende tactics findes for bruger og opgave, hvor systemet ud fra sin kontekst understøtter brugerens handlinger ud fra forventninger om, hvilke handlinger brugeren ønsker at foretage sig. I disse tilfælde skal systemet svare retvisende og respondere så hurtigt, at brugeren ikke bliver usikker på om kommandoen er i værksat, men heller ikke hurtigere end brugeren kan nå at følge med. I Scrumsystemer gælder dette for eksempel mht. oprettelse af User Stories og Tasks, hvor systemet skal åbne og lukke indtastningsvinduerne og respondere på tastetryk og registreringer. Det er også vigtigt, at systemet virker intuitivt for brugeren, så Page 30 of 69

31 denne ikke er i tvivl om rækkefølgen på kommandoer i forbindelse med oprettelse og editering af diverse objekter. Den anden gren er Designtime tactics, som er tæt knyttet til Modifiability tactics, idet denne type tactics omhandler separation af brugergrænsefladen og den øvrige del af systemet, hvilket hænger sammen med Semantic coherence fra Modifiability tactics (fremgår af Fig. 18 som Separate User Interface). Dette kan håndteres vha. en lagdelt arkitektur, hvor f.eks. et Model-View-Controler pattern kan bruges til at adskille præsentation (grafik), logik og model. I Scrumsystemet kan denne arkitektur implementeres vha. et observer pattern, som f.eks. i Burndown Chartet viser effekten af de ændringer, som foretages på Scrum Boardet. Page 31 of 69

32 5 Analyse og diskussion I dette afsnit analyseres de afholdte interviews, input fra GeekNight event samt forskellig brug af Scrum i forhold til metodens anbefalinger og øvrig forskning på området. 5.1 Interviews og event Kvalitative forskningsinterviews er en anerkendt og struktureret metode til indsamling af oplysninger. Det kan være en stor fordel at optage interviewet i stedet for at tage notater, da man dels er mere nærværende under selve interviewet og dels kan genhøre optagelsen. Ved sidstnævnte falder man måske over udtalelser, som man i første omgang overhørte eller ikke tillagde nogen betydning. Derudover mindsker man risikoen for fejlnotater, som beskrevet i afsnit 4.1. Men selvom man anvender en interviewguide, kan det være vanskeligt at holde fokus på de prædefinerede spørgsmål, fordi interviewet udvikler sig specielt når man stiller åbne spørgsmål og informanterne kommer til at svare på flere spørgsmål samtidigt. Derudover kan der være spørgsmål, som bliver overset, kun besvares delvist eller måske ikke er lige relevante for alle informanterne. Sidstnævnte kan give mudrede svar, hvor uddybning af svaret efterfølgende kan være nødvendig. I appendiks 9.2 sammenlignes udvalgte emner fra de fire interviews. Informanterne blev udvalgt på den baggrund, at jeg gennem tidligere samtaler havde fået bekræftet, at de arbejdede med Scrum Interview med Birte, Logica Birte arbejder som udvikler hos Logica Danmark A/S og har flere års erfaring med Scrum (BLH 01:10). I Logica, som er en international virksomhed med medarbejdere inden for teknologi- og virksomhedsservice, har man i Århus afdelingen i mere end 3 år brugt Scrum i forbindelse med udviklingsopgaver og support (BLH 00:20). Iflg. Birte egner metoden sig bedst til nyudvikling (BLH 01:55), men kan dog også bruges til andre projekttyper, hvis man tilretter den (BLH 02:24). Hos Logica sammensættes og prioriteres Sprint backloggen af Product Owner i fællesskab med teamet. (BLH 26:15) I den forbindelse kigger man bl.a. på kompetencerne i teamet alle skal kunne se sig selv i sprintet dvs. der skal være opgaver til alle (BLH 05:24). Alle opgaverne i backloggen skal ligeledes være estimerede (fra 2 til 40 timer), hvilket Product owner står for. Page 32 of 69

33 Der estimeres på baggrund af poker estimering 2 eller estimat fra den deltager, som har oprettet opgaven (BLH 13:42) (det er altså ikke kun Produkt Owner, som lægger opgaver i backloggen). Ved store opgaver er første skridt ofte at opdele opgaven i mindre bidder (BLH 14:57), som f.eks. analyse, beskrivelse og samtale med kunden (BLH 15:38). Selve opgaverne med beskrivelser og dokumentation (BLH 18:40) håndteres vha. JIRA, som også kunderne har adgang til (BLH 20:33). I løbet af et Sprint hænder det, at opgaver tilføjes, omprioriteres eller udtages, hvis der f.eks. bliver indrapporteret alvorlige fejl eller nye presserende ønsker (BLH 27:55), og eventuelle fejlestimater rettes på deres Scrum tavle (BLH 16:57). Birte anser Scrumtavlen, som det mest anvendelige artefakt, fordi den afspejler alle opgaverne i backloggen (BLH 08:52) og skaber overblik mht. hvem der laver hvad, hvilket er en fordel, når teamet er fordelt på flere kontorer (BLH 09:19). Udviklerne kan selv vælge blandt opgaverne: hvis man har lyst til at prøve noget nyt, har man mulighed for at tage en anden [mere spændende] opgave (BLH 08:52). Ud fra Birtes beskrivelse om Logica s brug af Scrum tavlen ser det ud til at tavlen er motivationsfaktor, idet udviklerne har indflydelse på deres eget arbejde. Hos Logica har man inddelt Scrum tavlen i kategorierne: Ikke påbegyndte opgaver, Impeded (i dvale eksempelvis hvis man mangler svar fra kunden), Igangværende og Afsluttede opgaver (BLH 10:51). Som i de fleste andre Scrum Board løsninger synliggøres opgaverne vha. små sedler (BLH 30:20) med forskellige farver afhængig af opgavetypen (udvikling, test, møde, indkomne ikke planlagte opgaver osv.) (BLH 30:30). Sedlerne har forskellige informationer fra backloggen bl.a. et nummer, en beskrivelse, en prioritering samt et tidsestimat. Enkelte kan også have en deadline noteret (BLH 11:54). Scrumtavlen har også været med til at løse en udfordring med at synliggøre vigtige oplysninger og opgaver, som tidligere lå fordelt i teamdeltagernes s (BLH 09:50). Et andet vigtigt artefakt, Birte nævner, er Sprint Burndown chartet, hvor man dagligt registrer løste opgaver (BLH 11:08). Opgaver, som kun er delvis løste, bliver ikke registreret (BLH 19:35). Det ser dog ud til, at også Burndown chartet har en motiverende effekt, idet der kan gå sport i at nå opgaverne, hvis man er kommet bagefter (BLH 11:08). Den største udfordring er i den forbindelse større eller specielle/vigtige supportopgaver, som kræver hjælp af andre end den person, som står for supporten (BLH 31:26). Det er vanskeligt at få disse opgaver synliggjort på Scrum tavlen og man har uden held tidligere forsøgt sig med en swimlane - en kategori af opgaver som flød på dagligdagen og ikke var en del af backloggen (BLH 31:51). Birte erkender vigtigheden af den type opgaver og vil gerne have en bedre understøttelse af disse, men har umiddelbart ikke noget løsningsforslag til problemet. 2 Poker estimering (Planning Poker) er en form for kortspil, hvor de enkelte deltagere uafhængigt med hvert sit kort, estimerer udviklingstiden for en opgave. Ud fra estimaterne diskuteres opgaven i teamet. En stor variation blandt estimaterne kan være et tegn på forskellig opfattelse af opgavens omfang. Page 33 of 69

34 Det skal bemærkes, at både Scrumtavlen og Burndown Charts håndteres vha. lavpraktiske værktøjer og at man ikke arbejder med faste leverancer efter hvert sprint, men i stedet med halvårlige eller kvartårlige releases afhængig af kundernes ønsker (BLH 21:50) Interview med Thomas, Vertica Thomas er udvikler hos Vertica A/S, hvor man har benyttet Scrum i en del år. Vertica er et softwarehus med ca. 40 ansatte fordelt på kontorer i Århus og København. Virksomheden har specialiseret sig indenfor systemintegrationer samt E-handels-, Portal- og mobile løsninger. Her bruger man Scrum til at skabe fokus med hensyn til opgaver og fremdrift overfor kunderne (TBE 00:30), samt internt, overfor udviklerne, til at synliggøre hvilke opgaver der skal arbejdes på (TBE 00:58). Hos Vertica bruger man Scrum forskelligt afhængig af forretningsområdet og projekttypen (TBE 02:30). Kun i store projekter bruges Scrum i større omfang (TBE 06:40) og det bruges mest aktivt i forbindelse med e-handelsløsninger og portaler, hvor man anvender en klassisk Scrum model, med Feature backlog, Scrum møder, Burndown charts osv. (TBE 04:30). I forbindelse med integrationsprojekter anvendes Scrum mere varieret (TBE 03:46), da der i mange tilfælde ikke er tale om decideret projektarbejde fra Vertica s side (TBE 05:52). I stedet deltager Vertica ofte i kundens projektgruppe med rådgivende konsulenter frem for egen udvikling (TBE 06:00). I disse tilfælde er det kunderne, som definerer en eventuel Scrum model (TBE 08:30). For integrationsprojekterne er det iflg. Thomas også vanskeligt at lave en fornuftig backlog med veldefinerede opgaver, fordi disse projekter ofte består af mange afhængigheder ender, der skal mødes (TBE 06:50). Her kan for løst definerede opgaver give økonomiske problemer, hvis det senere i projektet bliver nødvendigt med radikale ændringer (TBE 11:29). I enkelte tilfælde bruges backloggen også som grundlag for fastprisaftale, hvilket stiller ekstra krav i forbindelse med ændringer eller tilføjelser, da disse falder uden for aftalen (TBE 12:15). I sådanne tilfælde får backloggen en kontraktuel betydning (TBE 13:23) i form af en kravspecifikation. God kommunikation er vigtig hos Vertica og man har gode erfaringer med at lade udviklerne deltage i sprintmøderne og have tæt kontakt til kunderne, da man mener, at dette bidrager til en bedre forståelse for kundens behov og ønsker (TBE 12:15). Men det kræver også ærlighed overfor kunderne, i tilfælde hvor kundens ønsker er tvetydige eller ikke harmonerer med den valgte løsning (TBE 18:18). Vertika bruger ikke fast Sprint time-boxing, men tilpasser fra gang til gang i forhold til mængden af veldefinerede opgaver (TBE 22:02) eller iht. kundens ønsker (TBE 21:53). Man justerer altså Sprintlængden efter, hvor uklare opgaverne er. Jo mere uklare opgaverne er, jo kortere sprint, for ikke at få for mange opgaver i sprintet, da man har erfaringer med, at Sprint backloggen ellers skal ændres efterfølgende. Internt drager man stadig fordel af den tætte kontakt, som Scrum tilbyder (TBE 43:50). Men Thomas mener, at der ofte bliver brugt for lidt tid på projektledelse i integrationsprojekter, hvilket efterfølgende giver bagslag (TBE 23:43), fordi Scrum Page 34 of 69

35 egner sig mindre godt til integrationsprojekter. En af udfordringerne er relationer til andre partnere, der vanskeliggør planlægning med uklare eller udetaljerede opgaver, som igen medfører et for udefinerede projektforløb (TBE 39:30). Ved veldefinerede projekter er der meget fokus på burndown og levering, fordi kunden ofte har en deadline (time to market), som skal overholdes (TBE 30:05). Hvorimod kunder, som er mere interesseret i features og funktionalitet, ikke lægger så stor vægt på denne del, fordi der hele tiden kommer nye ting til og backloggen derved ændres (TBE 30:15). I disse projekter er der mere fokus på selve sprintet og specielt den afsluttende demo (TBE 30:40). Hos Vertica har man adskilt udvikling og drift ved at lave serviceaftaler for support af eksisterende løsninger. Denne funktion varetages af en decideret serviceafdeling (TBE 34:18), hvilket giver ro i forbindelse med nyudvikling, fordi man ikke skal afsætte tid til drift i et sprint og udviklerne ikke bliver forstyrret af driftopgaver (TBE 32:52) Interview med Henrik, Unifeeder Henrik er CIO hos Unifeeder A/S, som er et af verdens største feederrederier og har ca. 300 ansatte fordelt på 9 kontorer i Nordeuropa. Unifeeder udvikler selv kun en mindre del af virksomhedens it-systemer, men har mange forskellige typer af projekter, heriblandt dataudveksling med kunder og samarbejdspartnere. Henrik ser mest Scrum som et effektivt projektstyringsredskab, der tilbyder projektledere (HFI 24:40) nogle praktiske værktøjer (HFI 00:35), hvor man "får meget foræret", bl.a. pga. den tætte opfølgning (HFI 20:18). Specielt de daglige Scrummøder giver stor værdi, fordi produktiviteten synliggøres og udfordringerne kommer til udtryk, uden man bruger for meget tid på det (HFI 20:58). Hos Unifeeder valgte man Scrum for at få bedre styr på it-projekterne (HFI 01:22), som ofte er tilknyttede forskellige Product Owners og afvikles sideløbende (HFI 08:15). Tilgangen har været "learning by doing" og modellen har derfor også udviklet sig i løbet af de 1½ år, man har brugt den (HFI 03:45). Man har ikke noget standardsystem til understøttelse af modellen (HFI 05:03), men bruger i stedet Lotus Notes til projektopgaver/backloggen og Excel til sprintplanlægning (HFI 05:20). For at koordinere de forskellige projekter afholder man lidt utraditionelt et preplanning møde inden sprint start, hvor hovedopgaver fra de forskellige projekter diskuteres af Produkt Owners og projektlederne (HFI 13:55). Af artefakter benytter man et Scrum board, men ikke Burndown Charts, da man mener, det ikke er muligt at restestimere opgaverne på dagligt basis (HFI 11:25). I stedet reflekterer man retrospektivt over tidsforbrug og opgavestatus i forbindelse med Sprint afslutningen, hvor man opsummerer tidsregistreringer af de enkelte opgaver (HFI 11:37). Henrik mener, at Unifeeder s Scrummodel mangler synlighed udadtil for eksempelvis Produkt Owners og med den nuværende løsning, er det vanskeligt at restestimere opgaverne. Derfor planlægger man at introducere Burndown Charts for herigennem synligøre opgavestatus og fremdrift over for Product Owners og andre interessenter (HFI 17:20). Hertil savner Henrik stærkere værktøjer til Page 35 of 69

36 opgaveestimering og evaluering (HFI 18:06). Han tror dog, at dette mål kunne opnås ved at anvende de eksisterende værktøjer med en større manuel administrativ indsats (HFI 18:55). Den nuværende løsning giver derfor størst udbytte for de deltager, som er "tæt på" projekterne (HFI 25:50). I modsætning til ovenstående fungerer Unifeeder s Scrum Board løsning til gengæld bedre, fordi det skaber dialog og dynamik, men man kunne godt tænke sig en bedre teknologisk løsning (HFI 21:37). Udover planlægning bruger man også Scrummodellen til ressourcestyrring (HFI 13:55), hvor det er projektlederne, som prioriterer og tildeler opgaverne (HFI 14:44). Arbejdsopgaverne på Scrum Boardet er som udgangspunkt ikke prioriterede (Fig. 19). Det er op til udviklerne selv at bestemme rækkefølgen af disse - evt. i samråd med projektlederne (HFI 22:27). Fig. 19. Eksemple på Unifeeder s Scrum Board (foto: Jan Bjerg) Interview med Svend, Alexandra Instituttet Svend er projektleder på Alexandra Instituttet og har arbejdet med Scrum både i sin nuværende stilling og den forrige hos Mjølner Informatics (SRT 00:05). Hos Mjølner Informatics bruger man en struktureret udviklingsproces til sine softwareprojekter. Metoden er inspireret af IBM s RUP (Rational Unified Process) og kombineres med Scrum (SRT 00:30). På Alexander Instituttet arbejder man med software i kombinerede projekter for forskellige virksomheder (SRT 01:09). I disse projekter har man frie rammer og Svend kan derfor udvælge udviklingsmetoden ud fra projekttypen, karakteristika Page 36 of 69

37 og omstændigheder (SRT 01:30). Han kan dog ikke udelukkende bruge Scrum, fordi projekterne ikke kun omfatter softwareudvikling, men også samarbejde og udvikling med eksterne partnere om produkter, hvori softwaren indgår (SRT 02:15). Projektdeltagerne er ofte tilknyttet andre projekter samtidig (SRT 03:36), og man afholder derfor ikke faste møder, men aftaler disse efter behov (SRT 06:30). Derudover arbejder man ofte med innovativ udvikling, hvor man opdeler projekterne i opgaver eller delprojekter, som ikke nødvendigvis omfatter software udvikling (SRT 06:58). Til disse "proof of concept" projekter (SRT 23:50) mødes man f.eks. en gang hver måned for at koordinere opgaverne (SRT 07:50) og længden af hvert sprint aftales derfor fra gang til gang, afhængig af mængden af delopgaver (SRT 09:24). Svend er stor tilhænger af agil softwareudvikling, hvor han mener, at man skal bruge de bedste værktøjer. Han ser sig selv som en "reflekterende projektleder" og benytter sig af værktøjer fra både den klassiske og agile projektledelse (SRT 11:22), idet han ud fra et projekts længde, kompleksitet og uklarhed bruger elementer fra både de klassiske og agile projektledelsesteorier (SRT 13:43). I den forbindelse er det typisk ham selv, der vælger udviklingsmodellen (SRT 15:40) og han mener, at den metode, han har valgt at bruge i sit nuværende projekt, kan sammenlignes med Scrum (SRT 10:50). Men da han ikke har et fast team og opgaverne ikke kun omfatter softwareudvikling, er det ikke altid muligt at benytte Scrum 100 % (SRT 36:30). Hvis der var tale om en ren softwareudvikling med et fasttømret team ville Svend nok vælge Scrum - måske justeret, så den passer til forholdene (SRT 38:02). Han er i det hele taget meget inspireret af Scrum og agil udvikling. Men han påpeger, at i forbindelse med agil udvikling, er det nødvendigt med struktur, da det ellers kan ende med "cowboy kodning" eller anden form for anarkistisk udvikling (SRT 11:48), og nævner, at der er mange, som udvikler agilt, men ikke følger principperne for agil udvikling (SRT 38:30). På Alexandra Instituttet har man vedtaget nogle faste rammer for projektledelse, som alle er underlagt for at undgå ustruktureret udvikling (SRT 13:10) og Svend ser potentiale i brug af standardværktøjer i hele organisationen til eksempelvis projektplaner (SRT 28:14). Men savner umiddelbart ikke andre værktøjer i sit daglige arbejde. Sven påpeger også, at eventuelle administrative værktøjer skal være indlejret i udviklingsmiljøet og være en naturlig del af arbejdet, hvis det skal give værdi og ikke administrativt ekstraarbejde (SRT 22:35;SRT 31:00). Men han nævner også, at det for udviklere og projektledere er meget vigtigt at have administrative data til rådighed for at kunne styre et projekt mht. status og indsigt (SRT 33:50). I den forbindelse er det vigtigt, at det er let for udviklerne at registrerer oplysningerne, så de er motiveret for at bruge systemet, hvilket medfører højere datakvalitet (SRT 34:23). Her nævner Svend et andet projekt på Alexandra Instituttet, hvor man netop arbejder med en virtualiseret løsning af et Scrum Board (SRT 31:20), som blev beskrevet i afsnit Page 37 of 69

38 Mht. artefakter bruger Svend ikke Burndown Charts, fordi han mener, at man kun kan beregne realistisk velocity 3, hvis man arbejder med samme opgavetyper eller systemer (SRT 21:08). Tidsestimering af opgaverne fastsætter han selv, dog nogle gange i samråd med deltagerne (SRT 22:48) Geeknight om Distributed Scrum and Agile Onsdag d. 14. marts 2012 afholdte ScrumForum Aarhus et Geeknight event om Distributed Scrum and Agile hos Trifork A/S i Århus. Det bestod af et fagligt oplæg v. Mads Troels Hansen, og efterfølgende OpenSpace debat om relaterende emner udvalgt af deltagerne. Et at emnerne var Collaboration Tools, hvor brug af forskellige værktøjer blev debatteret i en gruppe på 11 deltagere. Alle deltagerne repræsenterede forskellige softwareproducenter eller virksomheder med egen udvikling, som brugte Scrum i en distribueret kontekst. Hertil benyttede de alle dedikerede it-systemer, som understøttede processen og artefakter, som f.eks. Backlogs og Burndown Charts. Grunden til, at alle benyttede it-baserede værktøjer, var et resultat af de behov den mere komplekse kontekst Distribuerede Scrum stiller. På grund af den fysiske adskildelse stilles der større krav til kommunikation og synliggørelse af opgavernes status i Sprintet ved distribuerede teams, end der gør ved tæt samarbejdende Scrum team med Daily Scrum og hyppig interaktion. Distribuerede løsninger kræver derfor, at teamet kan tilgå de samme ressourcer og artefakter i et digitaliseret Scrumsystem. Ovenstående bliver også bekræftet af eksisterende forskning på området. Hossain et al. foretog i 2009 et større review af studier inden for Global Software Development (GSD), hvor Scrum bl.a. blev benyttet. De konkluderede, at distribueret softwareudvikling stiller store krav til kommunikation og de understøttende værktøjer. Den samme konklusion kom Rubart og Freykamp også til (omtalt tidligere i afsnit 3.1.3). Nedenfor er oplistet de systemer, som blev brugt af de distribuerede teams: TFS (Microsofts Team Foundation Server) Basecamp ( JIRA-Greenhopper ( RCC ( Springloops ( Google docs 3 En indikator for hvor produktiv teamets forventes at være i et sprint. Ofte angivet i story points eller tidsenheder, som kan sammenholdes med estimater på opgaver i Backloggen. Page 38 of 69

39 5.2 Udfordringer ved brug af Scrum I dette afsnit sammenlignes og diskuteres udvalgte emner fra de afholdte interviews samt eksisterende forskning Resultat af interviews De fire interviews afspejler, at Scrum bruges på forskellig vis i disse organisationer og at der i nogle tilfælde er så store udfordringer, at det kan diskuteres, om det overhovedet giver mening at bruge Scrum som udviklingsmodel. Thomas nævner f.eks., at det i forbindelse med integrationsprojekter er vanskeligt at lave en fornuftig backlog med veldefinerede opgaver, fordi disse projekter ofte består af mange afhængigheder (TBE). Set i den kontekst kunne Kanban måske være en bedre løsning, da man stadig opnår fordelene ved at være tæt på opgaverne med et visualiseret overblik, men ikke bliver bremset af de rigide regler i Scrum mht. ændringer af opgaver i et Sprint (Boeg, 2011). Et emne, som er vanskeligt at håndtere i Scrum, er fejlhåndtering (Kniberg, 2006; Marchenko & Abrahamsson; BLH). Specielt, når der opstår bugs i systemer, som allerede er taget i brug og det udviklende Scrumteam også skal løse fejlen, bliver det problematisk, fordi det er vanskeligt at planlægge med sådanne opgaver, da man ikke ved hvornår de opstår. Bugs bliver af naturlige årsager, ofte prioriteret højt dvs. at de normalt skal løses i det indeværende Sprint, hvilket får indflydelse på nyudviklingen og de øvrige aktiviteter i Sprintet. Løsningen kan være en særskilt serviceafdeling til at tager sig af disse problemer (TBE). Men denne løsning vil ofte kræve en organisation af en vis størrelse, da det kræver en del ressourcer at afsætte personale alene til fejlhåndtering Tilpasning af Scrum I følge den eksisterende Scrumforskning lader det til, at Scrummetoden eller metodikken i årenes løb, har udviklet sig til et framework (Hossain et al., 2009). At metoden er blevet til et framework appellere i sagens natur til tilpasninger, men der er delte meninger om, i hvilken udstrækning dette er tilladt. Om Scrum kan ændres? og er der herefter stadig tale om Scrum? Kniberg citerer Schwaber og skriver: In Ken Schwaber s words, Scrum is not a methodology, it is a framework. What that means is that Scrum is not really going to tell you exactly what to do (Kniberg, 2006, s.5). Men han skiver også selv, at Scrum skal tilpasses individuelt: The strength and pain of Scrum is that you are forced to adapt it to your specific situation (Kniberg, 2006, s.5). Myllerup skiver i sin oversættelse af The Scrum Guide at: Page 39 of 69

40 Scrum er ikke en proces eller en teknik til udvikling af produkter, men nærmere en ramme, inden for hvilken man kan anvende forskellige processer og teknikker (Myllerup, 2010, s.3). Det fremgår også af Myllerups oversættelse, at Scrum er funderet i teorien om empirisk proceskontrol og understøtter iterativ softwareudvikling. Frameworket består af et sæt af metoder og regler, som bl.a. omfatter møder og artefakter, der har til formål at optimere forudsigelighed og kontrollere risici (Myllerup, 2010). I flg. ophavsmændene selv er tilpasningerne mulige, men så er der ikke længere tale om Scrum: Scrum s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum (Sutherland & Schwaber, 2011, s.15). Ken Schwaber skriver tydeligt i sin bog The Enterprise and Scrum at man ikke bør ændre Scrum: "Do not change Scrum. Scrum isn't a process that you modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products. It is your canary in a coal mine. Whenever people change Scrum, it's because they have run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to your enterprise. If you allow this to happen, you will have just lost Scrum's primary benefit" (Schwaber, 2007, s.7). I ovenstående citat argumenterer Schwaber for, at hvis man finder det nødvendigt at ændre eller tilpasse Scrum, er det et tegn på, at noget andet er galt og man bør derfor starte med at analysere og rette fejlen. Men hvis ovennævnte er sandt, hvorfor er der så alligevel mange, som tilpasser metoden? Hvordan mapper den oprindelige Scrummetode egentlig til de mange projekter, hvori den bruges? Scrum er uden tvivl en meget benyttet metode, men det er nok ikke fordi den i alle tilfælde benyttes præcis efter bogen (Schwaper og Sutherland s). En anden grund kunne være, at man har fokus på de relevante opgaver, og at man motiverer udviklerne ved at give dem medbestemmelse og kun planlægger udviklingen et par uger frem, ud fra den agile betragtning om, at virkeligheden nok alligevel ænder sig undervejs. Man kunne formode at en del, som i Unifeeders tilfælde, ikke bruger rigtig Scrum, når det kommer til stykket, men i stedet bruger en fornuftig projektmodel, hvor man kalder møder og artefakter det samme som i Scrum. En årsag hertil kan være at et projekt eller organisation ikke matcher the sweet spot et begreb som Kruchten har introduceret: The sweet spot mirrors the kinds of projects that the method designers had in mind when they constructed the first Agile methods. It is unsurprising that projects in the sweet spot benefit from the application of methods such as Scrum and XP (Hoda et al., 2010, s.84). Dvs. at en metode ikke passer alle kontekster lige godt, hvilket ikke nødvendigvis er ensbetydende med, at metoden ikke kan bruges. Der er bare behov for tilpasning (BLH; TBE; SRT; HFI). We found that our participants follow many Scrum and XP practices without adapting them. Where participants did adapt practices, we found the modification Page 40 of 69

41 stems from the fact that the projects do not sit within this sweet spot (Hoda et al., 2010, s.84). Det vil derfor være nærliggende at justere metoden, så den passer til den aktuelle kontekst, hvilket sandsynligvis er det, som er foretaget i ovennævnte tilfælde. Herved opstår de i afsnit omtalte Scrum-Buts. Men i modsætning til Schwaber argumenterer Jurgen Appelo for, at det er tilpasningerne, der giver Scrum værdi: ScrumButs Are the Best Part of Scrum (Appelo). Dette udsagn begrunder han på følgende vis:..because optimal behavior is a function of internal structure and external environment, the real optimal method always depends on the team's structure and environment (Appelo). Altså at tilpasning er en nødvendighed for at opnå den optimale metode. Men man skal naturligvis passe på, at Scrum-but undtagelser ikke bliver en undskyldning for ikke at løse eventuelle dybereliggende problemer. Det er heller ikke alle, der er af den opfattelse at Scrum er enestående i sine principper. Rising & Janoff argumentere for, at Scrum bygger på Barry Boehm s Spiral model: The essential ideas behind the spiral model are exactly the same as those in Scrum - just speeded up! (Rising & Janoff, 2000, s.32). Fig. 20. Barry Boehm s Spiral model ( Page 41 of 69

42 Spiralmodellen har måske været en inspirationskilde bag flere af de agile metoder omtalt i afsnit 1.2, idet det er en af de første modeller, der er baseret på en iterativ fremgangsmåde. Der er afgjort visse ligheder mellem Spiralmodellen og Scrum mht. iterativ tilgang med faseinddeling/sprint. Men Spiralmodellen indeholder nogle andre elementer end Scrum - som f.eks. risikoanalyse og tests (Fig. 20), og den stiller ikke så mange krav mht. ceremonier, artefakter og roller som Scrum gør. Hvis Scrum skulle være en omskrivning af spiralmodellen, ville det så gøre en forskel, hvis man ikke kaldte sin udviklingsmetode for Scrum, men i stedet lavede en liste med opgaver og features, som skulle udvikles og herefter udvalgte de vigtigste af dem, som man vurderede, var realistiske at afvikle indenfor en kortere aftalt periode og så mødtes hver dag til en lille snak om, hvordan det stod til med projektet? Det ville det nok ikke i den forbindelse. Men om udeladelse af elementer fra Scrum vil få konsekvenser for et projekts gennemførsel eller sucess, vil kræve en del yderlig forskning og resultatet vil sikkert være meget afhængig af det enkelte projektets konteks. Man kunne argumentere for, at Scrum i ovennævnte tilfælde er blevet brugt på den måde, som Rising & Janoff beskriver, nemlig at Scrum bare er en omskrivning af Spiral modellen (Rising & Janoff, 2000). Men iflg. Schwarber ville ovennævnte ikke være Scrum. Men hvad er det, der gør Scrum til Scrum? Er det de omtalte artefakter, roller og ceremonier eller er det kravet om et eksekverbart produkt ved udgangen af hvert sprint? Scrum er tiltænkt agil softwareudvikling, hvor deltagerne i mindre teams selv vælger blandt opgaverne og forpligter (commitment) sig til at levere disse ved Sprintets afslutning (Sutherland & Schwaber, 2007). I disse tilfælde arbejder teamet ofte som en selvstyrende gruppe. Sammenholdt med teamets engagement, har det en motiverende effekt på teamet, som Birte også oplever der kan gå sport i at nå opgaverne, hvis man er kommet bagefter (afsnit 5.1.1). I nogle tilfælde varetages rollen som Scrum Master i stedet af en projektleder (SRT; HFI) og der er i højere grad tale om et arbejdsleder/arbejdstager forhold, hvilket ikke helt harmonerer med metodes grundtanke om self-motivated teams (Sutherland & Schwaber, 2007, s.87). Men det kan måske hænge sammen med, at der kan være stor forskel på deltagernes kompetencer som Birte nævner alle skal kunne se sig selv i sprintet (afsnit 5.1.1). Dvs. at ikke alle udviklere kan påtage sig alle opgaver. Hos Unifeeder er det af samme årsag projektlederne, som prioriterer og tildeler opgaverne, men det er dog stadig op til udviklerne selv at tilrettelægge deres abejde. Ovenstående er eksempler på emperi, hvor Scrum ikke helt rammer the sweet sport. Svaret på ovennævnte spørgsmålet: hvad der gør Scrum til Scrum, er derfor, at det er helheden i metoden. Dvs. at alle elementer fra Scrum frameworket skal være repræsenteret i de enkelte implementeringer før, at man kan sige, at det er Scrum, man anvender. Denne antagelse er i overensstemmelse med ophavsmændenes definition af Scrum i The Scrum Guide og i sidste ende er det denne definition, som er gældende (Sutherland & Schwaber, 2011). Dette betyder dog ikke, at Scrumelementerne ikke med fordel kan bruges enkeltvis og i mange forskellige sammenhænge men der er i såfald ikke tale om Scrum. Page 42 of 69

43 5.2.3 Hvad gør Scrum så populær? I forbindelse med softwareudvikling er Scrum formodentlig blevet populær, fordi metoden er baseret på effektive projektledelsesprincipper, som f.eks. fælles mål, synlighed, opgavefokus, opfølgning osv. principper, der er meget formaliserede i Scrum. Både Henrik og Svend giver også udtryk for, at de ser et stort potentiale i de enkelte delelementer, som Scrum består af og at det ikke er nødvendigt, at anvende hele metoden (HFI; SRT). Men at delelementer kan anvendes uafhængigt, da det lader til at Scrum består af elementer, som kan bruges i forbindelse med andre projekttyper end softwarekonstruktion (Nyboe et al., 2009). Grunden til populariteten er formodentlig også, at metoden bygger på nogle grundlæggende projektstyrings- og ledelsesprincipper, som bl.a. detaljeret planlægning, hyppig opfølgning og motiverende arbejdsformer, hvor udviklerne eller teamet selv har stor indflydelse på tilrettelæggelsen af arbejdet: We chose Scrum as it has a focus on day to day project management and is the most widely adopted agile project management method (Hossain et al., 2009, s.175). Ud fra ovenstående citat kan man aflede, at der også er en tendens til at følge en trend og bruge andres gode erfaringer. Umiddelbart er det vanskeligt at afgøre, om Scrum også fungerer i projekter, hvor man ikke benytter metoden helt efter forskriften. Men ud fra de fire interviews i dette studie tyder det på, at det er muligt, og jeg mener også, at der i Scrum indgår elementer, som er brugbare i mange andre sammenhænge, hvor konteksten ikke lige matcher the Sweet spot for metoden. Derfor er det også vigtigt, uanset om der er tale om Scrum eller ej, at processen understøttes af et digitaliseret værktøj, som kan sikre data og hjælpe udvikleren med at bevare overblikket Brug af Scrum værktøjer I forbindelse med Scum har man behov for et værktøj til at styre processen og der er stor forskel på de værktøjer, der bruges til at understøtte Scrum og agil udvikling. De spænder fra lavpraktiske lister og Post-it sedler, som udelukkende håndteres manuelt, til avancerede digitaliserede systemer. Et af de mest centrale værktøjer er Scrum Boardet. Det er ofte benyttet og kan være struktureret på mange forskellige måder. Scrum Boardet bruges både som et diskussionsmedie Det interaktive Scrum Board (Alexandra) og som en visuel projektoversigt visual pulse board, hvor det synliggør status og eventuelle problemer: It is easy to see when the participants have a problem and reserve a separate meeting discussing that problem (Ericsson et al., 2011, s.8). Det er normalt omkring Scrum Boardet, at et projektteam samles i forbindelse med Daily Scrum og Sprint Planning. Her kan boardet bl.a. være med til at højne kvaliteten i diskussionerne: After the implementation of visual pulse board the quality of discussions at the weekly follow-up meetings have solidly increased compared to before when they were realized in an office (Ericsson et al., 2011, s.8). Page 43 of 69

44 Der synes dog at være en sammenhæng mellem de valgte løsninger og den empiriske kompleksitet, de bruges i. For eksempel fungerer lavpraktiske løsninger bedst i projekter, hvor hele Scrum teamet er samlet, hvorimod udvikling med distribuerede og globaliserede teams stiller højere krav til systemerne, da kommunikation over distancer og tidszoner er vanskeligere. Iflg. Hossain et al s review er det også ineffektive værktøjer, der fremhæves som en af udfordringerne i forbindelse med Globaliseret udvikling: Lack of effective collaborative tools, global task boards, suitable bug and issue trackers, globally accessible backlog tool are also reported to be challenging factors (Hossain et al., 2009, 179). Lack of tools and insufficient infrastructure support may also make use of Scrum practices in GSD difficult (Hossain et al., 2009, s.182). De fremhæver også hvilke værktøjer, der er nødvendige i denne sammenhæng: GSD projects that consider using Scrum need a wide range of tool support. Tools may include communication, collaborative, project management, issue tracking, bug tracking, globally accessible backlog, and burn down chart etc (Hossain et al., 2009, s.181). Derudover hævder de også, at man på et tidligt tidspunkt i sådanne projekter bør etablere de nødvendige værktøjer til at supportere processen: We found the practice: proactive resource management helps ensure that a Scrum team has the necessary tools and skills to support their Scrum practices in distributed settings (Hossain et al., 2009, s.181). A distributed Scrum team also needs to be supported by various tools for project management, backlog management, tracking issues, and so on (Hossain et al., 2009, s.182). Ved det tidligere omtalte OpenMeeting om distribueret Scrum og Agil udvikling brugte alle, der deltog i Tools debatten på GeekNight, da også digitaliserede systemer til at understøtte Scrum, hvorimod mine interviews samt andre (Kniberg, 2006) hovedsagligt brugte lavpraktiske værktøjer. Ovennævnte viser, at der findes et behov for digitaliserede værktøjer, som kan understøtte fleksibel brug af Scrum i forbindelse med agil softwareudvikling, herunder distribuerede og globaliserede teams. Her vil det specielt være Scrum Boardet, som bør understøttes. Men i den forbindelse stilles der store krav til arkitektur og design, idet lokale teams ofte foretrækker lavpraktiske løsninger (Alexandra) og en digitaliseret løsning skal være modificerbar nok til at kunne understøtte forskellig struktur/inddeling og brug. Registreringer af f.eks. tidsforbrug, opgaveestimering og restestimering /færdighedsgrad, som er ukorrekte er i bedste fald ubrugelige, men kan i værste fald være direkte vildledende og føre til forkerte konklusioner i forbindelse med retrospektive analyser. Hvis ovennævnte håndteres i administrative systemer, som ikke er synkroniseret med Scrumprocessen eller på anden måde er for usikre eller omstændige, så teammedlemmerne ikke er motiverede for at benytte dem korrekt, kan dette ligeledes være en kilde til fejl. Derfor skal de administrative oplysninger om tidsforbrug, estimater, opgavestatus og færdighedsgrader helst indgå som en naturlig del af Scrum processen dvs. de Page 44 of 69

45 skal understøttes i de værktøjer og artefakter, som man ellers benytter (f.eks. Scrum Board og Backlogs). Nøgleordene er synlighed, brugervenlighed, fleksibilitet og modificerbarhed. Registrering og tilgang til administrative data, kan f.eks. forgå både fra PC og Scrum Board. Page 45 of 69

46 6 Generisk Scrum prototype I de følgende afsnit vil jeg argumentere for, hvilke kvaliteter og funktioner, der er relevante i et Scrumsystem, som kan understøtte Scrumprocessen. For at få afklaret hvilken funktionalitet et Scrumsystem skulle håndtere, lavede jeg, på baggrund af de afholdte interviews og artikler om Scrum, en mocup prototype af et Scrumsystem, som kunne præsenteres for informanterne. Til prototype blev der eksperimenteret med forskellige mockup tools som f.eks. lumzy ( og Balsamiq ( men ingen af værktøjerne virkede overbevisende, så valgte faldt i stedet på Powerpoint, fordi det var lettere at bruge og opfyldte de samme behov mht. tekst og grafiske elementer. 6.1 Systemkrav De arkitektoniske drivers var, som tidligere beskrevet i afsnit 4.3, usability og modifiability, da disse kvalitetsattributter er de mest relevante i et generisk Scrumsystem, som kan understøtte atypisk brug af Scrum. Målet var nemlig at tilbyde et system, som kunne tilpasses og anvendes i forbindelse med atypisk Scrum af en bred målgruppe, uden at det ville være nødvendigt at ændre i koden. Herved adskilder dette system sig fra de i kapitel 3 beskrevne systemer. Mht. værktøjer har Sutherland & Schwaber også anbefalinger om, hvorledes Scrumsystemer bør understøtte processen. "tools should track tasks completed by developers and work remaining. They provide more detailed and useful data than time sheets, which should be avoided. Timesheets are extra overhead that do not provide useful information on the state of the project, and are de-motivating to developers" (Sutherland & Schwaber, 2007, s.82). Det var derfor også et mål for systemet at understøtte Scrum processen på en intuitiv måde, således at de administrative funktioner håndteres, som en naturlig del af flowet og derved kræver så lidt ekstra tid af brugerne som muligt. Designet skulle derfor virke motiverende for brugerne, da det gerne skulle lette opgavehåndteringen i forhold til den manuelle proces, med små opgavesedler og tidsforbrug som efterfølgende skal registreres i et it-system. Fokus for prototypen har derfor været at tilbyde en letvægtsudgave af et Scrumsystem, hvor konfigurationen bl.a. styrer de grafiske elementer, som f.eks. Scrum Boardet. Det er hensigten, at der på Boardet kun findes de nødvendige komponenter, så det virker overskueligt så brugerne bevarer overblikket. Inspirationen hertil har været apps til Smart phones, Pads og mobile enheder, som pga. små skærme og touch interaktion, stiller krav til det grafiske design, mht. en simpel opbygning med store komponenter, som f.eks. knapper og tekstfelter. Det samme gælder for Scrumsystemet, hvor målet er kun at vise de komponenter, som er relevante i den aktuelle kontekst. Page 46 of 69

47 Omdrejningspunktet er de visuelle elementer i form af et digitaliseret Scrum Board med opgaver, som typisk vil være der, hvor de daglige registreringer foretages f.eks. i forbindelse med Daily Scrum. Ud fra opgavernes placering på Scrum Boardet, estimater og den resterende tid kan systemet holde styr på, om det er opnåeligt at få løst alle opgaver i sprintet og markere de lavest prioriterede opgaver, som er i fare for ikke at blive afsluttet i indeværende Sprint Funktionalitet Systemet understøtter alle artefakterne i Scrum: User Story, Backlogs, Sprint og Burndown Chart. Backloggen håndteres på samme måde som i flere eksisterende systemer, hvor Product Owner eller en projektleder opretter User Stories med beskrivelser af ønsket funktionalitet og prioritet. Den funktion foretages ved en almindelig PC og er derfor uintersant i denne forbindelse, da den ikke stiller specielle krav mht. design og interaktion. Men det er muligt at tilgå systemet fra forskellige PC er, hvor f.eks. Product Owner, projektleder og bruger kan håndtere User Stories, Tasks etc. på mere traditionel vis vha. tastatur og mus. Kernefunktionaliteten i systemet er som i andre Scrumsystemer opgavehåndtering i form af User Stories og Tasks af forskellige karakter, som i dette tilfælde skifter status afhængig af deres aktuelle placering på Scrum Boardet. Når en Task eller User Story flyttes på Scrum Boardet skifter den status til den status, der er tilknyttet det felt, den flyttes til (Fig. 21). Fig. 21. Task 1 flyttes fra In Progress til Done. Status og felter sættes op i den aktuelle konfiguration af Systemet, og hver flytning logges. Ved tryk på Submit knappen gemmes alle opgaveflytninger og ændringer i en database. De kan herefter benyttes til at opdatere Backlogs og senere indgå i Sprint Review eller retrospektiv analyse. Altså et nyttigt værktøj til analyse i forhold til en lavpraktisk løsning med Post-it sedler, som f.eks. samles sammen og noteres i et regneark. Page 47 of 69

48 Men som udgangspunkt bør Tasks kun relatere til en User Story eller være enkeltstående i form af bugs eller ændringer af f.eks. teknisk karakter, som ikke direkte er tilknyttet en User Story. Det kunne f.eks. være refactoring af koden pga. arkitektoniske ændringer. I min løsning kan man oprette Tasks direkte fra en User Story, hvorved der skabes en relation mellem Task og User Story. Når en bruger trykker på T feltet i en User Story (Fig. 22) åbnes et Task vindue (Step 1), hvor den nye Task automatisk har fået et nyt nummer (#2) samt en reference til den tilhørende User Story (#4). Brugeren kan herefter vælge en kategori f.eks. Feature, samt indtaste øvrige oplysninger så som prioritet, titel, opgavebeskrivelse og tidsestimat. Ved at trykke på OK knappen lukkes Taskvinduet igen og oplysningerne valgt iht. konfigurationen, kan ses i det nye Taskobjekt på Boardet (Step 2), som placeres lige under den tilhørende User Story. Fig. 22. Oprettelse af Task fra User Story. Det vil dog heller ikke kræve ret store ændringer at tilføje den samme funktionalitet på Taskobjekterne og skabe en relation mellem to af disse. Derved understøttes samme funktionalitet, som beskrevet af Rubart & Freykamp (2009). Mht. registrering af fremdrift for User Stories og Tasks findes der to typer: 1. Forbrugt tid, som angiver hvor mange udviklingstimer, man har brugt på de enkelte opgaver. 2. Restestimat, som angiver hvor mange udviklingstimer, der skal bruges for at afslutte en opgave. Valg af registreringsmetode kan aftales for hvert enkelt projekt og vil typisk afhænge af et projekts kontekst eller et teams arbejdsmåde. Man kan også vælge helt at lade være og f.eks. kun registrere om en opgave er løst eller ej. Det afhænger af konfigurationen. Page 48 of 69

49 Et scenario hvor man registrer tid kunne se således ud. I figur Fig. 23 flyttes en Taks fra In Progress til Done (Step 1). Når Taskobjektet slippes i Done, åbnes automatisk et vindue (Step 2), hvori brugeren kan angive det brugte antal tidsenheder. Når brugeren trykker på OK knappen lukkes vinduet og de registrerede tidsenheder gemmes. Fig. 23. Flytning af Task med tidsregistrering. Ved at inkorporere tidregistrering i flytning af Tasks og User Stories bliver to opgave i stedet til én (flytning af sedler og tidsregistrering). Man sikre derved, at tidsregistreringen er fortaget, når dette sker i forbindelse med Daily Scrum, samt at Burndown Chartet er retvisende. En anden fordel kan være at eventuelle problematiske Tasks bliver synlige tidligere i Sprintet og kan diskuteres i teamet. Denne funktionalitet vil f.eks. give nogle fordele hos Unifeeder i forhold til den eksisterende løsning, hvor tidsregistrering foretages i et andet system, hvilket er hovedårsagen til, at man ikke benytter Burndown Charts Pervasive interaktion Et digitaliseret Scrum Board skal kunne kommunikeres med interaktivt uden brug af eksterne enheder, som tastatur eller mus, hvis det skal være brugbart, ellers er der kun tale om en almindelig PC med en forstørret skærm. Til at opfylde dette ønske findes flere interaktionsmuligheder og teknologier. Den mest oplagte teknologi er Touch-screens, som er store trykfølsomme skærme i stil med dem, man bruger i smart phones, bare meget større. En anden mulighed er Smart boards, som består af et white board, som belyses af en projektor. Det fungerer ved, at boardet overvåges af et antal kameraer, som sammen med en PC, fortolker de handlinger, der foretages på boardet og agerer herefter. Begge Page 49 of 69

50 løsninger er blevet meget udbredte de seneste år og de gør det muligt at manipulere med visuelle objekter direkte på skærmen uden behov for tastatur eller mus. En anden og mere eksperimentiel løsning er brug af QR tags i stil med den Alexandra Instituttet arbejder med, som er beskrevet i afsnit Stemmegenkendelse er også en interaktionsmulighed, som bla.a har været brugt inden for hospitalsverdenen (Hansen, 2004). Set i forhold til Scrumsystemet kunne et scenario være at deltageren taler direkte til Scrum Boardet og f.eks. siger command, new task hvorefter systemet åbner et vindue til oprettelse af en task og herefter indsætter de oplysninger, som deltagerne kommanderer, f.eks. category, bug, prioiry, 110, Title, error in login osv. Problemet med denne teknologi er, at den er mindre anvendelig i sociale situationer, idet baggrundsstøj i forbindelse med Daily Scrum, hvor hele teamet står tæt samlet foran Scrum Boardet og taler sammen, kan påvirke resultatet. Ligeledes er det en udfordring, at systemet skal kunne genkende stemmerne for hele teamet og helst også hvis de er forkølede eller af andre årsager, har stemmeforandring. Gestusgenkendelse, hvor brugerens bevægelser opfanges af et webcam eller en håndholdt enhed med et accelerometer og omsættes til handlinger, kunne også være en mulig interaktionsform. Men teknologien er i forbindelse med et Scrumsystem ikke så praktisk, da den er bedst egnet til faste kommandoer som eksempelvis: gem, luk og åben. For at kunne erstatte et tastatur i forbindelse med indtastning af tekst, som der vil være brug for i et Scrumsystem, vil man være nødsaget til at oversætte bestemte fagter til faste sætninger eller ord, hvilket formodentlig ikke vil være særlig anvendeligt, da der i så fald vil blive mange fakter at huske. Alternativt skulle man have en bevægelse for hvert bogstav. Men det ville nok blive for besværligt og langsomt i forhold til et tastatur på en trykfølsom skærm. Hvis Scrum Boardet skal holde styr på, hvem der gør hvad, er det også nødvendigt at systemet kan genkende, hvem der flytter (har løst) en opgave. Den optimale løsning vil i dette tilfælde være, at systemet genkender brugeren ved boardet intuitivt, uden at brugerne skal foretage sig noget særskilt. Dette kunne f.eks. håndteres vha. RFID tags eller anden kortrækkende trådløsenhed, der udsender et signal, som fortæller, hvem brugerne er. Men en af udfordringerne er antallet af deltagerer (5-9) og afstanden til Scrumboardet, som normalt er forholdsvis kort 1-2 meter. Der er altså risiko for, at systemet modtager forkerte data eller misfortolker signalerne, hvilket kan medføre, at registreringerne bliver forkerte. En bedre løsning kunne i såfald være ansigtsgenkendelse vha. webcam, som genkender og registrere den bruger, som står nærmest. Den simpelste løsning vil dog stadig være, at lade hver bruger logge sig ind, umiddelbart inden han/hun foretager sig noget ved boardet. Men denne løsning kræver mere disciplin, da det er en risikofaktor at brugerne glemmer at logge sig ind og kommer til at registrerer på hinandens opgaver. Page 50 of 69

51 6.1.3 User Stories Herunder beskrives et eksemple på Scrumsystemets funktionalitet og virkemåde vha. Mockup Walk Through. Eksemplet er baseret på en trykfølsom skærm og manuel bruger login. Funktioner, som bruges i forbindelse med opsætning og oprettelse af f.eks. brugere, projekter, sprints og User Stories vil ikke blive beskrevet, da disse operationer ikke har nævneværdig indflydelse på den daglige brug af systemet. Eksempel: Opret en Task ved Scrumboardet I firma SoftProd A/S, hvor man benytter version 1.0 af det nye GeniScrumsystem skal Per, Hanne, Ole og Bent til at starte på dagens Daily Scrum møde. De er i gang med at udvikle en webløsning til en E-bogs butik. Det er dag 1 i Sprint 2 og de samles foran den store trykfølsommeskærm, som viser det nye sprint med de opgaver (Fig. 24), Scrum Masteren Bent har lagt i dette sprint iflg. aftale med Product Ownerne fra E-bogs butikken. Fig. 24. Scrum Board ved dag 1 for Sprint nr. 2. Ole bemærker, at Bent mangler en opgave under User Story #2 Fjern vare fra indkøbskurv og da det er Ole, der skal kode varehåndteringen, går han hen til Boardet og trykker på sit eget ikon på skærmen (Fig. 25). Herved angiver Ole, at det nu er ham, som skal logges som den aktive bruger. Page 51 of 69

52 Fig. 25. Aktivering af bruger. Herefter trykker Ole på T knappen i User Story #2 (Fig. 26) for at oprette en ny task under denne User Story. Fig. 26. Tryk på T tast for at oprette en Task. Systemet kreere nu en ny opgave (Taskobjekt) og åbner et vindue, hvori Ole kan indsætte de nødvendige oplysninger (Fig. 27). Derudover kan Ole flytte rundt på vinduet ved at placere en finger på vinduet og trække det, hvorhen han ønsker det. Page 52 of 69

53 Fig. 27. Scrum Board med default Taskvindue. Opgaven indeholder allerede et Task nummer, reference til den tilhørende User Story samt en katogori Feature, som SoftProd har sat til at være default. Ole vil lige tilføje en Titel så han trykker på Title og systemet åbner et tastatur på skærmen (Fig. 28) Fig. 28. Scrum Board med Taksobjekt og Tastatur Page 53 of 69

54 Efter indtastning af titlen trykker Ole tastaturet væk ved at trykke på tastatur knappen i nedereste højre hjørne på tastaturet (Fig. 28). Inden han gemmer opgaven, vil han dog lige angive at udviklingen forventes at tage 2 timer, så han trykker på Remaining på Task vinduet, hvorefter systemet åbner et nyt numerisk tastatur (Fig. 29). Fig. 29. Scrum Board med Taksobjekt og Numerisk tastatur. Ole er nu færdig med sin opgaveoprettelse og lukker derfor de to vinduer ved, at trykke på OK knapperne i vinduerne (Fig. 29). Herefter opretter systemet en ny lille task under User Story #2 med Oles indtastninger og Ole som User (Fig. 30). Page 54 of 69

55 Fig. 30. Scrum Board med Oles nye Taksobjekt. Hvis Ole ønsker at arbejde på opgaven med det samme, kan han flytte den nye Task ved at trække den med en finger fra ToDo til In Progress. Til sidst mangler han bare at trykke på Submit for at gemme sine ændringer. Hvis han har behov for det, kan han også efterfølgende logge på fra sin egen PC og rette sine opgaver derfra. Han undgår derved at spilde tid ved det korte Daily Scrum møde. Fordelen ved ovenstående løsning er, at deltagerene kan oprette opgaver direkte på boardet, hvilket er en digitaliseret erstatning af den lavpraktiske procedure, hvor deltagerne udfylder Post-it sedler med tusch og klistre dem op. Brugerne skal ikke hen til en PC og det hele sker i én proces, idet opgaverne ikke efterfølgende skal registreres i et system for at kunne indgå i eksempelvis Burndown Charts Interfaces Herunder nævnes de vigtigeste komponenter som systemet håndterer via grænseflader som ikke indgår i det daglige system. Opsætning: Håndtering af teammedlemmer/brugere (navn, login, osv) Statushåndtering (navn/titel) Håndtering af tasktyper/farver, story points og tidsenheder Page 55 of 69

56 Backlog: Registrering af User Stories og Tasks Oprettelse af Sprints Tilknytning af User Stories og Tasks til Sprints Scrum Board: Grafisk inddeling af kategorier (To Do, In Progress, Done, osv.) Handlinger (angivelse af aktuel bruger, undo) Oprettelse af Tasks og evt. User Stories (quick insert, estimering) Flytning af Tasks (med tracking af bruger og statusskift) Restestimering (tid/procent) Øvrige visninger: Sprint Burndown Velocity beregning Objekter Project - overordnet opgave, som består af et antal leverancer, som udvikles i løbet af et eller flere sprints. Attributter: ID autogenereret nummer Titel projektnavn Description beskrivelse af projektet Start date dato for hvornår projektet starter End date dato/deadline for hvornår projektet forventes afsluttet Udover overstående vil der naturligvis være en del andre oplysninger for projektet, som f.eks. interessenter, budget osv. Men de er ikke interessante i denne forbindelse. Sprint en periode indenfor hvilken et antal User Stories skal realiseres. Attributter: ID autogenereret nummer Titel navn eller nummer Velocity antal estimerede story points eller tidsenheder Start date dato for hvornår et sprint starter Page 56 of 69

57 End date dato for hvornår et sprint slutter User Story en beskrivelse af afgrænset funktionalitet, som ønskes af Product Owner. User Stories kan nedbrydes i arbejdsopgaver (Tasks). En User Story kan tilknyttes flere Sprints, hvis den f.eks. ikke kan løses inden for et enkelt og har laveste status ift. tilknyttede tasks. Attributter: ID autogeneret nummer Titel navn eller kort beskrivelse Priority som angiver vigtigheden af funktionaliteten Deadline dato hvor alle opgaver vedr. en User Story skal være færdige Sprint tilknytning til et Sprint Estimate den totale estimerede tid/story points Description detaljerede oplysninger om funktionalitet Task del af en User Story eller enkeltstående opgave, som f.eks. et teknisk problem eller bug, som skal løses, men ikke kan kobles til en bestemt User story. Attributter: ID autogenereret nummer Titel navn eller kort beskrivelse Type - En taks skal kunne have en type (new feature, bug, unplaned osv) Priority som angiver vigtigheden af opgaven Deadline dato, hvor opgaven skal være færdig Sprint tilknytning til aktuel Sprint eller arves fra en tilknyttet User story User tilknytning til den/de brugere som har/skal arbejde på opgaven Estimate tid Residual estimat resterende tid Realisert tid summen af registreret tid brugt på opgaven For at man visuelt lettere kan skelne mellem forskellige opgavetyper, kan typen f.eks. være afgørende for, hvilken farve opgaven har på Scrum Boardet: Afgrænsninger Sikkerhed af teknisk eller datamæssig karakter, som f.eks. roller, interaktion og netværk, vil ikke blive håndteret, da dette ikke er fokus for denne mockup prototype. Retrospektiv vil der ligeledes ikke blive fokuseret på, da dette er en proces, som ikke kræver megen brugerfunktionalitet af systemet. Det ville dog være naturligt at logge relevante indtastninger og ændringer, så man Page 57 of 69

58 efterfølgende kan udtrække historisk data til understøttelse af en retrospektiv analyse. 6.2 Præsentation af prototypen Jeg har i første omgang valgt at basere interaktionen i prototypen på en trykfølsom skærm, da dette var den mest oplagte interaktionsform. De andre interaktionsformer, som beskrives i afsnit vil kunne tilføjes efterfølgende, idet brugsmønsteret og funktioner vil være ens kun interaktionen og konfigurationen vil være forskellig. Da mockup protypen var færdig, blev de simulerede skærmbilleder printet ud og præsenteret for Birte, Thomas og Henrik med henblik på at få deres feedback på layout/grafik, interaktion og funktionalitet, samt om systemet ville være brugbart i deres kontekst. Selve præsentationen foregik ved, at de fire mockup skærmbilleder (Appendiks 9.3 figur. Fig Fig. 34) blev bredt ud på et bord, hvorefter de blev præsenteret og forklaret mht. funktioner, afhængigheder, samt beskrivelse af hvorledes prototypen skulle ses i en kontekst. For eksempel hvordan felter og typer kunne konfigureres og hvordan et Scrum team kunne diskutere opgaverne på Scurm Boardet, oprette nye og skiftes til at flytte rundt på dem. Derudover blev et par af de vigtigeste scenarier som f.eks. flytning af en opgave med tidsregistrering samt oprettelse af User Stories og Tasks simuleret ved, at pege på vinduerne i den rækkefølge, som de ville blive præsenteret for brugeren. 6.3 Feedback på prototypen I forbindelse med præsentationen blev kommentarer fra informanterne noteteret dels direkte på papirskærmbillederne, hvis de var tæt knyttet til disse og dels på en notesblok, hvis der var tale om mere overordnede synspunkter. To af præsentationerne blev også optaget på et lydmedie, hvilket ikke var til megen nytte, da det efterfølgende var uklart, hvilke skærmbilleder, der blev diskuteret. Hvis visuelt udstyr som video eller webcam havde været tilgængeligt, kunne jeg have med fordel have anvendt billedeoptagelser i stedet. Birte var positiv overfor prototypen og påpegede, at værktøjet skulle være overskueligt og nemt at bruge. Hun mente, at begge disse kvaliteter blev understøttet i prototypen og at den ved første øjekast indeholdte de nødvendige oplysninger og funktioner. Derudover sammenholdte hun prototypen med erfaringer fra JIRA. Mht. forbedringer nævnte Birte, at de hos Logica havde brug for et felt mere til impeded, som et variationspunkt, der i prototypen kunne håndteres via konfiguration (Grafisk inddeling af kategorier afsnit 6.1.4). Både Thomas og Henrik var også positiv overfor prototypen og mente, at funktionaliteten ville være en brugbar erstatning for en lavpraktisk løsning. Page 58 of 69

59 Enkelte Use Cases blev gennemgået f.eks. oprettelse og flytning af Tasks og User Stories, og i den forbindelse diskuterede vi, hvordan sammenhængen mellem disse skulle håndteres. For eksempel kunne der være behov for at gruppere Tasks under den tilhørende User Story. Derudover blev håndtering af estimater og tidsregistrering diskuteret f.eks. om dette skulle ske ved Scrum Boardet i forbindelse med Daily Scrum. Fordelene ville være at registreringerne sammen med restestimater kunne bidage med aktuelle oplysning til status på Burndown Chartet. Ulemperne kunne være, at det kan virke demotiverende, at skulle registrere et tidsforbrug offentligt, som var større end forventet. Men her kunne det så måske afsløre, om en opgave var rigtigt forstået eller om udvikleren havde brug for hjælp. Et par mangler som tilføjelse af User Story nummer, titlen på tasks samt en funktion til registrering af forbrugt tid blev identificerede og tilføjet på prototypen. Page 59 of 69

60 7 Konklusion I dette studie er forskellig brug af Scrum blevet analyseret ud fra interviews med erfarne Scrumbrugere fra fire virksomheder, hvor man i en årrække har brugt Scrum. De fire afholdte interviews er blevet analyseret og diskuteret på baggrund af eksisterende forskning. I alle fire tilfælde blev det belyst, at Scrum bruges i forskellige tilpassede varianter afhængig af virksomhedernes empiri og deres projekters kontekst. Med afsæt i denne erkendelse er betydningen af afvigelser i forhold til den oprindelige Scrummetode og hvilke konsekvenser dette har for itprojektledelse blevet diskuteret. Både interviews og forskning viste også tydeligt, at der findes et behov for digitaliserede værktøjer, som kan understøtte atypisk brug af Scrum. I den forbindelse stilles der store krav til arkitektur og design, mht. intuitivt, overskuelighed og nem tilgængelighed, hvis lokale Scrumteams skal foretrække en en digitaliseret løsning frem for de nuværende simple lavpraktisk løsninger. I modsætning til lokale teams er distribuerede teams i højere grad afhængige af digitaliserede løsninger, hvilket bekræftes af både eksisterende forskning samt Geek Night Event. Med inspiration fra forskellige softwarearkitektoniske principper indenfor Modifiability og Useability er en mockup prototype på et system til generisk understøttelse af Scrumprocessen blevet udviklet. Prototypen blev derefter præsenteret for informanterne fra de fire interviews og kommenteret af disse. Derudover er den blevet diskuteret ud fra komparativt materiale, som dels bestod af eksisterende produkter og dels af alternative løsninger, der understøtter Scrum. Prototypen adskilder sig fra flere af de eksisterende løsninger ved at den fra starten af er enkel, innovativ og samtidig kan understøtte Scrum i varierende kontekster. Dette studie bidrager derved med ny viden inden for forskningen om udbredelsen og brug af Scrum, speciel hvad angår etablerede løsninger, som med tiden er blevet tilpasset lokale forhold. Dette område er tilsyneladende ikke vel belyst i den eksisterende forskning. Et studie baseret på fire tilfældige eksempler kan naturligvis ikke give mere end et fingerpeg om i hvilket omfang Scrum benyttes i modificeret form, taget i betragtning af, hvor stor en udbredelsen Scrum har. Men alle informanterne har givet udtryk for, at de bruger Scrum i varierende omfang og på forskellig vis og det må derfor antages, at der ikke er tale om enkeltstående tilfælde, men at denne trend vil kunne genfindes i mange andre virksomheder. Sprøgsmålet er så, hvor mange der i virkeligheden bruger Scrum, når man ser bort fra alle de tilpassede variationer? Ud fra dette studie må det formodes, at der findes en del andre eksempler, hvor brug af enkeltstående elementer fra Scrum, er blevet et synonym for Scrum. Men det vil kræve en større undersøgelse at kunne bekræfte denne tendens. På baggrund af ovenstående må det anbefales, at der forskes videre inden for området, da Scrum er meget udbredt indenfor agil softwareudvikling og der trods flere eksisterende produkter, stadig er et stort potentiale i optimering af digitaliserede værktøjer, som intuitivt understøtter processen vha. de nye teknologier, som har vundet indpas inden for de seneste år. I den forbindelse bør der forskes yderligere i brug af eksempelvis Scrum Boards samt eksperimenteres Page 60 of 69

61 med de i afsnit omtalte teknologier for at afklare om teknologierne er brugbare i en Scrumkontekst. En stor tak til Anne, Birte, Erik, Henrik, Line, Svend og Thomas for deres medvirken og hjælpsomme bidrag til dette studie. Page 61 of 69

62 8 Referencer (agilemanifesto) ( ) (alexandra) (Appelo) nyheder-2012/sider/interaktiv-scrumboard.aspx ( ) Jurgen Appelo scrumbuts-are-the-best-part-of-scrum.html ( ) (Bass et al., 2006) Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice, 2nd Edition, Addison Wesley (kap. 4 5) (BLH) Interview med Birte, Logica BLH.m4a (45:14) (Boeg, 2011) (Ericsson et al., 2011) (Hansen, 2004) (HFI) Jesper Boeg, 2011 Priming Kanban Trifork Agile Excellence Mini Book Series Evelina Ericsson, Joakim Lilliesköld, Liv Marcks von Würtemberg, 2011 Visual Planning Applied in a Research Environment Thomas Riisgaard Hansen, 2004 Interacting with pervasive computer systems How to support physical, mobile, collaborative and distributed work Interview med Henrik, Unifeeder HFI.m4a (27:17) (Highsmith & Cockburn, 2001) Jim Highsmith & Alistair Cockburn, 2001 Agile Software Development: The Business of Innovation, SOFTWARE MANAGEMENT (Hoda et al., 2010) (Hossain et al., 2009) (Kniberg, 2006) (Kvale, 2006) (Marchenko & Abrahamsson) Rashina Hoda, Philippe Kruchten, James Noble, 2010 Agility in Context, OOPSLA/SPLASH 10 Emam Hossain, Muhammad Ali Babar & Hyeyoung Paik, 2009 Using Scrum in Global Software Development: A Systematic Literature Review, Fourth IEEE International Conference on Global Software Engineering Henrik Kniberg, 2006 Scrum and XP from the Trenches, Crisp Kvale, Steinar, 2006 En introduktion til det kvalitative forskningsinterview Kap. 4: Kvalitativ forskning i videnskab og i praksis Artem Marchenko og Pekka Abrahamsson "Scrum in a Multiproject Environment: An Ethnographically-Inspired Case Study on the Adoption Challenges" Page 62 of 69

63 (Myllerup, 2010) (Nyboe et al., 2009) (Overhage et al., 2010) (Pries-Heje, 2011) Bent Myllerup, 2010 Oversættelse af The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game af Ken Schwaber and Jeff Sutherland Freja Bange Nyboe, Louise Smed Møller, Tobias Bornakke Jørgensen & Jens Jarl Broe Scrummer to scrum or not to scrum Sven Overhage, Sebastian Schlauderer, Dominik Birkmeier, Jonas Miller, 2010 On the Developer Adoption of Scrum: A New Acceptance Model for Agile Methodologies Working Papers on Information Systems, Sprouts Lene Pries-Heje & Jan Pries-Heje, 2011 Why Scrum works (Rayhan & Haque, 2008) Syed H. Rayhan and Nimat Haque, 2008 Incremental Adoption of Scrum for Successful Delivery of an IT Project in a Remote Setup (Rising & Janoff, 2000) Linda Rising & Norman S. Janoff, 2000 The Scrum Software Development Process for Small Teams IEEE SOFTWARE (Rubart & Freykamp, 2009) Jessica Rubart & Frank Freykamp, 2009 Supporting Daily Scrum Meetings with Change Structure (Salo & Abrahamsson, 2008) O. Salo & P. Abrahamsson, 2008 Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum (scrum) ( ) (SRT) Interview med Svend, Alexandra Instituttet SRT.m4a (47:07) (Sutherland & Schwaber, 2007) Jeff Sutherland, Ken Schwaber, 2007 The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process (Sutherland & Schwaber, 2011) Jeff Sutherland, Ken Schwaber, 2011 The Scrum Guide (Schwaber, 2007) (TBE) Ken Schwaber, 2007 The Enterprise and Scrum Interview med Thomas, Vertica TBE.m4a (44:59) (Tomm, 1988) Tomm, Karl., 1988 Family Process, Vol. 27 Intending to ask lineal, circular, strategic, or reflexive questions? (1-15) (Uy & Rosendahl, 2008) Edward Uy & René Rosendahl, 2008 "Migrating From SharePoint to a Better Scrum Tool" Agile 2008 Conference Page 63 of 69

64 9 Appendiks 9.1 Interviewguide 1. Hvad er Scrum for jer og hvorfor bruger I Scrum? 2. Hvor længe har I brugt Scrum? 3. I hvilket omfang bruger I Scrum (alle projekter)? 4. Hvilke af følgende artefakter bruger I og hvordan bruger I dem? a. Product Backlog b. Release Burndown chart c. Sprint Backlog d. Sprint Burndown charts 5. Bruger i andre artefakter, som ikke er blevet nævnt? 6. Hvilke artefakter, synes du, er de vigtigste eller mest anvendelige? 7. Hvilke krav har I til elementerne i Backloggen? (fx detaljeringsgrad) 8. Hvordan håndterer I funktionalitet? (fx Use Cases/Stories, ønsker) 9. Hvilke af følgende møder afholder I og hvor meget tid bruge I på dem: a. Release Planning b. Sprint Planning c. Daily Scrum d. Sprint Review e. Sprint Retrospective 10. Bruger i andre? 11. Hvor har I tilpasset jeres Scrum metode? (hvorledes og hvorfor?) 12. Bruger I altid en fast struktur eller kan det variere? 13. Har jeres måde at bruge Scrum på ændret sig, siden det blev introduceret? 14. Hvilke programmer bruger I til at understøtte Scrum? 15. Bruger I et Scrum board? (hvis ja, hvordan og hvordan er det opbygget?) 16. Synes du Scrum er effektivt? (hvorfor/hvorfor ikke?) 17. Hvilke fordele og ulemper er der ved at bruge Scrum? 18. Hvis du havde mulighed for det, ville du så ændre jeres Scrum løsning? 19. Kunne du evt. tænker dig at bruge noget andet i stedet? Page 64 of 69

65 9.2 Interviewskema Emner Birte, Logica (BLH) Thomas, Vertica (TBE) Hvad er Scrum? Erfaring med Scrum Omfang af brug Artefakter: - Product Backlog - Release Burndown Chart - Sprint Backlog - Sprint burndown chart Andre artefakter Møder/- ceremonier: - Release Planning - Sprint Planning - Daily Scrum - Sprint Review - Sprint Retro- En metode med nogle overordnede rammer [01:28] En metode [01:36] Henrik, Unifeeder (HFI) Et projektstyringsredskab [00:35] Svend, Alexandra Instituttet (SRT) En model med et arsenal af værktøjer [35:45] 3 år 4 år [01:51] 1½ år [02:28] Flere år [02:50] Udvikling og support Overfor kunder og internt [00:30] Hele porteføljen af Itprojekter [01:45] Ja [02:45] Ja [05:29] Ja [05:20] Ja [08:25] Projekter, hvor det er brugbart [13:43] Ikke besvaret Ikke besvaret Nej [10:46] Ja, i nogle tilfælde [21:15] Ja [02:47] Ja [05:30] Ja [05:20] Ikke besvaret Ja [02:49] Scrum tavle [02:50] retrospektive smiley [07:34] Skabeloner til løsningsbeskrivelser [21:09] Ja, halvårligt [21:50] eller hver 3. måned [22:25] Ja [25:40] men bruges ikke altid [29:45] Scrum Board [03:10] Bruges ikke altid Nej [10:46] Excel ark med tidsforbrug [13:05] Scrum Board white board med post-it sedler [21:37] Ja, i nogle tilfælde [21:15] Liste over delprojekter [08:01] Interessent- og risikoanalyser [11:30] Projektstyringsark [13:05] Ikke besvaret Nej [13:38] Ikke besvaret Ja [04:24] Ja [15:10] Ja [13:45] Ja [08:50] Ja [02:52] Ikke besvaret Ja, [13:48] Ikke altid Ikke besvaret Ja [21:30] Ja [13:50] Ja [08:45] Ja [07:20] Ikke besvaret Ja [13:20] Ikke besvaret Page 65 of 69

66 spective Andre møder/- ceremonier Bruges Timeboxing Bruges fast sprintlængde Ja, kundemøder [03:05] Ja [23:11] Daily Scrum 15 min. [09:28] Sprintplanlægning 1,5 time [23:37] Retrospektiv 1,5 time [24:26] Ja, opsamlingsmøde [27:13] Nej, er forskelligt fra projekt til projekt [19:18]. Ja, pre-planning [13:54] Nej Ja, koordineringsmøder efter aftale [09:42] Ikke besvaret Nej [02:59] Nej, [20:55] Ja, 14 dage [17:18] Nej, 1, 2 eller 4 uger [09:24] Tidsestimering Opgavefordeling Backlog krav Bruges prototyping Bruges pairprogramming Metodetilpasninger Timeestimering med velocity [13:17] Frivillig, men der skal være opgaver til alle [04:26] Prioriteret rækkefølge [06:24] Opgaver skal være estimerede [12:20] Ja, iflg. aftale med kunden [35:59] Ja, i sjældne tilfælde [40:36] Ja, ved projekter som ikke er nyudvikling. Trækker en person ud til support [03:19] Features tidsestimers på sprintmøderne sammen med kunden [26:13] Ikke besvaret Ja, jo bedre beskrivelse, jo bedre teknisk løsning [10:50] Projektlederens ansvar [12:41], men diskutere løsninger med udviklerne [17:12]. Ja [12:19] Bestemmes af projektlederne [14:44] Ja, af projektlederen evt. i samråd med deltagerne [22:48] Ikke besvaret Ja, i stor stil [37:38] Ikke besvaret Ja [23:56] Ja, i enkelt tilfælde [37:02] Ja, afhængig af projekttypen [02:30] Der er ikke krav om et eksekverbart system efter hvert sprint [21:30] Ikke besvaret Ja, [04:48] Bruger ikke User Stories [09:20] Ikke besvaret Ja, bruger ikke Daily Scrum, men mødes efter behov [05:55] Backloggen består bl.a. delprojekter [08:25] Fast sprint struktur Nej, er tilpasset de enkelte grupper Nej, kan være både 2 og 3 ugers sprint Ja, 2 ugers sprint Nej [07:50] Page 66 of 69

67 Systemunderstøttelse Om Scrum [00:40] f.eks. 3 ugers sprint [11:23] 2-3 udviklings sprint og et test sprint [33:40] JIRA til opgave styring [18:09], bugs og kommunikation med kunder [20:35] Sprint backlog håndteres i et regneark [29:15] Separat tidsregistreringssystem [18:55] - Fordele Fællesskab og tilhørsforhold til opgaverne [39:01] Synlige opgaver [43:40] - Ulemper Indkomne ikke planlagte opgaver kan ødelægge et sprint [43:44] Mest anvendelige elementer - Ændringsforslag [20:55] Fastsættes ofte sammen med kunden iht. ønsker og opgaven [21:53] [31:50] Ressource- og opgavestyring håndteres i Excel [07:45] [24:58] Burndown Charts laves ligeledes udfra Excel [29:30] Brugte tidligere Ekstra net [32:15] Udviklere, projekt folk og produkt er i sync [35:50] Agilmetode og kommunikation via Daily Scrum [36:07] Egner sig mindre godt til integrationsprojekter [39:30] Lotus Notes til projektopgaver/ backloggen [05:20] og tidsregistrering [12:19] Excel til sprint planlægning [06:10] Kontinuerlig opfølgning [23:32] Skaber fælles forståelse [24:03] Manglende synlighed udadtil for Produkt Owners [25:50] Scrum tavle [08:52] Ikke besvaret Daily Scrum [20:58] Bedre support håndtering [31:26] Strukturere Scrum lidt bedre til integrationsprojekter [39:10] Scrum Board [21:37] Brug af User Stories [10:07] Brug af Burndown Charts [17:06] Teknologisk bedre Scrum Board løsning [21:55] Tidsregistreringssystem [13:01] Projektstyringsark i Excel med timeregistrering og omkostninger [13:05] [18:05] Sharepoint ved distribueret udvikling [26:07] En god model som viser flowet i processen [37:02] Stiller artefakter til rådighed [37:13] Skaber fokus på opgaverne som motiverende forpligter og skaber fremgang [44:50] Man skal ikke følge processen blindt den skal tilpasses [39:03] Ikke besvaret Ikke besvaret Page 67 of 69

68 9.3 Mockup Prototype Nedenestående er mockup skærmbillder fra prototypen inklusive forklaringer. Fig. 31. Scrum Boardet. Fig. 32. Task- og forskellige interaktionsvinduer. Page 68 of 69

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

Kvalitetssikring og agile udvikling

Kvalitetssikring og agile udvikling Kvalitetssikring og agile udvikling Gæsteforelæsning for dsoftark-e10 på Århus Universitet Dagsorden Hvem er jeg og hvad er min baggrund i test og agile? Hvad kan I forvente? Agile og scrum Kvalitetssikring

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste

Det vigtigste først! Dette er måske den vigtigste bog der nogensinde er skrevet om agile vs. vandfald. Muligvis fordi det vel stadig er den eneste WTF? Thomas Schou-Moldt, Miracle A/S (siden 2008) Arkitekt, udvikler, teknisk projektleder, mv. Indtil videre afsonet lidt over 20 år i branchen, ingen udsigt til prøveløsladelse tsm@miracleas.dk, 5374

Læs mere

Projektarbejde med scrum- metoden

Projektarbejde med scrum- metoden Projektarbejde med scrum- metoden Indhold Indhold... 1 1 Indledning... 2 2 Roller og terminologi i scrum... 3 Opgavestilleren... 3 Scrum Masteren... 3 Projektgruppen... 3 Sprint... 3 3 Møder... 3 Planlægningsmødet...

Læs mere

Objektorienterede metoder

Objektorienterede metoder Objektorienterede metoder Gang 12. Kvalitet i større systemer Evt.: Ekstremprogrammering (XP) Dette materiale er under Åben Dokumentlicens, se http://www.sslug.dk/linuxbog/licens.html projektopgaven i

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

Product Ownerens værktøjskasse

Product Ownerens værktøjskasse Product Ownerens værktøjskasse 26. marts 2014 Jesper Thaning, agil praktiker & partner i BestBrains Agenda Vurdering af behov (værdi og risiko) Nedbrydning Det visuelle Afklaring af User Stories PO i større

Læs mere

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive

Læs mere

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. It-håndbogen Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Noter fra workshop med OS2

Noter fra workshop med OS2 Noter fra workshop med OS2 Exported on 12/10/2017 Noter fra workshop med OS2 1 Table of Contents 1 Table of Contents... 2 2 Overordnede noter:... 3 3 Beslutninger og noter til de enkelte kandidater:...

Læs mere

Behavior Driven Test and Development. ebay Classifieds

Behavior Driven Test and Development. ebay Classifieds Behavior Driven Test and Development ebay Classifieds Det kommer til at handle om User Stories agil udvikling Fokus på adfærd Gherkin syntaks Afgrænsning: Sælger ikke BDD Gør os ikke til eksperter i det

Læs mere

Visual Studio Team System. Team Build en grundpille i søgen efter it-projektproduktivitet?

Visual Studio Team System. Team Build en grundpille i søgen efter it-projektproduktivitet? Visual Studio Team System Team Build en grundpille i søgen efter it-projektproduktivitet? Agenda: Introduktion Hvorfor Automatiseret Build Microsoft Team Build Rapportering/Data warehouse Commentor A/S

Læs mere

Agile metoder og kontrakter

Agile metoder og kontrakter Agile metoder og kontrakter 24. september 2009 Myllerup Consult, Hasseltoften 11, 8361 Hasselager +45 2834 9084, info@myllerup.dk Images: Disney Dream Works Indhold Scrum introduktion Processens ritualer

Læs mere

extreme Programming Kunders og udvikleres menneskerettigheder

extreme Programming Kunders og udvikleres menneskerettigheder extreme Programming Software Engineering 13 1 Kunders og udvikleres menneskerettigheder Kunder: At sætte mål og få projektet til at følge dem At kende varighed og pris At bestemme softwarefunktionalitet

Læs mere

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN

DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN DANMARKS NATIONALBANK LEVER AGIL UDVIKLING STADIG I DET VILDE VESTEN Sikkerhed og Revision 2013 Martin Falk-Hansen & Svend M Er sikkerhed og revision et problem i agil udvikling? Og i givet fald hvorfor?

Læs mere

sådan kører vi processen

sådan kører vi processen VERTICA sådan kører vi processen Når du som ny kunde skal have udviklet en ny e-handelsløsning eller app til din virksomhed, kan det være svært at overskue den proces, der følger. Hos Vertica har vi været

Læs mere

Lær jeres kunder - bedre - at kende

Lær jeres kunder - bedre - at kende Tryksag 541-643 Læs standarden for kundetilfredshedsundersøgelse: DS/ISO 10004:2012, Kvalitetsledelse Kundetilfredshed Overvågning og måling Vejledning I kan købe standarden her: webshop.ds.dk Hvis I vil

Læs mere

Nexus Guide. Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling. Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.

Nexus Guide. Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling. Udarbejdet og vedligeholdt af Ken Schwaber og Scrum. Nexus Guide Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.org August 2015 Indholdsfortegnelse Nexus overblik... 2 Formålet

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Scrum er ikke Agilt! Jesper Boeg, Agile Coach, Developer, Lean Consultant, jbo@trifork.com. Januar 19, 2010

Scrum er ikke Agilt! Jesper Boeg, Agile Coach, Developer, Lean Consultant, jbo@trifork.com. Januar 19, 2010 Scrum er ikke Agilt! Jesper Boeg, Agile Coach, Developer, Lean Consultant, jbo@trifork.com Januar 19, 2010 Først lidt reklame fortrifork Udvikling Public Finance IPhone Proces Scrum kurser Workshops Coaching

Læs mere

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele

Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele LEVERANCE 2.1 Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele Konceptet beskriver, hvordan koden forvaltes, og hvordan

Læs mere

Metodehåndbog til VTV

Metodehåndbog til VTV Metodehåndbog til VTV Enheden for Velfærdsteknologi KØBENHAVNS KOMMUNE SOCIALFORVALTNINGEN 1. udgave, maj 2017 Kontakt og mere info: velfaerdsteknologi@sof.kk.dk www.socialveltek.kk.dk 1 Indholdsfortegnelse

Læs mere

Hvornår er dit ERP-system dødt?

Hvornår er dit ERP-system dødt? Hvornår er dit ERP-system dødt? Ved du egentlig hvornår dit ERP-system er dødt? Vi giver dig vores bud på, hvilke tegn du skal holde øje med, så du kan handle i tide. Hvornår er dit ERP-system dødt? At

Læs mere

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering Digital Kommuneplan Kravsspecifikation gennem brugerinvolvering Indhold Introduktion Afklaring af behov: Hvad skal digitale kommuneplaner kunne? Udarbejdelse og test af løsning: Hvordan skal digitale kommuneplaner

Læs mere

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4 IT opgave Informationsteknologi B Vejleder: Karl Navn: Devran Kücükyildiz Klasse: 2,4 Dato:03-03-2009 1 Indholdsfortegnelse 1. Indledning... 3 2. Planlægning... 3 Kommunikationsplanlægning... 3 Problemstillingen...

Læs mere

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT

SYNOPSIS 1. SEMESTER 2013 E-CONCEPT DEVELOPMENT SYNOPSIS E-CONCEPT DEVELOPMENT INDHOLD 1. JONAS KROGSLUND HVEM ER JEG?... Side 3 2. PRÆSENTATION & MOTIVATION... Side 3 3. FAGLIGE UDFORDRINGER & PROBLEMER... Side 4 3.1 SCRUM...... Side 4 3.2 KRAVSPECOFIKATION...

Læs mere

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

Læs mere

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47)

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) 1 Projektevaluering Caretech Innovation Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) Deltagere/partnere: Systematic A/S Regionshospitalet Randers og Grenå Caretech Innovation Dato: 8.

Læs mere

DANSK IT ARKITEKTUR CERTIFICERING

DANSK IT ARKITEKTUR CERTIFICERING DANSK IT ARKITEKTUR CERTIFICERING Practitioneruddannelsen System Arkitekt Practitioner Kompetencebeskrivelse Version 2018.02.08 DANSK IT www.dit.dk/ark Copyright All Rights Reserved DANSK IT ARKITEKTUR

Læs mere

Usability-arbejde i virksomheder

Usability-arbejde i virksomheder Usability-arbejde i virksomheder Jan Stage Professor, PhD Forskningsleder i Information Systems (IS) og Human-Computer Interaction (HCI) Aalborg University, Department of Computer Science jans@cs.aau.dk

Læs mere

Introduktion til projekter

Introduktion til projekter Introduktion til projekter v. 1.0.3 Introduktion I dette materiale ser vi overordnet på, hvad projekter egentlig er, hvordan de er skruet sammen og hvilke begreber, som relaterer sig til projekter. Vi

Læs mere

Dynamisk hverdag Dynamiske processer

Dynamisk hverdag Dynamiske processer Dynamisk hverdag Dynamiske processer Verden og hverdagen er kompleks og i konstant forandring - og derfor skal den måde vi arbejder med projekter og implementering være enkel og forandringsparat. Agil

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

Materiale til kursus i brugercentreret design

Materiale til kursus i brugercentreret design Materiale til kursus i brugercentreret design Sønderborg 2014 Indledning Hvorfor brugercentreret design? Fordi det giver god mening! Og fordi det medvirker til at kvalificere koncepter, undervisningsaktiviteter,

Læs mere

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen

IT Service Management (ITIL) i en agil verden. Lars Zobbe Mortensen IT Service Management (ITIL) i en agil verden Lars Zobbe Mortensen Om Lars It service management konsulent ITIL ekspert og underviser Projekt leder PRINCE2 agile og underviser Tidligere leder for udviklings

Læs mere

Kom godt i gang med Digital Transformation via din Microsoft ERP-platform

Kom godt i gang med Digital Transformation via din Microsoft ERP-platform INDLÆG 16 DIGITAL TRANSFORMATION Kom godt i gang med Digital Transformation via din Microsoft ERP-platform Shila Henriksen 03.11.2015 CGI Group Inc. 2015 Shila Henriksen Uddannelse Civiling, Software Eng.

Læs mere

Studieordning for kandidatuddannelsen i informationsteknologi ved IT-Universitetet i København, Digital design og interaktive teknologier

Studieordning for kandidatuddannelsen i informationsteknologi ved IT-Universitetet i København, Digital design og interaktive teknologier Studieordning for kandidatuddannelsen i informationsteknologi ved IT-Universitetet i København, Digital design og interaktive teknologier Studieordning af Indhold Indledning Kapitel 1. Uddannelsens titulatur,

Læs mere

Redskaber og inspiration til udarbejdelsen af en VelfærdsTeknologiVurdering

Redskaber og inspiration til udarbejdelsen af en VelfærdsTeknologiVurdering Denne vejledning indeholder konkrete redskaber og inspiration som kan anvendes når du som medarbejder skal udarbejde en VelfærdsTeknologiVurdering. Redskaber og inspiration til udarbejdelsen af en VelfærdsTeknologiVurdering

Læs mere

Principper for digitalisering og ny teknologi i Brønderslev Kommune

Principper for digitalisering og ny teknologi i Brønderslev Kommune Principper for digitalisering og ny teknologi i Brønderslev Kommune v. 1.0 22032017 Godkendt i Økonomiudvalget Dette dokument beskriver Brønderslev kommunes 5 overordnede digitaliseringsprincipper: 1.

Læs mere

Agil softwareudvikling i praksis. v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S

Agil softwareudvikling i praksis. v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S Agil softwareudvikling i praksis v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S Thomas Schou-Moldt, Lead Architect Ansat i Miracle A/S (siden 2008) Arbejder som arkitekt / tech lead / teknisk projektleder

Læs mere

VÆRKTØJSKASSEN TIL INNOVATION OG ENTREPRENØRSKAB I UNDERVISNINGEN

VÆRKTØJSKASSEN TIL INNOVATION OG ENTREPRENØRSKAB I UNDERVISNINGEN VÆRKTØJSKASSEN TIL INNOVATION OG ENTREPRENØRSKAB I UNDERVISNINGEN LÆRINGSMÅL FOR INNOVATION OG ENTREPRENØRSKAB Tabellen på side 2 viser en række læringsmål for innovation og ud fra områderne: - Kreativitet

Læs mere

Automatisering Af Hverdagen

Automatisering Af Hverdagen Automatisering Af Hverdagen Programmering - Eksamensopgave 10-05-2011 Roskilde Tekniske Gymnasium (Kl. 3,3m) Mads Christiansen & Tobias Hjelholt Svendsen 2 Automatisering Af Hverdagen Indhold Introduktion:...

Læs mere

I det kommende afsnit vil vi løbende komme ind på de enkelte resultater og samtidig komme med bud på, hvordan disse kunne løses i fremtiden.

I det kommende afsnit vil vi løbende komme ind på de enkelte resultater og samtidig komme med bud på, hvordan disse kunne løses i fremtiden. Opsummeret Feedback Introduktion I dette dokument vil vi opsummere de mest relevante resultater, der kom fra begge de afholdte workshops. De mest relevante resultater var dem, der igennem begge workshops

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Jan-juni 2016 Institution UCH/ Handelsskolen Uddannelse Fag og niveau Lærer(e) Hold EUX Business IT B Lars

Læs mere

DSB s egen rejse med ny DSB App. Rubathas Thirumathyam Principal Architect Mobile

DSB s egen rejse med ny DSB App. Rubathas Thirumathyam Principal Architect Mobile DSB s egen rejse med ny DSB App Rubathas Thirumathyam Principal Architect Mobile Marts 2018 AGENDA 1. Ny App? Ny Silo? 2. Kunden => Kunderne i centrum 1 Ny app? Ny silo? 3 Mødetitel Velkommen til Danske

Læs mere

360 eworker. App en, der gør det endnu lettere at arbejde i 360 - Arbejd med sagsbehandlingsopgaver, dokumenter og information fra din ipad

360 eworker. App en, der gør det endnu lettere at arbejde i 360 - Arbejd med sagsbehandlingsopgaver, dokumenter og information fra din ipad 360 eworker App en, der gør det endnu lettere at arbejde i 360 - Arbejd med sagsbehandlingsopgaver, dokumenter og information fra din ipad 360 eworker - App en, der gør det endnu lettere at arbejde i 360

Læs mere

IT Support Guide. Indledning. Program: Microsoft Office Outlook 2007. Publikationsnr.: 281208.01.03. Udgivet af: Michael Spelling 2008

IT Support Guide. Indledning. Program: Microsoft Office Outlook 2007. Publikationsnr.: 281208.01.03. Udgivet af: Michael Spelling 2008 IT Support Guide Denne guide er hentet på www.spelling.dk Microsoft Office Outlook 2007 Program sprogver.: Guide emne: ENG (US) Opsætning af POP3 e mail accounts Publikationsnr.: 281208.01.03 Udgivet af:

Læs mere

Aktivitet: Du kan skrive et specialeoplæg ud fra punkterne nedenfor. Skriv så meget du kan (10)

Aktivitet: Du kan skrive et specialeoplæg ud fra punkterne nedenfor. Skriv så meget du kan (10) Aktivitet: Du kan skrive et specialeoplæg ud fra punkterne nedenfor. Skriv så meget du kan (10) 1. Det er et problem at... (udgangspunktet, igangsætteren ). 2. Det er især et problem for... (hvem angår

Læs mere

Bierhverv Ekstern Lektor på Institut for Ledelse. Uddannelse Cand. Oecon. Master i Organisationspsykologi PRINCE 2, Scrum-Master, Pædagogikum, etc.

Bierhverv Ekstern Lektor på Institut for Ledelse. Uddannelse Cand. Oecon. Master i Organisationspsykologi PRINCE 2, Scrum-Master, Pædagogikum, etc. Erfaring Direktør & konsulent Rosenmeiers Konsulenthus ApS Direktør ved Marselisborg Uddannelse & Management Business Manager ved ATTRACTOR Rambøll Management Udviklingschef ved ATTRACTOR Organisations

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Case til opgaven: Evaluering som belutningsmodel for forandring. Case til opgaven: Evaluering som beslutningsmodel for forandring.

Case til opgaven: Evaluering som belutningsmodel for forandring. Case til opgaven: Evaluering som beslutningsmodel for forandring. Case til opgaven: Evaluering som beslutningsmodel for forandring. Palle Ragn 1/6 Introduktion til casen Casen beskriver et forløb for implementering af et system for en af Stibo s kunder. Efter casen har

Læs mere

System Arkitekt Practitioner

System Arkitekt Practitioner System Arkitekt Practitioner Kompetencebeskrivelsee DISAC Danish IT Society s Architectural Certification DANSK IT 2012 1 IT arkitekt Practitioner System Arkitekt Denne certificering repræsenterer det

Læs mere

EVALUERING AF BOLIGSOCIALE AKTIVITETER

EVALUERING AF BOLIGSOCIALE AKTIVITETER Guide EVALUERING AF BOLIGSOCIALE AKTIVITETER Det er rart at vide, om en aktivitet virker. Derfor følger der ofte et ønske om evaluering med, når I iværksætter nye aktiviteter. Denne guide er en hjælp til

Læs mere

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur

Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur Cloud i brug Migrering af Digitalisér.dk til cloud computing infrastruktur 02 Indhold > Executive Summary............................................................... 03 Digitaliser.dk.....................................................................

Læs mere

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med.

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med. Ansøgning Yderligere bemærkninger til ansøgningen Det var fedt at rammerne var så åbne, som jeg så det var der kun to krav til projektet: Det skulle være open source og det skulle have det offentliges

Læs mere

Lær at tænke som en servicedesigner servicedesign kurser i København og Aarhus

Lær at tænke som en servicedesigner servicedesign kurser i København og Aarhus Lær at tænke som en servicedesigner servicedesign kurser i København og Aarhus Kursus: Servicedesign 1 Serviceydelser udgør en stor andel af samfundsøkonomien. Ny teknologi ændrer eksisterende serviceydelser

Læs mere

Guide til elevnøgler

Guide til elevnøgler 21SKILLS.DK Guide til elevnøgler Forslag til konkret arbejde Arbejd sammen! Den bedste måde at få de 21. århundredes kompetencer ind under huden er gennem erfaring og diskussion. Lærerens arbejde med de

Læs mere

Studieordning for masteruddannelse i software engineering ved IT-Universitetet i København

Studieordning for masteruddannelse i software engineering ved IT-Universitetet i København Studieordning for masteruddannelse i software engineering ved IT-Universitetet i København Studieordning af 1. august 2008 Revideret pr. 1.september 2014 Revideret pr. 19. august 2015 Indhold Indledning

Læs mere

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010. It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud Region Midtjylland 2010. 1 1 Indledning 1.1 Versionshistorie Version Dato Ansvarlig Status Beskrivelse 1.0 2010-05-04 HENSTI Lukket Definition

Læs mere

Workshops til Vækst. - Modul 3: Eksternt fokus. Indholdsfortegnelse

Workshops til Vækst. - Modul 3: Eksternt fokus. Indholdsfortegnelse Workshops til Vækst - Modul 3: Eksternt fokus Indholdsfortegnelse Workshops til Vækst... 1 Eksternt fokus... 2 Praktiske forberedelser... 3 Mentale modeller... 5 Indbydelse... 6 Program... 7 Opsamling

Læs mere

Pain Treatment Survey

Pain Treatment Survey Pain Treatment Survey Projektoplæg Projektoplæg til fælles udviklingsprojekt, i samarbejde mellem KLONK og smerteeksperter fra Sverige, Danmark og Norge www.klonk.dk Indholdsfortegnelse Baggrund... 2 Idé...

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Scrum guiden. Den ultimative guide til Scrum: Spillets regler. Oktober 2011. Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland

Scrum guiden. Den ultimative guide til Scrum: Spillets regler. Oktober 2011. Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Scrum guiden Den ultimative guide til Scrum: Spillets regler Oktober 2011 Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Indholdsfortegnelse Formålet med Scrum guiden... 3 Scrum overblik...

Læs mere

Andet oplæg til en model for Politisk lederskab af innovation i Furesø

Andet oplæg til en model for Politisk lederskab af innovation i Furesø Andet oplæg til en model for Politisk lederskab af innovation i Furesø Indhold: Hvorfor en innovationsmodel?...3 Hvordan definerer vi innovation i Furesø?...3 Principper for innovation...3 Innovationsmodellen

Læs mere

Proces orientering af IT organisationer (ITIL - implementering)

Proces orientering af IT organisationer (ITIL - implementering) Proces orientering af IT organisationer (ITIL - implementering) Af Lars Zobbe Mortensen Indholdsfortegnelse 1 Indledning... 3 1.1 Hvorfor bedst practice processer (f.eks. ITIL)?... 3 2 Beslutning om forandring...

Læs mere

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser BibDok En til at dokumentere effekt af bibliotekets er Guide til BibDok BibDok understøtter en systematisk refleksiv praksis. Det er derfor væsentligt, at I følger guiden trin for trin. 1. Sammenhæng mellem

Læs mere

Metoder og produktion af data

Metoder og produktion af data Metoder og produktion af data Kvalitative metoder Kvantitative metoder Ikke-empiriske metoder Data er fortolkninger og erfaringer indblik i behov og holdninger Feltundersøgelser Fokusgrupper Det kontrollerede

Læs mere

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund Det Nye Testamente lyd-app v. Stefan Lykkehøj Lund Indledning For nogle år siden, fik jeg Det Nye Testamente som lydbog på USB. I starten lyttede jeg en del med tiden blev det dog til mindre og mindre.

Læs mere

Planlæg din kommunikation

Planlæg din kommunikation Planlæg din kommunikation Dette er et værktøj for dig, som står over for en kommunikationsindsats vil sikre, at dine budskaber når frem vil kommunikere effektivt med medarbejderne vil gøre indtryk på dine

Læs mere

IFC Egenskaber. Mohammad Hussain Parsianfar s102951 BYG DTU

IFC Egenskaber. Mohammad Hussain Parsianfar s102951 BYG DTU Mohammad Hussain Parsianfar s102951 Indholdsfortegnelse 1 Introduktion... 3 1.1 Hvorfor er det interessant... 3 1.2 Formål... 4 2 Simplebim... 5 2.1 Præsentation af softwaren... 5 2.1.1 Brugergrænseflade...

Læs mere

Intelligent brugerinvolvering. Udvikling af en model til berigelse af afleveringsøjeblikket. Projekt støttet af DDB-puljen 2014

Intelligent brugerinvolvering. Udvikling af en model til berigelse af afleveringsøjeblikket. Projekt støttet af DDB-puljen 2014 Intelligent brugerinvolvering Udvikling af en model til berigelse af afleveringsøjeblikket Projekt støttet af DDB-puljen 2014 Silkeborg Bibliotek November 2014 Indhold Historik... 2 Arbejdsgruppen... 2

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Vejledning til opfølgning

Vejledning til opfølgning Vejledning til opfølgning Metoder til opfølgning: HVAD KAN VEJLEDNING TIL OPFØLGNING? 2 1. AFTALER OG PÅMINDELSER I MICROSOFT OUTLOOK 3 2. SAMTALE VED GENSIDIG FEEDBACK 4 3. FÆLLES UNDERSØGELSE GENNEM

Læs mere

GRAFISK WORKFLOW. Hjemmeside design til Chem-Tec Plating

GRAFISK WORKFLOW. Hjemmeside design til Chem-Tec Plating GRAFISK WORKFLOW Hjemmeside design til Chem-Tec Plating REDEGØRELSE Hvad går opgaven ud på Virksomheden Chem-Tec Plating, som specialisere sig i metallisk overfladebehandling, havde været igennem et generationsskiftet

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Aug 2016 - juni 2017 Institution UCH/ Handelsskolen Uddannelse Fag og niveau Lærer(e) EUX Business IT B Lars

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Et praktisk bud på hvordan man kan arbejde med driftsledelse og visuelle styringstavler

Et praktisk bud på hvordan man kan arbejde med driftsledelse og visuelle styringstavler Et praktisk bud på hvordan man kan arbejde med driftsledelse og visuelle styringstavler Motivation for at skrive artiklen er at dele erfaringer med driftsledelse som ledelsesdisciplin og brug af visuelle

Læs mere

Lightning Decision Jam. Ti enkle trin til at fastlægge fokus og realiserbare næste bedste skridt

Lightning Decision Jam. Ti enkle trin til at fastlægge fokus og realiserbare næste bedste skridt Lightning Decision Jam Ti enkle trin til at fastlægge fokus og realiserbare næste bedste skridt Lightning Decision Jam Lightning Decision Jam er en trin-for-trin proces, der hjælper teams til at identificere,

Læs mere

Kom godt i gang. Guide til at arbejde med det 21. århundredes kompetencer

Kom godt i gang. Guide til at arbejde med det 21. århundredes kompetencer 21SKILLS.DK CFU, DK Kom godt i gang Guide til at arbejde med det 21. århundredes kompetencer Arbejde med det 21. århundredes kompetencer Arbejd sammen! Den bedste måde at få det 21. århundredes kompetencer

Læs mere

Velkommen til den nye og forbedrede Dynamicweb 9

Velkommen til den nye og forbedrede Dynamicweb 9 Velkommen til den nye og forbedrede Dynamicweb 9 Effektive kundeoplevelser på tværs af alle kanaler med én integreret platform. Én platform dækker (alle) dine digitale behov Med Dynamicweb 9 får du adgang

Læs mere

En måling er bedre end 100 mavefornemmelser

En måling er bedre end 100 mavefornemmelser Test din virksomheds modenhed til at gennemføre projekter En måling er bedre end 100 mavefornemmelser Per Hartlev ph@whitebox.dk 10/3-2016 Søren T. Lyngsø 1984-1993 ABB 1993-2001 DELTA 2001-2014 Whitebox

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

GEONIS Vand. fact sheet. Planlæg, dokumentér og vedligehold

GEONIS Vand. fact sheet. Planlæg, dokumentér og vedligehold JUNE 2015 Planlæg, dokumentér og vedligehold er en effektiv fagspecialist løsning for planlægning, dokumentation og vedligeholdelse af et vand forsyningssystem. Data model supportere en række nationale

Læs mere

PRODUKTIONSSTYRING OG -PLANLÆGNING

PRODUKTIONSSTYRING OG -PLANLÆGNING PRODUKTIONSSTYRING OG -PLANLÆGNING Introduktion Er det egentlig præcist at tale om produktion når temaet er spiludvikling? For produktion dufter jo af faste procedurer, kendte milepæle, og definerede krav

Læs mere

Arbejdsformer i datalogiske forundersøgelser

Arbejdsformer i datalogiske forundersøgelser Arbejdsformer i datalogiske forundersøgelser Keld Bødker, Finn Kensing og Jesper Simonsen, RUC/datalogi Projektet foregår i et samarbejde mellem Danmarks Radio, H:S Informatik, WMdata Consulting A/S og

Læs mere

HIT projektet og KOS. Side 1 af 5

HIT projektet og KOS. Side 1 af 5 HIT projektet og KOS Dette projektgrundlag udgør aftalen for samarbejdet mellem HIT projektet og KOS frem til 31. januar 2005. Aftalen kan herefter genforhandles med henblik på eventuel forlængelse. 1.

Læs mere

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012

Harmoni. Med SAP PI. Når tingene går op i en højere enhed. Kort & Godt. January 2012 January 2012 3. årgang, nummer 1 Harmoni Med SAP PI Når tingene går op i en højere enhed Godt nytår! Vi er kommet ind i 2012 med fuld fart, og vi glæder os til et fortsat godt samarbejde med kunder og

Læs mere

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange

Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange Lean gammel vin på nye flasker SCKK Excellence om Lean og arbejdsgange 3. april 2006 Jørgen Kjærgaard Lean i historisk perspektiv en del af kvalitetstraditionen med TQM og Excellence 2 Toyota Production

Læs mere

Projektlederens guide til tilfredsstillende geoinformationsprodukter

Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide er udarbejdet på baggrund af projektet: MobilGIS til natur- og arealforvaltere en web-baseret prototype. Projektet

Læs mere

Shop Floor System til Microsoft Dynamics NAV* *Microsoft Dynamics NAV (Navision)

Shop Floor System til Microsoft Dynamics NAV* *Microsoft Dynamics NAV (Navision) Shop Floor System til Microsoft Dynamics NAV* *Microsoft Dynamics NAV (Navision) Et banebrydende system til planlægning og rapportering i produktionen. NAVEKSA s Shop Floor System anvendes til planlægning,

Læs mere

Analyse af værket What We Will

Analyse af værket What We Will 1 Analyse af værket What We Will af John Cayley Digital Æstetisk - Analyse What We Will af John Cayley Analyse af værket What We Will 17. MARTS 2011 PERNILLE GRAND ÅRSKORTNUMMER 20105480 ANTAL ANSLAG 9.131

Læs mere

Mogens F. Mikkelsen

Mogens F. Mikkelsen Læringsbehov afhænger af kompleksitet Forberedte spørgsmål fra deltagerne?! 5% tog sig tid til at sætte mål for udbyttet af dette seminar. Hvorfor gjorde de det? Hvorfor kun 5%? - og hvad gjorde de 95%

Læs mere

31/05/2012. Vejledning med flere vejledere et case til at starte diskussionen på vejledningskurser

31/05/2012. Vejledning med flere vejledere et case til at starte diskussionen på vejledningskurser Interaktion i ph.d.-vejledning Vejledning med flere vejledere et case til at starte diskussionen på vejledningskurser Sofie Kobayashi og Camilla Rump skobayashi@ind.ku.dk Dias 1 Tilgængelige diskurser

Læs mere

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen

Nye testteknikker fra ISTQB - direkte fra hylderne. Ole Chr. Hansen Nye testteknikker fra ISTQB - direkte fra hylderne Ole Chr. Hansen TestExpo 29. Januar 2015 Præsentation Ole Chr. Hansen Managing Consultant Fellow SogetiLabs Global Innovation Team Blog - http://ochansen.blogspot.com

Læs mere

Scrum er ikke Agilt! Jesper Boeg, Agile Coach jbo@trifork.com. 2. september, 2010

Scrum er ikke Agilt! Jesper Boeg, Agile Coach jbo@trifork.com. 2. september, 2010 Scrum er ikke Agilt! Jesper Boeg, Agile Coach jbo@trifork.com 2. september, 2010 Først lidt reklame fortrifork Udvikling Public Finance IPhone Proces Scrum kurser Workshops Coaching Verdens bedste konferencer

Læs mere

METODESAMLING TIL ELEVER

METODESAMLING TIL ELEVER METODESAMLING TIL ELEVER I dette materiale kan I finde forskellige metoder til at arbejde med kreativitet og innovation i forbindelse med den obligatoriske projektopgave. Metoderne kan hjælpe jer til:

Læs mere

Operationalisering af Agil udvikling. Implementering af Agile principper i dagligdagen vha. effektive værktøjer

Operationalisering af Agil udvikling. Implementering af Agile principper i dagligdagen vha. effektive værktøjer Operationalisering af Agil udvikling Implementering af Agile principper i dagligdagen vha. effektive værktøjer Indhold Den Agile bevægelse Praktiske udfordringer ved Agile og Lean projekter Værktøjer på

Læs mere

Agil-model versus V-model set i lyset af en testers dilemmaer

Agil-model versus V-model set i lyset af en testers dilemmaer Agil-model versus V-model set i lyset af en testers dilemmaer 1 Præsentation Foredragsholder Ane Clausen: Cand.Scient i Datalogi Københavns Universitet, Danmark Gift, 3 børn 25 års erfaring med IT: 12

Læs mere