Extreme Programming TheorieExtreme-Programm… · Labor "Software Engineering Experiment" Extreme...

Labor Labor "Software Engineering Experiment""Software Engineering Experiment"

Extreme Programming-Theorie -

Sebastian [email protected]

Sebastian Meyer: Labor "Software Engineering Experiment" 2

Geschichte der Agilen MethodenGeschichte der Agilen Methoden

• Agile Methoden entstanden

– Mitte der 90er Jahre

– Als „Gegenbewegung“ zu den „klassischen“ Prozessen• RUP• ISO 9000

– Durch Praktiker


RRüückblick: ckblick: „„KlassischesKlassisches““ Software EngineeringSoftware Engineering

• F.L. Bauer, NATO Science Conference, Garmisch-Partenkirchen 1968– „Anwendung von Ingenieursprinzipien für zuverlässige SW, die auf

realen Rechnern läuft und mit wirtschaftl. Mitteln erstellt wird.“

• Daraus resultierend:– Prozesse– Checks / Quality Gates / Reviews …– Dokumentation / Viele Typen von Dokumenten


Wasserfallmodell Wasserfallmodell -- ÜÜberblickberblick


DDas Spannungsfeldas Spannungsfeld

Reife Verfahrendiszipliniertes Vorgehen

Gutes Reaktionsvermögenschnell und flexibel

Passgenauigkeit der Hilfsmittel(Checklisten, Templates, Vorgaben)

wenig Overhead

Bedarf und Prioritätensind verschieden

wo liegt der größte „Grenznutzen“

für eine Firma/ein Projekt?

Verbesserung in einem Bereichohne zu viel Verschlechterung im anderen


Probleme in heutigen ProjektenProbleme in heutigen Projekten

Software-Projekte

Qualität und

Wartbarkeit

kürzeretime-to-market

schnellereReleasezyklen

viele, späteÄnderungen


• Beobachtung: Planung hat ihre Grenzen

• Daher nur nächste Schritte genau planen, spätere nur grob

• Voraussetzung: Ständige Fortschrittskontrolle und Feedback

• Beispiel für agiles „Mikromanagement“: SCRUM

Projektmanagement einmal anders: agilProjektmanagement einmal anders: agil

Fester Plan

veränderte AnforderungenPlan ändertsich

Plan passt sich oft an


Das Agile ManifestDas Agile Manifest

Manifesto for Agile Software Development

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.

Kent Beck Mike Beedle

Arie van Bennekum Alistair Cockburn

Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries

Jon Kern Brian Marick

Robert C. Martin Steve Mellor

Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.


Wie Wie wirdwird ein Projekt agil(er)?ein Projekt agil(er)?

• Druck reduzieren durch leicht-gewichtige Ansätze– Unnötige Dokumente einsparen– Vorgaben und Templates “verschlanken”

• Vage Anforderungen und Änderungen einkalkulieren– schnell zum Kernsystem, Weiterentwicklung inkrementell

• Besseres Feedback– konkrete organisatorische und technische Maßnahmen– engere Kundeneinbindung


SmallReleases

next iterationnew user stories

Concept

AblAblääufe in XP (Prozesse) ufe in XP (Prozesse) auf Basis der Praktikenauf Basis der Praktiken

AcceptanceTests

test scenariosreqs.

Iterationrelease

plan

Ca. 2-3 Wochen

Frei nach J. Donovan Wells, Copyright 2000

Viele Praktiken sindhier nicht explizit zusehen!

estimates

Spike(“Prototyp”)

Release Planning

SystemMetaphor

User Stories


Agile WerteAgile Werte

• Ableitung aus dem Agile Manifesto

• Spezifisch für jede Methode– Z.B. für Extreme Programming (XP)

• Communication• Simplicity• Feedback• Courage

„XP acknowledges that projects are ultimately people-centric. It is the ingenuityof people, and not any particular process, that cause projects to succeed.Courage also manifests itself in the features of feedback and refactoring, asdescribed the XP principles.“


Agile Methoden

feingranulare Verträgead hoc

Meilenstein- u. Plangetrieben

Meilenstein- u. Risikogesteuert

eXtreme Programming

Agiles Beispiel: SCRUM+ mittelfristig geplant+ reagiert schnell- hängt an MA-Qualifikation- Endprodukt nicht spezifiziert

Daily SCRUM+ SPRINT

Planungshorizont nach MaPlanungshorizont nach Maßß nach Barry Boehmnach Barry Boehm


Prinzip und Denkweise von Agilen MethodenPrinzip und Denkweise von Agilen Methoden

Bisheriger Ansatz Agiler Ansatz

Mitwirkung desKunden

unwahrscheinlich kritischerErfolgsfaktor

Etwas Nützlicheswird geliefert

erst nach einiger(längerer) Zeit

mindestens allesechs Wochen

Das Richtigeentwickeln durch

langes Spezifizieren,Vorausdenken

Kern entwickeln,zeigen, verbessern

Nötige Disziplin formal, wenig informell, vielÄnderungen erzeugen Widerstand werden erwartet und

toleriertKommunikation über Dokumente zwischen Menschen

Vorsorge fürÄnderungen

durch Versuch derVorausplanung

durch „flexibelBleiben“

nach Frühauf,Conquest 2001


Architektur

„Prozesse“

Test

Praktiken von Praktiken von „„eXtreme ProgrammingeXtreme Programming““

On-site Customer

40 hour week

Acceptance Testing

Planning GameMetaphor

Refactoring

Simple Design

Pair Programming

Unit Testing

Short Releases

Continuous Integration

Coding Standards

Collective Ownership

• Praktiken– Verstärken sich gegenseitig – Zusammenspiel von Prozess,

Testen und Architekturfragen


„„ReifegradeReifegrade““ ffüür Agilitr Agilitäätt

• Kent Beck: „Turn to 10“– Voll aufdrehen: eXtreme!

• Idee der „Agilitäts-Reife“– Man kann nicht immer

„auf 10 drehen“– Jedenfalls nicht sofort– Und manchmal will

man es gar nicht

• Daher werden Reifestufen definiert– Jede XP-Technik einzeln

bewertet– Resultat:

• Radar-Diagramme, • „Roadmap“ zur Umsetzung• „Metrik für Agilität“

02468

10Pair Prog

Test

Small Releases

Planning Game

Customer

Refactoring

Simple DesignCont. Integ.

Coding Stds.

Collect. Owner

Metapher

Pace (40h)

Average

XP

MarchDesired MarchMayDesired May

Aus: Krebs, William (2002): Turning the Knobs: A Coaching Pattern for XP through Agile Metrics. Springer, Lecture Notes on Computer Science 2418


Beispiel: Reifestufen fBeispiel: Reifestufen füür Onr On--site Customersite Customer

• Oben etwas „lustig“ formuliert, aber ernst gemeint• Beachtlich: „desired“ muss nicht 10 sein!• Current-Einschätzung ist wichtig, um Fortschritt zu

sehen• Langsam starten, in Zyklen fortschreiten

Aus: Krebs, William (2002): Turning the Knobs: A Coaching Pattern for XP through Agile Metrics. Springer, Lecture Notes on Computer Science 2418


Extreme ProgrammingExtreme Programming

„XP ist eine Diziplin der Software-Entwicklung, die sich durch

Einfachheit, Kommunikation, Feedback und Mut

auszeichnet. Dabei wird den jeweiligen Rollen […] hohe Bedeutung eingeräumt und den Personen in diesen Rollen außerdem

Schlüsselrechte und –verantwortlichkeiten

zugeschrieben“

Aus: Ron Jeffries et.al. Extreme Programming Installed


Rollen in XPRollen in XP

• XP kennt im wesentlichen drei verschiedene Rollen

– Kunde• Wählt Funktionalität nach ihrem Geschäftswert aus• Priorisiert Features• Bestimmt Akzeptanztests

– Programmierer• Entwerfen und programmieren die Software• Schätzen den Aufwand für Features

– Manager• Verschmilzt Kunde(n) und Programmierer zu einem Team• Ebnet dem Team den Weg


Rechte des Kunden und des ManagersRechte des Kunden und des Managers

• Recht auf einen Gesamtplan– Was kann zu wann zu welchen Kosten fertiggestellt werden?

• Recht auf maximalen Wertezuwachs– Und das aus jeder Programmierwoche

• Recht auf ein lauffähiges System– Immer– Durch Tests belegt

• Recht auf Änderungen– Ändern von Prioritäten und Features

• Recht auf Information– Z.B. über terminliche Änderungen


Rechte der ProgrammiererRechte der Programmierer

• Recht zu wissen, was als nächstes benötigt wird– Anhand von klaren Prioritäten

• Recht darauf, Qualität produzieren zu können– D.h. wenn es eng wird, wird an der Funktionalität gespart

• Recht auf Hilfe– Zu jeder Zeit– Von jedem (andere Programmierer, Kunde, Manager)

• Recht Einschätzungen abzugeben und zu ändern– Z.B. Schätzungen, die sich als unrealistisch herausstellen

• Recht darauf, Verantwortlichkeiten zu akzeptieren– Nicht zugewiesen zu bekommen


OnOn--site Customer / Kunde vor Ortsite Customer / Kunde vor Ort

• Aufgaben– User Stories schreiben– Fragen beantworten– Entscheidungen treffen

• Dazu: Kunde ist über gesamte Projekt-Laufzeit vor Ort

• User Stories– informelle kleine (Anwendungs-) Geschichten aus seiner Sicht

– Weder formal noch vollständig– Festgehalten auf Story Cards

– „Spezifikation“:• User Stories• abgeleitete Akzeptanztests • Unit Tests

Aber: (Diese) Dokumente sind für XP nicht so wichtig


OnOn--site Customer site Customer -- TippsTipps

• Muss nicht 100% vor Ort sein, aber kurzfristig erreichbar– Z.B. tägliches „Stand-up Meeting“ (ähnlich SCRUM)– Auf lange Frist könnte 100%-anwesender Kunde

sonst sogar die „Kundigkeit“ verlieren– Oft sind verschiedene „Kunden-Arten nötig“ (z.B. Multi-

Channeling)

• Wichtige Unterscheidung– Anwender beantwortet fachliche Rückfragen– Kunde priorisiert Story Cards

• Häufig der Versuch, den echten Kunden zu ersetzen– Kunden haben wenig Zeit– On-Site Customer sitzt zeitweise herum


OnOn--site Customer site Customer -- TippsTipps

• Verhaltensweisen von Kunden– Oft werden Soll- mit Istprozessen verwechselt– Altsystem wurde lange „trickreich umgangen“– Stellen sich oft nur lokale Änderungen dazu vor

• Daher: Entwickler helfen Kunden beim Story Card-Schreiben– Erinnern an die Prüfbarkeit, fragen gleich nach

• Ganz wichtig für den Erfolg– Anwenderkontakt ist essenziell– Wenn Entwicklerteam fachliche Frage hat: nicht selbst raten, fragen!– Anwender entscheidet über Alternativen– Überlegen und klären:

Welche „Kundenarten“ (GBs, Funktionen) sind relevant? Wie herankommen?


Anforderung

Aufwand,Datum der Erledigung

geschätzt: 3 GB

1. Fahrer dreht Zündschlüssel2. Zündung an3. Motor startet4. Fahrzeug fährt

Motor starten12.4.2002, D.Autor

Planning Game / PlanungssitzungPlanning Game / Planungssitzung

• Anforderungen werden auf Story Cards gesammelt– DIN A5 (auch DIN A4 ok), möglichst informell

• Entwickler schätzen Kosten für jede Story Card– Bisherige Produktivität des Entwicklungsteams ist Limit

• Entwickler notieren also, wie lange sie gebraucht haben• Vergleich schult die Schätzfähigkeit

– Vergangene Zeit ist nicht gleich eingesetzte Zeit!• Telefonate, email, Pausen• Verhältnis: „Velocity“, „Load Factor“ : brutto oft 3-5*netto

– Möglichst auf 1,5-2 drücken• Ebenfalls nach jeder Iteration errechnen

– Realistisch schätzen: • Brutto-Dauer schätzen, mit Netto-Produktivität

– Relative, abstrakte Schätzung oft besser– Maximalwert festlegen (5 Gu.): alles größere wird geteilt

– Wichtig: jede Iteration hat gleich viel Zeit!


Beispiele: Story CardBeispiele: Story Card


Planning Game / Planungssitzung (I)Planning Game / Planungssitzung (I)• Begriff Planungs“spiel“ ist für Deutschland zu unernst• Kunde wählt Story Cards für nächste Release(s) aus

– (Meistens) nach Nutzen priorisiert– Dabei kann – und muss – man oft rückfragen– Für diesen Schritt müssen Story Cards physisch

vorliegen (nicht im Computer)

• Entwicklerpaar nimmt sich oberste Story Card vom Stapel– Zufallselement sorgt für Mischung

• Story Cards sind Grundlage für Akzeptanz-Tests– Müssen daher testbar sein– Tests entwickeln sich ebenfalls im Laufe der Zeit– Es gibt zusätzlich Task Cards: feinere/technisch motivierte Aufgaben

• Streitfall: Was geschieht mit Story Cards weiter?– Variante 1: Dokumentation der Anforderungen– Variante 2: Wegwerfen! Anforderungen ändern sich ja


Planning Game / Planungssitzung (II)Planning Game / Planungssitzung (II)

• Arbeiten auf Basis von Story- und Task-Cards fordert Konzentration– Man muss das umsetzen, was gefordert ist– Weitergehende Ideen sind nicht gefragt, und man hat keine Zeit– Die Arbeit ist sehr intensiv und anstrengend

• Gefahr: Ausbrennen von Entwicklern– Zu lange am engen Zügel geführt, kein „gold plating“ mehr erlaubt– Zu lange im Stress– Zu lange keine neuen technischen Herausforderungen mehr

• Abhilfe: Gold Cards– Ein „Joker“ für einen lange angespannt arbeitenden Mitarbeiter– Muss mal (z.B. ein, zwei Tage lang) an einer neuen technischen Frage knobeln– Darf rumprobieren und Grundlagen legen– In der Schätzung gehen die automatisch ein, sofern regelmäßig durchgeführt


Programmierung Programmierung -- TestFirstTestFirst

• Wenn Testen gut ist, dann ist häufig/immer Testen besser

• Idee: Test schreiben, bevor implementiert wird

1. Test schreiben2. Test fehlschlagen lassen

– Fange ich damit wirklich noch nicht vorhandene Funktionalität ab?3. Implementieren, bis Test erfüllt

– Und das möglichst einfach!4. Refactoring


Einfacher Entwurf Einfacher Entwurf -- konkretkonkret

• Einfachheit ist Trumpf: Unnötige Mehrarbeit vermeiden– Nichts auf „Vorrat“ (wird nicht gebraucht, nicht getestet, belastet nur)– YAGNI: you ain´t gonna need it

• „Einfach drauf los?“– Nein: Architektur hilfreich; exzessives Entwerfen dagegen nicht

• Kriterien für Einfachen Entwurf– Code und Testfälle sollen alles verständlich machen

• z.B. durch gute Bezeichner• Keine „Magic-Values“

– Kein duplizierter Code („only once“ – Prinzip)

– So wenige Klassen wie möglich

– So wenige Methoden wie möglich• Dennoch eleganter/sauberer Code

Aber: alle Unit Tests laufen


Einfacher Entwurf Einfacher Entwurf -- TippsTipps

• Einer der häufigsten Einwände überhaupt:– „Wenn man an nicht gleich mit einplant, dass ...,

wird man sich später sehr viel schwerer tun“• Das lernt man seit jeher im Software Engineering

– Hier braucht man einen XP-Coach, um bei der (agilen) Stange zu bleiben

• Oft wirklich hilfreich: Standardarchitektur für Bereich– Flexibilität durch tragende Struktur– Aber natürlich: Refactorings/Aufräumen nicht zu lange aufschieben

• Empfehlungen– Ein gutes Design geht auf ein Whiteboard (oder zwei)– Keine Designsitzung über einen halben Tag; 3-5 Leute– Schlechte Designs rasch ändern (Refactoring)

• Dadurch auch Performance immer im grünen Bereich


Collective Code OwnershipCollective Code Ownership

• Jeder darf alles ändern

– Oder

• Jedem gehört alles

• Gewöhnungsbedürftig

• Nötig, um schnell Änderungen durchzuführen– Storycards laufen nicht entlang von Modulgrenzen!


ProgrammierstandardsProgrammierstandards

• Sollen dazu dienen, dass jeder den Code lesen und ändern kann– Collective Code Ownership

• Hohe Wartbarkeit des Codes

• Gute Lesbarkeit

• Hier (im Experiment) gelten die Java Coding Standards– http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html


Java Coding StandardsJava Coding Standards

• Packages haben Kleinbuchstaben und sind die umgedrehte Domain– Hier: de.unihannover.se.xpe09

• Klassennamen beginnen mit einem Großbuchstaben. Mehrere Wörter werden durch Binnengroßschreibung konkateniert– z.B. BusinessFactory

• Methoden, Variablen und Parameter fangen mit einem Kleinbuchstaben an. Binnengroßschreibung– z.B. getName(), firstName

• Konstanten werden großgeschrieben. Wörter mit _ getrennt– z.B. MAX_COUNT

• Klammern öffnen am Ende einer Zeile und schließen am Anfang einer neuen


Continuous IntegrationContinuous Integration

• Es wird spätestens nach jeder Storycard integriert.– An einem Integrationsrechner– Checkin nur, wenn alle Tests laufen– Taggen nach jedem Checkin

• Erzeugt ein immer auslieferbares System

• Erfordert kurze Buildzeiten– Erfordert Refactoring, intelligente Build-Tools

• Erfordert kleine, neue Checkins– Wenn zu lange gewartet wird, drifften die verschiedenen Versionen zu

weit auseinander


Pair Programming (I)Pair Programming (I)

• Jedes Paar arbeitet an einer Story Card– oder Task Card– Nach dem 4-Augen-Prinzip

• Pair Programming heißt: Keine Arbeitsteilung, alles gemeinsam!– Tastatur geht schnell hin und her (10 Min)

• Auch die Paar-Zusammenstellung wechselt ständig– Spezialwissen verteilt sich so im Team („Truck-Factor“)– Einheitlicherer Code– Mindestens 50% gute Leute sind nötig– Das hat aber Grenzen: Spezialisten und Domain-Subteam


Pair Pair ProgrammingProgramming (II)(II)

• Programmieren in Paaren: Wirkungen– Zwang zur Disziplin (keine emails, keine Telefonate!)– Zwang zur Teamfähigkeit (mit allen können)

• Auch soziale Kontrolle in Stresszeiten– Stärkere Konzentration auf die Aufgabe

– Lerneffekt• Meist erklärt der mit der Tastatur, warum er das tut, was er tut• Der Schlechtere lernt schnell hinzu• Aber der bessere wird langsamer

• Nebenwirkungen– Zu viele Paare auf zu engem Raum: schwierig– Aber zwei oder drei sind ok; Beifahrer hören sich gegenseitig

– Mobiliar muss so aufgestellt sein, dass Wechsel einfach ist


Pair Pair ProgrammingProgramming (III)(III)

• Pair Programming lernen– Ist nötig! Es dauert, sich daran zu gewöhnen– Ständiges Feedback: was ist gut gelaufen, was weniger?

• In der Durchführung– Pausen nicht am Arbeitsplatz– Unterbrechungen minimieren– Konzeptdiskussionen begrenzen– Management muss explizit verdeutlichen, dass es Pair Programming

will– An das geeignete Mobiliar denken (Pairs ermöglichen)

• Wenn einer sich nicht einfügt– Kann man ihn evtl. nicht zwingen– Möglichst aus dem Team nehmen– Lange nicht so gut: einer ohne Pairs; dann aber viele Reviews


Wie startet ein Projekt?Wie startet ein Projekt?

• Entwicklung eines Prototyps– Klären von technischen Problemen– Erkunden der Problemdomaine

• Vor der 1. Iteration und dann wenn nötig:• Kurze Designsitzung

– In echten Projekten max. halber Tag

• 1. Iteration wählen die Entwickler die Storycards aus

• Beachten der XP-Praktiken in den Iterationen– Sehr schnell, max. 2 Monate– Hier: 1 Tag


ProjektablaufProjektablauf

• 1. Blocktag: Projektvorstellung, Prototyp

• 2. Blocktag: Iterationsanfang mit Planning Game– Iteration jeweils 1 Tag


RRüückblick: Tipps zum Wasserfallmodellckblick: Tipps zum Wasserfallmodell

• Tester müssen nicht unbedingt auch schon das Design gemacht haben– Eine Ansicht: Entwickler dürfen nicht testen!– Realität: oft überlappt es sich

• Code sollte von zweitem Augenpaar durchgesehen werden– Heute gibt es formalisierte Verfahren des “Durchsehens”:

Walkthrough, Inspection, Review– Nicht nur Code sollte “durchgesehen” werden

• Testen Sie jeden Programmpfad mindestens einmal; sonst sollte man es nicht abnehmen– Path Coverage als ein Kriterium für ausreichenden Test– Wird selten wirklich befolgt– Die Abnahme selbst ist heute umfangreiche Prozessmodelle wert

• Kunden sollten beteiligt werden– Immer noch ein ungelöstes Anliegen: Kunden haben anderes zu tun (?!)

Extreme Programming TheorieExtreme-Programm… · Labor "Software Engineering Experiment" Extreme...

Documents

Transcript of Extreme Programming TheorieExtreme-Programm… · Labor "Software Engineering Experiment" Extreme...