ݺߣ

ݺߣShare a Scribd company logo

Intro til agile 31 aug 2015

•
•
BestBrains
BestBrains

Mangler du en pragmatisk introduktion til Scrum og Agile? Leder du efter startblokken for at komme i gang med agile projekter? Eller er dit behov essentiel viden om den agile proces, så du forstår hvad der forventes af dig? På en aften vil du få løftet din forståelse af de tre mest udbredte agile metoder: Scrum, Kanban og XP. Du vil få præsenteret de enkelte metoders bestanddele og hvordan de hænger sammen. Du vil forstå metodernes forskelle og vil også få et indblik i hvordan de kan kombineres. Alt i alt vil du få et godt grundlag på din vej til at blive en dygtig agil praktiker.

1 of 33
Download to read offline
VELKOMMEN
 VI STARTER MED AT MINGLE! men med regler: • Gå igang med det samme!
 (må gerne smide overtøjet først) • Find eller dan en gruppe og snak om “hvad I kender til agile?” • Hvis gruppen bliver flere end 
 3 personer, så split gruppen i to
3 AGILE METODER PÅ ÉN AFTEN Cafémøde hos BestBrains, 31. august 2015
 af Nino Stokbro Ag
PROGRAM • Det agile fundament • Scrum Framework • Kanban Software Development • eXtreme Programming Spørg endelig undervejs!
DET AGILE FUNDAMENT Et fælles værdisæt for alle agile praktikker • agile kendetegn • værdierne i det agile manifest • principperne i det agile manifest
AGILE KENDETEGN EMPIRISK PROCES KONTROL kontrol af uforudsigelige systemer gennem transparens, inspektion og tilpasning
AGILE KENDETEGN ITERATIVT & INKREMENTELT via gentagne forløb af identiske skridt leveres trinvist i dele der bygger oven på hinanden
AGILE KENDETEGN SELVORGANISERING teamet gøres handlekraftigt og beslutningsdygtig
AGILE KENDETEGN HURTIG FEEDBACK hurtig feedback søges aktivt
 og bruges til at skabe forbedringer
AGILE KENDETEGN OPTIMERING AF FLOW fokus på optimering af hele kæden, ikke enkelt led fokus på at afslutte opgaver
AGILE KENDETEGN LETVÆGTSPLANLÆGNING planlæg kun tilstrækkeligt, fokuser på afhængigheder planlægning er vigtig, planen er ikke
AGILE KENDETEGN KONTINUERLIGE FORBEDRINGER et konstant fokus på små forbedringer driver fremgang
AGILE KENDETEGN SPILLE FOR AT VINDE Fokus på fælles sejr, ikke individuelt-styrket i nederlag
AGILE MANIFEST
 4 VÆRDISÆTNINGER • Individer og samspil
 frem for arbejdsgange og værktøjer • Software der virker
 frem for omfattende dokumentation • Kunde-samarbejde
 frem for kontraktforhandling • Handle på forandringer
 frem for fastholdelse af en plan
4. Forretningsrepræsentanter og udviklere skal samarbejde dagligt gennem hele projektet.
 
 
 5. Opbyg projekter omkring motiverede personer. Giv dem de rette omgivelser og den støtte de behøver, og hav tillid til at de klarer opgaven.
 
 6. Den mest effektive måde til videregivelse af oplysninger til og inden for en gruppe er ansigt-til-ansigt samtale.
 AGILE MANIFESTO 12 PRINCIPPER, 1-6 1. Vores højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering værdifuld software.
 
 2. Tag imod skiftende krav, selv sent i udviklingsforløbet. Agile processer tøjler ændringer til kundens konkurrencemæssige fordel.
 
 3. Vi leverer brugbart software ofte, fra et par uger til et par måneder, med præference for kortere intervaller.
 Kontinuerlige leverancer værdsæt ændringer Korte iterationer Samarbejde Motivation Ansigt-til-ansigt
10. Enkelhed
 — kunsten at maksimere mængden af arbejde, der ikke udføres —
 er afgørende.
 
 11. De bedste arkitekturer, krav og designs opstår ud af selv-organiserende teams.
 
 12. Med jævne mellemrum reflekterer teamet over, hvordan de kan blive mere effektive, op justerer deres adfærd i overensstemmelse hermed. AGILE MANIFESTO 12 PRINCIPPER, 7-12 7. Software der virker, er den primære målestok for fremdrift.
 
 8. Agile processer fremmer bæredygtig udvikling. Sponsorere, udviklere og brugere skal kunne opretholde et fast udviklingstempo på ubestemt tid.
 
 9. Konstant opmærksomhed på teknisk ekspertise og godt design øger agilitet. Software, der virker Bæredygtig udvikling Teknisk ekspertise Enkelthed Selvorganisering Kontinuerlig forbedring
10 MIN PAUSE Snak i pausen om: - hvordan relaterer det sig til din hverdag? - hvad giver mening i forhold til din kontekst?
SCRUM FRAMEWORK JEFF SUTHERLAND & KEN SCHWABER Et framework for samarbejde i produktudvikling
SCRUM FRAMEWORK UDVIKLINGSPROCESSEN Scrum artifakter: ‣ Product Backlog ‣ Sprint Backlog ‣ Product Increment ‣ Definition of Ready ‣ Definition of Done Scrum aktiviteter: ‣ Backlog Refinement ‣ Sprint Planning I & II ‣ Daily Scrum ‣ Sprint Review ‣ Sprint Retrospective Scrum roller: ‣ Product Owner ‣ Scrummaster ‣ Development Team
Emphasis on Process Linear Process Style Focus on Upfront Planning Comprehensive Documentation Centralized Managed Organisation Command and Control Management Style Plan Conformity is the Primary Succes Criteria Customer Involvement in Project Start and Finish Return of Investment upon Project Completion Process Centric Quality Assurance Emphasis on People Iterative Process Style Limiting Upfront Planning Only Required Documentation Decentralized Self-Organisation Servant Leadership Management Style Business Value is the Primary Succes Criteria Customer Involvement Throughout Project Return of Investment Early and Throughout Customer Centric Quality Assurance SCRUM TRADITIONAL ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌
KANBAN SOFTWARE DEVELOPMENT DAVID J. ANDERSON Sæt farten ned, for at komme hurtigere frem
KANBAN SYSTEMS (VISUELT KORT / OPGAVETAVLE) THE IMPERIAL GARDEN I TOKYO
KANBAN SOFTWARE DEVELOPMENT INSPIRERET AF LEAN THINKING Kanban kerne praktikker: ‣ Visualize the workflow ‣ Limit work in process (WIP) ‣ Make process policies explicit ‣ Manage flow ‣ Improve collaboratively
No prescribed roles
 Continuous Delivery Work is ‘pulled’ through the system
 (single piece flow) Changes can be made at any time Important measures: Lead time & Cycle time Can work in operational environments with a high degree of variability in priority Pre-defined roles of 
 Scrum master, Product owner and team member Timeboxed sprints Work is ‘pushed’ through the system in batches
 (the sprint backlog) No changes allowed mid-sprint Important measure: Velocity Requires situations where work can be prioritized in batches that can be left alone SCRUM KANBAN ⬌ ⬌ ⬌ ⬌ ⬌ ⬌
10 MIN PAUSE Snak i pausen om: - hvordan adskiller disse idéer sig jeres arbejdspraksis? - kan I bruge nogle af disse idéer til at forbedre jer?
EXTREME PROGRAMMING KENT BECK Gode velkendte udviklingspraktikker ført ud i ekstremet
EXTREME PROGRAMMING Praktikker: ‣ User Stories ‣ The Planning Game ‣ Whole Team ‣ On-site customer ‣ Acceptance Tests ‣ Small Releases ‣ Continuous Integration
 ‣ Collective Ownership ‣ Coding Standard ‣ Metaphor ‣ Sustainable Pace ‣ Pair Programming ‣ Test Driven Development ‣ Refactoring ‣ Simple Design
EXTREME PROGRAMMING Primære principper: ‣ Rapid feedback ‣ Assume simplicity ‣ Incremental change ‣ Embracing change ‣ Quality work
 Sekundære principper: ‣ Teach learning ‣ Small initial investment ‣ Play to win ‣ Open, honest communication ‣ Accepted responsibility ‣ Local adaptation
Regler Planning ‣ User stories are written. ‣ Release planning creates the release schedule. ‣ Make frequent small releases. ‣ The project is divided into iterations. ‣ Iteration planning starts each iteration. Managing ‣ Give the team a dedicated open work space. ‣ Set a sustainable pace. ‣ A stand up meeting starts each day. ‣ The Project Velocity is measured. ‣ Move people around. ‣ Fix XP when it breaks.
 Designing ‣ Simplicity. ‣ Choose a system metaphor. ‣ Use CRC cards for design sessions. ‣ Create spike solutions to reduce risk. ‣ No functionality is added early. ‣ Refactor whenever and wherever possible. Coding ‣ The customer is always available. ‣ Code must be written to agreed standards. ‣ Code the unit test first. ‣ All production code is pair programmed. ‣ Only one pair integrates code at a time. ‣ Integrate often. ‣ Set up a dedicated integration computer. ‣ Use collective ownership. Testing ‣ All code must have unit tests. ‣ All code must pass all unit tests before it can be released. ‣ When a bug is found tests are created. ‣ Acceptance tests are run often and the score is published. EXTREME PROGRAMMING
AGILE, FRA IDÉ TIL VÆRDI DEN AGILE PROCES MED SCRUM
SOFTWARE ENGINEERING EN KLASSISK METAFOR FOR SOFTWARE UDVIKLING
SOFTWARE SURGERY EN ALTERNATIV METAFOR FOR SOFTWARE UDVIKLING
SOFTWARE EXPEDITION ENDNU EN METAFOR FOR SOFTWARE UDVIKLING
TAK, OG FORTSAT GOD AFTEN Og husk evalueringer, tak.

More Related Content

Intro til agile 31 aug 2015

  • 1. VELKOMMEN
 VI STARTER MED AT MINGLE! men med regler: • Gå igang med det samme!
 (må gerne smide overtøjet først) • Find eller dan en gruppe og snak om “hvad I kender til agile?” • Hvis gruppen bliver flere end 
 3 personer, så split gruppen i to
  • 2. 3 AGILE METODER PÅ ÉN AFTEN Cafémøde hos BestBrains, 31. august 2015
 af Nino Stokbro Ag
  • 3. PROGRAM • Det agile fundament • Scrum Framework • Kanban Software Development • eXtreme Programming Spørg endelig undervejs!
  • 4. DET AGILE FUNDAMENT Et fælles værdisæt for alle agile praktikker • agile kendetegn • værdierne i det agile manifest • principperne i det agile manifest
  • 5. AGILE KENDETEGN EMPIRISK PROCES KONTROL kontrol af uforudsigelige systemer gennem transparens, inspektion og tilpasning
  • 6. AGILE KENDETEGN ITERATIVT & INKREMENTELT via gentagne forløb af identiske skridt leveres trinvist i dele der bygger oven på hinanden
  • 7. AGILE KENDETEGN SELVORGANISERING teamet gøres handlekraftigt og beslutningsdygtig
  • 8. AGILE KENDETEGN HURTIG FEEDBACK hurtig feedback søges aktivt
 og bruges til at skabe forbedringer
  • 9. AGILE KENDETEGN OPTIMERING AF FLOW fokus på optimering af hele kæden, ikke enkelt led fokus på at afslutte opgaver
  • 10. AGILE KENDETEGN LETVÆGTSPLANLÆGNING planlæg kun tilstrækkeligt, fokuser på afhængigheder planlægning er vigtig, planen er ikke
  • 11. AGILE KENDETEGN KONTINUERLIGE FORBEDRINGER et konstant fokus på små forbedringer driver fremgang
  • 12. AGILE KENDETEGN SPILLE FOR AT VINDE Fokus på fælles sejr, ikke individuelt-styrket i nederlag
  • 13. AGILE MANIFEST
 4 VÆRDISÆTNINGER • Individer og samspil
 frem for arbejdsgange og værktøjer • Software der virker
 frem for omfattende dokumentation • Kunde-samarbejde
 frem for kontraktforhandling • Handle på forandringer
 frem for fastholdelse af en plan
  • 14. 4. Forretningsrepræsentanter og udviklere skal samarbejde dagligt gennem hele projektet.
 
 
 5. Opbyg projekter omkring motiverede personer. Giv dem de rette omgivelser og den støtte de behøver, og hav tillid til at de klarer opgaven.
 
 6. Den mest effektive måde til videregivelse af oplysninger til og inden for en gruppe er ansigt-til-ansigt samtale.
 AGILE MANIFESTO 12 PRINCIPPER, 1-6 1. Vores højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering værdifuld software.
 
 2. Tag imod skiftende krav, selv sent i udviklingsforløbet. Agile processer tøjler ændringer til kundens konkurrencemæssige fordel.
 
 3. Vi leverer brugbart software ofte, fra et par uger til et par måneder, med præference for kortere intervaller.
 Kontinuerlige leverancer værdsæt ændringer Korte iterationer Samarbejde Motivation Ansigt-til-ansigt
  • 15. 10. Enkelhed
 — kunsten at maksimere mængden af arbejde, der ikke udføres —
 er afgørende.
 
 11. De bedste arkitekturer, krav og designs opstår ud af selv-organiserende teams.
 
 12. Med jævne mellemrum reflekterer teamet over, hvordan de kan blive mere effektive, op justerer deres adfærd i overensstemmelse hermed. AGILE MANIFESTO 12 PRINCIPPER, 7-12 7. Software der virker, er den primære målestok for fremdrift.
 
 8. Agile processer fremmer bæredygtig udvikling. Sponsorere, udviklere og brugere skal kunne opretholde et fast udviklingstempo på ubestemt tid.
 
 9. Konstant opmærksomhed på teknisk ekspertise og godt design øger agilitet. Software, der virker Bæredygtig udvikling Teknisk ekspertise Enkelthed Selvorganisering Kontinuerlig forbedring
  • 16. 10 MIN PAUSE Snak i pausen om: - hvordan relaterer det sig til din hverdag? - hvad giver mening i forhold til din kontekst?
  • 17. SCRUM FRAMEWORK JEFF SUTHERLAND & KEN SCHWABER Et framework for samarbejde i produktudvikling
  • 18. SCRUM FRAMEWORK UDVIKLINGSPROCESSEN Scrum artifakter: ‣ Product Backlog ‣ Sprint Backlog ‣ Product Increment ‣ Definition of Ready ‣ Definition of Done Scrum aktiviteter: ‣ Backlog Refinement ‣ Sprint Planning I & II ‣ Daily Scrum ‣ Sprint Review ‣ Sprint Retrospective Scrum roller: ‣ Product Owner ‣ Scrummaster ‣ Development Team
  • 19. Emphasis on Process Linear Process Style Focus on Upfront Planning Comprehensive Documentation Centralized Managed Organisation Command and Control Management Style Plan Conformity is the Primary Succes Criteria Customer Involvement in Project Start and Finish Return of Investment upon Project Completion Process Centric Quality Assurance Emphasis on People Iterative Process Style Limiting Upfront Planning Only Required Documentation Decentralized Self-Organisation Servant Leadership Management Style Business Value is the Primary Succes Criteria Customer Involvement Throughout Project Return of Investment Early and Throughout Customer Centric Quality Assurance SCRUM TRADITIONAL ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌ ⬌
  • 20. KANBAN SOFTWARE DEVELOPMENT DAVID J. ANDERSON Sæt farten ned, for at komme hurtigere frem
  • 21. KANBAN SYSTEMS (VISUELT KORT / OPGAVETAVLE) THE IMPERIAL GARDEN I TOKYO
  • 22. KANBAN SOFTWARE DEVELOPMENT INSPIRERET AF LEAN THINKING Kanban kerne praktikker: ‣ Visualize the workflow ‣ Limit work in process (WIP) ‣ Make process policies explicit ‣ Manage flow ‣ Improve collaboratively
  • 23. No prescribed roles
 Continuous Delivery Work is ‘pulled’ through the system
 (single piece flow) Changes can be made at any time Important measures: Lead time & Cycle time Can work in operational environments with a high degree of variability in priority Pre-defined roles of 
 Scrum master, Product owner and team member Timeboxed sprints Work is ‘pushed’ through the system in batches
 (the sprint backlog) No changes allowed mid-sprint Important measure: Velocity Requires situations where work can be prioritized in batches that can be left alone SCRUM KANBAN ⬌ ⬌ ⬌ ⬌ ⬌ ⬌
  • 24. 10 MIN PAUSE Snak i pausen om: - hvordan adskiller disse idéer sig jeres arbejdspraksis? - kan I bruge nogle af disse idéer til at forbedre jer?
  • 25. EXTREME PROGRAMMING KENT BECK Gode velkendte udviklingspraktikker ført ud i ekstremet
  • 26. EXTREME PROGRAMMING Praktikker: ‣ User Stories ‣ The Planning Game ‣ Whole Team ‣ On-site customer ‣ Acceptance Tests ‣ Small Releases ‣ Continuous Integration
 ‣ Collective Ownership ‣ Coding Standard ‣ Metaphor ‣ Sustainable Pace ‣ Pair Programming ‣ Test Driven Development ‣ Refactoring ‣ Simple Design
  • 27. EXTREME PROGRAMMING Primære principper: ‣ Rapid feedback ‣ Assume simplicity ‣ Incremental change ‣ Embracing change ‣ Quality work
 Sekundære principper: ‣ Teach learning ‣ Small initial investment ‣ Play to win ‣ Open, honest communication ‣ Accepted responsibility ‣ Local adaptation
  • 28. Regler Planning ‣ User stories are written. ‣ Release planning creates the release schedule. ‣ Make frequent small releases. ‣ The project is divided into iterations. ‣ Iteration planning starts each iteration. Managing ‣ Give the team a dedicated open work space. ‣ Set a sustainable pace. ‣ A stand up meeting starts each day. ‣ The Project Velocity is measured. ‣ Move people around. ‣ Fix XP when it breaks.
 Designing ‣ Simplicity. ‣ Choose a system metaphor. ‣ Use CRC cards for design sessions. ‣ Create spike solutions to reduce risk. ‣ No functionality is added early. ‣ Refactor whenever and wherever possible. Coding ‣ The customer is always available. ‣ Code must be written to agreed standards. ‣ Code the unit test first. ‣ All production code is pair programmed. ‣ Only one pair integrates code at a time. ‣ Integrate often. ‣ Set up a dedicated integration computer. ‣ Use collective ownership. Testing ‣ All code must have unit tests. ‣ All code must pass all unit tests before it can be released. ‣ When a bug is found tests are created. ‣ Acceptance tests are run often and the score is published. EXTREME PROGRAMMING
  • 29. AGILE, FRA IDÉ TIL VÆRDI DEN AGILE PROCES MED SCRUM
  • 30. SOFTWARE ENGINEERING EN KLASSISK METAFOR FOR SOFTWARE UDVIKLING
  • 31. SOFTWARE SURGERY EN ALTERNATIV METAFOR FOR SOFTWARE UDVIKLING
  • 32. SOFTWARE EXPEDITION ENDNU EN METAFOR FOR SOFTWARE UDVIKLING
  • 33. TAK, OG FORTSAT GOD AFTEN Og husk evalueringer, tak.