Agile Methoden

Agile Methoden
flink
beweglich
"Agile" Team-Mitglieder müssen

offen für Veränderungen sein
selbständig arbeiten können
Verantwortung übernehmen wollen
diszipliniert arbeiten wollen
Scrum
eXtreme Programming (XP)
Kanban
Inkompatibel

Matrix-Organisation mit vielen Wechseln, keine gute Teambildung möglich
Prozesse konsolidieren, einheitliche Tools einführen
Projektaudits, bei denen auf Formalismen geachtet wird
Scrum
Ken Schwaber, 2001
Ursprung: Lean Production, Toyota
"Das Gedränge ist ein komplizierter Spielzug, der sorgsam einstudiert und
orchestriert werden muss. Er verlangt eine disziplinierte Teamarbeit"
(Pichler 2008)
Ziel

Ständige Weiterentwicklung
der Mitarbeiter,
der Arbeitsprozesse,
der Arbeitsmittel und Methoden,

unter gleichzeitig konstantem Beibehalten der Grundannahme:
Die Produktion ständig zu verbessern,
um höchste Qualität
bei niedrigstem Aufwand
zu erreichen (Kaizen).
Product Owner

Entwicklungsteam

Scrum Master
Der Scrum Master
ist
KEIN
Projektleiter
hat die Vision vom Produkt
legt das Ziel fest
stellt das Budget zur Verfügung
setzt die Prioritäten
schätzt die Aufwände
erledigt die Aufgaben
arbeitet selbstorganisiert
ist verantwortlich
Scrum leben
Team unterstützen und beschützen
Arbeitsmittel organisieren
Hindernisse beseitigen
enthält die Features des zu entwickelnden Produkts
Wird vor jedem Sprint aktualisiert, neu bewertet und priorisiert
Features sind grob beschrieben und grob geschätzt
Hoch priorisierte Features werden vom Team fein geschätzt und in den Sprint-Backlog übernommen
enthält alle Aufgaben für den aktuellen Sprint
neben Features auch technische u. administrative Aufgaben
Aufgaben sind feingranular und sorgfältig geschätzt
Daily Scrum

Tägliches max. 15 min Meeting im Stehen, jeder beantwortet 3 Fragen:
"Bist du gestern mit dem fertig geworden, was du dir vorgenommen hast?"
"Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten?"
"Gibt es ein Problem, das dich blockiert?"
Sprint

Anforderungsworkshop
Sprint mit Scrums
Review
Retrospektive
Meeting, in dem das Team die Sprint-Ergebnisse dem Kunden vorführt
Meeting, in dem der zurückliegende Sprint betrachtet wird
Was war gut, was könnte besser werden?
Häufigste Probleme

Mangelnde Verfügbarkeit des Produkt Owner
Entwicklungsteam kann hohes Qualitätsniveau nicht erfüllen
Scrum Master ist ehemaliger Projektleiter und fällt in alte Gewohnheiten zurück
XP
Kent Beck, 1999
Lohnbuchhaltungssoftware-Projekt, Chrysler
Konzentration auf Bewährtes
Pragmatik vor Generik/Featuritis
Nichts ist beständiger als der Wandel
Ständige Kundenpräsenz am Entwicklungsteam
Verzicht auf Formalia (Dokumente)
Viele und frühe Tests: Unit-Tests, Test-Driven
Pair Programming Ständiger Review, Vier-Augen-Prinzip, Wissensverbreitung
Kollektives Eigentum Aufgaben und Code gehören dem ganzen Team
Continous Integration Unit-Tests, Nightly Builds
Testgetriebene Entwicklung Tests vor Modul entwickeln
Kundeneinbeziehung
Refactoring Ständige Architektur-, Design- u. Code-Verbesserungen
Keine Überstunden Team-Produktivität sinkt mit Überstunden nachweislich
Iterationen In regelmäßigen kurzen Zeitabständen lauffähige Zwischenstände liefern
Metaphern Anforderungen (User Stories) in Kundensprache, Glossar
Coding Standards Gemeinsame Standards ermöglichen wechselnden Einsatz der Entwickler
Einfaches Design KISS (Keep it small and simple), YAGNI (Yout Aint't Gonna Need It)
Planning Game Team mit Kunde schätzt Aufwände
Agile Schätzmethoden

Story Points, Fibonacci
Vergleichsmethode
Planungspoker
Anforderungen: User Stories

Sehr schlanker Anwendungsfall (Use Case)
Beschreibung einer Funktion des System aus Sicht des Users
Muster: "Als x kann ich y tun, um z zu erreichen."

"Als Arzt kann ich alle Patienten sehen, die ich am Tage habe."
"Als Arzthelferin kann ich einem Patienten einen Termin geben."

Story-Card: Karteikarte, vorne User Story, hinten Akzeptanzkriterien
Häufigste Irrtümer

Agilität = XP (Nur eine Methode von mehreren)
Agilität = Chaos (Agile Methoden sind in Wahrheit regider als viele Andere)
Agilität = Keine (Es wird begründet dokumentiert, nicht pauschal)
Dokumentation
Agilität = Dogma (Klare Regeln - mit dem Willen zur Veränderung)
Agilität = Keine (Anforderungen sind wichtig, nicht aber auf Tonnen von Papier)
Anforderungsanalyse
Verbreitung

Umfrage Web-Magazin Methods&Tools (3/2008)
13% Wissen nicht, was das ist
17% Einsatz in allen neuen Projekten
56% Experimente in verschiedenem Umfang
http://blog.coldewey.com/agile/2008/03/06/verbreitung-agiler-entwicklung/print/

Google, ebay
Hamburg: IT-agile, XING, Otto
http://blog.xing.com/2009/05/einfuhrung-von-scrum-bei-xing-%E2%80%93-ein-erfahrungsbericht/

Microsoft: XP seit 2006 (Windows 7, Bing)
http://www.spiegel.de/spiegel/0,1518,634334-2,00.html

Tom deMarco (Erfinder der Strukturierten Analyse)
Agile Methoden sind der richtige Weg
http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
Quellen

Scum-Prozess: http://commons.wikimedia.org/wiki/Image:Scrum_process.svg?uselang=de
XP-Kreis: http://commons.wikimedia.org/wiki/Image:Xp-kreis.png?uselang=de
Burndown-Chart: http://en.wikipedia.org/wiki/File:SampleBurndownChart.png

rancor3k: http://www.flickr.com/photos/rancor3k/3257929471/ (Wasserfall)
virtva: http://www.flickr.com/photos/virtee/1304958972/ (scrum1)
FirstBaptistnashville: http://www.flickr.com/photos/firstbaptistnashville/2659905406/ (scrum2)
Improve It: http://www.flickr.com/photos/improveit/1675563146/ (whiteboard)

Roman Pichler: Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt 2007
Rollen
Scrum
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
evodion Information Technologies
Högerdamm 41, 20097 Hamburg
+49-40-2714340-0
info@evodion.de
http://www.evodion.de
Scopemanagement -

Zeitmanagement -

Kostenmanagement -
Kommunikationsmanagement -

Risikomanagement -
Qualitätsmanagement -


Lieferantenmanagement -
Personalmanagement -

Product Owner für die Produktversion
Team für die Sprints
Product Owner für den Releaseplan
Team für das Sprint Backlog
Product Owner
Product Owner für das Release-Reporting
Team für die Berichterstattung im Sprint
Product Owner mit Input vom Team
Product Owner für die Produktleistungsmerkmale
Team für die qualitätssichernden Maßnahmen
ScrumMaster für die richtige Anwendung des Prozesses
Management für die Bereitstellung der Mitarbeiter
Team für die Produktivität und kontinuierliche Prozessverbesserung
Traditioneller
Projektleiter
Aufgabe übernimmt in Scrum
adaptiv!
1, 2, 3, 5, 8, 13, 20, 40, 100, ?