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, ?
Present Remotely
Send the link below via email or IM
Present to your audience
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article