Projektplan: Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

eXtreme Programming Lehrmeinung zur Softwaretechnik Architektur ist ganz wichtig Process ist ganz wichtig Vollständige Anforderungsdefinition ist unabdingbar Kent Beck (Berater im Silicon Valley)’s Meinung zur Softwaretechnik: Der ganze Quatsch hält nur auf lasst uns lieber Programmieren . . . Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Übersicht eXtreme Programming Das Planungsspiel Testen Pair Programming Raumaufteilung on-site customer Design Metapher Gemeinsamer Codebesitz Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

eXtreme Programming Prinzipien / Elemente Das Planungsspiel (The planning game) der Kunde schreibt "Stories" auf Story-Karten (Use Cases mit kurzer textueller Beschreibung) Die Entwickler schätzen den Entwicklungsaufwand (basierend auf grober Zeiterfassung und Vergleich mit früheren Schätzungen, aber ohne besondere Techniken) Kunde wählt (begrenzt durch den gesteckten Zeit- und Kostenrahmen) zu realisierende Stories für das nächste Release aus Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Story Card Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testen Stories werden in Implementierungs-Tasks / (Teil-) Funktionalitäten runtergebrochen Kunde schreibt Tests für seine Stories bevor man eine Funktionalität implementiert wird als erstes dafür ein "einfacher" Test (Test-first) geschrieben dann wird solange implementiert, bis der Test durchläuft fertig, nächste Funktionalität oder Test erweitern und Implementierung erweitern Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Task Card Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testen Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Paar-Programmierung (Pair Programming) Man sitzt immer zu zweit vor dem Rechner Einer tippt, erklärt, . . . Einer schaut, fragt, meckert, achtet auf Vorgehen und Standards, ... Paare werden Task-weise neu zusammengestellt Ersatz für Reviewing-Techniken Ziele sind die selben Paar-Programmierung ist eXtremer als Reviewing Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Raumaufteilung großer Raum für das ganze Team Rechner in der Mitte mit genügend Platz damit bis drei Leute davor sitzen können Hilfe auf Zuruf ist möglich Kein Teppich, damit die Stühle besser hin und herrollen können Cubicles an den Außenwänden Tisch für Besprechungen Kaffee Ecke mit (jeder Menge) Snacks und kleine Spiele, ... Tafeln für Diskussionen Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik, Empowerment, ...) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Raumaufteilung Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Kunde vor Ort (on-site customer) Ein Kundenvertreter sitzt die ganze Zeit beim Entwickler-Team (lebende Anforderungsdefinition) Der Kundenvertreter kennt die Anwendungsdomäne, ist selber zukünftiger Anwender oder Anwender des Vorgängersystems Der Kundenvertreter schreibt Stories (Use-Cases) Der Kundenvertreter implementiert Tests für die Stories Der Kundenvertreter priorisiert Anforderungen im Planungsspiel Der Kundenvertreter nimmt Releases ab und entscheidet über Projektfortsetzung (Wo kriegt man solche Kunden her?) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Einfaches / simples Design Lehrmeinung: Kosten für Änderungen steigen exponentiell mit Projektlaufzeit Kent Beck’s Meinung: Änderungen werden mit der Projektlaufzeit eher billiger Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Einfaches / simples Design Die Lehrmeinung impliziert: Kent Beck’s Meinung impliziert Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Design in XP kein "Voraus-Design" kein Design für Wiederverwendung kein Product-Line-Design immer nur die gerade notwendigsten Klassen und Methoden Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Metapher eines der ungelösten Mysterien des XP Metapher ist gemeinsame bildhafte Vorstellung des Systems z.B.: Bahnhof, Postamt, Markt, Agentensystem, ... Methapher sorgt für gemeinsame Sprachwelt im Team und mit dem Kunden Der Begriff bleibt im Buch ziemlich unklar Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Kleine Releases sobald wie eben möglich wird das erste Teil-Release an den Kunden ausgeliefert und geht dort in "Produktion" (z.B. nach drei Monaten) dann folgen viele kleine Releases in kurzen Abständen (z.B. monatlich) Im Prinzip die Idee des "iterativen" Lebenszyklusmodells (wie beim Unified Process) frühes Feedback durch den Kunden Steuerung noch möglich Gefahr fehlerhafter neuer Releases wird durch automatisches Testen minimiert Achtung: Altdatenbestände / festgeschriebene Bedienungsabläufe können Redesign-Schritte behindern Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Gemeinsamer Codebesitz Keine Aufteilung des Programms in Verantwortungsbereiche Jeder ist für das gesamte verantwortlich Jeder darf überall beliebig ändern Aber: die Tests müssen weiter durchlaufen Das machen wir in Fujaba auch so funktioniert gut (obwohl wir bisher nicht mal automatische Tests haben) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Coding Standards damit "gemeinsamer Code-Besitz" funktioniert muss Code möglichst überall gleich aussehen starke Coding Standards werden benötigt Paar-Programmierung stellt Einhaltung der Standards sicher das machen wir in Fujaba mit einem Indentierungstool Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Refactoring Refactoring heißt Code-Reorganisation / kleiner Redesign-Schritte Copy-Paste Code in Methoden auslagern Klassenhierarchie überarbeiten Hilfsklassen, -methoden, -strukturen einführen . . . Immer wenn man was sieht, was man mal überarbeiten sollte, auf die Task-Card schreiben bevor man neue Funktionalität implementiert, gegebenenfalls Desginänderungen vornehmen während der Implementierung nicht gleichzeitig refactorieren nach der Implementierung Refactoring-Tasks abarbeiten Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Kontinuierliche Systemintegration fertige Teilfunktionalitäten werden so früh wie möglich (täglich) in die Team-Master-Kopie integriert dafür gibt es einen extra Integrations-PC das machen wir mit CVS Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

40 Stunden Woche müde Leute machen Fehler müde Leute sind unproduktiv Kent möchte genügend Zeit für seine Kinder haben entspricht allen allgemeinen Empfehlungen zur Produktivität von Arbeitskräften widerspricht der industriellen Praxis (gerade bei IT-Start-Ups) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Rollen in einem XP-Projekt Programmierer: fast alle sind Programmierer Tests schreiben Refactoring Tests implementieren kommunizieren pairen Kunde ein Kundenvertreter vor Ort "lebende" Anforderungsdefinition funktionale Anforderungen als Stories formulieren funktionale Tests schreiben Funktionalität für die Releases auswählen Verbindung nach Hause halten Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Rollen in einem XP-Projekt Tester einer im Team unterstützt den Kunden beim Schreiben der funktionalen Tests Tracker schiebt die "Done" Markierungen auf dem Balkenplan weiter führt Produktivitätsstatistiken Coach verantwortlich für die Einhaltung / Umsetzung der XP Prinzipien wichtig beim Einstieg in die XP-Arbeitsweise etwas auch für die Architektur verantwortlich: wenn nötig, Refactoring initiieren Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Rollen in einem XP-Projekt Consultant XP fördert / produziert "allround" Programmierer für komplizierte / neue Technik(en) braucht man gegebenenfalls einen Berater Big Boss der "Projektmanager" vertritt / beschützt das Team nach außen hin trifft gelegentlich Personalentscheidungen mischt sich nicht in technische Sachen / die eigentliche Arbeit ein Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Bewertung XP hat viele gute Elemente / "Best Practices" Test-First Prinzip Paar-Programmierung (Reviewing funktioniert oft schlecht) Planungsspiel und On-Site-Kunde (wenn das der Kunde mit macht) XP hat klare Beschränkungen kleine Projekte keine sicherheitskritischen Systeme wo zertifizierte Entwicklungsprozesse verlangt´werden XP und Softwaretechnik sind eigentlich kein Widerspruch Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Datenflussmodellierung mit FLOW (Kurt Schneider) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Datenflussmodellierung mit FLOW (Kurt Schneider) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Datenflussmodellierung mit FLOW (Kurt Schneider) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Fachgebiet Software Engineering. Übersicht. © 27. 03 Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University