Einführung in Agile

Agile Entwicklungs- und Projektmethodik bei Infopark

Thomas Witt<thomas.witt@infopark.de>

Software-Entwicklung

(classic)

Was der Projektleiter

verstand

Was derKunde erklärte

Was der Berater definierte

Wie es der Designer entwarf

Was der Programmierer programmierte

Wie das Projekt dokumentiert

wurde

Was tatsächlich installiert

wurde

Was dem Kunden in Rechnung

gestellt wurde

Wie das Projekt gewartet wurde

Was der Kunde tatsächlich

benötigt hätte

Quelle: unbekannt

Warum?

Wasserfall

1970: Dr. Winston W. Royce

Quelle: Royce, Managing the Development of Large Software Systems [1970] <http://tinyurl.com/r3jaj>

Department of Defense (DoD)

1980: "DOD-STD-2167"• Militär-Standard für

Software-Projekte• Wasserfall-Vorgehen• Dokumentenorientiert

<http://tinyurl.com/5uu6pr>

Definierter Prozess

Ziele• Abweichungen

minimieren• Effizienz maximieren

Liefert Qualität auf reproduzierbare Weise

Wasserfall ist ein definierter Prozess

Beispiele für definierte Prozesse?

Beispiel

Kochrezept

Beispiel

Industrielle Massenproduktion

Reproduzierbar

Gemeinsamkeiten?

IT- / Web-Projekte?

Die Welt ändert sich dauernd ...

Einige Probleme beim Wasserfall...Wir legen alle Details zu dem Zeitpunkt fest, an dem wir am wenigsten wissen.

Anforderungen müssen stabil bleiben, sich ändernde äußere Einflüsse werden nicht berücksichtigt.

Eine gute Idee in der Mitte des Projekts ist kein Geschenk, sondern eine Bedrohung.

Unnötig großer Umfang: Alles, was man vielleicht braucht, landet in den Anforderungen.

Großer Abstand zwischen Analyse und Realisierung

Dokumenten-Fokussierung führt zu massivem Wissensverlust (Stille Post)

Projektfortschritt nur schwer abschätzbar, das Ergebnis wird geprüft, wenn alles zu spät ist.

Risikoreiche Schritte finden am Ende statt.

Aha-Effekt kommt erst sehr spät: beim Anschauen.

Angst vor Fehlern führt zu unrealistischen Zeitplänen ("Sicherheitsaufschlag")

Verzögerungen werden schöngeredet

Was Royce selbst dazu sagt...

Quelle: Royce [1970]

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]

«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]

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 Zeitrahmen- Im Budgetrahmen- Alle Funktionen wie im Original spezifiziert

0102030405060

6 9 12 18 24

Erfo

lgsa

ntei

l in

%

Dauer in Monaten Quelle: Standish Group [2001]

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]

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]

Der nächste Schritt:

Empirisch

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.»

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>

Die Lösung:Iterativ

«Pläne sind nichts. Planen ist alles.»

– Helmuth Graf von Moltke

Iterative EntwicklungSequenz 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"

Iteration Release

Iteration Release• stabiles, integriertes

System• wird nicht zwangsweise

ausgeliefert• könnte aber jederzeit in

Produktion genommen werden

Timeboxes und MilestonesMilestone: Phasen-Ende

Ende einer Timebox und Milestones fast identisch• Zeitpunkt• Erfüllte Eigenschaften

Unterschied: Dinge gehen schief• Milestone:

wird verschoben• Timebox: Eigenschaften

werden angepasst

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

« Kein Plan überlebt die erste Feindberührung.»

– Helmuth Graf von Moltke

eine neuer Hype?

Iterative Entwicklung …

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>

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]

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.»

Iterativ- wann?

«Je planmäßiger die Menschen vorgehen, desto wirksamer trifft

sie der Zufall.»

– Friedrich Dürrenmatt

Komplexität von Projekten

Komplex

Chaos

Kompliziert

Einfach

Anf

orde

rung

en

Technologie völlig unsichersicher

klar, einig

unklar, strittig

Nicht komplett verständlich, nicht vorhersagbarErst im Rückblick nachvollziehbar

Genauigkeit von Schätzungen

1,5x

0,8x1x

0,25x

0,67x

4x

2x

1,25x

0,5x

Zeit im Projekt

Schä

tzun

g/Re

al

Quelle: McConnell's Software Estimation: Demystifying the Black Art

Komplexe Projekte

Wann ist Iterativ sinnvoll?

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>

State of the Art-Methodik

Agile Development

Agiler Begriffswirrwar...

Agile

Planning Meeting

Incremental Delivery

Burndown Chart

Scrum

Timeboxing

Scrum Master

Retrospective

eXtreme Programming

Product Owner

Review Meeting

Planning Poker

Agile

≠

Projekt-Management

Scrum und Agile

XP

Agile

Projektmanagement

Scrum

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding 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.

Manifesto for Agile Software Development

= Flexibilität

Kombiniert aus XP und Scrum…

Infopark-Methdik

«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

Was ist Scrum?

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 gesundenMenschenverstand zurück ins Projekt

Scrum ist einfach

4 verschiedene Rollen

3 Arten von Dokumenten

4 Arten von Meetings

Wenige Regeln• In wenigen Minuten

erklärt

Product OwnerDer “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

Product BacklogListe mit • Dingen, die getan

werden sollen• gewünschte

Eigenschaften

Priorisiert• Oberster Punkt hat

höchsten Wert

Jederzeit erweiterbar• Alle können Input liefern

TeamOptimal: 7 Leute• auch weniger möglich• keine festen Rollen,

crossfunktional

Realisieren die Wünsche im Product Backlog• eigenverantwortlich

Vertrag• Commitment gegen

störungsfreies Arbeiten

SprintZeitintervall fester Länge • typisch: 2-4 Wochen

Ordnung im Chaos• keine externe Störung

Anfang: Planning Meeting

Ende: Review Meeting

Ergebnis• Potentiell auslieferbares

Produkt

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

Planning MeetingAm Anfang eines Sprints

Teilnehmer• Team• Product Owner• Scrum Master

Dauer• ~8 Std. für 30 Tage-Sprint

2 Teile• Sprint-Planung• Commitment

Review MeetingTeilnehmer• Team• Product Owner• Scrum Master• Weitere Interessierte

Dauer• ~1-2 Stunden

Inhalt• Team zeigt Ergebnisse• “running tested

features”, keine Slides

RetrospectiveNach 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

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

Daily ScrumTeilnehmer 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

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

Sprint-AbbruchWenn 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

Zusammenfassung

Was enthält das Backlog?

User-Stories

Anforderugen werden als User-Stories formuliert

User-Stories ≠ Use-Cases

User-Stories

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

Anforderungen als User StoriesAnforderungen• 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.»

Form

Als ein [Benutzer-Typ] möchte ich [Fähigkeit], (damit [Nutzen]).

Ein Überziel (Epos) wird in mehrere Stories geteilt.• Eine andere Geschichte,

deren Details ein anderes Mal erzählt werden.

«Als Benutzer kann ich meinen Lebenslauf auf der Web-Site veröffentlichen.»

Drei ElementeSchriftliche 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.

BeispieleGute 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."

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

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

... Tests auf die Rückseite

Versuche es mit- einer leeren Stellenbeschreibung- einer ganz langen Beschreibung- ohne Gehaltsangabe- mit einer 7-stelligen Gehaltsangabe

Verhandelbar

Stories sind keine Verträge oder Anforderungen

Die Details in Gesprächen verhandeln• Stories müssen nicht alle

möglichen Details enthalten

Verhandelbare Story

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

Hinweis: Visa, MasterCard sicher, vielleicht auch American Express

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.

Goldene Regel: INVEST

Independent

Negotiable

Valuable

Estimatable

Small

Testable

Reihenfolge?

BacklogListe 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

Priorisieren nach Risiko und Wert

Risiko

Wertniedrig

niedrig hoch

hoch

hohes Risikoniedriger Wert

niedriges Risikoniedriger Wert

niedriges Risikohoher Wert

hohes Risikohoher Wert

Priorisieren nach Risiko und Wert

Risiko

Wertniedrig

niedrig hoch

hoch

vermeiden

Als letztesmachen

Als zweitesmachen

Zuerstmachen

Priorität Story Nutzen Risiko

1 D +++ +++

2 B +++ ++

3 C +++ +

4 A ++ +

5 F ++ +

... ... ... ...

Die Bestandsliste mit Stories

Priorität Story Nutzen Risiko

1 D +++ +++

2 B +++ ++

3 C +++ +

4 A ++ +

5 F ++ +

... ... ... ...

Nächster Schritt

Spätere Schritte

Spri

nt

Auf die Plätze, fertig, los!

Priorität Story Nutzen Risiko

1 D +++ +++

2 B +++ ++

3 C +++ +

4 A ++ +

5 F ++ +

... ... ... ...

Repriorisieren

Neues aufnehmen

Gewonnene Erfahrung nutzen

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…

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.

Was fehlt?

Projekt-management

Projektziele• Strategisch und technisch• Projektleitdokument

Rahmenbedingungen• Zeit• Budget

Einige wichtige Rollen …• Projektleiter• Lenkungsausschuß

Empfohlen: Prince 2

Projektmanagement

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

AufgabenErnennung von …• Projektleiter• Product Owner

Genehmigung sämtlicher Planungen / Änderungen

Gewährleistung der Ressourcenverfügbarkeit und Kooperation während der Projektlaufzeit

Schlichtung von Konflikten

ProjektleiterVerantwortlich 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

… und noch viel mehr

… aber dazu ein anderes Mal mehr.

Entwicklungsmethodik• ≠ Projektmagnement

Geeignet für ungenaue, wechselnde Anforderungen• flexible Webprojekte

Braucht Coaching und Erfahrung• Infopark wendet

Agile seit sechs Jahren an

Zusammenfassung Agile

Infopark AG

Vorstellung

Infopark: Dialog im WebKunden 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

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

Infopark: Dialog im WebDienstleistungen rund ums Web• Workshops

- Web-Strategie, SEO, Web 2.0 etc.

• Prozess- und Nutzen-Analyse

Konzeption und Realisierung• Consulting und Training• Betrieb als Service

「ˈwiː.kiː」

1

23

4www