Agile intro-90min (2007)

496 Aufrufe

Veröffentlicht am

2007 Agile Intro presentation (Deutsch)

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
496
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Task Switching: DeMarco/Lister: Peopleware, Project-Multitasking: Goldratt in Critical Chain
  • Individuals and interaction
    without the right people who have the right technical and behavioral skills, all the process and tools in the world won‘t produce results.
    People often tied down with procedures and forms
    BPR proponents thought that structured processes would somehow make up for mediocre individual capabilities
    No process can overcome the lack of good engineers, product managers, customers, suppliers and executives
    Good process should support the team rather than dictate it actions
    APM supports creators, not stewards

    Working results
    a characteristic of serial development is delivering documentation artifacts
    large, front-end loaded projects spend months, and even years gathering and documenting requirements, proposing architectures and designing products are prone to errors
    Documents do not work. Products do.
    stress the delivery of versions of the product (or effective simulations and models)
    this delivery verifies that something tangible to the customer is being built
    working features provide dependable feedback into the development process, in a way, a document cannot.
    Documentation is not unimportant, it is just less important than a working version
    Documentation is not a substitute for interaction and collaboration
    In traditional forms, a document often has become a substitute (customer & product owner send a requirements document to development), and thus barricade to progress (no knowledge is transferred)

    Customer collaboration
    customer team and development team form a partnership with specific roles, responsibilities and accountabilities
    the customer is the individual or group who uses the created product to generate business value
    Customers define value
    Other stakeholders define constraints (we must not confuse these roles)
    Customers define requirements (features) that provide value and the business objective (schedule, cost) that assist in quantifying that value
    today value arises from implemented features that meet the requirements
    tomorrow‘s benefits (once a product is delivered) is a function of how quickly and cost effectively the product can be adapted.
     Deliver today, adapt tomorrow


    Responding to change
    every project has to balance planning and change
    exploration style projects are characterized by a process that emphasizes envisioning and then exploring into that vision rather than detailed planning and relatively strict execution of tasks
    Cost of exploration, experimenting = cost of an iteration. Low cost iterations enable adaptive style of development
    „conforming to plan“ falls very short in a turbulent economy.
    The old mantra „plan the work“ and then „work the plan“


    Highsmith 2004, pp. 8ff
    Mike Cohn 2006, pp. 21f

    J. Coldewey:

    Collaboration over formalisms
    short increments over year long mediation
    flexibility over planning orgies
    Customer involvement over safeguarding

  • Klassisches Vorgehen also Plan/Execute = Ziel anvisieren, Abschießen einer „unguided Missile“

    Nur: eigentlich immer ein bewegliches Ziel (Anforderungen, Technologie, …)

    Agile Methoden verwenden ein iterativ inkrementelles Vorgehen

    Iterativ heißt „in Iterationen“

    Fixe Länge, zB 2 Wo
    klarem Fokus auf das Ziel
    Feedback: früh & häufig

    Ähnlich Navigationssystem im Auto

    In jeder Iteration Entscheidungsräume
  • 100% Fertig = Getestet

    Wesentliche Unterscheidung zur klassischen Entwicklung

    Typ. Release zB. Ein Jahr, mehrere MS, a, b, Release, HotFix

    klassisch: spät testen, spät integrieren, spät dokumentieren

    iterativ: von Beginn weg testen, integrieren, dokumentieren
    Workload und Stress ausnivellieren
    Qualität konstant hoch halten
    Geschwindigkeit nicht ohne Qualität möglich

    Regelmäßige Shipments möglich, da Inkremente auslieferbar sind
  • Beispiel bei Fabasoft

    Planung / Sprint Kommitment
    - Einfache, sehr effiziente Visualisierung
    - Daily Scrum: ca. 10 min täglich
  • Produktivität auch Team-Entwicklung, Reibungen, Extrem klarer Fokus

    Stress: Auch Entlastung von Einzelkämpfern,
    Belohnungseffekt, positiv

  • A round should not take longer than three minutes
    If the requirements are not clear, define the story new (not in the poker game)
  • The team was not able to finish the committed work. It looks like it had an issue in progress on day 3-4 and the second week. It seems, that they spent more than once much more time on finishing tasks in significant more time than planned.
    The team was faster than expected and finished more work than planned. The velocity was higher than planned. The PO put in another story and the team seemed to delivered it.
  • The material in this document is protected by copyright law.
    Some contents in this presentation have been included from their original authors with permission, these are:
    Ken Schwaber’s Version 5 Certified ScrumMaster Course and CSM course materials
    Mike Cohn’s Redistributable Intro to Scrum
    Ken Schwaber’s and Mike Cohn’s CSPO course materials
    Roman Pichler’s CSM course materials

    No part of this publication may be reproduced or transmitted in any form or for any purpose without prior express permission of Objectbay.
    The information contained herein may be changed without prior notice.
    Some software products marketed by Objectbay and its distributors contain proprietary software components of other software vendors.
    Objectbay is a trademark or registered trademark of Objectbay Software & Consulting GmbH in Austria and/or the European Union and in several other countries all over the world. All other products and names mentioned are trademarks or registered trademarks of their respective companies.
  • Agile intro-90min (2007)

    1. 1. Agile Softwareentwicklung in der Praxis DI Dr. Andreas Wintersteiger Objectbay Software & Consulting GmbH andreas.wintersteiger@objectbay.com 1 V5.306/2008
    2. 2. © 2007 Objectbay Software & Consulting GmbH. www.objectbay.com Wurzeln – Verschwendung (Lean)  Frage nach dem Beitrag zur Wertschöpfung  The Poppendieck Seven Wastes  Unfertige Arbeit  Zusätzliche Prozesse  Extra Features  Task Switching  Waiting  Motion  Defects 4 Quelle: Poppendieck, 2007
    3. 3. © 2007 Objectbay Software & Consulting GmbH. www.objectbay.com Wurzeln: Werte in XP (Kent Beck, 1999)  Kommunikation („Communication“)  Problems with projects are [...] somebody not talking to somebody else about something important.  Einfachheit („Simplicity“)  The simplest thing that could possibly work  Feedback  Auf mehreren Ebenen  Mut („Courage“)  Mut zu Feedback  Mut zur Lücke  Mut zur Richtigstellung 5  Amazon.de
    4. 4. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Agile Werte  Kleine Releases  kleine Stücke  Kurze Zeiträume  Iterativ-inkrementelle Entwicklung  Gesamter Entwicklungszyklus  Iterationen fixer Länger mit fixiertem Umfang  „Time-Boxes“  Collocation  Face-to-Face Communication  Team-Raum  Visualisierung  Feature Backlog  Benutzer-/Wert-Orientiert  Priorisiert  Laufende, adaptive Planung  Unterscheide Grob- und Feinplan  „Planning Game“  Komplexität  Verantwortung  Feedback  Maximierung Feedback  Kontinuierliches Lernen und Verbessern  Qualität/Stabilität  Effiziente Interaktion  Effiziente Teamaktivitäten  Gleicher Status (Synchronisation)  Reflektiert Kundenwert  Explorative Annäherung an bewegliche Ziele  Balance Verantwortung und Mitsprache  Erwartungen über Ziele abschätzbar  Abschätzung durch Beteiligte 6
    5. 5. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Agile Werte (2) 7  Selbst organisierende Teams  Autonomes Handeln  Prozess-Intelligenz  Qualitätsgetriebene Prozesse  „Jidoka“ (aus Lean Production)  Testgetriebene Entwicklung  Feedback  Definition von „Fertig“  Inspektion und Adaption  Retrospektiven  Einfachheit, Adaptierbarkeit  Inhaltlich und prozessual einfach halten  Lean (wenig Verschwendung)  Adaptierbar  Kein Mikro-Management  Lösungskompetenz  Produktivität  Solides Fundament (Früherkennung)  Kein „technical debt“  Hohe Änderbarkeit  Vermeidung von „Halbfabrikaten“  Lernen und Verbessern  Reflexion  Maximierung des Business-Value  Maximierung des Kundenwerts  Veränderungen „entgegenkommen“
    6. 6. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Das agile Manifest 8  Individuals and interactions  over processes and tools  Working results  over comprehensive documentation  Customer collaboration  over contract negotiation  Responding to change  over execution of a plan Original Signees: Kent Beck Mike Beedle Arie v. Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Feb. 11-13, 2001, Snowbird ski resort Wasatch mountains, Utah, USA
    7. 7. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Prozessmodelle der Software-Entwicklung 9
    8. 8. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Scrum! 10
    9. 9. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Charakteristika 11  “Agiler Prozess” mit Fokus auf „Projektmanagement“  Selbstorganisierende, funktionsübergreifende Teams  Entwicklungsfortschritt in einmonatigen „Sprints“  Anforderungen in einer Liste (“Product Backlog”)  Keine spezifischen Engineering Practices  Kombination mit XP (xp@scrum)  Generative Regeln  Schaffen „Agile Umgebung“ um Entwicklungsprojekte abzuwickeln  ISO und CMMI „Kompatibilität“
    10. 10. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Scrum - Wurzeln  Produktivität  Borland QuattroPro Team  8 Developer, 31 Monate, 1 MLOC  1 KLOC / Developer / Week (37x Industry Standard) [Coplien, 94]  PatientKeeper  45 production releases per Year  860 hospitals, bi-weekly [Sutherland, 2007]  Selbstorganisation  Pull-Prinzip  Iterativ-Inkrementell 12 Quelle: Jeff Sutherland
    11. 11. © 2007 Objectbay Software & Consulting GmbH. www.objectbay.com Iterativ-inkrementelle Entwicklung Start Ziel (aus heutiger Sicht) 13
    12. 12. © 2007 Objectbay Software & Consulting GmbH. www.objectbay.com Entwicklungszyklus 1 2 3 4 5 6 7 8 9 10 11 12 Fehlerrate Stress 14
    13. 13. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Sequentielle vs. überlappende Entwicklung 15  Anstatt pro Phase alle Aufgaben zu erledigen  machen agile Teams ständig einen Teil aller Aufgaben Analysis Design Develop Test Integrate
    14. 14. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Sprints 16  Scrum Projekte schreiten in einer Serie von “Sprints” fort  Vgl. Iterationen in XP  Fixe Dauer von einem Monat  Abweichend auch 1 bis 4 Wochen  Wichtig ist die Entstehung eines Rhythmus  Während des Sprints  Alle Aktivitäten aus den klassischen Phasen  Produktdesign, Code, Test, Dokumentation …  Ergebnis – „Done“  „Potenziell auslieferbares Produktinkrement“
    15. 15. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Sprints liefern ein „Produktinkrement“ ab 17 Produkt-Release User Interface Layer Business Layer Database Layer Infrastructure Layer Inkrement1 Inkrement2 Inkrement3 Quelle: R. Pichler
    16. 16. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Der Scrum Prozess 18 2 – 4 Wochen 24 Std. Sprint Backlog Produkt Backlog Daily Scrum Sprint Produkt Inkrement  UP
    17. 17. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Keine Änderungen während des Sprints 19  Das Team erklärt verbindlich, eine bestimmte Menge an Features/Anforderungen in einem Sprint abzuliefern  Änderungen dieser Anforderungen sind nicht erlaubt  Keine Störung oder Unterbrechungen von außen  Sprintdauer sollte so gewählt werden, wie lange es möglich ist, Veränderung außen vor zu halten.
    18. 18. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Rollen in Scrum 20 Product Owner Scrum Master Team Bildquellen: Apple, Inc., Scrum Alliance Inc., EuropuppyUSA.com
    19. 19. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Scrum in Action 21
    20. 20. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Another Silver Bullet?  Prozess-Schwächen werden sichtbar  Verschwendung: Nicht-wertschöpfende Aktivitäten (Wert aus der Sicht des Kunden)  Engpässe und Blockaden  Überlastung 22
    21. 21. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Scrum – Nachweisliche Ergebnisse  Funktionsfähige Software am Ende eines jeden Sprints  „Fertig“  Qualität  Kontinuierliche Steigerung der Produktivität  Reduktion des Stress-Niveaus  Steigerung der Zufriedenheit von Kunden und Mitarbeitern  Fokus auf die richtigen Features  Transparenz auf den Projektfortschritt  Einfachere und realistischere Möglichkeit zur Planung  Nachhaltige Steigerung der Softwarequalität 23
    22. 22. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Product Backlog  Liste  Anforderungen  Arbeitspakete  Was ist zu tun  Einträge: User Stories - „Wert“ für Kunde/Benutzer  Priorisiert  Geschätzt  „Sizing“ 24
    23. 23. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com User Stories: User + Story 25  Anforderungen/Features aus Benutzersicht  Jede Story muss einen Wert für den Benutzer darstellen  Ist einfach zu verstehen  Kurzer Beschreibungstext  Klarheit darüber, was der User damit an Funktionalität bekommt Quelle: Mike Cohn, Mountain Goat Software As a vacation planner, I want to see photos of the hotels. As a user, I want to cancel a reservation. As a frequent flyer, I want to rebook a past trip, so that I can save time booking trips I take.
    24. 24. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Der Product Backlog Eisberg 26 Priorität Sprint Release Nächstes Release
    25. 25. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Wo halten wir den Backlog? 27 Bildquellen: Scrumworks, VersionOne, T-Online, Mountain Goat Software
    26. 26. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Tools (2) 28
    27. 27. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Sizing – Planungspoker 29  In vielen Fällen konvergiert das Ergebnis bereits nach der zweiten Runde.  Der Moderator sollte versuchen, Konvergenz in der Diskussion herbeizuführen.  Es geht dabei nicht um Genauigkeit, sondern Angemessenheit. Schätzer 1. Runde 2. Runde Fred 3 5 Wilma 8 5 Barny 2 5 Betty 5 8 Quelle: Mike Cohn
    28. 28. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Vor dem Sprint / Planning - Themen  Vorbereitung  Backlog  Team  Bugs  Tasks  Granularität, „Herunterbrechen“  Diskussion, Schätzen  Das gesamte Team (Qualität des Plans)  Was kommt in den Sprint?  „Neben-Aufgaben“, Infrastruktur, „Administrative Aufgaben“…? 30
    29. 29. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Das „Task Board“ ist ein Sprint-Monitor 31 Story Tasks to do Design and Code the User Interface 8 Code the Middle tier interfaces 8 Code the business logic 12 Design the Integration rules 4 Design and Code the User Interface 4 Code the Middle tier interfaces 8 Code the business logic 2 Design the Integration rules 2 In progress To be verified Done Design and Code the User Interface 4 Code the Middle tier interfaces 8 Code the business logic 6 Design the Integration rules 4 Hours 18 10 14 Summe der verbleibenden Stunden am Ende des Tages / 6 / 2 / 2
    30. 30. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Definition von „DONE“  Teams zu 3 - max. 6 Personen  Ein aktuelles (oder fiktives) Produkt/Projekt  Was bedeutet „Done“ („Fertig“) …?  für mich persönlich  für mein Team  für meinen Vorgesetzten  für meinen Kunden  … 32
    31. 31. © 2007 Objectbay Software & Consulting GmbH. www.objectbay.com Continuous Integration  Build Automatisierung  Automatisierte Tests  Unit-Tests  Integrationstests  UAT  Last- u. Performance-Tests  Coverage  Deployment  Code-Analyse  Metriken  Report 33
    32. 32. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com FAQ: Architektur  Evolving Architecture  Architektur entwickelt sich über die Zeit  Wieviel Architektur ist notwendig? Wie wenig möglich?  Architektur-Sprints  Zumindest ein Stück Funktionalität im Sprint  Spikes, Prototypen  Joint Application Design Sessions  Das gesamte Team arbeitet an der Architektur  Entweder unmittelbar vor oder nach dem Sprint Planning 34
    33. 33. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Beispiel Sprint-Board 35
    34. 34. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Beispiele: Sprint Burndowns 36
    35. 35. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Non-Excel Burndown Reports 37
    36. 36. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Der Visuelle Arbeitsplatz 38  Agile Methoden bevorzugen einfache Visualisierung und offene Kommunikation  Arbeitsplatz mit allen wichtigen Informationen verfügbar  Release Plan  Sprintziel  Sprint Backlog  Hindernisse, …  Build-Ergebnisse, Metriken,  Erlaubt Selbstorganisation und Inspect & Adapt  Erlaubt dem P.O. den Fortschritt des Teams zu erkennen und ob das Ziel erreicht werden kann Quelle: Ken Schwaber
    37. 37. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Sprint Review  Demo funktionsfähiger Software  Qualitätsgesichert  Ziel: Präsentation von Software als Life-Demo  Vorbereitung  Tests  Kurzer Intro (Sprint-Ziel, Context,…)  Hoch-Produktive Teams zeigen nur Life-Demos  Keine Dokumente, Diagramme, Folien etc.  Einzige Ausnahme für „technische Stories“ zB. Testergebnisse, Reports 39
    38. 38. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Retrospektiven  Wichtig für alle Teams, um stetig produktiver zu werden  Team (typischerweise ohne P.O.)  Praktiken aus der Moderationstechnik  Good/Bad  Timeline  5 Whys  …  „Lessions learned“ verteilen  „Knowledge Bridge“  Skalierte Retrospektive  SM weekly, SOS 40
    39. 39. © 2008 Objectbay Software & Consulting GmbH. www.objectbay.com Literaturempfehlungen 41 Ken Schwaber: Agile Project Management with Scrum Microsoft Press, 2004 ISBN 0-7356-1993-X  Amazon.de Mike Cohn: User Stories Applied Addison Wesley, 2004 ISBN 0-321-20568-5  Amazon.de Boris Gloger: Scrum Carl Hanser Verlag Wien München, 2008 ISBN 978-3-446-41495-2  Amazon.de Mike Cohn: Agile Estimating and Planning Prentice Hall Intl., 2005 ISBN 0-13-147941-5  Amazon.de
    40. 40. Vielen Dank www.objectbay.com 42

    ×