extreme Programming: Überblick

Ähnliche Dokumente
Festpreisvertrag und agil nützt nicht viel? Stefan Roock, Henning Wolf,

RE bei agilen Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Sind wir nicht alle ein bisschen agil? Dipl.-Inform. Tammo Freese xpdays, Karlsruhe, 22. November 2004

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni Thomas Hemmer

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert,

Präsentation einer agilen Methode

Agile Softwareprozess-Modelle

ZuuL - Entwicklung eines Adventures

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Agile Methoden vs. Testen

Das Who s Who der agilen Methoden Golo Roden

Agile Methoden bei der Entwicklung medizinischer Software

Planst Du noch oder lebst Du schon (agil)?

Agile Einführung eines SAP Datenmanagement Systems bei der Maschinenfabrik Bernard Krone GmbH & Co.KG. Michael Sommerer

Sei Dein eigener SCRUM Master Agiles Arbeiten im Alltag. Hans-Christoph Gründler Nürnberg,

Agile Software Entwicklung. Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski

11. Tübinger Arbeitsrechtstag

XP, Scrum, Crystal, FDD:

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung

Universität Bielefeld. Softwarepraktikum. Gernot A. Fink SS Rückblick extreme Programming (XP)

Agile Praktiken für das Service Transition Management. und wie IT Automation Ihre Service Transition Prozesse verändert - Change Management

akquinet Anforderungen, Usability und Agilität Stefan Roock

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D Braunschweig

AGIL WIE EIN WASSERFALL

Agile Methoden und Projektverträge. Berlin DoSE

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

6 Jahre extreme Programming Eine Retrospektive

Extreme Programming ACM/GI Regionalgruppe Bremen,

Interpretation des agilen Manifest

Softwareentwicklung aus Sicht des Gehirns

Agiles Anforderungsmanagement Detlef Buder / Alexander Fischbach - Mai 2008

Scrum. Golo Roden.

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April GRIDFUSION

Projektmanagement. Projektmanagement

IT-Projektmanagement

Extreme Programming: Überblick

Extremes Programmieren

Are you Agile. SAQ Zug um Zug, 27. November Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen?

Projekt: Requirements Engineering Sommersemester Anforderungsspezifikation im X-Treme Programming

Klassische vs. agile Methoden der Softwareentwicklung

Herausforderungen bei agiler Entwicklung und agilem Testen

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

Extremes Programmieren

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

Fragestellungen im IT Projektgeschäft

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Agile Softwareentwicklung mit Scrum

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Scrum. Olivier Guillet, Daniel Saraci, Mai 2011

Agile SW- Entwicklungsmethoden. Ein agiler Vortrag über Ideen, die uns das Leben erleichtern sollen. von Paul Palaszewski

(und was wir davon lernen können!)

Agile Management Einführung in agiles Management

Lehrplan: Projektmanagement

Führung von agilen verteilten Teams

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH

Gemeinsam mehr erreichen.

Einführung in agile Entwicklung

extreme Programming (XP)

Qualifizierung für agile Methoden in der Programmiertechnik

Iterativ. Inkrementell

Inhalt. 3.1 Der inkrementelle Entwurf im Überblick Flache Aufwandskurve Qualitätskriterien für den inkrementellen Entwurf...

DER AGILE ENTWICKLER, VERSION 1.2

Titelbild1 ANSYS. Customer Portal LogIn

Agile Softwareentwicklung mit Scrum

Requirements Engineering für die agile Softwareentwicklung

Agile Dokumentation. Erfahrungen, Herausforderungen, Chancen. tekom, RG München doctima GmbH Johannes Dreikorn

Ganzheitliches IT-Projektmanagement

RE-Metriken in SCRUM. Michael Mainik

Gedränge. Was ist Scrum? Stefan Reinhold IT-Informatik GmbH

WAS IST XP? Vorteile von XP : extreme Programming. extreme Programming. flexible Planung geringer Dokumentationsaufwand geringe Kosten

Agile Softwareentwicklung mit Scrum

Software- Projektmanagement. Dokument V Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Trends in der Agilität Dr. Martin Geier

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis

Softwareentwicklung aus Sicht des Gehirns

Institut für Informatik AG Software Engineering. 15. März 2012 Seminar Beiträge zum Software Engineering

Wie funktioniert agile Software-

Agile Softwareentwicklung - Ein praktisches Beispiel -

SCRUM. Agile Development

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Agile Software-Entwicklung: Überblick und Techniken. Prof. Dr. Stefan Kowalewski Dr. Carsten Weise 1/29

Software Engineering

GI Fachgruppentreffen RE 2015

Wenn so ein agiler Zug erst mal losdampft gilt es als Scrum Master die Ruhe zu bewahren. Die Realität ist meist spannender als jede Fachliteratur

Kurzübersicht Unified Process und Agile Prozesse

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Extreme Programming mit Rails. xpdays, 23. November 2007 Tammo Freese

Scrum und Use Case Analyse. Agilität versus schwergewichtiger Analyse, ein Widerspruch?


Corporate Digital Learning, How to Get It Right. Learning Café

Starke vs. Schwache Prozesse. Seminarvortrag

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master,

Architektur in agilen Projekten

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Transkript:

extreme Programming: Überblick Dipl.-Informatiker Stefan Roock, stefan.roock@it-agile.de Dipl.-Informatiker Bernd Schiffer, bernd.schiffer@it-agile.de http://www.it-agile.de

Stellenwert agiler Softwareentwicklung Zweite Generation agiler Methoden verfügbar (XP in zweiter Auflage, IXP). Standish Group empfiehlt im CHAOS-Report 2004 agile Methoden. V-Modell XT (XT = extreme Tailoring) lässt Tailoring für agiles Vorgehen zu. Eclipse wird mit einer eigenen agilen Methode entwickelt. Microsoft setzt bei sich SCRUM ein (z.b. für.net). 21.11.2005 http://www.it-agile.de 2

XP Ende 1999 veröffentlichte Kent Beck extreme Programming Explained. 2005 ist die zweite Auflage erschienen: Ein komplett neu geschriebenes Buch. Ursachen für Änderungen: Präzisierung: z.b. Short Releases -> Weekly Cycle, Quarterly Cycle Vereinfachung: z.b. Metapher aufgegangen in Incremental Design Erfahrung: z.b. Aufteilung in Primär- und Folgetechniken Herausforderung: z.b. Test-First Programming, Daily Deployment, Pay-Per- Use 21.11.2005 http://www.it-agile.de 3

Nutzen von XP Hohe Qualität Aufgabenangemessene Software Anwender Wirtschaftlichkeit Agile Softwareentwicklung Stolz auf die eigene Arbeit Entwickler Geringer Stress Geringe Wartungskosten Kunde Flexible Planung Qualitätsarbeit 21.11.2005 http://www.it-agile.de 4

Money, Money, Money Der Nutzen der Software muss ihre Kosten übersteigen. 21.11.2005 http://www.it-agile.de 5

Der Prozessansatz Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten 21.11.2005 http://www.it-agile.de 6

Die Verantwortlichkeiten Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten Verantwortlich für Geschäftswert Verantwortlich für Technologie 21.11.2005 http://www.it-agile.de 7

Das agile Manifest We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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. Siehe http://www.agilemanifesto.org 21.11.2005 http://www.it-agile.de 8

XP: Werte, Prinzipien, Techniken konkret universell prüfbar Techniken (Practices) Werte komplementär konsistent situiert XP zielgerichtet Prinzipien breit anwendbar widersprüchlich anwendungsspezifisch Nach Beck: Extreme Programming Explained, 2005 21.11.2005 http://www.it-agile.de 9

XP-Werte Feedback Mut Kommunikation plus projektspezifische Werte Einfachheit Respekt 21.11.2005 http://www.it-agile.de 10

XP-Techniken (engl. Practices) Primärtechniken (engl. Primary Practices) zuerst einsetzen Folgetechniken (engl. Corollary Practices) erst einsetzen, wenn das Projekt die Primärtechniken beherrscht Folgetechniken ohne Primärtechniken sind gefährlich Die meisten Techniken sind nicht neu, sondern waren schon lange vor XP erfolgreich im Einsatz. Best Practices 21.11.2005 http://www.it-agile.de 11

Zeitlicher Projektverlauf: Beispiel Explorationsphase Release- Planung Release- Planung Kick-Off Release 1 (intern) Release 2 (veröffentlicht) 2005 28.2. 4.4. 2.5. 6.6. 4.7. 1.8. 5.9. 3.10. 21.11.2005 http://www.it-agile.de 12

Ziel der Explorationsphase: Risiken reduzieren Fachlich Architekturell Technologisch Personell 21.11.2005 http://www.it-agile.de 13

Zeitlicher Projektverlauf: Explorationsphase Kick-Off Iterations planung Iterations planung Iterations planung Retrospektive Iteration 1 Iteration 2 Iteration 3 Iteration 4 28.2. 7.3. 14.3. 21.3. 28.3. 21.11.2005 http://www.it-agile.de 14

Ergebnisse der Explorationsphase Gemeinsame Vision über das Projekt Projektziele Grobe Gesamtschätzung Releaseplan Risikoliste Oberflächenprototypen Fachliches Kernmodell Architekturvorstellung Kern-Technologien Gemeinsame Sprache 21.11.2005 http://www.it-agile.de 15

Das Projektziel SMART Specific Measurable Achievable Relevant Time Based 21.11.2005 http://www.it-agile.de 16

Das Projektziel: Beispiel Apple itunes 1 Mio. Downloads im ersten Monat SMART Specific Measurable Achievable Relevant Time Based 21.11.2005 http://www.it-agile.de 17

Das Projektziel We have to be completely inflexible on where we want to go, but completely flexible on how we get there. Martin Fowler 21.11.2005 http://www.it-agile.de 18

Ziel eines Releases Mehrwert für den Kunden 21.11.2005 http://www.it-agile.de 19

Zeitlicher Projektverlauf: Release Release- Planung Iterationsplanung Iterationsplanung Iterationsplanung Retrospektive Iterationsplanung Iterationsplanung Iterationsplanung Iterationsplanung Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Iteration 7 4.4. 11.4. 18.4. 25.4. 2.5. 9.5. 16.5. 23.5. 1.7. 21.11.2005 http://www.it-agile.de 20

Die vier Variablen in Softwareprojekten Qualität Funktionalität Zeit Kosten 21.11.2005 http://www.it-agile.de 21

Die vier Variablen in Softwareprojekten Qualität Funktionalität Was machen Sie, wenn was schief geht? Zeit Kosten 21.11.2005 http://www.it-agile.de 22

Die vier Variablen in Softwareprojekten Qualität Funktionalität Zeit Kosten 21.11.2005 http://www.it-agile.de 23

RTF: Running Tested Features (Ron Jeffries) 21.11.2005 http://www.it-agile.de 24

Primärtechnik: Geschichten engl. Stories Anforderungen werden informell als Geschichten (Stories) formuliert. Idealerweise schreibt der Kunde die Geschichten. Häufig werden die Geschichten auf Karteikarten (Story-Cards) geschrieben. Versprechen für ein Gespräch (Promise for Conversation) Geschichten sind die Einheiten, die geschätzt werden. 21.11.2005 http://www.it-agile.de 25

Primärtechnik: Geschichten schätzen Abstrakte Maße 21.11.2005 http://www.it-agile.de 26

Primärtechnik: Geschichten Administratoren - System Administratoren legen Administratoren und Koordinatoren an Administratoren weisen Koordinatorengruppen Views zu Administratoren legen neue Koordinatorengruppen an Administratoren löschen Administratoren und Koordinatoren Weitere Features BBV-User vollständig löschen BBV-User Daten aus der ZBA auslesen Viewnamen aus dem DDS auslesen LogIn mit LDAP User Bereich verändern BBV-User analog zu bestehendem BBV-User berechtigen Berechtigungsvergabe mit Viewgruppen Mehrfachfilter Angabe von Wertemengen bei IN 2. Stufe BBV-User anlegen Benutzergruppen anlegen BBV-User Angaben ändern (Name, Raum, Telefonnr.) Filter setzen Koordinatoren - System 1. Stufe BBV-User in vorhandene Benutzergruppe eintragen BBV-User aus einer Benutzergruppe entfernen Einer Benutzergruppe einen View hinzufügen Einer Benutzergruppe eine Berechtigng an einem View entziehen 21.11.2005 http://www.it-agile.de 27

Folgetechnik: Echte Kundenbeteiligung engl. Real Customer Involvement Der echte Kunde schreibt die Geschichten (Stories) und die Akteptanztests. Gefahren kein echter Kunde verfügbar Kunde hat die falschen Qualifikationen Kunde hat kein ausreichendes Zeitbudget Voraussetzungen geeigneter Kunde Vertrauen zwischen Kunde und Entwicklern 21.11.2005 http://www.it-agile.de 28

Folgetechnik: Inkrementelle Ausbreitung engl. Incremental Deployment Das neue System wird schrittweise entlang des Fertigstellungsgrades an die Anwender verteilt. Gefahren Anwender erhalten Systemversionen, mit denen sich nichts anfangen können hohe Aufwände für Integration, z.b. mit Altanwendungen Voraussetzungen gemeinsame Planung zwischen Kunde und Entwicklern 21.11.2005 http://www.it-agile.de 29

Inkrementelle Ausbreitung erfordert häufig eine neue Perspektive 21.11.2005 http://www.it-agile.de 30

Folgetechnik: Eine Codebasis engl. Single Code Base Es gibt nur eine einzige Codebasis (keine Branches). Neue Versionen für die Anwender werden direkt aus der Codebasis erstellt. Gefahren Anwender erhalten fehlerhafte Systeme dringende Bugfixes stören Weiterentwicklung halb umgebaute Systeme werden an Anwender ausgeliefert. Voraussetzungen wenige Fehler Zerlegung großer Stories Zerlegung großer Refactoring automatisierte Integrationsbuilds (z.b. Cruise-Control) 21.11.2005 http://www.it-agile.de 31

Folgetechnik: Eine Codebasis Seien Sie nicht leichtfertig. 21.11.2005 http://www.it-agile.de 32