Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Einführung in Agile
  Agile Entwicklungs- und
  Projektmethodik bei Infopark

  Thomas Witt
  <thomas.witt@infopark.de>
Software-
Entwicklung
   (classic)
Was der           Was der        Was der Berater     Wie es der         Was der
Kunde erklärte     Projektleiter      defin...
Warum?
Wasserfall
1970: Dr. Winston W. Royce




      Quelle: Royce, Managing the Development of Large Software Systems [1970] <http://tiny...
Department of Defense (DoD)


1980: "DOD-STD-2167"
• Militär-Standard für
  Software-Projekte
• Wasserfall-Vorgehen
• Doku...
Definierter Prozess

           Ziele
           • Abweichungen
             minimieren
           • Effizienz maximieren
  ...
Beispiele für
 definierte
 Prozesse?
Beispiel



Kochrezept
Beispiel



   Industrielle
Massenproduktion
Gemeinsamkeiten?



Reproduzierbar
IT- / Web-
Projekte?
Die Welt ändert sich dauernd ...
Einige Probleme beim Wasserfall...
  Wir legen alle Details zu dem     Dokumenten-Fokussierung
  Zeitpunkt fest, an dem wi...
Was Royce selbst dazu sagt...




                           Quelle: Royce [1970]
Zitate
«l am going to describe my personal views about
managing large software developments.»

«The implementation describ...
«I regret the creation of the rigid single-pass
waterfall standard.

I was not familiar with the practice of timeboxed
ite...
Die Standardisierung des
 Wasserfall-Modells ist
  eine Folge aus Zufall,
Missverständnissen und
       Unkenntnis.
Die Folgen…
Die Zahlen belegen dies ...
Studie der Standish Group (2001)

Untersucht wurden 23.000 Projekte
• Erfolgsdefinition:
  - Im...
Auch das DoD sieht das so …


1999: Studie früherer Wasserfallprojekte im
amerikanischen Verteidungsministerium
• Projekte...
Und andere ...
UK-Studie Thomas '01
• Insgesamt 1027 IT-
  Projekte

Ergebnis
• 87% Fehlschläge
• In 82% Wasserfall-
  Vor...
Der nächste
  Schritt:
 Empirisch
Empirischer Prozeß
Royce sagt: «Baut es zweimal!»
• Wenn neuartige Elemente und unbekannte
  Faktoren involviert sind, emp...
Der zweite Versuch …

1980: "DOD-STD-2167"
• Wasserfall-Vorgehen
• Dokumentenorientiert
1988: "DOD-STD-2167A"
• Erlaubt er...
Die Lösung:
  Iterativ
«Pläne sind nichts.
 Planen ist alles.»
   – Helmuth Graf von Moltke
Iterative Entwicklung
Sequenz von Iterationen,
wobei jede Iteration …
• ein fertiges Ergebnis
  liefert.
   - "Iteration R...
Iteration Release

Iteration Release
• stabiles, integriertes
   System
• wird nicht zwangsweise
   ausgeliefert
• könnte ...
Timeboxes und Milestones
Milestone: Phasen-Ende

Ende einer Timebox und
Milestones fast identisch
• Zeitpunkt
• Erfüllte E...
Iterative Entwicklung
Kernpunkt
• Anforderungen, Schätzungen, Pläne entstehen
  im Laufe der Zeit und werden allmählich
  ...
« Kein Plan überlebt die
erste Feindberührung.»
     – Helmuth Graf von Moltke
Iterative Entwicklung …


eine neuer
  Hype?
Iterative Entwicklung schon alt
1950er Jahre
• USA Air Defense Project "SAGE": stagewise model
• X-15 Überschall-Flugzeug
...
Space Shuttle

1977-1980: Primary
Avionics Software System
• 17 timeboxed Iterationen
• 31 Monate
• Iterationslänge:
  ca....
Space Shuttle

Zitate
• «Due to the size, complexity and evolutionary
  nature, the ideal software development process
  [...
Iterativ
- wann?
«Je planmäßiger die
Menschen vorgehen,
desto wirksamer trifft
    sie der Zufall.»
      – Friedrich Dürrenmatt
Komplexität von Projekten
   unklar,
   strittig
                                                            Chaos
       ...
Genauigkeit von Schätzungen
                   4x
 Schätzung/Real


                   2x

                   1,5x
       ...
Wann ist Iterativ sinnvoll?


 Komplexe
  Projekte
Auch das DoD hat erkannt …
1980: DOD-STD-2167
• Wasserfall-Vorgehen
• Dokumentenorientiert
1988: DOD-STD-2167A
• Erlaubt e...
State of the Art-Methodik


   Agile
Development
Agiler Begriffswirrwar...
                    eXtreme Programming

        Scrum                   Product Owner
         ...
Agile
    ≠
  Projekt-
Management
Scrum und Agile


   Scrum   XP



       Agile

 Projektmanagement
Manifesto for Agile Software Development


  Individuals and interactions over processes and tools
 Working software over ...
Kombiniert aus XP und Scrum…


    Infopark-
     Methdik
Was ist Scrum?

«Scrum ist ein Weg, Kreativität, Freude an der
Arbeit, Spass bei der Teamarbeit in produktive
Bahnen zu le...
Was ist Scrum?
«Scrum» ist ein Begriff aus
dem Rugby
• Ein Rugby-Team bringt
  den Ball gemeinsam mit
  schnellen Pässen v...
Scrum ist einfach

4 verschiedene Rollen

3 Arten von Dokumenten

4 Arten von Meetings

Wenige Regeln
• In wenigen Minuten...
Product Owner
Der “Kunde”
• Repräsentant
Aufgaben
• Projekt inhaltlich steuern
• Wert des Produkts
  maximieren
• Priorisi...
Product Backlog
Liste mit
• Dingen, die getan
  werden sollen
• gewünschte
  Eigenschaften

Priorisiert
• Oberster Punkt h...
Team
Optimal: 7 Leute
• auch weniger möglich
• keine festen Rollen,
  crossfunktional

Realisieren die Wünsche im
Product ...
Sprint
Zeitintervall fester Länge
• typisch: 2-4 Wochen
Ordnung im Chaos
• keine externe Störung
Anfang: Planning Meeting
...
Scrum Master
“Chef-Mechaniker”
• Stellt den Prozeß sicher
• Plant und moderiert
  Meetings
• Schützt Team vor
  Fremdeinflü...
Planning Meeting
Am Anfang eines Sprints

Teilnehmer
• Team
• Product Owner
• Scrum Master
Dauer
• ~8 Std. für 30 Tage-Spr...
Review Meeting
Teilnehmer
• Team
• Product Owner
• Scrum Master
• Weitere Interessierte
Dauer
• ~1-2 Stunden
Inhalt
• Team...
Retrospective
Nach dem Review

Teilnehmer
• Team
• Scrum Master
• Evtl. Product Owner
Inhalt
• Fragen: Was lief gut?
  Was...
Sprint Backlog

Aufgaben, die das Team im
Sprint erledigen muss, um
sein Commitment zu
erfüllen

Gehört dem Team
• Separat...
Daily Scrum
Teilnehmer stehend
• Team
• Scrum Master
• Interessierte nur Zuhörer
3 Fragen: Was …
• habe ich gestern
  gema...
Burndown Chart

Zeigt Restaufwand aller
offenen Aufgaben über die
Zeit
• Wird täglich vom Team
  aktualisiert
• Gehört dem...
Sprint-Abbruch
Wenn das Sprint-Ziel
unsinnig bzw. unerreichbar
geworden ist

Kann von jeder der Rollen
verlangt werden

Wa...
Zusammenfassung
Was enthält
das Backlog?
User-Stories
User-Stories


Anforderugen werden als
User-Stories formuliert

User-Stories ≠ Use-Cases
User Story

Eine User Story ist ein leichtgewichtiges Element
für Planung und Priorisierung von Anforderungen
• enthält ni...
Anforderungen als User Stories
Anforderungen
• leichtgewichtig
• für Kunden und Entwickler verständlich
   - ohne Dominanz...
Form

Als ein [Benutzer-Typ]
möchte ich [Fähigkeit],
(damit [Nutzen]).               «Al s Be n
                          ...
Drei Elemente
Schriftliche Formulierung (Card)
• zum Plannen
• als Erinnerung
• ein oder zwei Sätze
• repräsentiert Anford...
Beispiele
Gute Stories
• "Als Benutzer kann ich nach Stellen suchen."
• "Als HR-Mitarbeiter kann ich neue
  Stellenangebot...
Wo bitte bleiben die Details?

"Als Benutzer kann ich nach Stellen suchen"
• Nach welchen Werten kann ich suchen? Stadt?
 ...
Details ins Gespräch ....

  Als Benutzer kann ich Informationen
  über jede Stelle sehen, die auf die
  eingegebenen Such...
... Tests auf die Rückseite

   Versuche es mit
   - einer leeren Stellenbeschreibung
   - einer ganz langen Beschreibung
...
Verhandelbar

Stories sind keine Verträge
oder Anforderungen

Die Details in Gesprächen
verhandeln
• Stories müssen nicht ...
Verhandelbare Story

Als Firmenmitarbeiter kann ich für
eine Stellenanzeige mit der
Firmenkreditkarte zahlen.




Hinweis:...
scheinbar präziser...
Als Firmenmitarbeiter kann ich für eine
Stellenanzeige mit der Firmenkreditkarte zahlen.

Hinweis: V...
Goldene Regel: INVEST
Independent

Negotiable

Valuable

Estimatable

Small

Testable
Reihenfolge?
Backlog
Liste mit Dingen, die getan
werden müssen
• gewünschte
  Eigenschaften des
  Produktes
• als User-Stories
• jederz...
Priorisieren nach Risiko und Wert
     hoch
              hohes Risiko     hohes Risiko
             niedriger Wert    hoh...
Priorisieren nach Risiko und Wert
     hoch
                                Zuerst
              vermeiden
               ...
Die Bestandsliste mit Stories
  Priorität   Story   Nutzen   Risiko
     1         D       +++      +++

     2         B ...
Auf die Plätze, fertig, los!
       Priorität   Story   Nutzen   Risiko
          1         D       +++      +++
Nächster ...
Gewonnene Erfahrung nutzen
  Priorität   Story   Nutzen   Risiko
     1         D       +++      +++
    Repriorisieren
  ...
Was ist mir am wichtigsten?
Keine einfache Entscheidung

Faktoren sind:
• Risiko
• Kundennutzen
• Man lernt aber auch im P...
Und wann habe ich es?
Schätzen
• Aufgabe des Teams
• Wichtiger Input für die
  Priorisierung

Ein ganz großes Thema
• Vers...
Was fehlt?
Projekt-
management
Projektmanagement
Projektziele
• Strategisch und technisch
• Projektleitdokument
Rahmenbedingungen
• Zeit
• Budget
Einige ...
Projektlenkungsausschuß
Gremium hinter dem
Product Owner
• Projektentscheidungen
  auf Arbeitsebene

Hat volle Autorität u...
Aufgaben
Ernennung von …
• Projektleiter
• Product Owner
Genehmigung sämtlicher
Planungen / Änderungen

Gewährleistung der...
Projektleiter
Verantwortlich für
Erreichung der Projektziele

Organisiert und koordiniert
das Projekt auf Tagesbasis
• Ans...
… und noch viel mehr



 … aber dazu ein
anderes Mal mehr.
Zusammenfassung Agile
            Entwicklungsmethodik
            • ≠ Projektmagnement
            Geeignet für
         ...
Infopark AG
              Vorstellung
Infopark: Dialog im Web
Kunden online gewinnen
• durch Interaktion
  begeistern
• 100 Web-Spezialisten
  erschließen für I...
Infopark: Dialog im Web

Digital im Web
• über 600 Installationen
• über 60.000 Anwender
Software-Produkte
• Infopark CMS ...
Infopark: Dialog im Web
Dienstleistungen rund ums
Web
• Workshops
  - Web-Strategie, SEO,
    Web 2.0 etc.
               ...
Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken
Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken
Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken
Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken
Upcoming SlideShare
Loading in …5
×

Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken

6,935 views

Published on

Published in: Technology, Business
  • Be the first to comment

Einführung in Agile / iterative Projekt- und Entwicklungsmethodiken

  1. 1. Einführung in Agile Agile Entwicklungs- und Projektmethodik bei Infopark Thomas Witt <thomas.witt@infopark.de>
  2. 2. Software- Entwicklung (classic)
  3. 3. Was der Was der Was der Berater Wie es der Was der Kunde erklärte Projektleiter definierte Designer Programmierer verstand entwarf programmierte Wie das Projekt Was tatsächlich Was dem Wie das Projekt Was der Kunde dokumentiert installiert Kunden in gewartet wurde tatsächlich wurde wurde Rechnung benötigt hätte gestellt wurde Quelle: unbekannt
  4. 4. Warum?
  5. 5. Wasserfall
  6. 6. 1970: Dr. Winston W. Royce Quelle: Royce, Managing the Development of Large Software Systems [1970] <http://tinyurl.com/r3jaj>
  7. 7. Department of Defense (DoD) 1980: "DOD-STD-2167" • Militär-Standard für Software-Projekte • Wasserfall-Vorgehen • Dokumentenorientiert <http://tinyurl.com/5uu6pr>
  8. 8. Definierter Prozess Ziele • Abweichungen minimieren • Effizienz maximieren Liefert Qualität auf reproduzierbare Weise Wasserfall ist ein definierter Prozess
  9. 9. Beispiele für definierte Prozesse?
  10. 10. Beispiel Kochrezept
  11. 11. Beispiel Industrielle Massenproduktion
  12. 12. Gemeinsamkeiten? Reproduzierbar
  13. 13. IT- / Web- Projekte?
  14. 14. Die Welt ändert sich dauernd ...
  15. 15. Einige Probleme beim Wasserfall... Wir legen alle Details zu dem Dokumenten-Fokussierung Zeitpunkt fest, an dem wir am führt zu massivem wenigsten wissen. Wissensverlust (Stille Post) Anforderungen müssen stabil Projektfortschritt nur schwer bleiben, sich ändernde äußere abschätzbar, das Ergebnis wird Einflüsse werden nicht geprüft, wenn alles zu spät ist. berücksichtigt. Risikoreiche Schritte finden am Eine gute Idee in der Mitte des Ende statt. Projekts ist kein Geschenk, sondern eine Bedrohung. Aha-Effekt kommt erst sehr spät: beim Anschauen. Unnötig großer Umfang: Alles, was man vielleicht braucht, Angst vor Fehlern führt zu landet in den Anforderungen. unrealistischen Zeitplänen ("Sicherheitsaufschlag") Großer Abstand zwischen Analyse und Realisierung Verzögerungen werden schöngeredet
  16. 16. Was Royce selbst dazu sagt... Quelle: Royce [1970]
  17. 17. Zitate «l am going to describe my personal views about managing large software developments.» «The implementation described above is risky and invites failure. The simpler method has never worked on large software development efforts.» «My father was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects.» (Walker Royce) Quelle: Royce [1970]
  18. 18. «I regret the creation of the rigid single-pass waterfall standard. I was not familiar with the practice of timeboxed iterative development and evolutionary requirements at the time. My advice was based on textbooks and consultants advocating the waterfall method. If I could write 2167 again, it would contain a strong recommendation for incremental iterative development.» – David S. Maibor, principal author of DOD-STD-2167 Quelle: Craig Larman, The historical accident of waterfall validity, in: Agile & iterative development [2004]
  19. 19. Die Standardisierung des Wasserfall-Modells ist eine Folge aus Zufall, Missverständnissen und Unkenntnis.
  20. 20. Die Folgen…
  21. 21. Die Zahlen belegen dies ... Studie der Standish Group (2001) Untersucht wurden 23.000 Projekte • Erfolgsdefinition: - Im Zeitrahmen - Im Budgetrahmen - Alle Funktionen wie im Original spezifiziert 60 Erfolgsanteil in % 50 40 30 20 10 0 6 9 12 18 24 Dauer in Monaten Quelle: Standish Group [2001]
  22. 22. Auch das DoD sieht das so … 1999: Studie früherer Wasserfallprojekte im amerikanischen Verteidungsministerium • Projekte mit insg. 37 Mrd. USD Umfang • 75% fehlgeschlagen oder nie benutzt • 2% benutzt ohne umfangreiche Anpassungen Quelle: Jarzombek. The 5thAnnual JAWS S3 Proceedings [1999]
  23. 23. Und andere ... UK-Studie Thomas '01 • Insgesamt 1027 IT- Projekte Ergebnis • 87% Fehlschläge • In 82% Wasserfall- Vorgehen als Hauptgrund für Fehlschlag genannt • 10% des entwickelten Code ging in Produktion • Davon nur 20% tatsächlich benutzt Quelle: Thomas [2001]
  24. 24. Der nächste Schritt: Empirisch
  25. 25. Empirischer Prozeß Royce sagt: «Baut es zweimal!» • Wenn neuartige Elemente und unbekannte Faktoren involviert sind, empfiehlt Royce 1/3 der Zeit in einen Wegwerf-Prototypen zu investieren, um daran zu lernen. W. H. Ray in “Process Dynamics, Modeling and Control”: • «When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.»
  26. 26. Der zweite Versuch … 1980: "DOD-STD-2167" • Wasserfall-Vorgehen • Dokumentenorientiert 1988: "DOD-STD-2167A" • Erlaubt erweiterte Freiheiten • Immer noch stark Pro- Wasserfall <http://tinyurl.com/5a6b9z>
  27. 27. Die Lösung: Iterativ
  28. 28. «Pläne sind nichts. Planen ist alles.» – Helmuth Graf von Moltke
  29. 29. Iterative Entwicklung Sequenz von Iterationen, wobei jede Iteration … • ein fertiges Ergebnis liefert. - "Iteration Release" • Aktivitäten wie Requirements-Analyse, Design, Programmieren und Testen beinhaltet. Iterationen gleich lang • typisch: 1-6 Wochen • aber immer "timeboxed"
  30. 30. Iteration Release Iteration Release • stabiles, integriertes System • wird nicht zwangsweise ausgeliefert • könnte aber jederzeit in Produktion genommen werden
  31. 31. Timeboxes und Milestones Milestone: Phasen-Ende Ende einer Timebox und Milestones fast identisch • Zeitpunkt • Erfüllte Eigenschaften Unterschied: Dinge gehen schief • Milestone: wird verschoben • Timebox: Eigenschaften werden angepasst
  32. 32. Iterative Entwicklung Kernpunkt • Anforderungen, Schätzungen, Pläne entstehen im Laufe der Zeit und werden allmählich verfeinert Elemente werden angepasst als Reaktion auf Feedback zu bisheriger Arbeit. • Reaktionen auf unvorhersagbare Entdeckungen und Veränderungen bei der Entwickung neuer Produkte sind jederzeit möglich
  33. 33. « Kein Plan überlebt die erste Feindberührung.» – Helmuth Graf von Moltke
  34. 34. Iterative Entwicklung … eine neuer Hype?
  35. 35. Iterative Entwicklung schon alt 1950er Jahre • USA Air Defense Project "SAGE": stagewise model • X-15 Überschall-Flugzeug 1960er Jahre • 61-63: Project Mercury • 0,5d Iterationen (!) 1970er Jahre • Command-and-Control System des Trident U-Boots (4 Iterationen) • Navy Helicopter-ship system LAMPS (45 Iterationen) <http://tinyurl.com/64vyhx>
  36. 36. Space Shuttle 1977-1980: Primary Avionics Software System • 17 timeboxed Iterationen • 31 Monate • Iterationslänge: ca. 8 Wochen • Feedback-getriebene Requirements Quelle: Madden/Rone: Space Shuttle Flight SW., Communications of the ACM [11/1984]
  37. 37. Space Shuttle Zitate • «Due to the size, complexity and evolutionary nature, the ideal software development process [the waterfall model] could not be strictly applied.» • «The waterfall lifecyle was not suitable because the requirements on the Shuttle program evolved during the software development process.»
  38. 38. Iterativ - wann?
  39. 39. «Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall.» – Friedrich Dürrenmatt
  40. 40. Komplexität von Projekten unklar, strittig Chaos Anforderungen Komplex Nicht komplett verständlich, nicht vorhersagbar Kompliziert Erst im Rückblick nachvollziehbar Einfach klar, einig sicher Technologie völlig unsicher
  41. 41. Genauigkeit von Schätzungen 4x Schätzung/Real 2x 1,5x 1,25x 1x 0,8x 0,67x 0,5x 0,25x Zeit im Projekt Quelle: McConnell's Software Estimation: Demystifying the Black Art
  42. 42. Wann ist Iterativ sinnvoll? Komplexe Projekte
  43. 43. Auch das DoD hat erkannt … 1980: DOD-STD-2167 • Wasserfall-Vorgehen • Dokumentenorientiert 1988: DOD-STD-2167A • Erlaubt erweiterte Freiheiten • Immer noch als Pro-Wasserfall angesehen 1994: Wechsel zu iterativer Entwicklung • Report: «Manage programs using iterative development. Apply evolutionary development with rapid deployment of initial functionality.» • MIL-STD-498 legt iteratives Vorgehen fest. <http://tinyurl.com/5dacf4>, <http://tinyurl.com/65wfyw>
  44. 44. State of the Art-Methodik Agile Development
  45. 45. Agiler Begriffswirrwar... eXtreme Programming Scrum Product Owner Burndown Chart Scrum Master Incremental Delivery Timeboxing Planning Poker Agile Retrospective Planning Meeting Review Meeting
  46. 46. Agile ≠ Projekt- Management
  47. 47. Scrum und Agile Scrum XP Agile Projektmanagement
  48. 48. Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. = Flexibilität
  49. 49. Kombiniert aus XP und Scrum… Infopark- Methdik
  50. 50. Was ist Scrum? «Scrum ist ein Weg, Kreativität, Freude an der Arbeit, Spass bei der Teamarbeit in produktive Bahnen zu lenken, um auch komplexe Produkte extrem effizient herzustellen.» – Ken Schwaber Quelle: Agile Software Development with Scrum, Ken Schwaber
  51. 51. Was ist Scrum? «Scrum» ist ein Begriff aus dem Rugby • Ein Rugby-Team bringt den Ball gemeinsam mit schnellen Pässen voran • Gegensatz zu Staffellauf Scrum bringt den gesunden Menschenverstand zurück ins Projekt
  52. 52. Scrum ist einfach 4 verschiedene Rollen 3 Arten von Dokumenten 4 Arten von Meetings Wenige Regeln • In wenigen Minuten erklärt
  53. 53. Product Owner Der “Kunde” • Repräsentant Aufgaben • Projekt inhaltlich steuern • Wert des Produkts maximieren • Priorisieren und Entscheiden • Initiator des Projekts • Steht für Fragen bereit • Pflegt das Product Backlog
  54. 54. Product Backlog Liste mit • Dingen, die getan werden sollen • gewünschte Eigenschaften Priorisiert • Oberster Punkt hat höchsten Wert Jederzeit erweiterbar • Alle können Input liefern
  55. 55. Team Optimal: 7 Leute • auch weniger möglich • keine festen Rollen, crossfunktional Realisieren die Wünsche im Product Backlog • eigenverantwortlich Vertrag • Commitment gegen störungsfreies Arbeiten
  56. 56. Sprint Zeitintervall fester Länge • typisch: 2-4 Wochen Ordnung im Chaos • keine externe Störung Anfang: Planning Meeting Ende: Review Meeting Ergebnis • Potentiell auslieferbares Produkt
  57. 57. Scrum Master “Chef-Mechaniker” • Stellt den Prozeß sicher • Plant und moderiert Meetings • Schützt Team vor Fremdeinflüssen • Beseitigt Hindernisse • Coacht die Beteiligten KEIN Projektleiter • Keine Weisungsbefugnis • Keine inhaltliche Verantwortung
  58. 58. Planning Meeting Am Anfang eines Sprints Teilnehmer • Team • Product Owner • Scrum Master Dauer • ~8 Std. für 30 Tage-Sprint 2 Teile • Sprint-Planung • Commitment
  59. 59. Review Meeting Teilnehmer • Team • Product Owner • Scrum Master • Weitere Interessierte Dauer • ~1-2 Stunden Inhalt • Team zeigt Ergebnisse • “running tested features”, keine Slides
  60. 60. Retrospective Nach dem Review Teilnehmer • Team • Scrum Master • Evtl. Product Owner Inhalt • Fragen: Was lief gut? Was können wir besser? • Ergebnis: Konkrete Veränderungen • Scrum Master moderiert
  61. 61. Sprint Backlog Aufgaben, die das Team im Sprint erledigen muss, um sein Commitment zu erfüllen Gehört dem Team • Separat vom Product Backlog halten
  62. 62. Daily Scrum Teilnehmer stehend • Team • Scrum Master • Interessierte nur Zuhörer 3 Fragen: Was … • habe ich gestern gemacht? • werde ich heute machen? • hindert mich am Erfolg? Vom Team für das Team • Diskussionen danach
  63. 63. Burndown Chart Zeigt Restaufwand aller offenen Aufgaben über die Zeit • Wird täglich vom Team aktualisiert • Gehört dem Team Groß, sichtbar an der Wand
  64. 64. Sprint-Abbruch Wenn das Sprint-Ziel unsinnig bzw. unerreichbar geworden ist Kann von jeder der Rollen verlangt werden Was passiert? • Es findet sofort ein Planning-Meeting statt Sehr selten
  65. 65. Zusammenfassung
  66. 66. Was enthält das Backlog?
  67. 67. User-Stories
  68. 68. User-Stories Anforderugen werden als User-Stories formuliert User-Stories ≠ Use-Cases
  69. 69. User Story Eine User Story ist ein leichtgewichtiges Element für Planung und Priorisierung von Anforderungen • enthält nicht alle Details • ist ein Versprechen auf ein Gespräch Zu Beginn eines Sprints • Gespräch zwischen Product Owner und Team • Festlegung nötiger Details • Ergebnis des Gesprächs: Akzeptanz-Tests
  70. 70. Anforderungen als User Stories Anforderungen • leichtgewichtig • für Kunden und Entwickler verständlich - ohne Dominanz für eine Seite Was ist eine User Story? • beschreibt Funktionalität, die wertvoll ist für den Kunden oder Nutzer «Als Benutzer kann ich meinen Lebenslauf auf der Web-Site veröffentlichen.»
  71. 71. Form Als ein [Benutzer-Typ] möchte ich [Fähigkeit], (damit [Nutzen]). «Al s Be n u t ze r k a ich me i n nn e n Le be n Ein Überziel (Epos) wird in au f de r W s l au f ve röf f e n e b -S i te mehrere Stories geteilt. t l i c h e n .» • Eine andere Geschichte, deren Details ein anderes Mal erzählt werden.
  72. 72. Drei Elemente Schriftliche Formulierung (Card) • zum Plannen • als Erinnerung • ein oder zwei Sätze • repräsentiert Anforderungen Gespräche über die Story (Conversation) • zur Klärung der Details • erst, wenn Umsetzung unmittelbar bevor steht Tests (Confirmation) • dokumentieren Details • klären, ob die Story fertig umgesetzt ist.
  73. 73. Beispiele Gute Stories • "Als Benutzer kann ich nach Stellen suchen." • "Als HR-Mitarbeiter kann ich neue Stellenangebote einstellen." • "Als Benutzer kann ich einschränken, wer meinen Lebenslauf sehen darf." Schlechte Stories • "Die Software soll in Java geschrieben werden." • "Das Programm redet mit der Datenbank über einen Connection-Pool." • "Es gibt einen grünen Kontakt-Button in Arial- Schrift 42 Pixel vom oberen Rand entfernt."
  74. 74. Wo bitte bleiben die Details? "Als Benutzer kann ich nach Stellen suchen" • Nach welchen Werten kann ich suchen? Stadt? Keywords? Titel? ... • Muss ich dazu angemeldetes Mitglied sein? • Kann ich meine Suche abspeichern? • Was wird auf der Ergebnisseite angezeigt? Manches gehört in eigene Stories Vieles wird im Gespräch geklärt
  75. 75. Details ins Gespräch .... Als Benutzer kann ich Informationen über jede Stelle sehen, die auf die eingegebenen Suchkriterien passt. Ralph sagt: Beschreibung, Gehalt und Ort anzeigen
  76. 76. ... Tests auf die Rückseite Versuche es mit - einer leeren Stellenbeschreibung - einer ganz langen Beschreibung - ohne Gehaltsangabe - mit einer 7-stelligen Gehaltsangabe
  77. 77. Verhandelbar Stories sind keine Verträge oder Anforderungen Die Details in Gesprächen verhandeln • Stories müssen nicht alle möglichen Details enthalten
  78. 78. Verhandelbare Story Als Firmenmitarbeiter kann ich für eine Stellenanzeige mit der Firmenkreditkarte zahlen. Hinweis: Visa, MasterCard sicher, vielleicht auch American Express
  79. 79. scheinbar präziser... Als Firmenmitarbeiter kann ich für eine Stellenanzeige mit der Firmenkreditkarte zahlen. Hinweis: Visa, MasterCard sicher, vielleicht auch American Express. Bei Einkäufen über 100€ nach ID auf Kartenrückseite fragen. Das System kann den Kartentyp anhand der ersten zwei Stellen der Kreditkarte erkennen. Das System kann die Kartennummer für die Zukunft speichern. Kartennummern mit Blowfish/SHA-256 verschlüsseln. Dabei auch Expiration- und Karten- Datum speichern, CCV muß aber nicht.
  80. 80. Goldene Regel: INVEST Independent Negotiable Valuable Estimatable Small Testable
  81. 81. Reihenfolge?
  82. 82. Backlog Liste mit Dingen, die getan werden müssen • gewünschte Eigenschaften des Produktes • als User-Stories • jederzeit erweiterbar Priorisiert: Oberster Punkt hat höchsten Wert • Alle können Input liefern, aber Product Owner priorisiert
  83. 83. Priorisieren nach Risiko und Wert hoch hohes Risiko hohes Risiko niedriger Wert hoher Wert Risiko niedriges Risiko niedriges Risiko niedriger Wert hoher Wert niedrig niedrig Wert hoch
  84. 84. Priorisieren nach Risiko und Wert hoch Zuerst vermeiden machen Risiko Als letztes Als zweites machen machen niedrig niedrig Wert hoch
  85. 85. Die Bestandsliste mit Stories Priorität Story Nutzen Risiko 1 D +++ +++ 2 B +++ ++ 3 C +++ + 4 A ++ + 5 F ++ + ... ... ... ...
  86. 86. Auf die Plätze, fertig, los! Priorität Story Nutzen Risiko 1 D +++ +++ Nächster Schritt Sprint 2 B +++ ++ 3 C +++ + 4 A ++ + Spätere Schritte 5 F ++ + ... ... ... ...
  87. 87. Gewonnene Erfahrung nutzen Priorität Story Nutzen Risiko 1 D +++ +++ Repriorisieren 2 B +++ ++ 3 C +++ + 4 A ++ + Neues 5 F ++ aufnehmen + ... ... ... ...
  88. 88. Was ist mir am wichtigsten? Keine einfache Entscheidung Faktoren sind: • Risiko • Kundennutzen • Man lernt aber auch im Projekt dazu … Oft irrational getroffen • Konfliktvermeidung • Oft dringend, aber nicht wirklich wichtig Eine andere Geschichte, die ein anderes Mal erzählt wird…
  89. 89. Und wann habe ich es? Schätzen • Aufgabe des Teams • Wichtiger Input für die Priorisierung Ein ganz großes Thema • Verschiedene Methodiken Auch eine andere Geschichte, die ein anderes Mal erzählt wird.
  90. 90. Was fehlt?
  91. 91. Projekt- management
  92. 92. Projektmanagement Projektziele • Strategisch und technisch • Projektleitdokument Rahmenbedingungen • Zeit • Budget Einige wichtige Rollen … • Projektleiter • Lenkungsausschuß Empfohlen: Prince 2
  93. 93. Projektlenkungsausschuß Gremium hinter dem Product Owner • Projektentscheidungen auf Arbeitsebene Hat volle Autorität und Verantwortung für die Projektdurchführung Wird vom Projektleiter über den Status unterrichtet und um notwendige Entscheidungen gebeten
  94. 94. Aufgaben Ernennung von … • Projektleiter • Product Owner Genehmigung sämtlicher Planungen / Änderungen Gewährleistung der Ressourcenverfügbarkeit und Kooperation während der Projektlaufzeit Schlichtung von Konflikten
  95. 95. Projektleiter Verantwortlich für Erreichung der Projektziele Organisiert und koordiniert das Projekt auf Tagesbasis • Ansprechpartner für Product Owner und Scrum Master Überwacht Budget- verteilung und -verbrauch Leitet Dokumentation/QA
  96. 96. … und noch viel mehr … aber dazu ein anderes Mal mehr.
  97. 97. Zusammenfassung Agile Entwicklungsmethodik • ≠ Projektmagnement Geeignet für ungenaue, wechselnde Anforderungen • flexible Webprojekte Braucht Coaching und Erfahrung • Infopark wendet Agile seit sechs Jahren an
  98. 98. Infopark AG Vorstellung
  99. 99. Infopark: Dialog im Web Kunden online gewinnen • durch Interaktion begeistern • 100 Web-Spezialisten erschließen für Ihre Geschäftsprozesse das Internet Sicher und wirtschaftlich • Analyse, Konzeption, Umsetzung und Betrieb von anspruchsvollen Portal-Lösungen
  100. 100. Infopark: Dialog im Web Digital im Web • über 600 Installationen • über 60.000 Anwender Software-Produkte • Infopark CMS Fiona - Portal-Lösungen • Infopark Online Marketing Cockpit
  101. 101. Infopark: Dialog im Web Dienstleistungen rund ums Web • Workshops - Web-Strategie, SEO, Web 2.0 etc. 4 1 • Prozess- und Nutzen- www Analyse 3 2 Konzeption und ˈwiː.kiː Realisierung • Consulting und Training • Betrieb als Service

×