Embed Size (px)
Citation preview
Gelsenkirchen 26. – 28. März 2012
Agile Softwareentwicklung mit LotusNotes
27. März 2012
Werner Motzet
20
12
Methode für diesen Vortrag
• „Fertigstellungstermin“ ist fix 1030Uhr – 5 Min. „Vorspann“
– 40 Min. Überblick (trad. + agile Methoden)
– 40 Min. für Konkretisierung und Fragen
– 5 Min. Zusammenfassung /Literatur + Links
• Bitte Fragen stellen auch während des Vortrages (nicht versuchen zu merken)
• Erfahrung - über 20 J. PM + SW Koordinator Development (nicht selber „Programmierer“)
• Mehr Infos zu mir?
?
20
12
Erwartungen / Ziele
• Was erwartet Ihr Euch von diesem Vortrag?
• …
• …
• …
• Meine Ziele: – Überblick / Anregung / Verständnis
– Basis für Vertiefung (2. Schritt + Fragen)
– K E I N(E) allgemeingültiges/n Rezept(e)!
20
12
Übersicht
• Wie „läuft‘s“ - Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Wie läuft SW-Dev. mit LN?
• Welche Vorgehensweise verwendest Du/Ihr? den Vorschlag von IBM (12. Jan. 2012):
20
12
Wie läuft SW-Dev. mit LN?
• Im Redbook sieht der Aufbau dann so aus:
• richtiger Link zum Wiki: – http://www-
10.lotus.com/ldd/ddwiki.nsf/xpViewCategories.xsp?lookupName=Redbooks%20Wiki%3A%20Lotus%20Domino%20Development%20Best%20Practices
• Wie läufts „normal“? – …….
– …….
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
"traditionelle“ Methode(n)
• Wasserfallmodell (1970 – IEEE-Konferenz)
– sequenzielle Vorgehensweise
– Beispiel (W. Royce) Lockheed IT
– Erweitert 1981 v. Berry Boehm um:
QM (Validierung, Verifikation, Test)
20
12
"traditionelle“ Methoden
20
12
"traditionelle“ Methoden
• V-Modell
– 1986 IAGB
– Gesch. Marke
• V-Modell 97
– „moderner“
• V-Model XT (2005)
– Extrem Tailoring
20
12
Bewertung "traditionelle“
• Vorteile:
– streng sequenzielle Anordnung
– einfache Phasenstruktur -> einfache Organisationsstruktur (‘Staffellauf’)
– Einfache Planung und Kontrolle
– Stabile Anforderung(en) -> klare Abschätzung
20
12
Bewertung "traditionelle“
• Nachteile – Winston Royce 1970: "In my experience, however,
the simpler method has never worked on large software development [...].“
– Die “Welt” ist nicht so einfach: • Anforderungen ändern sich (sind noch nicht bekannt)
-> sehr hoher Aufwand in Analyse- und Konzeptphase!
• Einführung des Systems sehr spät
• Fehler werden (trotz Analyse) zu spät erkannt (“Big Bang”)
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Agile (lightwight / XP)
• Reaktion auf Nachteile von Wasserfall / V
• 80/90-er Jahre: (Große) Firmen suchen „Auswege“ = neue Methoden
– Ab 1991 IBM Alistair Cockburn „Befragung erfolgreicher Teams“ -> Buch 2001
– Ab 1990 neue Rolle für PM – 1996 erster Vortrag zu „scrum“ -> erstes Buch 2001
– 1999 Kent Beck -> Buch zu XP Extreme Programming
• Lockeres Treffen im Feb. 2001
20
12
Agiles Manifesto
Agile Manifesto
11.-13. Feb. 2001 Snowbird Ski-Resort
Utah
„Crystal“ ASD
DSDM
MDA / UML
OO/UML
XP / UML
XP/ Testdriven
XP / Ruby
XP / OO
20
12
Agiles Manifesto
• “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value”:
• Individuen und Interaktionen • Mehr als „Prozesse und Werkzeuge“
• Funktionierende Software • Mehr als „umfassende Dokumentation“
• Zusammenarbeit mit dem Kunden • Mehr als „[Kunst der] Vertragsverhandlungen“
• Reagieren[Antworten] auf Veränderung – Mehr als „ das Befolgen eines Plans“
20
12
Agiles Manifesto
• “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value”:
• Individuen und Interaktionen • Mehr als „Prozesse und Werkzeuge“
• Funktionierende Software • Mehr als „umfassende Dokumentation“
• Zusammenarbeit mit dem Kunden • Mehr als „[Kunst der] Vertragsverhandlungen“
• Reagieren[Antworten] auf Veränderung – Mehr als „ das Befolgen eines Plans“
Wir schätzen die Werte auf der rechten Seite, aber die auf der linken Seite sind uns wichtiger
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Was ist Scrum?
Woher kommt der Name?
20
12
Wurzeln von Scrum
“Der … (sequentielle) ‘Staffellauf’-Ansatz bei der Produktentwicklung… kann zu den Zielen der Maximierung von Geschwindigkeit und Flexibilität in Konflikt stehen. Im Gegensatz dazu kann ein ganzheitlicher oder ‚Rugby‘-Ansatz — mit dem ein Team als Einheit versucht Boden gut zu machen, indem der Ball hin- und hergespielt wird — besser heutige Wettbewerbsanforderungen erfüllen.” (frei übersetzt)
Hirotaka Takeuchi und Ikujiro Nonaka, “The New New Product Development
Game”, Harvard Business Review, Januar 1986
20
12
Scrum - Die Ursprünge
• Jeff Sutherland
– Initiale Scrums bei Easel Corp., 1993
– IDX und über 500 Personen arbeiten mit Scrum
• Ken Schwaber
– ADM (Advanced Development Methods)
– Präsentiert Scrum auf der OOPSLA 96 mit Sutherland
– Autor von drei Büchern über Scrum
• Mike Beedle
– Scrum-Pattern in PLOPD4
• Ken Schwaber und Mike Cohn
– Scrum Alliance in 2002 gegründet; zuerst innerhalb der Agile Alliance
20
12
Geschenkpapier
Gutscheine
Stornieren
Scrum
Stornieren
Geschenkpapier
Sprint 2-4 Wochen
Rücksendung
Sprint Ziel
Sprint Backlog Potentiell auslieferbares Produkt-Inkrement
Product Backlog
Gutscheine
24 Stunden
Rücksendung
20
12
Die Sprints
• Scrum-Projekte schreiten in Serien von Sprints voran – Analog zu den Iterationen bei XP
• Die typische Sprintdauer beträgt (2 -) 4 Wochen (Kalendermonat)
• Eine konstante Dauer führt zu einem besseren Rhythmus
• Das Produkt wird während des Sprints entworfen, kodiert und getestet
20
12
Keine Änderungen während des Sprints
• Planen Sie die Sprintdauer abhängig davon, wie lange Veränderungen vom Sprint ferngehalten werden können
Änderungen
!
20
12
Scrum - der Rahmen
Rollen
Meetings
Artefakte
•Produkt-Owner •ScrumMaster •Team
20
12
Rolle: Product Owner
• Definiert Produkt-Features
• Bestimmt Auslieferungsdatum und Inhalt
• Ist verantwortlich für das finanzielle Ergebnis des Projekts (ROI)
• Priorisiert Features abhängig vom Marktwert
• Passt Features und Prioritäten nach Bedarf für jeden Sprint an
• Akzeptiert oder weist Arbeitsergebnisse zurück
20
12
Rolle: Scrum Master
• Repräsentiert das Management gegenüber dem Projekt
• Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
• Beseitigt Hindernisse
• Stellt sicher, dass das Team vollständig funktional und produktiv ist
• Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
• Schützt das Team vor äußeren Störungen
20
12
Das Team • Typischerweise 5-9 Personen
• Funktionsübergreifend:
– QS, Programmierer, UI-Designer, etc.
• Mitglieder sollten Vollzeitmitglieder sein
– Wenige Ausnahmen (z.B. Systemadministratoren)
• Teams organisieren sich selbst
– Ideal: keine Titel
• Mitgliedschaft kann sich nur zwischen Sprints verändern
20
12
Die Scrum Rollen im Überblick
Bild verfügbar auf www.mountaingoatsoftware.com/scrum
Product Owner
Input von End-Usern, Customer, Team und weitere Stakeholders
Scrum Master
20
12
Zusammenarbeit und Verantwortung
http://www.implementingscrum.com/section/blog/cartoons/
20
12
•Produkt-Owner •ScrumMaster •Team
Rollen
Scrum - der Rahmen
Artefakte
•Sprint-Planung (+Grooming Meeting)
•Sprint-Review •Sprint-Retrospektive •Tägliches Scrum-Meeting
Meetings
20
12
Die Meetings
• . Teil 1
Sprint Plann-ing
Teil 2
Daily Scrum (meeting)
• Was hast du gestern getan? • Was wirst du heute tun? • Welche Hindernisse sind in deinem Weg?
• Rederecht nur “Pigs” • Anwesenheitspflicht • Keine Diskussion • Scrum Master moderiert
Sprint Review (max. 2h Vorb.)
Sprint Retrospective Im Anschluß an das Review • Ziel: Zusammenarbeit und Prozessverbessern • Story Telling Stil • Scrum Master moderiert
Grooming Meeting
20
12
Rollen
Scrum - der Rahmen
Meetings
•Product Backlog •Sprint Backlog •Burndown-Diagramm
Artefakte
20
12
Der Product Backlog • Die Anforderungen
• Eine Liste aller gewünschten Projektarbeiten
• Idealerweise soll jeder Eintrag wertvoll für Benutzer des Produktes oder Kunden sein
• Vom Produkt-Owner priorisiert
• Zu Beginn jedes Sprints re-priorisiert
Product Backlog
Sprint Backlog
20
12
Product Backlog: Beispiel Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports
(revenue-per-available-room) 8
Improve exception handling 8
... 30
... 50
20
12
Das Sprint Ziel
• Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
Database Application
Financial Services
Life Sciences
Support features necessary for population genetics studies.
Support more technical indicators than company ABC with real-time, streaming data.
Make the application run on SQL Server in addition to Oracle.
20
12
Management des Sprint Backlog
• Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
• Die geschätzte restliche Arbeit wird täglich aktualisiert
• Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern
• Neue, für den Sprint benötigte Arbeit taucht auf
• Wenn Arbeit unklar ist, definieren Sie eine Task mit einer größeren Zeitschätzung und brechen diese später herunter
• Updaten Sie verbleibende Arbeit sobald Sie mehr wissen
20
12
Burndown chart
0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Burndown
verbleibend
0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Burndown
verbleibend
zutun täglich
Aufwand
0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Burndown
verbleibend
zutun täglich
Aufwand
Prognose
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Bewertung agile und Scrum +
+ Kundennutzen steht im Mittelpunkt + Regelmäßigkeit (täglich, 4-wöchentlich) („Ritus“) + Überschaubare Zeiträume (schrittweise fachl. Einigung) + Früh sichtbare (Teil-)Ergebnisse + Transparenz (wo stehen wir) + Klare Regeln und klare Rollen + Gewisser Freiheitsgrad + Ein Team (Gleichheit) + Störungsfreiheit (no Change Request) + Rückfluß der Erfahrungen in den Prozess
20
12
Bewertung agile und Scrum -
DIE Methode gibt es nicht / ist keine Lösung Scrum geht von Idealen aus, die es so nicht gibt:
Jeder arbeitet nur in einem Projekt Keine Störung Team „nahe beisammen“ (alle! Incl. Tester und Doku) und 5-9
Personen.
Aufgabe des Productowners ist von einer Person nicht zu leisten (Daher heute oft Productowner-Team)
Doku kommt (ursprünglich) nicht vor Ein „Hauptproblem“ bleibt :
• Perfekte Kommunikation ist unmöglich! • Worte sind bedeutungslos.
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
?
20
12
Fragen?
20
12
Übersicht
• Wie „läuft‘s“, Softwareentwicklung mit LN?
• "traditionell“ Wasserfall V-Modell (V-97/V-XT)
• Agile Vorgehensweise/Methode(n)
• Scrum
• Bewertung agile und Scrum
• Fragen – Fragen – Fragen
• Zusammenfassung und weiterführende Literatur und Links
20
12
Zusammenfassung
• Erwartungen erfüllt?
– …..
– …..
– …..
• Ziele erfüllt?
• Bitte Bewertungsbogen ausfüllen
• Zeit für weitere Fragen jetzt und später (jetzt: hier
überall auf dem Camp ?)
20
12
Weiterführende Literatur + Links
• Enzyklopaedie der Wirtschaftsinformatik: http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon
• Alistair Cockburn :
– Twitter.com: @TotherAlistair http://alistair.cockburn.us/
20
12
Weiterführende Literatur + Links
• Mike Cohn
– http://www.mountaingoatsoftware.com
– twitter: @mikewcohn
20
12
Weiterführende Literatur + Links
• „ScrumPapers.pdf“ 224 S. von Jeff Sutherland and Ken Schwaber
• „ASQF-Nuernberg-BitterScrum.pdf“ v. Chris Rupp und Thomas Mödl
• http://scrum-master.ch/
_______________________
• Hermes http://www.hermes.admin.ch/welcome?set_language=de&cl=de
20
12
Kontakt
Werner Motzet
91781 Weißenburg i.Bay.
http://blog.motzet.it
http://twitter.com/#!/Werner_Mo
Werner Motzet
IM: im.bleedyellow.com oder
greenhouse.lotus.com
20
12
Danke
20
12
„Reserve“
• Scrum
20
12
Sprint-Planungsmeeting
Sprint Priorisierung
• Product Backlog analysieren und auswerten
• Sprint Ziel festlegen
Sprint-Planung
• Entscheiden, wie man das Sprint Ziel erreichen kann (Design)
• Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
• Sprint Backlog in Stunden schätzen
Sprint Ziel
Sprint Backlog
Business- Umgebung
Team- Kapazität
Product Backlog
Technologie
Aktuelles Produkt
20
12
Die Sprint-Planung
• Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
• Sprint Backlog wird erstellt – Tasks werden identifiziert und geschätzt (1-16 Stunden) – Dieses wird gemeinschaftlich getan, nicht vom
ScrumMaster allein
• Highlevel-Design wird berücksichtigt
As a vacation planner, I want to see photos of the hotels.
Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)
20
12
Das tägliche Scrum-Meeting
• Parameter: – Täglich
– 15 Minuten lang
– Stand-up
• Nicht zur Problemlösung – Alle sind eingeladen
– Aber nur Team-Mitglieder, der ScrumMaster, und der Produkt-Owner dürfen reden
• Hilft, andere/überflüssige Meetings zu vermeiden
