Labor "Software Engineering Experiment"

Transkript

1 Labor "Software Engineering Experiment" Extreme Programming -Theorie - Sebastian Meyer sebastian.meyer@inf.uni-hannover.de

2 Geschichte 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" 2

3 Rückblick: Klassisches Software 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" 3

4 Wasserfallmodell - Überblick Sebastian Meyer: Labor "Software Engineering Experiment" 4

5 Das as Spannungsfeld Reife Verfahren diszipliniertes Vorgehen Bedarf und Prioritäten sind verschieden Verbesserung in einem Bereich ohne zu viel Verschlechterung im anderen Passgenauigkeit der Hilfsmittel (Checklisten, Templates, Vorgaben) wenig Overhead wo liegt der größte Grenznutzen für eine Firma/ein Projekt? Gutes Reaktionsvermögen schnell und flexibel Sebastian Meyer: Labor "Software Engineering Experiment" 5

6 Probleme in heutigen Projekten kürzere time-to-market schnellere Releasezyklen viele, späte Änderungen Software-Projekte Qualität und Wartbarkeit Sebastian Meyer: Labor "Software Engineering Experiment" 6

7 Projektmanagement einmal anders: agil Beobachtung: Planung hat ihre Grenzen Daher nur nächste Schritte genau planen, spätere nur grob Voraussetzung: Ständige Fortschrittskontrolle und Feedback veränderte Anforderungen Plan passt sich oft an Plan ändert sich Fester Plan Beispiel für agiles Mikromanagement : SCRUM Sebastian Meyer: Labor "Software Engineering Experiment" 7

8 Das 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" 8

9 Wie wird 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" 9

10 Abläufe in XP (Prozesse) auf Basis der Praktiken User Stories test scenarios Viele Praktiken sind hier nicht explizit zu sehen! reqs. System Metaphor Concept Release Planning release plan Iteration Acceptance Tests Small Releases estimates new user stories next iteration Spike ( Prototyp ) Ca. 2-3 Wochen Frei nach J. Donovan Wells, Copyright 2000 Sebastian Meyer: Labor "Software Engineering Experiment" 10

11 Agile 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 ingenuity of people, and not any particular process, that cause projects to succeed. Courage also manifests itself in the features of feedback and refactoring, as described the XP principles. Sebastian Meyer: Labor "Software Engineering Experiment" 11

12 Planungshorizont nach Maß nach Barry Boehm Agiles Beispiel: SCRUM + mittelfristig geplant + reagiert schnell - hängt an MA-Qualifikation - Endprodukt nicht spezifiziert ad hoc extreme Programming Meilenstein- u. Risikogesteuert Meilenstein- u. Plangetrieben feingranulare Verträge Agile Methoden Daily SCRUM + SPRINT Sebastian Meyer: Labor "Software Engineering Experiment" 12

13 Prinzip und Denkweise von Agilen Methoden nach Frühauf, Conquest 2001 Bisheriger Ansatz Agiler Ansatz Mitwirkung des Kunden unwahrscheinlich kritischer Erfolgsfaktor Etwas Nützliches wird geliefert erst nach einiger (längerer) Zeit mindestens alle sechs Wochen Das Richtige entwickeln durch langes Spezifizieren, Vorausdenken Kern entwickeln, zeigen, verbessern Nötige Disziplin formal, wenig informell, viel Änderungen erzeugen Widerstand werden erwartet und toleriert Kommunikation über Dokumente zwischen Menschen Vorsorge für Änderungen durch Versuch der Vorausplanung durch flexibel Bleiben Sebastian Meyer: Labor "Software Engineering Experiment" 13

14 Praktiken von extreme Programming Praktiken Verstärken sich gegenseitig Zusammenspiel von Prozess, Testen und Architekturfragen On-site Customer Planning Game 40 hour week Prozesse Acceptance Testing Refactoring Collective Ownership Pair Programming Architektur Continuous Integration Unit Testing Test Simple Design Coding Standards Metaphor Short Releases Sebastian Meyer: Labor "Software Engineering Experiment" 14

15 Reifegrade für r Agilität 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 March Desired March May Desired May Average Pace (40h) Metapher XP Collect. Owner Coding Stds. Pair Prog Test Small Releases Planning Game Customer Refactoring Simple Design Cont. Integ. 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" 15

16 Beispiel: Reifestufen für f r On-site 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" 16

17 Extreme 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" 17

18 Rollen 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" 18

19 Rechte 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" 19

20 Rechte 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" 20

21 On-site 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" 22

22 On-site Customer - Tipps 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" 23

23 On-site Customer - Tipps 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" 24

24 Planning 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, , 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 Motor starten , D.Autor Anforderung 1. Fahrer dreht Zündschlüssel 2. Zündung an 3. Motor startet 4. Fahrzeug fährt Aufwand, Datum der Erledigung geschätzt: 3 GB Wichtig: jede Iteration hat gleich viel Zeit! Sebastian Meyer: Labor "Software Engineering Experiment" 25

25 Beispiele: Story Card Sebastian Meyer: Labor "Software Engineering Experiment" 26

26 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" 27

27 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" 28

28 Programmierung - TestFirst Wenn Testen gut ist, dann ist häufig/immer Testen besser Idee: Test schreiben, bevor implementiert wird 1. Test schreiben 2. 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" 29

29 Einfacher Entwurf - konkret 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" 30

30 Einfacher Entwurf - Tipps 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" 31

31 Collective 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" 32

32 Programmierstandards 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 Sebastian Meyer: Labor "Software Engineering Experiment" 33

33 Java 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" 34

34 Continuous 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" 35

35 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" 36

36 Pair Programming (II) Programmieren in Paaren: Wirkungen Zwang zur Disziplin (keine s, 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" 37

37 Pair Programming (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" 38

38 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" 39

39 Projektablauf 1. Blocktag: Projektvorstellung, Prototyp 2. Blocktag: Iterationsanfang mit Planning Game Iteration jeweils 1 Tag Sebastian Meyer: Labor "Software Engineering Experiment" 40

40 Rückblick: 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 (?!) Sebastian Meyer: Labor "Software Engineering Experiment" 41