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
Sebastian Meyer: Labor "Software Engineering Experiment" 3
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
Sebastian Meyer: Labor "Software Engineering Experiment" 4
Wasserfallmodell Wasserfallmodell -- ÜÜberblickberblick
Sebastian Meyer: Labor "Software Engineering Experiment" 5
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
Sebastian Meyer: Labor "Software Engineering Experiment" 6
Probleme in heutigen ProjektenProbleme in heutigen Projekten
Software-Projekte
Qualität und
Wartbarkeit
kürzeretime-to-market
schnellereReleasezyklen
viele, späteÄnderungen
Sebastian Meyer: Labor "Software Engineering Experiment" 7
• 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
Sebastian Meyer: Labor "Software Engineering Experiment" 8
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.
Sebastian Meyer: Labor "Software Engineering Experiment" 9
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
Sebastian Meyer: Labor "Software Engineering Experiment" 10
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
Sebastian Meyer: Labor "Software Engineering Experiment" 11
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.“
Sebastian Meyer: Labor "Software Engineering Experiment" 12
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
Sebastian Meyer: Labor "Software Engineering Experiment" 13
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
Sebastian Meyer: Labor "Software Engineering Experiment" 14
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
Sebastian Meyer: Labor "Software Engineering Experiment" 15
„„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
Sebastian Meyer: Labor "Software Engineering Experiment" 16
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
Sebastian Meyer: Labor "Software Engineering Experiment" 17
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
Sebastian Meyer: Labor "Software Engineering Experiment" 18
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
Sebastian Meyer: Labor "Software Engineering Experiment" 19
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
Sebastian Meyer: Labor "Software Engineering Experiment" 20
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
Sebastian Meyer: Labor "Software Engineering Experiment" 22
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
Sebastian Meyer: Labor "Software Engineering Experiment" 23
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
Sebastian Meyer: Labor "Software Engineering Experiment" 24
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?
Sebastian Meyer: Labor "Software Engineering Experiment" 25
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!
Sebastian Meyer: Labor "Software Engineering Experiment" 26
Beispiele: Story CardBeispiele: Story Card
Sebastian Meyer: Labor "Software Engineering Experiment" 27
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
Sebastian Meyer: Labor "Software Engineering Experiment" 28
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
Sebastian Meyer: Labor "Software Engineering Experiment" 29
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
Sebastian Meyer: Labor "Software Engineering Experiment" 30
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
Sebastian Meyer: Labor "Software Engineering Experiment" 31
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
Sebastian Meyer: Labor "Software Engineering Experiment" 32
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!
Sebastian Meyer: Labor "Software Engineering Experiment" 33
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
Sebastian Meyer: Labor "Software Engineering Experiment" 34
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
Sebastian Meyer: Labor "Software Engineering Experiment" 35
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
Sebastian Meyer: Labor "Software Engineering Experiment" 36
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
Sebastian Meyer: Labor "Software Engineering Experiment" 37
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
Sebastian Meyer: Labor "Software Engineering Experiment" 38
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
Sebastian Meyer: Labor "Software Engineering Experiment" 39
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
Sebastian Meyer: Labor "Software Engineering Experiment" 40
ProjektablaufProjektablauf
• 1. Blocktag: Projektvorstellung, Prototyp
• 2. Blocktag: Iterationsanfang mit Planning Game– Iteration jeweils 1 Tag
Sebastian Meyer: Labor "Software Engineering Experiment" 41
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 (?!)