Das Dokument behandelt Extreme Programming (XP), eine agile Softwareentwicklungsmethode, die auf Prinzipien wie iterative Entwicklung, kontinuierliche Integration und häufige Releases fokussiert ist. Es erläutert die Praktiken wie Pair Programming, Collective Code Ownership und das gnadenlose Überarbeiten (Refactoring) von Code. Ziel ist es, auf Kundenfeedback schnell zu reagieren und den Entwicklungsprozess zu optimieren, während gleichzeitig die Qualität des Codes durch Tests und klare Coding-Conventions sichergestellt wird.

1. präsentiert

2. objectiF eXtrem programmieren Kann man objectiF eXtrem programmieren?

3. objectiF eXtrem Vorstellung Einführung in XP TheSourceCodeIsTheDesign Code Generierung

4. Vorstellung SOFTWERFT (http://www.softwerft.de): Lösungen für professionelle Dienstleister SOFT:TIME ZEITLEISTUNGSMANAGEMENT automatisiert das kaufmännische Management von Dienstleistungen: vom Vertragsmanagement über die Zeiterfassung und das Genehmigungsverfahren bis hin zur Leistungsabrechnung, Rechnungsstellung und Auswertung der erzielten Ergebnisse. Olaf Lewitz: Geschäftsführer, Head of IT & Development

5. eXtreme Programming Iterativer und adaptiver Softwareentwicklungsprozeß Schöpfer: Kent Beck „ L istening, T esting, C oding, D esigning. That's all there is to software. Anyone who tells you different is selling something.“ Erstes Projekt: Chrysler-Lohnabrechnung (ChryslerComprehensiveCompensation) Pragmatische positive Erfahrungen werden als extreme Praktiken zu einem Ganzen

6. eXtreme Programming Einfaches Design Coding Conventions Collective Code Ownership Pair Programming Planning Game Continuous Integration Frequent Releases Kunde im Team Gnadenloses Überarbeiten (Refactoring) Design durch Tests System Metapher 40 Stunden Woche

7. Einfaches Design Do the simplest thing that could possibly work. Kurz gesagt: Entwickle niemals mehr, als für das im Moment anstehende Feature notwendig ist. Daraus ergibt sich ein iterativ wachsendes Design, das mit den implementierten Funktionen und deren Anforderungen wächst, nicht mit den Phantasien der Entwickler. Ausnahme: Datenbank-Layout, Architektur. Bedingung: Refactoring. Mandatorisch.

8. Coding Conventions Bedingung für Collective Code Ownership. Bedingung für Teamarbeit, Produktivität und PragmaticProgramming. Mehr als mandatorisch. Durch Codegenerierung zu unterstützen. Beispiele: Präfixe und Postfixe Sprache der Bezeichner, Groß- und Kleinschreibung Codelayout Alles, auf was man sich einigt, sollte fixiert sein!

9. Collective Code Ownership Jeder darf jede Codezeile in jedem Modul ändern. Ohne zu fragen. Das klingt viel revolutionärer, als es ist - vor allem für die Entwickler. Natürlich hat jeder die volle Verantwortung für den von ihm geschriebenen Code - das Config-Management verrät ihn... Bedingung für Refactoring. Absolut mandatorisch. Folge: Teamstolz statt Programmiererstolz. Funktioniert erstaunlich schnell.

10. Pair Programming Laut Buch wird jede Zeile Produktionscode von zwei Leuten gemeinsam programmiert. Erstaunlich (?) produktiv, wenn‘s funktioniert. Die Charaktere müssen passen. Vorteile: Gute Einarbeitung von neuen, wenig Know-How-Gefälle, wenige Bugs, gute Tests, gute Akzeptanz, deutlich gesteigerte Produktivität. Nachteil: Domänen- und technisches Wissen müssen gleichmäßig verteilt sein. Optional.

11. Planning Game Planung der anstehenden Tasks zu Beginn der Iteration. Festlegung der Prioritäten durch Kunden. Aufwandsschätzung durch Entwickler. Idealerweise mit Karteikarten. Macht XP aus.

12. Continuous Integration Der komplette Code des Projektes wird ständig (mindestens täglich) integriert und getestet. Kaum zusätzlicher Overhead für die Integration von Komponenten. Fehler treten sehr früh zutage, die Ursache ist leicht zu finden. Vollständiger Test aller Teile des Systems. Macht XP aus.

13. Frequent Releases Es werden häufig (in jeder Iteration, also alle ca. 2-4 Wochen) Releases an den Kunden gegeben. Kurzfristiges Feedback. Leichte Adaptierbarkeit von Änderungswünschen. Wenig Entwicklung „in die falsche Richtung“. Macht XP aus.

14. Kunde im Team Ein Mitarbeiter des Kunden ist Mitglied des Teams. Er arbeitet im selben Raum, steht jederzeit für Fragen der Entwickler zur Verfügung. Spezifikation erfolgt en detail während der Entwicklung mit dem Anwender. Idealvorstellung, optional.

15. Gnadenloses Überarbeiten (Refactoring) Nach der Implementierung jedes neuen Features muß das Design insgesamt soweit wie möglich vereinfacht werden. Danach!! Hervorragend behandelt durch Fowler. Stichwort: Eingeschlagenes Fenster... Absolut mandatorisch.

16. Design durch Tests Code a little, test a little... Der Unit Test definiert die Schnittstelle einer Klasse. Anwendungsfälle werden mit Grenz- und Problemfällen formuliert und dann "erfüllt". Idealer Weise gibt es keine Zeile ungetesteten Code. Problem: Datenbanken (Testdaten) Mandatorisch.

17. System Metapher Eine Metapher, die das System als ganzes treffend beschreibt. Meist schwer zu finden. Optional.

18. 40 Stunden Woche ;-)

19. XP Integration I Einfaches Design Hart. Architektur und Datenbanklayout müssen stehen. Frameworkentwicklung geht erstaunlich gut. Coding Conventions Bedingung: Kooperation und Pragmatismus. Laufend erweitern! Erbsenzähler im Team hilft! Collective Code Ownership Einfacher als es scheint, Teamerfolg zahlt sich schnell aus. Unit Tests beachten! Pair Programming Charaktere müssen zueinander passen.

20. XP Integration II Planning Game Workflow und Modus müssen eingewöhnt werden. Zeitschätzungen üben und dokumentieren! Continuous Integration Automatisierung notwendig Frequent Releases Automatisierung notwendig Kunde im Team Nicht bei jedem Kunden möglich Bei Standardsoftware durch Produktmanagement zu ersetzen.

21. XP Integration III Gnadenloses Überarbeiten (Refactoring) Hoher Spaßfaktor Man muß sich immer wieder die Zeit nehmen Design durch Tests Selbstdisziplin Bugs gleich in den Test! System Metapher Ich habe noch keine gute gesehen. 40 Stunden Woche Stellt sich wohl von selbst ein, wenn alles andere stimmt...

22. Integration Details 12 Entwickler Beginn der Einführungsphase im November Reihenfolge: Coding Conventions Unit Test Framework Iterationsplan und –workflow Integrationsumgebung (Build Management)

23. Literatur http:// www .c2. com / cgi / wiki ? ExtremeProgrammingRoadmap http://www.extremeprogramming.org/ http:// www . xprogramming . com / Kent Beck, Extreme Programming Explained: Embrace Change. ISBN: 0201616416 (dt. 3827317096 ) MartinFowler, Refactoring: Improving the Design of Existing Code. ISBN: 0201485672 (dt. 3827316308) Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master. ISBN: 020161622X

24. TheSourceCodeIsTheDesign Grobdesign in UML Wichtige, zentrale Klassen Schnittstellendesign im UnitTest Klassendiagramme sind die Ausnahme objectiF wird genutzt für Codegenerierung Aktivitätsdiagramme (Workflowdefinition) Sequenzdiagramme für komplexe Zusammenhänge

25. Design durch Test oder UML? objectiF vs. xUnit Vorteil objectiF Gut kommunizierbar an Nicht-Entwickler Übersicht über Zusammenhänge Dokumentation für Einsteiger Vorteil UnitTest Schnittstellen werden vom Benutzer aus entworfen Erfolgserlebnis, wenn Tests erfüllt sind Für jede Komponente existiert sofort eine Beispielanwendung Qualitätssicherung passiert quasi vor der Entwicklung

26. Fragen ? ? ?

27. KONTAKT ohltec SOFTWERFT GMBH Notkestraße 7 D- 22607 Hamburg Fon: +49 (0)40 - 31 99 1 -0 Fax: +49 (0)40 - 31 99 1 –100 [email_address] www.softwerft.de e