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

Størrelse: px
Starte visningen fra side:

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

Transkript

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

2 Indholdsfortegnelse Formålet med Scrum guiden... 3 Scrum overblik... 3 Scrum framework... 3 Scrum teori... 4 Scrum... 6 Scrum Team... 6 Product Owner... 6 Development Team... 7 Scrum Master... 8 Scrum møder... 9 Sprintet... 9 Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective Scrum artefakter Product Backlog Sprint Backlog Inkrement Definition af Done Konklusion Anerkendelser Individer Historie Oversættelse Alike license of Creative Commons. Side 2

3 Formålet med Scrum guiden Scrum er et framework, der kan benyttes i udvikling og fastholdelse af komplekse produkter. Denne guide indeholder definitionen af Scrum. Definitionen består af Scrums roller, møder, artefakter og de regler, der binder disse sammen. Ken Schwaber og Jeff Sutherland udviklede Scrum. Denne Scrum guide er skrevet af og stillet til rådighed af dem. Sammen står de bag Scrum guiden. Scrum overblik Scrum (n): Et framework hvori mennesker kan adressere komplekse problemer samtidig med, at der fokusereres på produktivitet og kreativt leveres produkter med højest mulig værdi. Scrum er: Letvægtsramme Nem at forstå Ekstrem svær at beherske Scrum er et proces framework, der har været anvendt til at styre kompleks produktudvikling siden starten af 1990 erne. Scrum er ikke en proces eller en teknik til at bygge produkter; men skal mere ses som et framework, hvori man kan anvende forskellige processer og teknikker. Scrum udstiller, hvor det står dårligt til med en virksomheds effektivitet i produktstyring og udvikling, så der er mulighed for at forbedre sig. Scrum framework Scrum frameworket består af Scrum Teams og deres tilhørende roller, møder, artefakter samt regler. Hver komponent i frameworket har et specifikt formål og er essentiel for Scrums succes og brug. Specifikke strategier for at anvende Scrum frameworket i forskellige situationer er beskrevet andetsteds. Reglerne i Scrum sammenknytter møder, roller og artefakter samt styrer relationen og interaktionen mellem disse. Reglerne i Scrum er beskrevet undervejs i dette dokument. Alike license of Creative Commons. Side 3

4 Scrum teori Scrum er baseret på empirisk proces kontrol teori, eller empiri. Empiri definerer, at viden kommer fra erfaring og at tage beslutninger, baseret på hvad der er kendt. Scrum implementerer en iterativ, inkrementel tilgang til at optimere forudsigeligheden og at kontrollere risici. Tre grundstøtter er fundamentet for enhver implementering af empirisk proces kontrol: gennemsigtighed, inspektion og tilpasning. Gennemsigtighed Essentielle dele af processen skal være synlig, for dem der frembringer resultatet. Gennemsigtighed kræver, at disse dele overholder en fælles standard, så de der observerer processen har det samme syn på, hvad der observeres. Eksempel: Et fælles sprog skal anvendes af alle, når man taler om processen; og En fælles definition af Done 1 skal være delt, af dem der udfører arbejdet og den, der skal acceptere det udarbejdede produkt. Inspektion Brugere af Scrum skal ofte inspicere Scrum artefakter og fremdriften mod et mål for at identificere uønskede afvigelser. Inspektion bør ikke foregå så ofte, at det går ud over arbejdet. Inspektioner er mest nyttige, når de gennemføres nøjsomt af erfarne reviewere i tilknytning til det arbejde, der udføres. Tilpasning Hvis en reviewer beslutter, at et eller flere aspekter af en proces falder uden for de forventede grænser, og at det resulterende produkt vil blive uacceptabelt, så skal processen, eller det der produceres, justeres. En justering skal gennemføres, så snart det er muligt, for at forhindre yderligere afvigelser. Scrum har fire formelle muligheder for inspektion og tilpasning som beskrevet i afsnittet om Scrum møder. Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective 1 Se Definition af Done, s. 15. Alike license of Creative Commons. Side 4

5 Alike license of Creative Commons. Side 5

6 Scrum Scrum er et framework, der er struktureret til at understøtte kompleks produktudvikling. Scrum består af Scrum Teams og deres tilknyttede roller, møder, artefakter og regler. Hver komponent i frameworket tjener et bestemt formål og er afgørende for Scrums succes og brug. Scrum Team Scrum Teamet består af en Product Owner, et Development Team og en Scrum Master. Scrum Teamet er selvorganiserende og tværfagligt. Selvorganiserende teams vælger, hvordan de bedst kan udføre deres arbejde snarere end at blive instrueret af andre uden for teamet. Tværfaglige teams indeholder alle nødvendige kompetencer, for at de kan udføre arbejdet uden at være afhængige af andre uden for teamet. Team modellen i Scrum er designet til at optimere fleksibilitet, kreativitet og produktivitet. Scrum Teams leverer et produkt iterativt og trinvist, hvilket maksimerer mulighederne for feedback. Delleverancer af det færdige produkt sikrer, at en potentielt brugbar version af det fungerende produkt altid er til rådighed. Product Owner Product Owner er ansvarlig for at maksimere værdien af produktet og arbejdet i Development Teamet. Hvordan dette gøres, kan variere meget på tværs af organisationer, Scrum Teams og enkeltpersoner. Product Owner er den eneste person, der er ansvarlig for administration af Product Backloggen. Product Backlog administration omfatter: Klart udtrykte Product Backlog items. Ændring på rækkefølgen af Product Backlog items således, at de bedst opfylder mål og missioner. Sikrer værdien af det arbejde, Development Teamet udfører. Sikrer at Product Backloggen er synlig, transparent og klar for alle, og samtidig viser, hvad Scrum Teamet arbejder på som det næste; og Sikrer, at Development Teamet forstår Product Backlog items på det nødvendige niveau. Product Owner kan selv udføre ovenstående arbejde eller få Development Teamet til at gøre det, men Product Owner er altid ansvarlig. Product Owner er én person, ikke et udvalg. Product Owner kan repræsentere ønskerne fra et udvalg i Product Backloggen, men dem, der ønsker at ændre et Product Backlog items prioritet, skal overbevise Product Owner. For at Product Owner kan få succes, skal hele organisationen respektere hans eller hendes beslutninger. Product Owners beslutninger er synlige i indholdet og rækkefølgen af Product Alike license of Creative Commons. Side 6

7 Backloggen. Ingen har lov til at fortælle Development Teamet, at de skal arbejde ud fra andre krav, og Development Teamet må ikke agere efter, hvad andre siger. Development Team Development Teamet består af professionelle Development Team medlemmer, der udfører arbejdet ved at levere potentiel produktionsfærdig funktionalitet efter hvert Sprint. Det er kun medlemmer af Development Teamet, der kan bidrage til leverancen. Development Teamet er struktureret og bemyndiget af organisationen til at organisere og styre deres eget arbejde. Den resulterende synergi optimerer Development Teamets samlede produktivitet og effektivitet. Development Teamet har følgende karakteristika: De er selvorganiserende. Ingen (ikke engang Scrum Master) fortæller Development Teamet, hvordan de omformer Product Backloggen til leverancer af potentiel produktionsfærdig funktionalitet. Development Teamet er tværfagligt med alle de færdigheder, som er nødvendige, for at teamet kan levere produkt funktionalitet. Scrum anerkender ikke andre titler end Udvikler på medlemmerne i Development Teamet, uanset hvilket arbejde en person udfører. Der er ingen undtagelser for denne regel. Individuelle Development Team medlemmer kan have specialiserede kompetencer og fokusområder, men selve ansvaret hører til hele Development teamet; og Development Teamet indeholder ikke sub-teams, der er dedikeret til bestemte domæner som test eller forretningsanalyse. Development Team størrelse Optimalt er Development Teamet ikke større, end at det kan vedblive med at være adræt, og ikke mindre end, at det kan afslutte betydningsfuldt arbejde. Færre end tre Development Team medlemmer kan mindske samspillet og resultere i mindre produktivitetsgevinster. Mindre Development Teams kan opleve begrænsninger i forhold til deres færdigheder i løbet af et Sprint, hvilket kan forårsage, at Development Teamet ikke er i stand til at levere potentiel produktionsfærdig funktionalitet. Mere end ni medlemmer kræver for meget koordination. Store Development Teams skaber for megen kompleksitet til, at man kan håndtere det i en empirisk proces. Product Owner og Scrum Master er ikke medtaget i denne optælling, medmindre de også udfører arbejde i Sprint Backloggen. Alike license of Creative Commons. Side 7

8 Scrum Master Scrum Master er ansvarlig for at sikre, at Scrum er blevet forstået og udført. Scrum Master sørger for dette ved at sikre, at Scrum teamet overholder Scrum teorien, praksis og reglerne. Scrum Master er en tjenende leder for Scrum teamet. Scrum Master hjælper dem uden for Scrum Teamet med at forstå hvilken interaktion med Scrum Teamet, der er nyttig, og hvilken der ikke er nyttig. Scrum Master hjælper alle med at ændre dette samspil for at optimere den værdi, der skabes af Scrum Teamet. Scrum Master tjener Product Owner Scrum Master tjener Product Owner på flere måder, herunder: Finde teknikker til effektiv styring af Product Backlog. Kommunikere vision, mål og Product Backlog items til Development Team. Undervise Scrum Teamet i oprettelse af klare og præcise Product Backlog items. Forståelse af langsigtet produktplanlægning i et empirisk miljø. Forståelse og praktisering af agilitet og Facilitere ønskede eller nødvendige Scrum møder. Scrum Master tjener Development Team Scrum Master tjener Development Team på flere måder, herunder: Coaching af Development Teamet i selvorganisering og tværfaglighed. Undervise og lede Development Teamet mod at skabe produkter af høj værdi. Fjerner forhindringer for Development Teamets fremdrift. Facilitere ønskede eller nødvendige Scrum møder, og Coaching af Development Teamet i organisatoriske miljøer, hvor Scrum endnu ikke er fuldt vedtaget og forstået. Scrum Master tjener organisationen Scrum Master tjener organisationen på flere måder, herunder: Lede og coache organisationen i tilpasningen til Scrum. Planlægning af Scrum implementeringer i organisationen. Hjælpe medarbejdere og interessenter med at forstå og indføre Scrum og empirisk produktudvikling. Forårsage ændringer, der øger produktiviteten af Scrum Teamet, og Arbejde med andre Scrum Masters for at forøge effektiviteten af anvendelsen af Scrum i organisationen. Alike license of Creative Commons. Side 8

9 Scrum møder Faste møder anvendes i Scrum for at skabe regelmæssighed og for at minimere behovet for møder, som ikke er defineret i Scrum. Scrum bruger tidsbegrænsede møder, således at ethvert møde har en maksimal varighed. Dette sikrer, at en passende mængde tid bliver brugt på planlægning, uden at der bruges spildtid i planlægningsprocessen. Ud over Sprintet selv, som er en beholder for alle andre begivenheder, er ethvert møde i Scrum en formel mulighed for at besigtige og tilpasse noget. Disse møder er specielt designet til at give kritisk åbenhed og kontrol. Undladelse af nogen af disse møder resulterer i reduceret transparens, og er en tabt mulighed for at besigtige og tilpasse. Sprintet Hjertet i Scrum er Sprintet, en afgrænset periode på en måned eller mindre, hvor en "færdig", brugbar og potentiel produktionsmoden funktionalitet er lavet. Sprint har en konsistent varighed igennem et udviklingsforløb. Et nyt Sprint starter umiddelbart efter afslutningen af det foregående Sprint. Sprint indeholder og består af Sprint Planning Meeting, Daily Scrums, selve udviklingsarbejdet, Sprint Review og Sprint Retrospective. Under Sprintet: Der må ikke foretages nogen ændringer, som vil påvirke Sprintets mål. Development Teamets sammensætning skal forblive konstant. Kvalitetsmålene må ikke mindskes, og Scope kan præciseres og genforhandles mellem Product Owner og Development Team, når man lærer nyt. Hvert Sprint kan betragtes som et projekt af maksimalt en måneds varighed. Ligesom projekter bliver Sprint brugt til at udrette noget. Hver Sprint har en definition af, hvad der skal bygges, et design og en fleksibel plan, der vejleder om, hvordan man bygger det, selve arbejdet og det resulterende produkt. Sprint er begrænsede til en kalendermåned. Når et Sprints varighed er for langt, kan definitionen af, hvad der bliver bygget, ændre sig, kompleksiteten kan stige, og risikoen kan øges. Sprint vil muliggøre forudsigelighed ved at sikre kontrol og tilpasning af fremskridt i retning af et mål mindst hver kalendermåned. Sprint begrænser også risikoen til omkostningerne af en kalendermåned. Afbrydelse af et Sprint Et Sprint kan annulleres før tid. Kun Product Owner har myndighed til at annullere et Sprint, selv om han eller hun kan være under indflydelse fra interessenter, Development Team eller Scrum Master. Alike license of Creative Commons. Side 9

10 Et Sprint skal annulleres, hvis Sprint Goal er forældet. Dette kan forekomme, hvis virksomheden skifter retning, eller hvis markedet eller teknologien ændrer sig. Generelt bør et Sprint annulleres, hvis det p.g.a. omstændigheder ikke længere giver mening. På grund af den korte varighed af Sprint, giver en annullering dog sjældent mening. Når et Sprint bliver annulleret, skal alle afsluttede og færdige Product Backlog items revideres. Hvis en del af arbejdet er potentielt produktionsfærdigt, vil Product Owner typisk acceptere det. Alle ufuldstændige Product Backlog items bliver restestimeret og tilføjet Product Backloggen igen. Det udførte arbejde på disse afskrives hurtigt, og må ofte restestimeres. En annullering af et Sprint forbruger ressourcer, da alle er nødt til at omgruppere sig i et nyt Sprint Planning Meeting til et andet Sprint. Sprint aflysninger er ofte traumatisk for Scrum Teamet og er meget usædvanligt. Sprint Planning Meeting Det arbejde, der skal udføres i et Sprint, er planlagt på Sprint Planning Meeting. Denne plan bliver skabt igennem et samarbejde mellem hele Scrum Teamet. Sprint Planning Meeting er tidsbegrænset til otte timer for et Sprint på en måned. For kortere Sprint er mødet proportionalt kortere. For eksempel har et to-ugers Sprint et fire-timers Sprint Planning Meeting. Sprint Planning Meeting består af to dele, som hver er tidsbegrænset til den ene halvdel af Sprint Planning Meetings varighed. De to dele af Sprint Planning Meeting besvarer følgende spørgsmål: Hvad bliver der leveret som følge af det kommende Sprint? Hvordan vil man arbejde for at opnå den leverance? Første del: Hvad bliver leveret i dette sprint? I denne del arbejder Development Teamet med at forudsige hvilken funktionalitet, der vil blive udviklet i løbet af Sprintet. Product Owner præsenterer Product Backlog items i rækkefølge for Development Teamet, og hele Scrum Teamet samarbejder om at forstå den funktionalitet, der tages ind i Sprintet. Input til dette møde er Product Backloggen, nyeste produktleverance, Development Teamets forventede kapacitet i løbet af Sprintet og Development Teamets tidligere fremdriftsresultater. Antallet af items, der bliver udvalgt fra Product Backloggen til det kommende Sprint, bestemmes alene af Development Teamet. Kun Development Teamet kan vurdere, hvad det kan udrette i løbet af det kommende Sprint. Efter at Development Teamet har forudsagt de Product Backlog items, de forventer at levere i Sprintet, forfatter Scrum Teamet et Sprint Goal. Sprint Goal er en målsætning, som vil blive Alike license of Creative Commons. Side 10

11 opfyldt inden for Sprintet igennem implementeringen af Product Backloggen, og den giver vejledning til Development Teamet om, hvorfor de bygger denne leverance. Anden del: Hvordan vil det valgte arbejde blive færdiggjort? Efter at funktionaliteten i Sprintet er valgt, beslutter Development Teamet, hvordan det vil bygge denne potentielle produktionsfærdige funktionalitet i Sprintet. De Product Backlog items, der er valgt i Sprintet, samt planen for hvordan man leverer, bliver kaldt Sprint Backlog. Development Teamet starter som regel med at designe systemet og det arbejde, der kræves for at konvertere Product Backloggen til fungerende produktfunktionalitet. Arbejdet kan være af varierende størrelse eller estimeret indsats. Men der planlægges arbejde nok i Sprint Planning Meeting til, at Development Teamet kan forudse, at de kan klare det i kommende Sprint. Det arbejde, der er planlagt af Development Teamet for de første dage af Sprintet, nedbrydes til enheder med en varighed på en dag eller mindre inden udgangen af dette møde. Development Teamet organiserer selv, hvordan de udfører arbejdet i Sprint Backloggen, både i løbet af Sprint Planning Meeting og efter behov igennem hele Sprint. Product Owner kan være til stede under anden del af Sprint Planning Meeting for at afklare de udvalgte Product Backlog items og hjælpe med afvejninger. Hvis Development Teamet fastslår, at det har for meget eller for lidt arbejde, kan det genforhandle Sprint Backloggen med Product Owner. Development Teamet kan også vælge at invitere andre mennesker til at deltage med henblik på teknisk eller domænespecifik vejledning. Ved udgangen af Sprint Planning Meeting skal Development Teamet være i stand til at forklare Product Owner og Scrum Master, hvordan det agter at arbejde som et selvorganiserende team og gennemføre Sprint Goal og udvikle den forventede leverance. Sprint Goal Sprint Goal giver Development Teamet nogen fleksibilitet med hensyn til den implementerede funktionalitet i Sprintet. Mens Development Teamet arbejder, holder det målet for øje. For at opfylde Sprint Goal implementeres funktionaliteten og teknologien. Hvis arbejdet viser sig at være anderledes end Development Teamet havde forventet, så samarbejder det med Product Owner om at forhandle omfanget af Sprint Backloggen, der skal implementeres inden for Sprintet. Sprint Goal kan være en milepæl i den større helhed af produktets roadmap. Daily Scrum Daily Scrum er et møde, der er tidsbegrænset til 15 minutter, hvor Development Teamet synkroniserer aktiviteter og skaber en plan for de næste 24 timer. Dette gøres ved at inspicere arbejdet siden sidste Daily Scrum og forudsige det arbejde, der kan gøres, før det næste. Alike license of Creative Commons. Side 11

12 Daily Scrum afholdes på samme tid og sted hver dag for at reducere kompleksiteten. Under mødet forklarer hvert Development Team medlem: Hvad har jeg opnået siden sidste møde? Hvad bliver færdigt før det næste møde? Hvilke hindringer er i vejen? Development Teamet bruger Daily Scrum til at vurdere fremskridt mod Sprint Goal og vurdere, hvordan fremdriftens tendens er mod færdiggørelsen af arbejdet i Sprint Backloggen. Daily Scrums optimerer sandsynligheden for, at Development Teamet lever op til Sprint Goal. Development Teamet mødes ofte umiddelbart efter Daily Scrum for at genplanlægge resten af Sprintets arbejde. Development Teamet bør hver dag være i stand til at forklare Product Owner og Scrum Master, hvordan de agter at arbejde sammen som et selvorganiserende team for at nå målet og skabe den forventede leverance i den resterende del af Sprintet. Scrum Master sikrer, at Development Teamet holder mødet, men Development Teamet er ansvarlig for gennemførelsen af Daily Scrum. Scrum Master lærer Development Teamet at holde Daily Scrum inden for tidsbegrænsningen på 15 minutter. Scrum Master håndhæver reglen om, at kun Development Teamets medlemmer deltager i Daily Scrum. Daily Scrum er ikke et status møde og er kun for de mennesker, der omdanner Product Backlog items til en leverance. Daily Scrums forbedrer kommunikation, eliminerer andre møder, identificerer og fjerner forhindringer for udvikling, fremhæver og fremmer en hurtig beslutningsproces og forbedrer Development Teamets projektvidensniveau. Dette er et centralt inspektions- og tilpasningsmøde. Sprint Review Et Sprint Review afholdes ved slutningen af hvert Sprint for at inspicere inkrementet og for at tilpasse Product Backlog - hvis nødvendigt. Under Sprint Review, vil Scrum Teamet og interessenter samarbejde om at vurdere, hvad der er afsluttet i Sprintet. Ud fra dette, og ud fra evt. ændringer til Product Backlog undervejs i Sprintet, vil deltagerne samarbejde om den næste funktionalitet, som kan blive færdig. Dette er et uformelt møde. Præsentationen af inkrementet har til hensigt at give umiddelbar feedback og tilskynde til samarbejde. Sprint Review er et tidsbegrænset møde af 4 timers varighed for et én-måneds Sprint. Er Sprintet kortere, allokeres der proportionalt mindre tid. Et to ugers Sprint har således et totimers Sprint Review. Sprint Review inkluderer følgende elementer: Product Owner identificerer, hvad der er færdigt, og hvad der ikke er færdigt jf. definitionen af Done. Alike license of Creative Commons. Side 12

13 Development Teamet drøfter, hvad der er gået godt i Sprintet, hvilket problemer der er opstået, og hvordan disse problemer er blevet løst. Development Teamet demonstrerer færdig funktionalitet og svarer på spørgsmål om inkrementet. Product Owner drøfter Product Backlog, som den nu ser ud. Han eller hun forudsiger sandsynlige slut datoer ud fra fremdrift indtil nu; og Alle drøfter hvad der skal foregå herefter, så Sprint Review giver værdifuldt input til efterfølgende Sprint Planning møde. Resultatet af Sprint Review er en revideret Product Backlog, der viser de sandsynlige Product Backlog items for næste Sprint. Product Backlog kan også blive revideret for at tage højde for nye forretningsmuligheder. Sprint Retrospective Sprint Retrospective er en mulighed for Scrum Teamet til at inspicere sig selv og udarbejde en plan for forbedringer, der kan effektueres i løbet af det næste Sprint. Sprint Retrospective forekommer efter Sprint Review og inden næste Sprint Planning møde. Dette er et tidsbegrænset møde af 3 timers varighed for et én-måneds Sprint. Er Sprintet kortere, allokeres der proportionelt mindre tid. Formålet med Sprint Retrospective er at: Inspicere hvordan Sprintet er gået i forhold til personer, relationer, proces og værktøjer. Identificere og ordne de større ting der er gået godt samt mulige forbedringer; og Udarbejde en plan for implementering af forbedringer til hvordan Scrum Teamet arbejder Scrum Master opfordrer Scrum Teamet til, inden for Scrum proces frameworket, at forbedre deres udviklingsproces og praktikker for at gøre dem mere effektive og glade i næste Sprint. Gennem hver Sprint Retrospective planlægger Scrum Teamet måder at øge produktkvaliteten på ved at tilpasse definitionen af Done efter behov. Ved slutningen af Sprint Retrospective burde Scrum Teamet have identificeret de forbedringer, de vil implementere i næste Sprint. Implementeringen af disse forbedringer i næste Sprint er Scrum Teamets tilpasning i forhold til deres egen inspicering. Selv om forbedringer kan implementeres på ethvert tidspunkt, så giver Sprint Retrospective den formelle mulighed for at fokusere på inspicering og tilpasning. Scrum artefakter Scrums artefakter repræsenterer arbejde eller værdi som på forskellig måde er værdifuld for at give gennemsigtighed og mulighed for inspicering og tilpasning. Scrum artefakter er specielt Alike license of Creative Commons. Side 13

14 designet til at maksimere gennemsigtighed af de nøgleinformationer, der er nødvendige for at sikre, at Scrum Teamet har succes med at kunne levere et færdigt inkrement. Product Backlog Product Backlog er en ordnet liste af alt, der kan være nødvendigt for produktet, og er den eneste kilde til ændringer af produktet. Product Owner er ansvarlig for Product Backlog, herunder indhold, tilgængelighed og rækkefølge. En Product Backlog er aldrig færdig. Den tidligste form af Product Backlog indeholder blot den initielle viden og de bedst forståede krav på dette tidspunkt. Product Backloggen udvikler sig over tid i takt med produktet og omgivelserne, hvori den anvendes. Product Backloggen er dynamisk; den forandrer sig konstant for at repræsentere et produkt, der er passende konkurrencedygtigt og nyttigt. En Product Backlog eksisterer, så længe dets produkt eksisterer. Product Backloggen lister alle funktioner, krav, udvidelser, og fejlrettelser, som udgør de ændringer, der skal implementeres i produktet i fremtidige releases. Product Backlog items indeholder beskrivelse, rækkefølge og estimat. Product Backlog er ofte ordnet efter værdi, risici, prioritet og nødvendighed. De højest ordnede Product Backlog items er drivkraften for umiddelbart forekommende udviklingsaktiviteter. Jo højere et Product Backlog item er ordnet, jo mere har det været vurderet, og jo mere enighed er der om indhold og dets værdi. Højere ordnede Product Backlog items er mere klare og mere detaljeret end de, der er lavere ordnede. Mere præcise estimater er baseret på den større klarhed og øgede detalje; jo lavere ordnet, jo mindre detalje. Product Backlog items, der vil blive behandlet af Development Teamet i det næste Sprint, er finkornede, idet de er opdelt, så hver enkelt del kan blive færdig inden for Sprintets timebox. Product Backlog items, som kan færdiggøres af Development Teamet inden for ét Sprint, anses for at være ready eller mulig at vælge på et Sprint Planning Meeting. I takt med at et produkt bliver anvendt og opnår værdi, og interessenterne giver feedback, bliver Product Backlog en større og mere udtømmende liste. Krav vil aldring stoppe med at blive ændret, derfor er en Product Backlog en levende artefakt. Ændringer i forretningskrav, markedsforhold, eller teknologi er mulige årsager til ændringer i Product Backloggen. Multiple Scrum Teams arbejder ofte sammen om et fælles produkt. Én Product Backlog benyttes til at beskrive det forventede arbejde på produktet. En Product Backlog attribut anvendes til at grupperer items. Product Backlog grooming er den aktivitet, hvor detaljer uddybes, og hvor estimater og orden bliver tildelt hver item i Product Backloggen. Dette er en løbende proces hvor Product Owner og Development Teamet samarbejder om detaljerne i Product Backlog items. Under Product Backlog grooming reviewes items, og de revideres eventuelt. De kan dog til enhver tid opdateres af Product Owner eller efter aftale med Product Owner. Alike license of Creative Commons. Side 14

15 Grooming er en delaktivitet, som foregår mellem Product Owner og Development Teamet, under et Sprint. Ofte vil Development Team have den forretningsmæssige viden til at groome Product Backlog selv. Hvordan og hvornår grooming finder sted, besluttes af Scrum Teamet. Grooming tager normalt ikke mere end 10% af Development Teamets kapacitet. Development Teamet er ansvarlige for alle estimater. Product Owner kan påvirke Development Teamet ved at hælpe med at forstå samt vælge mellem trade-offs, men de personer, der skal udføre det konkrete arbejde, er dem, der giver de endelige estimater. Monitorering af fremdrift mod et mål På ethvert tidspunkt er det muligt at summere den resterende mængde arbejde, der er nødvendig for at opnå et Sprint Goal. Product Owner måler denne totale mængde resterende arbejde mindst ved hvert Sprint Review. Product Owner sammenligner dette arbejde med den mængde, der var tilbage ved forrige Sprint Review, for at vurdere muligheden for at afslutte projektarbejdet til rette tid i forhold til det stillede mål. Denne information er frit tilgængelig for alle interessenter. Forskellige former for burndown- og burnup-grafer samt andre praktikker er blevet anvendt til at fremskrive fremskridtet. Dette har vist sig at være nyttigt, men disse grafer erstatter ikke vigtigheden af empiri. I komplekse omgivelser ved man ikke, hvad der vil opstå. Kun det, der er sket, kan anvendes til at træffe beslutninger om fremtiden. Sprint Backlog Sprint Backlog består af de dele af Product Backlog items, som er udvalgt til Sprintet herunder en plan for at levere et produkt inkrement og opnå Sprint Goal. Sprint Backlog indeholder Development Teamets forventning til hvilken funktionalitet, der vil være i det næste inkrement, og det nødvendige arbejde, der skal til for at levere denne funktionalitet. Sprint Backlog definerer det arbejde, Development Teamet skal udføre for at omsætte Product Backlog items til et Done inkrement. Sprint Backlog synliggør alt det arbejde, som Development Teamet har identificeret som nødvendigt for at opnå Sprint Goal. Sprint Backlog er en plan med tilstrækkelig detalje til, at ændringer i Daily Scrum kan forstås. Development Teamet ændrer Sprint Backlog gennem hele Sprintet, og Sprint Backloggen dannes gennem Sprintet. Dette forekommer, når Development Teamet arbejder sig gennem planen og lærer mere om det arbejde, der er nødvendigt for at opnå Sprint Goal. Når nyt arbejde er nødvendigt tilføjer Development Teamet det til Sprint Backloggen. Når arbejde er udført eller afsluttet, opdateres estimatet for det resterende arbejde. Når delelementer af planen anses for unødvendige, fjernes disse. Kun Development Teamet kan ændre Sprint Backloggen under et Sprint. Sprint Backloggen er et meget synligt realtidsbillede af det arbejde, som Development Teamet har planer om at opnå igennem Sprintet, og er udelukkende Development Teamets. Alike license of Creative Commons. Side 15

16 Monitorering af Sprint fremdrift Summen af et Sprints resterende Product Backlog items skal kunne opgøres på et hvilket som helst tidspunkt i Sprintet. Development Teamet monitorerer minimum det resterende arbejde i forbindelse med hver Daily Scrum. Development Teamet monitorerer summen dagligt og vurderer sandsynligheden for, at de kan nå Sprint Goal. Ved at monitorerer det resterende arbejde i løbet af Sprintet, kan Development Teamet styre dets fremdrift. Scrum bekymrer sig ikke om den tid, der er anvendt I forbindelse med et Sprint Backlog item. Det eneste af interesse er det resterende arbejde samt tiden forbundet med dette. Inkrement Inkrementet er summen af alle Product Backlog items, som er færdiggjort under Sprintet og de tidligere Sprint. Ved slutningen af et Sprint, skal det nye inkrement være Done, hvilket betyder, at det skal være i en brugbar tilstand og opfylde Scrum Teamets definition af Done. Det skal være i en brugbar tilstand uanset om Product Owner beslutter at lægge inkrementet i produktion. Definition af Done Når et Product Backlog item eller et inkrement beskrives som Done, er det nødvendigt, at alle har den samme opfattelse af, hvad dette betyder. Done varierer væsentligt fra Scrum Team til Scrum Team. Derfor må deltagerne i Scrum Teamet have en fælles forståelse af, hvad det betyder, at arbejdet er færdigt for at give gennemsigtighed. Dette betegnes som definition af Done for Scrum Teamet og benyttes til at vurdere, hvornår arbejdet er færdigt på det enkelte produkt inkrement. Den samme definition guider Development Teamet i at vide, hvor mange Product Backlog items Teamet kan vælge på Sprint Planning mødet. Formålet med hvert Sprint er at levere inkrementer af potentiel produktionsfærdig funktionalitet som opfylder Scrum Teamets nuværende definition af Done. Hver Sprint leverer Development Teamet et inkrement af potentiel produktionsfærdig funktionalitet. Disse inkrementer er brugbare. Derfor kan en Product Owner vælge at release funktionaliteten med det samme. Enhver inkremet lægger funktionalitet oveni tidligere inkrementer og er nøje gennemtestet således at det sikres, at alle inkrementer virker sammen. I takt med at Scrum Teamet bliver mere modent, forventes det, at deres kriterier for definition af Done bliver mere og mere fokuseret på at levere højere kvalitet. Alike license of Creative Commons. Side 16

17 Konklusion Scrum er frit og stilles til rådighed i denne guide. Scrums roller, artefakter, møder og regler er obligatoriske. Selvom det er muligt at implementere dele af Scrum, så er resultatet ikke Scrum. Scrum eksisterer kun i sin helhed og fungerer godt som en container for andre teknikker, metoder og praktikker. Alike license of Creative Commons. Side 17

18 Anerkendelser Individer Af de tusinder af individer der har bidraget til Scrum, vil vi gerne fremhæve dem, der var essentielle i dets første 10 år. Det startede med Jeff Sutherland, der arbejdede sammen med Jeff McKenna, og Ken Schwaber, der arbejdede sammen med Mike Smith og Chris Martin. Mange andre har bidraget i de følgende år og uden deres hjælp, ville Scrum ikke have nået så langt, som det er i dag. David Starr gav uvurderlig indsigt og redaktionel erfaring, da denne version af Scrum guiden blev udarbejdet. Historie Ken Schwaber og Jeff Sutherland præsenterede for første gang Scrum på OOPSLA konferencen i Denne præsentation dokumenterede den erfaring, som Ken og Jeff havde opnået igennem årene forinden, da de anvendte Scrum. Scrums historie er allerede lang. For at anerkende de første steder, hvor Scrum blev afprøvet og finjusteret, nævner vi her, Inc., Fidelity Investments, og IDX (nu GE Medical). Scrum guiden dokumenterer Scrum som udviklet og vedligeholdt gennem mere end 25 år af Jeff Sutherland og Ken Schwaber. Andre kilder beskriver mønstre, processer, og indsigt i hvordan praktikker anvendes, hvordan man hjælper et Scrum Team, samt værktøjer der komplementerer Scrum frameworket. Disse optimerer produktivitet, værdi, kreativitet og stolthed. Oversættelse Denne guide er oversat fra den engelske originalversion udarbejdet af Ken Schwaber og Jeff Sutherland. Guiden er oversat af Stig Efsen og Ole Rich Henningsen. Alike license of Creative Commons. Side 18

Februar 2010. Scrum: Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland

Februar 2010. Scrum: Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Februar 2010 Scrum: Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland INDLEDNING GENERELT SCRUM ER BASERET PÅ INDUSTRIANERKENDTE PRINCIPPER, DER GENNEM ÅRTIER HAR VÆRET ANVENDT OG VIST SIG NYTTIGE

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

Accelerate Agil implementering fra EG NeoProcess

Accelerate Agil implementering fra EG NeoProcess Accelerate Prioritise Sprint Accelerate Agil implementering fra EG NeoProcess EG NeoProcess www.eg-neoprocess.dk Accelerate den agile implementering Verden og hverdagen er kompleks og i konstant forandring

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

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

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

BILAG TIL STANDARDVILKÅR OG BETINGELSER

BILAG TIL STANDARDVILKÅR OG BETINGELSER BILAG TIL STANDARDVILKÅR OG BETINGELSER FOR DIGITALE PROJEKTER - en del af Leveringsaftalen for digitale projekter INDHOLDSFORTEGNELSE Bilag 1: Prismodeller... 2 Indledende... 2 1. Fast pris, fast leverance

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

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

Ledelsens vejledning

Ledelsens vejledning DI-version 2015-03-19 PL Problemløsning Alle rettigheder tilhører DI 3-4-1 - PL - Ledelsens Vejledning - 2015-03-19 side 1 af 5 Instruktion til kaizenleder Rettigheder DI ejer alle rettigheder til denne

Læs mere

Er I klar til at slippe kontrollen? - SCRUM som projektledelsesværktøj

Er I klar til at slippe kontrollen? - SCRUM som projektledelsesværktøj Er I klar til at slippe kontrollen? - SCRUM som projektledelsesværktøj Denne artikel er en sammenskrivning af 3 indlæg på dansk Magisterforenings projektlederblog i februar og marts 2011 Af Pia Petersen

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

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering)

Omfang af beføjelser til at træffe beslutninger (for eksempel anbefaling eller implementering) Skema til brug ved oprettelse af et team Formålet med teamet Forventede aktiviteter Tilsigtede resultater Tilgængelige ressourcer Begrænsninger Nødvendige færdigheder og kvaliteter Forventede teammedlemmer

Læs mere

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

ISO 9001:2015 OG ISO 14001:2015 NYE VERSIONER AF STANDARDERNE ER PÅ VEJ ER DU KLAR? Move Forward with Confidence

ISO 9001:2015 OG ISO 14001:2015 NYE VERSIONER AF STANDARDERNE ER PÅ VEJ ER DU KLAR? Move Forward with Confidence ISO 9001:2015 OG ISO 14001:2015 NYE VERSIONER AF STANDARDERNE ER PÅ VEJ ER DU KLAR? Move Forward with Confidence HVORFOR 2015 REVISIONEN? I en verden hvor de økonomiske, teknologiske og miljømæssige udfordringer

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

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

Scrum Master certificeringskursus

Scrum Master certificeringskursus Scrum Master certificeringskursus Vil du være Scrum Master? Scrum er en anderledes måde at styre projekter på, hvilket bliver stadig mere udbredt. Men at arbejde agilt er ikke enkelt og intuitivt. Det

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

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

Kvalitetssikring af IT udvikling hos TDC

Kvalitetssikring af IT udvikling hos TDC Kvalitetssikring af IT udvikling hos TDC Kvalitetsrevisor Henning Sams Har være ansat hos TDC siden 1976 og har arbejdet med kvalitet i ca. 10 år, primært som QAér og Proceskonsulent. Underviser bl.a på

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

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Mangler du som leder kompetencer til at skabe resultater sammen med andre?

Mangler du som leder kompetencer til at skabe resultater sammen med andre? Leadership Program PLP II When business gets personal! Mangler du som leder kompetencer til at skabe resultater sammen med andre? Leadership Program PLP II Acuity World Fortsæt Our field of expertise din

Læs mere

Projektlederskab II. - Fra planlægning til gennemførelse og læring. Projektlederskab II

Projektlederskab II. - Fra planlægning til gennemførelse og læring. Projektlederskab II Projektlederskab II - Fra planlægning til gennemførelse og læring Projektlederskab handler både om mennesker og metoder. På Projektlederskab I var fokus i høj grad på, hvordan man får den optimale start

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

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne Sammenfattende definitioner Definition og beskrivelse Vision En portefølje er en samling af projekter/mer, som vurderes samlet med henblik på at optimere sammensætning og prioritering af strategiske indsatser

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 Side 1 af 8 Så ligger det færdige udkast klar til den kommende version af ISO 9001:2015. Standarden er planlagt til at blive implementeret medio september 2015. Herefter har virksomhederne

Læs mere

jari@kea.dk Tlf: 2344 4682

jari@kea.dk Tlf: 2344 4682 jari@kea.dk Tlf: 2344 4682 STØRRELSE UDVÆLGELSE LEDELSE ARBEJDSSTIL TILGANG FORM TEAM Begrænset Afgørende Delt eller skiftende Dialog og vidensdeling Mangfoldighed Koordinering Dynamik og interaktion

Læs mere

Seminar d. 19.9.2013. Klik for at redigere forfatter

Seminar d. 19.9.2013. Klik for at redigere forfatter Seminar d. 19.9.2013 Klik for at redigere forfatter M_o_R En risiko er en usikker begivenhed, der, hvis den indtræffer, påvirker en målsætning Risici kan dele op i to typer Trusler: Der påvirker målsætningen

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

Kommunikation at gøre fælles

Kommunikation at gøre fælles Kommunikation at gøre fælles Ordet kommunikation kommer af latin, communicare, og betyder "at gøre fælles". Kommunikation er altså en grundlæggende forudsætning for alt socialt fællesskab ingen sociale

Læs mere

Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow

Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow Guide til projektledere: Succesfuld konceptudvikling, kommunikationsstrategi og eksekvering af dit projekt på BetterNow version 1.0 maj 2012 Indholdsfortegnelse 1. Indledning... 3 2. Definer budskabet

Læs mere

Den værdiskabende bestyrelse

Den værdiskabende bestyrelse Af cand. merc. Halfdan Schmidt, CMC, Konsulent i Udviklingsledelse Halfdan Schmidt LedelsesRådgivning ApS Den værdiskabende bestyrelse Det at sidde i en bestyrelse er et krævende og betroet job, der kræver

Læs mere

Vidensmedarbejdere i innovative processer

Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer Vidensmedarbejdere i innovative processer af direktør og partner Jakob Rasmussen, jr@hovedkontoret.dk, HOVEDkontoret ApS 1. Indledning Fra hårdt til blødt samfund

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

Sammenligning af metoder

Sammenligning af metoder Sammenligning af metoder Hvorfor sammenligne? Den ideelle metode Generelle frameworks (NIMSAD/Andersen) Wood-Harper framework til sammenligning Problemer med sammenligning af metoder Hvorfor sammenligne?

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 Side 1 af 8 Så blev den nye version af ISO 9001 implementeret. Det skete den 23. september 2015 og herefter har virksomhederne 36 måneder til at implementere de nye krav i standarden. At

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

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

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

[A20] Kick off document and process description. 1 of 5

[A20] Kick off document and process description. 1 of 5 [A20] Kick off document and process description 1 of 5 kick off document Huge Lawn Projekt Kick-Off Alle projekter og ideer er forskellige. For at vi kan give et reelt bud på dit/jeres projekt eller idé

Læs mere

SAS Standardarbejde i Administration og Service

SAS Standardarbejde i Administration og Service DI-version 2014-12-17 SAS Standardarbejde i Administration og Service Alle rettigheder tilhører DI 2-5-4 - SAS - Ledelsens Vejledning - 2014-12-17 side 1 af 8 Instruktion til kaizenleder Rettigheder DI

Læs mere

Velkommen Gruppe SJ-1

Velkommen Gruppe SJ-1 Velkommen Gruppe SJ-1 Lasse Ahm Consult Torsdag, den 25. september 2014 15:35 1 Program Programmet ser således ud: Kl. 10.00 Velkomst ved Lasse Michael Ahm - Info om ændringer blandt medlemmerne Kl. 10.05

Læs mere

STÆRK PERFORMANCE & SUND TRIVSEL

STÆRK PERFORMANCE & SUND TRIVSEL STÆRK PERFORMANCE & SUND TRIVSEL Cima Development udvikler ledere, medarbejdere og teams. Vi er specialiseret i at hjælpe: Nyetablerede teams og deres ledere, som skal godt og hurtigt fra start. Teams

Læs mere

De nye standarder for kundeengagement

De nye standarder for kundeengagement De nye standarder for kundeengagement : Sammenfattende rapport April 2015 www.decisioningvision.com Indledning Hvordan kan du vide, om din forretningsmodel er velegnet i dag, og om fem år? Den teknologiske

Læs mere

Empowerment 2010-2011

Empowerment 2010-2011 Empowerment 2010-2011 Introduktion Bygge- og anlægsbranchen har i mange år været kendetegnet af stigende efterspørgsel og heraf særdeles flotte omsætningstal. Ikke desto mindre har det vist sig, at rigtig

Læs mere

PRINCE2 - et strategisk valg

PRINCE2 - et strategisk valg PRINCE2 - et strategisk valg Per Palmkvist Knudsen, IT-direktør JP/Politikens Hus Per Palmkvist Knudsen fører dig gennem en rejse af faldgruber og succeser med PRINCE2, herunder: - Hvordan organiserer

Læs mere

Forbedringspolitik. Strategi

Forbedringspolitik. Strategi Forbedringspolitik Strategi 1 2 Indhold Forord... 3 Formål... 5 Vi vil forandre for at forbedre... 6 Forbedringer tager udgangspunkt i patientforløb og resultatet for patienten... 7 Medarbejder og brugerinvolvering...

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

Syv veje til kærligheden

Syv veje til kærligheden Syv veje til kærligheden Pouline Middleton 1. udgave, 1. oplag 2014 Fiction Works Aps Omslagsfoto: Fotograf Steen Larsen ISBN 9788799662999 Alle rettigheder forbeholdes. Enhver form for kommerciel gengivelse

Læs mere

OPFØLGNINGSPLAN HANSENBERG. Erhvervsuddannelserne 2015 Institutionsnummer:

OPFØLGNINGSPLAN HANSENBERG. Erhvervsuddannelserne 2015 Institutionsnummer: OPFØLGNINGSPLAN HANSENBERG Erhvervsuddannelserne 2015 Institutionsnummer: 621401 Indholdsfortegnelse Indledning 3 Opfølgning på arbejdet med skolens fælles pædagogiske og didaktiske grundlag (FPDG) 4 4

Læs mere

Agenda. Scrum. Baggrund & teori. Scrum metoden. Processen Begreber Regler. Praktiske erfaringer. Afbryd mig ofte, tak..

Agenda. Scrum. Baggrund & teori. Scrum metoden. Processen Begreber Regler. Praktiske erfaringer. Afbryd mig ofte, tak.. Agenda Baggrund & teori Scrum metoden Processen Begreber Regler Praktiske erfaringer Afbryd mig ofte, tak.. Scrum Rugby analogi Udspringer af agile/xp Iterativ udvikling Kunden tættere på udviklingen Forretningsorientering

Læs mere

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

Ældre- og Handicapforvaltningen, Aalborg Kommune Aalborg på Forkant Innovativ udvikling i sundhed og velfærd. Forundersøgelse. Aalborg på Forkant

Ældre- og Handicapforvaltningen, Aalborg Kommune Aalborg på Forkant Innovativ udvikling i sundhed og velfærd. Forundersøgelse. Aalborg på Forkant Forundersøgelse - bedre sundhed og mere omsorg og pleje for færre ressourcer Udvikling af innovative sundheds- og velfærdsløsninger i Ældre- og Handicapforvaltningen i Aalborg Kommune 1 Indholdsfortegnelse

Læs mere

Styregruppeformænd i SKAT Kort & godt (plastkort)

Styregruppeformænd i SKAT Kort & godt (plastkort) Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere

Læs mere

PERSONLIG TIME MANAGEMENT

PERSONLIG TIME MANAGEMENT ARKMANN RAINING ERSONLIG IME MANAGEMENT DIT KONKRETE UDBYTTE EFTER AT HAVE DELTAGET ER BL.A.» Du vil få bedre overblik, kontrol og fokus.» Du vil opnå flere af dine mål og altid nå dine vigtigste opgaver.»

Læs mere

PÆDAGOGIK PÅ EUD. Vores fælles pædagogiske didaktiske grundlag. ZBC Roskilde Maglegårdsvej 8 4000 Roskilde Tlf. 4634 6200

PÆDAGOGIK PÅ EUD. Vores fælles pædagogiske didaktiske grundlag. ZBC Roskilde Maglegårdsvej 8 4000 Roskilde Tlf. 4634 6200 PÆDAGOGIK PÅ EUD Vores fælles pædagogiske didaktiske grundlag ZBC Roskilde Maglegårdsvej 8 4000 Roskilde Tlf. 4634 6200 ZBC Ringsted Ahorn Allé 3-5 4100 Ringsted Tlf. 5768 2500 ZBC Næstved Handelsskolevej

Læs mere

Forhandlingsteknik for erfarne forhandlere

Forhandlingsteknik for erfarne forhandlere Forhandlingsteknik for erfarne forhandlere Forhandlingsteknik for erfarne forhandlere Skab resultater med større power og personlig gennemslagskraft Personlig gennemslagskraft styrker dine forhandlinger

Læs mere

Kom godt i gang med projektkarrieren Karsten Lodahl Madsen, Dansk Magisterforening Mikkel Lundstrøm, Unik Consult

Kom godt i gang med projektkarrieren Karsten Lodahl Madsen, Dansk Magisterforening Mikkel Lundstrøm, Unik Consult Kom godt i gang med projektkarrieren Karsten Lodahl Madsen, Dansk Magisterforening Mikkel Lundstrøm, Unik Consult Program 17.00 Velkomst og præsentation 17.15 Intro til projekternes verden 17.30 Intro

Læs mere

RYGAARDS SKOLE STRATEGISK PLAN 2013-2017

RYGAARDS SKOLE STRATEGISK PLAN 2013-2017 RYGAARDS SKOLE STRATEGISK PLAN 2013-2017 VISION FOR RYGAARDS SKOLE At sikre vores langsigtede fremtid som en enestående skole med kristne værdier, et højt fagligt niveau og en vision om, at uddannelse

Læs mere

Du skal i besvarelsen tage udgangspunkt i de mål og kompetencer, der er beskrevet i uddannelsesprogrammet for det pågældende uddannelseselement.

Du skal i besvarelsen tage udgangspunkt i de mål og kompetencer, der er beskrevet i uddannelsesprogrammet for det pågældende uddannelseselement. SPØRGESKEMA EVALUER.DK Du skal nu foretage en evaluering af det uddannelsessted, hvor du netop har afsluttet eller er ved at afslutte et uddannelseselement. Besvarelsen tager ca. 10-15 min. Vigtig tilbagemelding

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel Rollebeskrivelser Programroller ift. den fællesstatslige programmodel Indholdsfortegnelse Rollebeskrivelser... 1 1. Programprofiler... 3 1.1. Formand for programbestyrelse/programejer... 3 1.2. Programleder...

Læs mere

Udskillelse af leverandører ved overgang til fase 2

Udskillelse af leverandører ved overgang til fase 2 Bilag 5 Dato November 2015 Bilag 5 er i sin helhed et mindstekrav. Udskillelse af leverandører ved overgang til fase 2 Til Udvikling af nye, innovative løsninger til optimal anvendelse af ressourcer i

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

Samrådsspørgsmål. Akt 186

Samrådsspørgsmål. Akt 186 Samrådsspørgsmål Akt 186 Der ønskes en uddybende redegørelse for og en drøftelse af årsagerne til og konsekvenserne af den forventede meget betydelige fordyrelse og forsinkelse af projektet. Svar: Indledning

Læs mere

Forberedelse og planlægning af GMP Audit

Forberedelse og planlægning af GMP Audit Forberedelse og planlægning af GMP Audit Juli, 2014 Indledning I de kommende sider får du nogle hurtige tips og råd til din forberedelse og planlægning af en GMP audit. Dette er ikke en komplet og grundig

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

Ledelse i TDC. Casebeskrivelse Conmoto A/S Human Business Development. DMR Konsulentprisen 2006 TDC A/S

Ledelse i TDC. Casebeskrivelse Conmoto A/S Human Business Development. DMR Konsulentprisen 2006 TDC A/S Ledelse i TDC Casebeskrivelse Conmoto A/S Human Business Development DMR Konsulentprisen 2006 TDC A/S November 2005 Indledning Nedenstående case er en beskrivelse af samarbejdet mellem TDC Koncern HR og

Læs mere

Det bedste værktøj. er det der bliver brugt. RISMAstrategy

Det bedste værktøj. er det der bliver brugt. RISMAstrategy Det bedste værktøj er det der bliver brugt RISMA Vi er dedikeret til din succes Pålidelig rettidig information spiller en nøglerolle for succes i dagens omskiftelige forretningsverden. Samtidigt har vi

Læs mere

Delaftale 3 Pap-, papir-, glas-, metal- og træaffald

Delaftale 3 Pap-, papir-, glas-, metal- og træaffald Miljøstyrelsens Rammeaftale på affaldsfaglige konsulentydelser og -bistand Bilag 1: Kravspecifikation og anvendelsesområde Delaftale 3 Pap-, papir-, glas-, metal- og træaffald Side 1 af 8 Indholdsfortegnelse

Læs mere

PARTNERTILGANG AFRIKA KONTAKTS PARTNER & PROJEKTTILGANG

PARTNERTILGANG AFRIKA KONTAKTS PARTNER & PROJEKTTILGANG PARTNERTILGANG AFRIKA KONTAKTS PARTNER & PROJEKTTILGANG PARTNERTILGANG AFRIKA KONTAKTS PARTNER & PROJEKTTILGANG NOVEMBER 2013 AFRIKA KONTKAT BLÅGÅRDSGADE 7B DK2200 KØBENHVAN N TELEFON: +45 35 35 92 32

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning August 2013 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

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

Håndbog til projektledelse

Håndbog til projektledelse Mere info kontakt Julie Kirstine Olsen Udviklingskonsulent juols@ikast-brande.dk Tlf.: 9960 4153 Mads Ballegaard Konsulent mabal@ikast-brande.dk Tlf.: 9960 4021 Produceret af Håndbog til projektledelse

Læs mere

Gentofte Skole elevers alsidige udvikling

Gentofte Skole elevers alsidige udvikling Et udviklingsprojekt på Gentofte Skole ser på, hvordan man på forskellige måder kan fremme elevers alsidige udvikling, blandt andet gennem styrkelse af elevers samarbejde i projektarbejde og gennem undervisning,

Læs mere

Et forløb kan se således ud, fordelt på moduler, emner og formål: Modul 1

Et forløb kan se således ud, fordelt på moduler, emner og formål: Modul 1 3 GDJRJLVNYHMOHGQLQJIRU3URMHNWNRRUGLQDWRUIRU8GYLNOLQJ6DPVSLORJ 5HVXOWDWHU %HJUXQGHOVHIRUXGGDQQHOVH Projekter er blevet almindelige i danske virksomheder. Hvor projekter før i tiden var af mere teknisk

Læs mere

Spillemyndighedens certificeringsprogram. Retningslinjer for sårbarhedsscanning SCP.05.00.DK.1.0

Spillemyndighedens certificeringsprogram. Retningslinjer for sårbarhedsscanning SCP.05.00.DK.1.0 SCP.05.00.DK.1.0 Indhold Indhold... 2 1 Formålet med retningslinjer for sårbarhedsscanning... 3 1.1 Overblik over dette dokument... 3 1.2 Version... 3 2 Certificering... 3 2.1 Certificeringsfrekvens...

Læs mere

DI-version Kanban. Ledelsens vejledning Kanban - Ledelsens Vejledning Alle rettigheder tilhører DI side 1 af 6

DI-version Kanban. Ledelsens vejledning Kanban - Ledelsens Vejledning Alle rettigheder tilhører DI side 1 af 6 DI-version 2013-10-08 Kanban 2-4-1 - Kanban - Ledelsens Vejledning - 2013-10-08 Alle rettigheder tilhører DI side 1 af 6 Instruktion til kaizenleder Rettigheder DI ejer alle rettigheder til denne instruktion.

Læs mere

VSM. Værdistrømsanalyse. Ledelsens vejledning. DI version

VSM. Værdistrømsanalyse. Ledelsens vejledning. DI version DI version 2012-02-05 VSM Værdistrømsanalyse 2-1-1 - VSM - Ledelsens Vejledning - 2012-02-059 Alle rettigheder tilhører DI side 1 af 5 Instruktion til ledelsen Rettigheder DI ejer alle rettigheder til

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

Iterativ og Agil udvikling

Iterativ og Agil udvikling Iterativ og Agil udvikling 1 2 Udfordringer i hverdagen En liste over de udfordringer man står overfor ved implementering af iterativ og agil udvikling. 3 Udfordringer med Iterationer 4 Iterationer, I

Læs mere

Inklusionspolitik for Børne- og Kulturforvaltningen i Tårnby Kommune. 0 18 års-området

Inklusionspolitik for Børne- og Kulturforvaltningen i Tårnby Kommune. 0 18 års-området Inklusionspolitik for Børne- og Kulturforvaltningen i Tårnby Kommune 0 18 års-området Indledning: Inklusionsbegrebet i Tårnby Kommune baserer sig grundlæggende på Salamanca-erklæringen 1 fra 1994, der

Læs mere

. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten

. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten . spe. Bestemmelser der indarbejdes i Samarbejdsbilaget samt i Kontrakten Nedenstående er opdelt i to afsnit. Første afsnit indeholder bestemmelser, der forventes indarbejdet i Samarbejdsbilaget. Andet

Læs mere

DISSE 5 DATAELEMENTER ØGER VÆRDIEN AF DIT CRM-SYSTEM

DISSE 5 DATAELEMENTER ØGER VÆRDIEN AF DIT CRM-SYSTEM D DISSE 5 DATAELEMENTER ØGER VÆRDIEN AF DIT CRM-SYSTEM 1 - INTRODUKTION 2 - DATAELEMENT 1: KORREKT ADRESSEINFORMATION 3 - DATAELEMENT 2: DAGLIGE LEDERE 4 - DATAELEMENT 3: OMSÆTNING & DRIFTSRESULTAT 5 -

Læs mere

Vores arbejdsmetoder

Vores arbejdsmetoder Vores arbejdsmetoder Vores forretningsprincipper og Vores værdier udgør sammen kernen i vores virksomhed. I Vores arbejdsmåde beskrives det, hvordan vi omsætter vores ressourcer til resultater. Vi vil

Læs mere

Opskriften på vellykkede OPI er tre grundlæggende råd

Opskriften på vellykkede OPI er tre grundlæggende råd Opskriften på vellykkede OPI er tre grundlæggende råd 2015 SIDE 2 Opskriften på vellykkede OPI er tre grundlæggende råd Pjecen er udarbejdet af Rådet for Offentlig-Privat Samarbejde Carl Jacobsens Vej

Læs mere

Europaudvalget 2007 2822 - økofin Bilag 2 Offentligt

Europaudvalget 2007 2822 - økofin Bilag 2 Offentligt Europaudvalget 2007 2822 - økofin Bilag 2 Offentligt 28. september 2007 Supplerende samlenotat vedr. rådsmødet (ECOFIN) den 9. oktober 2007 Dagsordenspunkt 8b: Finansiel stabilitet i EU (Kriseberedskab)

Læs mere

2. Fødevareministeriet er en koncern

2. Fødevareministeriet er en koncern Ministeriet for Fødevarer, Landbrug og Fiskeri Fødevareministeriets effektiviseringsstrategi 1. Indledning 2. udgave af Fødevareministeriets effektiviseringsstrategi er udarbejdet i 2007. Effektiviseringsstrategien

Læs mere

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Presentation title 1 Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Peter Bøge Senior Controls manager, Novo Nordisk; Formand for Medicoindustriens ekspertgruppe for Safety

Læs mere

Vejledning til tiltrædelse og udvikling Vejledning til tiltrædelsessamtalen og udviklingsdelen

Vejledning til tiltrædelse og udvikling Vejledning til tiltrædelsessamtalen og udviklingsdelen Vejledning til tiltrædelsessamtalen og udviklingsdelen Herunder kan du finde hjælp til tiltrædelsessamtalen og til udviklingssamtalen og udviklingskontrakten. 1 Vejledning til tiltrædelsessamtalen Denne

Læs mere

Grøn Proces. Et redskab til produktionsforberedelse og styring

Grøn Proces. Et redskab til produktionsforberedelse og styring Grøn Proces Et redskab til produktionsforberedelse og styring Undersøgelser i byggebranchen viser at ventetid, spild, svind, tyveri og skader......udgør en væsentlig del af årsagen til branchens dårlige

Læs mere

ET GODT PSYKISK ARBEJDSMILJØ NÅR KOLLEGAER SKAL INKLUDERES PÅ ARBEJDSPLADSEN

ET GODT PSYKISK ARBEJDSMILJØ NÅR KOLLEGAER SKAL INKLUDERES PÅ ARBEJDSPLADSEN ET GODT PSYKISK ARBEJDSMILJØ NÅR KOLLEGAER SKAL INKLUDERES PÅ ARBEJDSPLADSEN UDGIVET MAJ 2013 2 Nedslidningen som følge af et dårligt psykisk arbejdsmiljø er et væsentligt tema for både samfund, virksomheder

Læs mere

Facilities Management 2013 Survey: Aktiviteter og forventninger

Facilities Management 2013 Survey: Aktiviteter og forventninger Facilities Management 2013 Survey: Aktiviteter og forventninger FM forbedrer produktiviteten for kernevirksomheden Produktiviteten skal forbedres hører vi fra alle sider. Produktivitet er produktionen

Læs mere

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER 1 INTRODUKTION 1.1 Formålet med Practitioner-eksamen er at give eksaminanden mulighed for at demonstrere forståelse af PRINCE2. Samtidig skal eksaminanden

Læs mere

Af produktivitetschef Bjarne Palstrøm, Dansk Industri

Af produktivitetschef Bjarne Palstrøm, Dansk Industri Faldgruber i Lean Af produktivitetschef Bjarne Palstrøm, Dansk Industri Erfaringerne med indførelse af Lean-tankegangen viser, at virksomhederne fra tid til anden ikke får det forventede udbytte. Denne

Læs mere

Simplify to optimize. Simplimize / METODE 02

Simplify to optimize. Simplimize / METODE 02 Simplify to optimize Simplimize / METODE 02 01 01 Simplimize / METODE Simplimize Simplimize / METODE 02 02 Høj lagerbinding Lang omstillingstid Stigende antal komponenter Nævn bare én virksomhed, som har

Læs mere