Nexus Guide. Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling. Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.
|
|
- Hedvig Lauridsen
- 6 år siden
- Visninger:
Transkript
1 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
2 Indholdsfortegnelse Nexus overblik... 2 Formålet med Nexus Guide...2 Definition af Nexus...2 Baggrunden for Nexus...2 Nexus rammeværk...3 Nexus proces flow...4 Software processer...4 Nexus... 4 Nexus Roles...5 Nexus Integration Team...5 Nexus Events...6 Nexus Sprint Planning...6 Nexus Daily Scrum...7 Nexus Sprint Review...7 Nexus Sprint Retrospective...7 Refinement...8 Nexus Artifacts...9 Product Backlog...9 Nexus Goal...9 Nexus Sprint Backlog...9 Integrated Increment...9 Gennemsigtighed af Artifact Definition of Done Slut bemærkninger Anerkendelse TRANSLATED BY: Stig Efsen LinkedIn Copyright Scrum.org, 2015 All Rights Reserved Page 1 (Version 1.1)
3 Nexus overblik Formålet med Nexus Guide Nexus er et rammeværk der anvendes ved udvikling og vedligehold af skalerede produkt- og softwareudvikling initiativer. Det benytter Scrum som sine byggesten. Denne guide indeholder definitionen af Nexus. Denne definition består af Nexus roles, events, artifacts, samt de regler der binder dem sammen. Ken Schwaber og Scrum.org har udviklet Nexus og er stillet til rådighed af dem. Definition af Nexus Nexus (n): Enhed for udvikling (i skaleret Professional Scrum) Nexus er et rammeværk og består af roles, events og artifacts, samt de teknikker der binder og sammenfletter arbejdet af mellem tre til ni Scrum Teams, der arbejder på én fælles Product Backlog for at udvikle et Integrated Increment som opfylder et mål. Baggrunden for Nexus Software udvikling er kompleks og integrationen af arbejdet i working software har mange artefakter og aktiviteter som skal koordineres for at skabe et resultat der er Done. Arbejdet skal tilrettelægges, nedbrydes i rækkefølge og afhængigheder skal være løst. Slut resultatet skal være planlagt. Software indeholder yderligere udfordringer, idet der ikke er tale om et fysisk produkt. Mange software udviklere benytter Scrum rammeværket til at arbejde i teams for at udvikle et Increment af working software. Men hvis mere end ét Scrum Team arbejder på den samme Product Backlog og i en fælles codebase for et produkt, opstår der udfordringer. Hvis udviklerne ikke sidder i et fælles team på samme lokalitet, hvordan skal de så kommunikere når de arbejder på opgaver der afhænger af hinanden? Hvis de arbejder i forskellige teams, hvordan skal de så integrere deres arbejde og teste det til et Integrated Increment? Disse udfordringer opstår når to eller flere teams arbejder sammen, og bliver signifikant mere besværligt med tre eller flere teams. Der er mange afhængigheder der opstår i arbejdet mellem multible teams der samarbejder om at frembringe et komplet og Done Increment mindst hver Sprint. Disse afhængigheder er relateret til: 1. Krav: Scope af kravene kan overlappe hinanden, og måden hvorpå de udvikles kan også påvirke hinanden. Denne viden bør tages i betragtning når man ordner Product Backlog og udvælger krav. 2. Domæne viden: Team medlemmer har forskellig viden om forretning og teknologi. Denne viden bør fordeles i Scrum Teams for at sikre at der er tilstrækkelig viden i de enkelte teams og for at minimere forstyrrelser mellem teams under et Sprint. 3. Software og test artefakter: Krav er eller vil blive afspejlet i software code og test suiter. Copyright Scrum.org, 2015 All Rights Reserved Page 2 (Version 1.1)
4 I det omfang at krav, teammedlemmers viden, og code/test artefakter er knyttet til samme Scrum Teams, så kan afhængigheder mellem teams blive reduceret. Når Scrum software udvikling skaleres bør disse afhængigheder af krav, domæne viden og software/test artefakter drive hvordan team organiseres. I det omgang det er tilfældet vil produktiviteten blive optimeret. Nexus rammeværk Nexus er et ydre skelet, der hviler på toppen af flere Scrum Teams når de kombineres for at skabe et Integrated Increment. Nexus er i overensstemmelse med Scrum og dens bestanddele vil være velkendt for dem, der har arbejdet på Scrum projekter. Forskellen er, at der fokuseres mere på afhængigheder og samspil mellem Scrum Teams, om at levere et "Done" Integrated Increment mindst hver Sprint. Som vist i den efterfølgende grafik består Nexus af: Roles: En ny rolle, Nexus Integration Team, er til for at koordiner, coache og vejlede brugen af Nexus og Scrum så det bedste resultat opnås. Nexus Integration Team består af en Product Owner, en Scrum Master samt Nexus Integration Team medlemmer. Artifacts: Alle Scrum Teams benytter en og samme Product Backlog. Når Product Backlog items bliver uddybet og gøres Sprint ready, vil indikatorer for hvilket team der skal implementere opgaven i et Sprint gøres synlig. Et nyt artefakt, Nexus Sprint Backlog, er oprettet for at hjælpe med at synliggøre arbejdet under Sprintet. Alle Scrum Teams vedligeholder deres egen Sprint Backlog. Events: Events tilføjes, omkranser, eller erstatter (for Sprint Reviews vedkommende) de normale Scrum events for at udvide dem. I modificeret udgave understøtter de både den overordnede indsats for alle Scrum Teams i Nexus og de individuelle teams. Nexus Framework, exoskeleton of scaled Scrum Copyright Scrum.org, 2015 All Rights Reserved Page 3 (Version 1.1)
5 Nexus proces flow Alt arbejde i et Nexus kan udføres af alle medlemmer i Scrum Teams, som cross-functional medlemmer af et Nexus. Ud fra afhængigheder kan teams vælge det bedst egnede medlem til en specifik opgave. Detaljering af Product Backlog: Product Backlog skal nedbrydes så afhængigheder er identificeret, fjernet eller minimeret. Product Backlog items er nedbrudt i små dele af funktionalitet og det team der skal udføre opgaven skal identificeres så tidligt i processen som muligt. Nexus Sprint Planning: Passende repræsentanter fra hvert Scrum Team mødes for at diskutere og reviewe den nedbrudte Product Backlog. De vælger Product Backlog items for hvert team. Hvert Scrum Team planlægger sit eget Sprint og samarbejder med øvrige teams efter behov. Resultatet er et antal Sprint Goals, som tilsammen opfylder det overordnede Nexus Goal, hvert Scrum Team's Sprint Backlog og en enkel Nexus Sprint Backlog. Nexus Sprint Backlog udgør Scrum Team's valgte Product Backlog items og enhver afhængighed transparent. Development work: Alle teams udvikler software og integrerer hyppigt deres arbejde i et fælles miljø og sikrer at integrationtests er gennemført. Nexus Daily Scrum: Passende repræsentanter fra hvert Scrum Development Team mødes dagligt for at identificere om der er udfordringer med integrationen. Hvis der er dette så tages denne information med tilbage til hvert Scrum Team s Daily Scrum. Scrum Teams benytter herefter deres Daily Scrum til at udarbejde en plan for dagen, hvor det sikres at udfordringerne med integration fra Nexus Daily Scrum bliver adresseret. Nexus Sprint Review: Alle teams mødes med Product Owner for at reviewe Integrated Increment. Justeringer til Product Backlog kan forekomme. Nexus Sprint Retrospective: Passende repræsentanter fra hvert Scrum Team mødes for at identificere fælles udfordringer. Herefter holder hvert Scrum Team individuelle Sprint Retrospectives. For at give en buttom-up tilgang mødes passende repræsentanter fra hvert team igen for at diskutere de nødvendige aktioner der skal igangsættes baseret på de fælles udfordringer. Software processer Mange software udviklingsprocesser er nødvendige for at sammenkoble resultater af Scrum Teams, der samarbejder om at skabe et Integrated Increment. De fleste af disse processer kræver automatisering. Automatisering hjælper med at styre størrelsen og kompleksiteten af arbejdet og de artefakter der er specielle især i et skalerbart miljø. Nexus Nexus roles, events og artifacts nedarver formål og hensigt fra de tilsvarende Scrum roles, events og artifacts, som dokumenteret i Scrum Guide. Copyright Scrum.org, 2015 All Rights Reserved Page 4 (Version 1.1)
6 Nexus Roles Et Nexus består af et Nexus Integration Team og ca. tre til ni Scrum Teams. Nexus Integration Team Et Nexus Integration Team er ansvarlig for at et Integrated Increment (det samlede arbejde færdiggjort af et Nexus) er leveret mindst en gang hvert Sprint. Scrum Teams er ansvarlige for udvikling af Increments af potentially releasable software, som foreskrevet in Scrum. Alle roller for medlemmer af Scrum Teams er som foreskrevet i Scrum Guide. Et Nexus Integration Team er et Scrum Team som består af: Product Owner Scrum Master Et eller flere Nexus Integration Team medlemmer Medlemmer af et Nexus Integration Team kan også arbejde i Scrum Teams i Nexus, hvis det er relevant og nødvendigt. Hvis dette er tilfældet, skal der gives prioritet til arbejdet for Nexus Integration Teamet. Medlemskab af et Nexus Integration Team har forrang for individuelle Scrum Team-medlemskab. Denne præference er med til at sikre, at arbejdet med at løse problemer, der påvirker mange hold har prioritet. Sammensætning af et Nexus Integration Team kan ændre sig over tid til at reflektere de aktuelle behov i et Nexus. Fælles aktiviteter et Nexus Integration Team kan udføre omfatter coaching, rådgivning, og at fremhæve bevidstheden om afhængigheder og cross-team udfordringer. Det kan også udføre arbejde fra Product Backlog. Nexus Integration Team'et tager ejerskab af eventuelle integrationsspørgsmål. Det har ansvaret for en vellykket integration af alt arbejde fra alle Scrum Teams i et Nexus. Integration omfatter at løse eventuelle tekniske og ikke-tekniske cross-team begrænsninger, der kan hindre et Nexus' evne til at levere en vedvarende Integrered Increment. De bør bruge bottom-up informationer fra Nexus for at løse udfordringerne. Product Owner i Nexus Integration Team Et Nexus arbejder ud fra en enkelt Product Backlog, og som beskrevet i Scrum rammerværket har en Product Backlog én Product Owner, der bestemmer over dens indhold. Product Owner er ansvarlig for at maksimere værdien af produktet og det arbejde der er udført og integreret af Scrum Teams. Product Owner er en del af et Nexus Integration Team. Product Owner er ansvarlig for at ordne og nedbryde Product Backlog så maksimal værdi leveres i Integrated Increment skabt af et Nexus. Hvordan dette skal gøres kan variere meget på tværs af organisationer, Nexus, Scrum Teams og enkeltpersoner. Copyright Scrum.org, 2015 All Rights Reserved Page 5 (Version 1.1)
7 Scrum Master in the Nexus Integration Team Scrum Master i et Nexus Integration Team'et har det overordnede ansvar for at sikre at Nexus rammerværket er forstået og følges. Denne Scrum Master kan også være en Scrum Master i et eller flere af de andre Scrum Teams i denne Nexus. Nexus Integration Team Members Skaleret udviklingsarbejde kræver værktøjer og processer, som de enkelte Scrum Teams måske ikke bruger så ofte. Nexus Integration Team'et består af software fagfolk, der er uddannet i brugen af disse processer, værktøjer og generelt indenfor systemudvikling. Nexus Integration Team medlemmer sikre, at praksis og værktøjer er implementeret, forstået, og anvendes til at påvise afhængigheder, og at alle artefakter integreres ofte til en "Done" tilstand. Nexus Integration Team medlemmer er ansvarlige for coaching og at vejlede Scrum Teams i et Nexus til at tilegne, implementere og lære disse processer og værktøjer. Derudover coacher de Scrum Teams indenfor nødvendige udviklings-, infrastruktur, eller arkitektoniske standarder, der kræves af organisationen for at sikre udviklingen af kvalitets Integrered Increments. Hvis deres primære ansvar er opfyldt, kan Nexus Integration Team medlemmer også arbejde som Development Team medlemmer i et eller flere Scrum Teams. Nexus Events Varigheden af Nexus begivenheder er styret af længden af de tilsvarende begivenheder i Scrum Guide. De er timeboxe i tillæg til deres tilsvarende begivenheder i Scrum. Nexus Sprint Planning Formålet med Nexus Sprint Planning er at koordinere aktiviteterne i alle Scrum Teams i et Nexus for en enkelt Sprint. Product Owner bidrager med domæneviden og guider udvælgelse og prioriterer beslutninger. Nexus Sprint Planning starter med, at relevante repræsentanter fra hver Scrum Team validerer og foretager tilpasninger til rækkefølgen af arbejdet som er skabt under Refinement begivenheder. Alle medlemmer af Scrum Teams bør deltage for at minimere tab af information. Nexus Sprint Goal formuleres i løbet af Nexus Sprint Planning. Den beskriver det formål, som vil blive opnået af Scrum Teams under Sprintet. Når det samlede arbejde for et Nexus er forstået, vil hver Scrum Team holde deres egen separate Sprint Planning. Hvis mødet gennemføres i et fælles lokale, kan Scrum Teams fortsætte med at dele nyligt fundne afhængigheder. Nexus Sprint Planning er færdig, når hver Scrum Team er færdig med deres individuelle Sprint Planning aktiviteter. Copyright Scrum.org, 2015 All Rights Reserved Page 6 (Version 1.1)
8 Nye afhængigheder kan opstå i løbet af Nexus Sprint Planning. De bør visualiseres og minimeres. Rækkefølgen af arbejdet på tværs af teams kan også justeres. Et tilstrækkeligt nedbrudt Product Backlog vil minimere fremkomsten af nye afhængigheder under Nexus Sprint Planning. Alle Product Backlog Items udvalgt til Sprint og deres afhængigheder skal visualiseres på Nexus Sprint Backlog. Product Backlog bør være tilstrækkeligt forfinet og identificerede afhængigheder bør være fjernet eller minimeret før Nexus Sprint Planning. Nexus Daily Scrum Nexus Daily Scrum er en begivenhed for relevante repræsentanter fra de enkelte Scrum Development Teams til at inspicere den aktuelle tilstand af Integrated Increment og for at identificere udfordringer med integrationen eller nyopdagede cross-team afhængigheder. Under Nexus Daily Scrum, bør deltagerne fokusere på hvert teams indvirkning på Integrated Increment og diskutere: Var den foregående dags arbejde succesfuldt integreret? Hvis ikke, hvorfor ikke? Hvilke nye afhængigheder er blevet identificeret? Hvilken information skal deles på tværs af teams i Nexus? Under Nexus Daily Scrum, bør Nexus Sprint Backlog bruges til at visualisere og administrere de nuværende afhængigheder. Arbejde, der er identificeret under Nexus Daily Scrum bliver derefter taget med tilbage til de enkelte Scrum teams for planlægning i deres Daily Scrum aktiviteter. Nexus Sprint Review Nexus Sprint Review afholdes i slutningen af Sprintet for at give feedback på det Integrated Increment et Nexus har leveret igennem Sprintet. En Nexus Sprint Review erstatter de individuelle Scrum Team Sprint Reviews, fordi hele Integrated Increment er i fokus under feedback fra interessenterne. Det kan være umuligt at vise alt afsluttet arbejde i detaljer. Forskellige teknikker kan være nødvendige for at maksimere feedback fra interessenterne. Nexus Sprint Retrospective The Nexus Sprint Retrospective er en formel mulighed for et Nexus til at fokusere på inspektion og tilpasning. Det består af tre dele: 1. Den første del er en mulighed for relevante repræsentanter fra hele Nexus til at mødes og identificere problemer, der har påvirket mere end et enkelt team. Formålet er at synliggøre disse problemer for alle Scrum Teams. Copyright Scrum.org, 2015 All Rights Reserved Page 7 (Version 1.1)
9 2. Den anden del består af, at hver Scrum Team holder deres eget Sprint Retrospective som beskrevet i Scrum Guide. De kan bruge problemer fra den første del af Nexus Retrospective som input til deres team diskussioner. De enkelte Scrum Teams bør oprette aktioner for at løse disse problemer i løbet af deres individuelle Scrum Team Sprint Retrospectives. 3. Tredje og sidste del er en mulighed for relevante repræsentanter fra Scrum Teams til at mødes igen og blive enige om, hvordan man kan visualisere og spore de identificerede tiltag. Dette gør det muligt for et Nexus at tilpasse sig som en helhed. Idet de er almindelige dysfunktioner ved skalering bør hver Retrospective behandle følgende emner: Var noget arbejde udeladt? Har Nexus genereret teknisk gæld? Blev alle artefakter, især kode, ofte (så ofte som hver dag) succesfuldt integreret? Var softwaren succesfuld bygget, testet og deployed ofte nok til at forhindre en uoverskuelig ophobning af uløste afhængigheder? For de ovennævnte spørgsmål, adressér om nødvendigt: Hvorfor skete det? Hvordan kan teknisk gæld fjernes? Hvordan kan en gentagelse forhindres? Refinement Ved skalering af Nexus er der mange niveauer af nedbrydning. Kun når Product Backlog items er tilstrækkeligt uafhængige kan de udvælges og arbejdes på uden en overdreven konflikt mellem Scrum Teams i et Nexus. Antallet, hyppighed, varighed og tilstedeværelse af Refinement møder er baseret på de afhængigheder der ligger i Product Backlog. Jo større kompleksitet og afhængigheder, jo mere skal Product Backlog nedbrydes for at fjerne afhængigheder. Product Backlog items passerer gennem forskellige niveauer af nedbrydning fra meget store og vage idéer til handlingsrettet arbejde, som et enkelt Scrum teamet kunne levere i et sprint. Product Backlog nedbrydning ved skalering tjener et dobbelt formål. Det forudsiger hvilket team der vil levere hvilke Product Backlog items, og det identificerer afhængigheder på tværs disse team. Visualisering giver teams mulighed for at overvåge og minimere afhængigheder. Den første del af cross-team Refinement bør bruges på at nedbryde Product Backlog items i tilstrækkelig detaljer til at forstå, hvilke team der kan levere dem, og i hvilken rækkefølge i løbet af kommende Sprints. Den anden del af Refinement bør bruges fokuseret på afhængigheder. Afhængigheder bør identificeres og visualiseres på tværs af teams og Sprints. Teams har brug for disse oplysninger Copyright Scrum.org, 2015 All Rights Reserved Page 8 (Version 1.1)
10 til at ændre på rækkefølgen og fordelingen af deres arbejde for at minimere antallet af crossteam afhængigheder. Tilstrækkelige antal Refinement møder er blevet afholdt under et Sprint, hvis Product Backlog items er klar og kan vælges med minimale afhængigheder under Sprint Planning mødet. Nexus Artifacts Artifacts repræsenterer arbejde eller værdi skabt for at give gennemsigtighed og mulighed for inspektion og tilpasning, som beskrevet i Scrum Guide. Product Backlog Der er én enkelt Product Backlog for hele Nexus og alle dets Scrum Teams. Product Owner er ansvarlig for Product Backlog, herunder dens indhold, tilgængelighed og rækkefølge af opgaver. Ved skalering skal Product Backlog forstås på et niveau, hvor afhængigheder kan identificeres og minimeres. For at understøtte dette må Product Backlog items ofte nedbrydes til et niveau kaldet "thinly sliced" funktionalitet. Product Backlog items anses for at være "ready" til Nexus Sprint Planning, når de kan vælges til implementering i Scrum Teams med ingen eller minimale afhængigheder med andre Scrum Teams. Nexus Goal Under Nexus Sprint Planning mødet formuleres et mål for hele Sprintet. Dette kaldes et Nexus Goal. Det er summen af al det arbejde og Sprint Goals for de enkelte Scrum Teams i et Nexus. Nexus skal demonstrere den funktionalitet, det er udviklet for at opnå et Nexus Goal, på Nexus Sprint Review. Nexus Sprint Backlog Et Nexus Sprint Backlog er sammensat af alle Product Backlog items fra Sprint Backlog i de enkelte Scrum Teams. Det bruges til at synliggøre afhængigheder og flow af arbejde i løbet af Sprintet. Den opdateres mindst en gang dagligt, ofte som en del af Nexus Daily Scrum. Integrated Increment Integrated Increment udgør summen af alt integreret arbejde afsluttet af en Nexus. Integrated Increment skal være brugbare og potentielt release bart hvilket betyder, at det skal opfylde definitionen på "Done". Integrated Increment inspiceres på Nexus Sprint Review. Copyright Scrum.org, 2015 All Rights Reserved Page 9 (Version 1.1)
11 Gennemsigtighed af Artifact Ligesom sin byggesten, Scrum, er Nexus baseret på gennemsigtighed. Et Nexus Integration Team arbejder med Scrum Teams inden for et Nexus og organisationen for at sikre, at gennemsigtighed er tydeligt på tværs af alle artefakter, og at den integrerede tilstand af Increment er bredt forstået. Beslutninger, der træffes på grundlag af tilstanden af Nexus artefakter er kun så effektive som niveauet for gennemsigtigheden af artefakter. Ufuldstændige eller delvise oplysninger vil føre til forkerte eller fejlagtige beslutninger. Virkningen af disse beslutninger kan forøges ved skalering af Nexus. En mangel på fuldstændig gennemsigtighed vil gøre det umuligt at guide en Nexus effektivt for at minimere risici og maksimere værdien. Software skal udvikles, så afhængigheder opdages og løses før teknisk gæld bliver uacceptabel. Uacceptable tekniske gæld forekommer når integrationen gennemføres, og det er uklart, om alle afhængigheder er løst. I disse tilfælde, forbliver de uløste afhængigheder skjult i koden og test base, hvilket sænke den samlede værdi af softwaren. Definition of Done Nexus Integration Team er ansvarlig for en definition af "Done", der kan anvendes til det Integrated Increment der bliver udviklet i hver Sprint. Alle Scrum Teams af et Nexus overholde denne definition af "Done". Increment er "Done", når det er brugbart og potentielt kan releases af Product Owner. En Product Backlog Item kan betragtes som "Done", når funktionaliteten er blevet føjet til produktet og succesfuldt integreret i Incrementet. Alle Scrum Teams er ansvarlige for at udvikle og integrere deres arbejde i et Increment, der opfylder dette. Individuelle Scrum Teams kan vælge at anvende en strengere definition af "Done" inden for deres eget team, men kan ikke anvende mindre strenge kriterier end aftalt for Increment. Slut bemærkninger Nexus er gratis og stilles til rådighed i denne Guide. Som med Scrum framework er Nexus' roles, artifacts, events og rules uforanderlige. Selvom det er muligt kun at anvende dele af Nexus, er resultatet ikke Nexus. Anerkendelse Nexus og Scaled Professional Scrum er i samarbejde udarbejdet af Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber og Gunther Verheyen. Copyright Scrum.org, 2015 All Rights Reserved Page 10 (Version 1.1)
The Scrum Guide TM. Den ultimative guide til Scrum : Spillets regler. Juli Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland
The Scrum Guide TM Den ultimative guide til Scrum : Spillets regler Juli 2016 Udviklet og vedligeholdt af Ken Schwaber og Jeff Sutherland Indholdsfortegnelse Formålet med Scrum Guiden... 3 Definition af
Læs mereScrum 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 mereThe Scrum Guide. Den ultimative guide til Scrum: Spillets regler. November 2017 DANISH
The Scrum Guide Den ultimative guide til Scrum: Spillets regler November 2017 DANISH Udviklet og vedligeholdt af Scrum-skaberne: Ken Schwaber og Jeff Sutherland Indholdsfortegnelse Formålet med Scrum Guiden...
Læs mereså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 mereAgile 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 mereFebruar 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 mereDet 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 mereVejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)
Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Version 2.10 / 04-01-2018 / PHM Indholdsfortegnelse Indledning... 3 Baggrund... 3 Iterativ udvikling med ASE-modellen... 4 Udviklingsprocessen
Læs mereKvalitetssikring 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 mereDynamisk 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 mereAccelerate 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 mereIT 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 mereNye 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 mereDANMARKS 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 mereSammenligning 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 mereIT-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 mereBehavior 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 mereBilag 10 - Forslag til struktur og principper (metamodel) for en forretningsdomænemodel
Bilag 10 Punkt 11.3 Bilag 10 - Forslag til struktur og principper (metamodel) for en forretningsdomænemodel Viden om forretningsdomænerne sikrer en solid forståelse af forretningens problemstillinger,
Læs mereUd 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 merePlan for præsentationen
Rejsen på vej til Test Drevet Udvikling i Uddannelses- og Forskningsministeriet Præsenteret af Klaus Olsen Willy Kofoed kontorchef i Uddannelses- og Forskningsministeriet Kenneth B Andersen IT Minds På
Læs mereThe LEGO Journey: Building an agile test foundation one brick at the time. Casper Gaardland Englund. Stephan Hjelmdal Nielsen. 2013 The LEGO Group l
The LEGO Journey: Building an agile test foundation one brick at the time Casper Gaardland Englund Stephan Hjelmdal Nielsen 2013 The LEGO Group l TestExpo 15 Hvem er vi? Casper Englund Uddannet datamatiker
Læs mereDE 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 mereIt-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 mereBring lys over driften af belysningen
Bring lys over driften af belysningen CityTouch LightPoint Asset Management system for belysning CityTouch LightPoint / Asset Management 3 Velkommen til den nye intelligens inden for belysning. Professionel
Læs mereVelkommen 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 mereKombinér. tirsdag d. 20. september 2011 Rovsing Management Agile Team
Kombinér og tirsdag d. 20. september 2011 Rovsing Management Agile Team og byder Kurser og rådgivning Udbrede PRINCE2 Udbrede PRINCE2 metoden i det danske uddannelsessystem Metropolskolen Niels Brock Ingeniørhøjskolen
Læs merePlanlæ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 mereAgil 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 mereDen digitale virkelighed
Hvem er vi What is hot 2018 undersøgelse Resultat og top scorer Trends indenfor top scorer Den digitale virkelighed Jannik Andersen kaastrup andersen Erfaringer og trends vi oplever Teknologiske aspekt
Læs mereKvalitetssikring 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 mereAgil-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 mereLeverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV
Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Indhold 1. DEFINITIONER... 2 2. BAGGRUND OG FORMÅL... 2 3. MODERNISERINGSSTYRELSENS YDELSER... 3 4. INSTITUTIONENS
Læs mereEA3 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 mereVejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3)
Vejledning til udviklingsprocessen for semesterprojekt 3 (PRJ3) Version 2.00 / 14-09-2016 / PHM Indholdsfortegnelse Indledning... 3 Baggrund... 3 Iterativ udvikling med ASE-modellen... 4 Udviklingsprocessen
Læs mereALGORITMER OG DATA SOM BAGGRUND FOR FORUDSIGELSER 8. KLASSE. Udfordring
ALGORITMER OG DATA SOM BAGGRUND FOR FORUDSIGELSER 8. KLASSE Udfordring INDHOLDSFORTEGNELSE 1. Forløbsbeskrivelse... 3 1.1 Overordnet beskrivelse tre sammenhængende forløb... 3 1.2 Resume... 5 1.3 Rammer
Læs mereVÆ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 mereLeverings- og vedligeholdelsesvilkår. for. Økonomistyrelsen lokale datavarehus ØS LDV
Leverings- og vedligeholdelsesvilkår for Økonomistyrelsen lokale datavarehus ØS LDV Økonomistyrelsen Landgreven 4, postboks 2193 DK-1017 København K (i det følgende benævnt Økonomistyrelsen) 1 INDHOLDSFORTEGNELSE
Læs mereBibDok. 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Årets Projektdag 2016 Troels Andersen-Lind SEGES AGILE IT - STRICTLY BUSINESS
Årets Projektdag 2016 Troels Andersen-Lind SEGES AGILE IT - STRICTLY BUSINESS AGENDA Hvem-Hvad-Hvor SEGES Kvæg - strictly business Hvad er agile Hvorfor fungerer KvægIT agile 2... HVEM ER SEGES SEGES er
Læs mereDet agile landskab. Få et overblik over agile metoder på team-, projekt- og enterprise-niveau
Det agile landskab Få et overblik over agile metoder på team-, projekt- og enterprise-niveau Indholdsfortegnelse Det agile landskab 1 Opdeling af agile metoder 2 Det agile landkort 3 Metoder på teamniveau
Læs mereProcedurer 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 mereIntroduktion 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#TestExpo. Test I en skaleret udviklingsmodel
#TestExpo Test I en skaleret udviklingsmodel 01 Hvem er jeg? Baggrund Konstabel i Flyvevåbnet Uddannelse SAFe SPC, SCRUM master, ISEB foundation/practitioner, CAT trainer, TMap Test Engineer, TMap Test
Læs mere[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 mereEksamineret Scrum Master
Eksamineret Scrum Master Bliv en succesfuld Scrum Master Scrum er en metode, der hjælper organisationer med at få mest muligt ud af deres indsatser. Metoden er en af de mest udbredte til at styre komplekse
Læs mereNoter 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 mereProduct 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 mereTeams 7 bevidsthedsniveauer
Teams 7 bevidsthedsniveauer Af Richard Barrett Oversat til dansk af Benjamin Lindquist og Thobias Laustsen Teams vækster og udvikler sig ved at mestre de syv niveauer af team bevidsthed. De syv forskellige
Læs mereAccelerace 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 mereIT 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 mereStrategiudrulning. Ledelsens vejledning. DI-version
DI-version 2013-11-20 Ledelsens vejledning 1-1-1 - STU - Ledelsens Vejledning - 2013-11-2011-20 Alle rettigheder tilhører DI side 1 af 9 Instruktion til kaizenleder Rettigheder DI ejer alle rettigheder
Læs mereArbejdsmiljøcertificering Selvevaluering i forhold til DS/OHSAS og bek. 87
Arbejdsmiljøcertificering Selvevaluering i forhold til DS/OHSAS 18001 og bek. 87 Punkt Emne Bemærkninger Handlingsplan 4.1 Generelle krav Organisationen skal etablere og vedligeholde et arbejdsmiljøledelses-system
Læs mereKvalitetsplan for Høng Gymnasium og HF 2014
Kvalitetsplan for Høng Gymnasium og HF 2014 Kvalitetsplanen er udarbejdet foråret 2014. Den er resultatet af det kontinuerlige arbejde, der foregår på skolen med henblik på optimering og udvikling af væsentlige
Læs mereVisual 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 mereTeknologiforståelse. Måloversigt
Teknologiforståelse Måloversigt Fagformål Eleverne skal i faget teknologiforståelse udvikle faglige kompetencer og opnå færdigheder og viden, således at de konstruktivt og kritisk kan deltage i udvikling
Læs mereAndet 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 mereFå lederne til at engagere sig. Opret et Workplace projektteam. Præsentér din business case for ledelsen
Quick Launch Guide Du er her, fordi du har besluttet at ændre måden, din virksomhed forbinder, kommunikerer og samarbejder på ved at bruge Workplace. Det er meget spændende, og vi kan ikke vente, til du
Læs mereOpen Call. Sprint:Digital søger sprint-facilitatorer
Open Call søger sprint-facilitatorer Open call Kan I hjælpe små og mellemstore virksomheder med deres digitale udfordringer og facilitere design-sprint? Så er det jer, vi søger til at være sprint-facilitator
Læs mereScrum 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 mereSpil om LEDELSE. Rigtig god fornøjelse!
Alle virksomheder har medarbejdere, som ledes af ledere. Derfor spørger både ledere og medarbejdere sig selv, hvad effektiv ledelse egentlig er og hvad det består af. Undersøgelser har samtidig vist, at
Læs mereKoncept 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 mereAgenda. 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 mereRegion Midtjylland Proces for Change Management
Region Midtjylland Proces for Change Management Version 1.1 Forord Dette dokument beskriver RMIT s Change Management proces. Processen beskriver minimumskravene (need to have) for at få processen til at
Læs mereInnovationens Syv Cirkler
Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for
Læs mereSYSTEMDOKUMENTATION AF POC
DIGITALISERINGSSTYRELSEN POC PÅ ORKESTRERINGSKOMPONENTEN SYSTEMDOKUMENTATION AF POC Version: 1.1 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. All rights reserved Dokumenthistorik Version
Læs merePRINCE2 - 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 merewww.robotool.com Food og Pharma Robotbaserede løsninger til Food og Pharma industrien
www.robotool.com Food og Pharma Robotbaserede løsninger til Food og Pharma industrien ROBOTOOL // velkommen til robotool Velkommen til Robotool RoboTool har siden 1997 beskæftiget sig med udvikling og
Læs mereHos 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 mereUdkast: Projektoplæg vedrørende visionsproces for Aalborg Kommune MAR18
#BREVFLET# Click here to enter text. Dokument: Neutral titel Borgmesterkontoret Sagsnr./Dok.nr. 2018-004065 / 2018-004065-32 Borgmesterens Forvaltning Boulevarden 13 9000 Aalborg Init.: LBS 22-03-2018
Læs mereKonference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD
Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites
Læs mereMasterplan for Rødovrevej 382
2011 Masterplan for Rødovrevej 382 Kompetenceudvikling i botilbud i Rødovre Kommune og Hvidovre Kommune Introduktion Denne masterplan er udarbejdet på baggrund af det kompetenceudviklingsforløb, som personalet
Læs mere(Bilaget ligger på i pdfformat og word-format.)
BILAG 7 DEN AGILE METODE OG SAMARBEJDSORGANISATION (Bilaget ligger på http://silkeborgkommune.dk/erhverv/udbud/varer-og-tjenesteydelser i pdfformat og word-format.) Skemaer udfyldes af Tilbudsgiver. Besvarelsen
Læs mereDen bedste løsning er den som bliver anvendt
Den bedste løsning er den som bliver anvendt RISMA Vi er dedikeret til din succes Pålidelig rettidig information spiller en nøglerolle for succes i dagens omskiftelige forretningsverden. Samtidigt har
Læs mereÆ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 mereUddelegering? Du er dig eller din leder eller en anden leder
Uddelegering? Du er dig eller din leder eller en anden leder Arbejder du ofte med opgaver, som kun du kan udføre? Tør du uddelegere? Eller er du bange for at miste kontrollen? Har du ikke tid til at uddelegere?
Læs mereMarkedsinput til Erhvervsstyrelsens itrammeaftale Delaftale 1 og 2
Markedsinput til Erhvervsstyrelsens itrammeaftale 2020-2024 Delaftale 1 og 2 23. maj 2019 Rasmus Pleidrup, Mads Bielefeldt Stjernø og Anita Smed Indhold 1 Mål med kommende it-rammeaftale 2 Tidsplan for
Læs mereTest i Danmark 2014. Undersøgelse på TestExpo 2014
Test i Danmark 2014 Undersøgelse på TestExpo 2014 Indledning I forbindelse med TestExpo-konferencen (www.testexpo.dk) den 30/1 2014 i Bella Center i København blev der foretaget en spørgeskemaundersøgelse.
Læs mereNovell Teaming 2.0. Novell. 29. juli 2009. Hurtig start. Starte Novell Teaming. Lære Novell Teaming-brugergrænsefladen og funktionerne at kende
Novell Teaming 2.0 29. juli 2009 Novell Hurtig start Når du begynder at bruge Novell Teaming, kan det være en god idé at starte med at konfigurere dit personlige arbejdsområde og oprette et teamarbejdsområde.
Læs mereService til Industrien
Service til Industrien - Aftaler der sikrer din forretning Fasthold maksimal effektivitet gennem dine anlægs levetid En investering i selv det bedste anlæg er ingen garanti for høj oppetid og effektivitet
Læs mereGuide 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 mereForløbskoordination i kommunalt regi
21. april 2009 Forløbskoordination i kommunalt regi Martin Sandberg Buch cand.scient.adm. msb@dsi.dk Hvordan kommer man i gang? 1. Hvor er koordinationsproblemerne? 2. Hvad skal koordineres? 3. Hvilken
Læs mereSpillemyndighedens 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 mereStudentervæksthus UCL. Kompasset
Studentervæksthus UCL Introduktion I Studentervæksthus UCL Skaber du noget nyt med din profession Sætter du din faglighed i spil på nye måder Lærer du at handle på dine idéer Udfordrer du dit talent Udbygger
Læs mereHvad kræver en opgradering af dit ERP-system?
Hvad kræver en opgradering af dit ERP-system? At opgradere dit ERP-system kan være meget omfangsrigt. Vi har redegjort for, hvilke elementer du skal være opmærksom og forberedt på inden du skifter. Hvad
Læs mereScrum og agile. Torsdag d. 29. november 2007
Projektbar (på vej hjem møde) Scrum og agile Torsdag d. 29. november 2007 Agenda Scrum kort overblik Portefølje og Roadmap pplanlægning g Scrum Implementation Atives produkter Scrum Team Agile coaching:
Læs mereApril a 106. anvisning aftale og kommunikation. Tjekliste. for kravspecifikation til Facilities Management-værktøj
April 2016 a 106 anvisning aftale og kommunikation Tjekliste for kravspecifikation til Facilities Management-værktøj Kolofon 2016-04- 08
Læs mereCertificering ISO 14001:2015
Certificering ISO 14001:2015 Nr. Æ-1B, Rev. Dato: 29-8.2018 Sagsnummer: E-mail: Rekvirent: Adresse(r): Auditor Dato: 2017.0070.0006 co@sk-as.dk Søborg Køl A/S Brøndbytoften 13, 2605 Brøndby PBP 05-12-2018
Læs mereErfaringer med gennemførelse af store IT-projekter. Fagdirektør Thomas Monefeldt, Udvikling og Forenklingsstyrelsen Skatteministeriet
Erfaringer med gennemførelse af store IT-projekter Fagdirektør Thomas Monefeldt, Udvikling og Forenklingsstyrelsen Skatteministeriet 1 Indhold Introduktion til ImplementeringsCenter for Inddrivelse (ICI)
Læs mereVIRKSOMHEDERNE KAN FÅ MERE UD AF DERES INNOVATION
Marts 215 VIRKSOMHEDERNE KAN FÅ MERE UD AF DERES INNOVATION AF CHEFKONSULENT HANNE MERETE LASSEN HAML@DI.DK Mange danske virksomheder arbejder med innovation for at styrke deres konkurrenceevne og indtjening.
Læs merePsykisk arbejdsmiljø ved fusioner
Psykisk arbejdsmiljø ved fusioner Når afdelinger eller virksomheder skal sammenlægges MEDINDFLYDELSE og MEDBESTEMMELSE. KRAV til INFORMATIONER. med RESPEKT SE MULIGHED FREMFOR BEGRÆNSNINGER ÅBENHED OG
Læs mereVærdibaseret styring og optimering af projektporteføljen
17. April 2007 Værdibaseret styring og optimering af projektporteføljen Programchef Thomas Steinmetz, G4S Teamleder Charlotte Blou Sand, Creuna Copyright Creuna Danmark A/S Om Creuna Skandinavisk IT-konsulenthus
Læs mereKom 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 mereHvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik
Hvad er en referencelinie? Tidsligt fastlagt Veldefineret tilstand af mellemprodukter Mellemprodukter vurderes Sandhedens øjeblik En referencelinie er en koordineret og veldefineret tilstand i et projekt,
Læs mereBackEnd Programmering PHP
17708 08/ 02/ 2013 BackEnd Programmering PHP Prototype (CMS system) 371615m02dka.sub.ots.dk/historyspot eller linket CMS system på: qrguide.mmd.eal.dk Login CMS Username: admin Password: 1234 Source kode
Læs mereTrojka. Multiple choice opgaver Kapitel Ledelse i praksis, 3. udgave, 2013
Opgave nr. 1 Lederens konfliktfokus Lederen bør i sin konflikthåndtering have fokus på: a Hvem af konfliktens parter der fagligt har ret b Om det er en konflikt, der skader produktiviteten c Uoverensstemmelser
Læs mereImpact værktøj retningslinjer
Impact værktøj retningslinjer Værktøj fra Daphne III projektet IMPACT: Evaluation of European Perpetrator Programmes (Programmet for evaluering af Europæiske udøvere af krænkende adfærd) Impact værktøj
Læs mereScrum 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 mereLightning 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 mereDigitalisering - hvordan håndterer vi det i SU?
Digitalisering - hvordan håndterer vi det i SU? Nye IT-systemer, digital kontakt til borgerne, mere selvbetjening, digitale redskaber integreret i ens arbejde. Den offentlige sektor er i rivende udvikling
Læs mereHassansalem.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