Lean SW-Development mit Scrum und Kanban

  • 1,930 views
Uploaded on

Historie des Lean SW-Development und Vergleich der beiden Ausprägungen Scrum und Kanban.

Historie des Lean SW-Development und Vergleich der beiden Ausprägungen Scrum und Kanban.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,930
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Lean SW-Development mit Scrum und Kanban Systemlösungen Brief Bonn , 17. Juli 20 10
  • 2. Historie Lean SW-Development
    • 1947-1970: Toyota entwickelt Grundideen beim Wiederaufbau (1947)
    • 1986: Hirotaka Takeuchi‘s wissensch. Studien zu „product development“
    • 1990: Prozess wird in der amerik. Wirtschaft erprobt (Schwaber, Sutherland…)
    • 1995: Erste öffentliche Publikation auf der OOPSLA 95 (Schwaber & Sutherland)
    • 2001: Buchveröffentlichung durch Mike Beedle und Ken Schwaber zu Scrum
    • 2001: Agile Manifest wird veröffentlicht, Agile SWE hat sich etabliert
    • 2005-2007: David Anderson probiert Kanban bei Microsoft aus, bloggt darüber
    • 2009: Corey Ladas veröffentlicht Scrumban
    • 2010: Buchveröffentlichung durch David Anderson zu Kanban
    • Parallele Entwicklungen:
      • Extreme Programming (XP), ca. 1996-1998
      • Crystal, ca. 1992-1997
      • Feature Driven Development (FDD), ca. 1997-2002
  • 3. Kernideen
    • Grundideen 1950-1970:
      • Build only what is needed
      • Eliminate everything that doesn‘t add value
      • Stop if something goes wrong
      • Respect those engaged in the work
    • Agiles Manifest 2001:
      • Individuals and interactions over processes and tools
      • Working software over comprehensive documentation
      • Customer collaboration over contract negotiation
      • Responding to change over following a plan
  • 4. Scrum 1. „ Scrum assumes you are all adults.“ Ken Schwaber
  • 5. Scrum Flow
  • 6. Rollen
      • Product Owner Team
      • Scrum Master
  • 7. Product Owner
    • Pflege des Product Backlogs
    • Vertritt die fachliche Auftraggeberseite
    • Priorisiert Product Backlog: business value, frühe Funktionalität, ROI
    • Passive Teilnahme an Daily Scrums
    • Beantwortet Rückfragen des Teams
    • Nicht:
      • Scrum Master, Team Member, Team Chef
      • Sprint Backlog während Sprint beeinflussen
      • Daily Scrums moderieren oder ungefragt dort reden
      • Seine Aufgaben nur zu Beginn / am Ende der Sprints wahrnehmen
  • 8. Scrum Master
    • Verantwortung für den Prozess
    • Moderiert Scrum-Meetings
    • Vermittler und Unterstützer (Facilitator)
    • Beseitigt Hindernisse (Impediment Log)
    • Kümmert sich um Informationsfluss zw. Team und Product Owner
    • Verantwortet Aktualität der Scrum-Artefakte
    • Nicht:
      • Chef für das Team
      • Arbeitszuteilung an Teammitglieder
      • Doppelfunktion Team Member / Product Owner (Interessenskonflikte)
  • 9. Team
    • 5 – 10 Personen
    • Selbstorganisierend
    • Interdisziplinär / Cross-functional
    • Daily Scrum
    • Ergebnis nach jedem Sprint: „shippable functionality“
    • Reported Restaufwände für Backlog
    • Nicht:
      • Fachkonzepte schreiben -> Product Owner
      • An Scrum Master oder Product Owner reporten -> berichten einander!
      • Das Sprint Backlog vernachlässigen
  • 10. Meetings
    • Sprint Planning (4 h)
    • Daily Scrum (15 min)
      • Was habe ich seit gestern getan? Fertig geworden?
      • Was tue ich morgen?
      • Hindernisse / Probleme
    • Sprint Review (2 h)
  • 11. Scrum Board / Burndown Chart Quelle: Mountaingoat Software 2010 Quelle: Alistair Cockburn, 2004
  • 12. Kanban 2. „ Yes, we kanban!“ David Anderson
  • 13. Bedeutung
    • Kanban ist japanisch ( 看板 ) (Kan = Signal, Ban = Karte / Tafel / Beleg)
    • Kanban = Signal für das Auslösen einer Aktivität / Aktion
    • Fokus auf Wertschöpfungs prozess den ein Produkt durchläuft
    • Beispiele für Kanban
  • 14. Prinzipien
    • Der gesamte Wertschöpfungsprozess wird sichtbar gemacht
    • Beschränkung der „Work in Progress“ (WIP) für jeden Prozessschritt
    • Workflow nach Pull-Prinzip
    • Es existiert ein Backlog mit Anforderungen
    • Konsequente Optimierung und Maximierung des Durchsatzes durch das Team
  • 15. Kanban Workflow Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 16. Kanban Workflow Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 17. Kanban Workflow Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 18. Kanban Workflow Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 19. Kanban Workflow
    • Limit WIP!
    Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 20. Kanban Workflow
    • Limit WIP!
    Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 21. Kanban Workflow
    • Limit WIP!
    Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 22. Kanban Workflow
    • Limit WIP!
    Step 1 Step 2 Step n Done Queue Queue Queue In Process In Process In Process ... ... Backlog (3) (2) (4) (2) (2) (1)
  • 23. Kanban Board Flow: from Engineering Release to Production Quelle: Norbert Winklareth, 2010 Model & Visual Control WIP Limits Pull
  • 24. Messung Indikatoren und Optimierung
    • Lead Time =  Zeit zur Fertigstellung einer in den Backlog gelegten Anforderung
    • Cycle Time =  Zeit zur Fertigstellung einer in den Prozess gegebenen Anforderung
    • Lead Time für den Kunden, Cycle Time zur Optimierung des Prozesses
    • Optimierungsansatz: Stabilisierung und Minimierung Cycle Time
      • Minimierung von überlaufenden / leerlaufenden Queues
      • Pakete möglichst gleichgroß in den Prozess geben, notfalls Aufsplittung
      • Ressourcen umverteilen
      • Ressourcen für Prozessschritt aufbauen
      • Anzahl Arbeitspakete im Prozess reduzieren
    • Ziel: Möglichst gleichmäßiger Durchflauf (Flow)
  • 25. Vergleich Scrum / Kanban Quelle: Norbert Winklareth, 2010 Prioritisation Roles Flexibility to add items Estimation WIP Limitation Work item size Team composition Planning / process improvement Team commitment Process model Prioritisation optional Items must be prioritised No roles prescribed Prescribed 3 roles Whenever capacity is available Not within ongoing iteration Optional Prescribed Number of Work Items per process step Feature Points per Iteration No size prescribed Max. lengh of iteration Cross-functional teams optional, Specialist teams allowed Cross-functional teams Lead time Velocity Optional Specific amount of work Event-driven not iterative Timeboxed iteration prescribed Kanban Scrum
  • 26. Links
    • David Anderson‘s Blog:
    • http://www.agilemanagement.net/Articles/Weblog/blog.html
    • Corey Lada‘s Blog:
    • http://leansoftwareengineering.com
    • Weiterführende Informationen:
    • http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/
    • http://en.wikipedia.org/wiki/Scrum_(development)
    • http://www.scrumalliance.org /
    • Buch: Agile Project Management with Scrum – Ken Schwaber
    • http://www.slideshare.net/norbertwinklareth/kanban-thinking-outside-the-time-box
  • 27. Vielen Dank für Ihre Aufmerksamkeit. Titel der Präsentation | Veranstaltungsort | XX. Monat XXXX Seite
  • 28. Backup
  • 29. Advanced Kanban
    • Behandlung von Bugs / dringlichen Wartungstätigkeiten
    • Multiprojektmanagement: Swimlanes
    • Statistische Auswertung (Cumulative Flow)
    • e-Kanban
    Cumulative Flow Quelle: Norbert Winklareth, 2010
  • 30. Warum Kanban?
    • Einschränkungen / Vorgaben durch den Scrum-Prozess
      • Maximale Größe von Anforderungen = Iterationslänge
      • Kleine Änderungen können erst nach einer Iteration live gehen
      • Daily Standup, Sprint Planning oder Sprint Retro sind verpflichtend
    • Das Unternehmen kann seinen bestehenden Prozess nutzen
      • Kosten für Prozessänderungen bei Einführung von Scrum
      • Kein Konflikt mit der Unternehmenskultur
      • Keine strikten Rollen: Ressourcenplanung einfacher