Software Engineering Projekt WS 07/

Transkript

1 Agile Software Entwicklung

2 Übersicht 1. Agile Software Entwicklung - Probleme bei der Software-Entwicklung - Das Agile Software Manifesto 2. Extreme Programming 3. Feature Driven Development 4. Kurzer 5. und Diskussion

3 Das Problem - Die Entwicklung von Software ist schwer : => Die Entwicklung braucht länger als geplant => Das Ergebnis entspricht nicht den Erwartungen des Kunden => Die Software enthält bei Auslieferung zu viele Fehler

4 Das Problem - Die Entwicklung von Software ist schwer : => Die Entwicklung braucht länger als geplant => Das Ergebnis entspricht nicht den Erwartungen des Kunden => Die Software enthält bei Auslieferung zu viele Fehler Warum???

5 Das Problem Warum? - Software-Projekte laufen sehr lang. Während dieser Zeit können sich die Anforderungen verändern. - Herkömliche Methoden der Software-Entwicklung reagieren zu träge auf Veränderungen. - Software-Entwicklung erfordert jedesmal erneut innovative, maßgeschneiderte Ansätze. Wie dieser Ansatz aussehen soll, wird oft erst während der Entwicklung deutlich, wenn die ersten Probleme der gewählten Architektur sichtbar werden. - Fehler im Design werden zu spät entdeckt. Die Kosten eines Design-Fehlers sind in herkömmlichen Modellen sehr hoch.

6 Das Problem : Programmieren vs. Planen Programmieren Planung ohne Peilung... (bzw. Planung)...ohne Programmierung

7 Das Problem : Fazit Software Entwicklung bedeutet das Treffen eines sich bewegenden Ziels (moving Target)

8 Agile Software Manifesto 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. Signed by 17 Developers on an Agile Meeting on February 11-13, 2001 (u.a. Kent Beck (), Martin Fowler (), Ron Jeffries (), Ward Cunningham (), Alistair Cockburn (Crytsal Methods), Jim Highsmith (ASD), Ken Schwaber (Scrum), Aarie van Bennkum(DSDM), Jon Kern () )

9 Extreme Programming

10 Extreme Programming - Übersicht Einleitung Konzepte Rollen Planungsspiel Pair Programming Lifecycle

11 Extreme Programming - Einleitung Entwickelt von Kent Beck und Ward Cunningham, 2000 verfolgt ein Quellcode-zentriertes Entwicklungskonzept. Quellcode spezifiert Subsysteme und Interfaces, enthält die Testfälle und die Probleme, welche durch die Testfälle aufgedeckt werden. Der Quellcode wird durch Refactoring überarbeitet. Quellcode erzeugt die Features, die der Kunde wünscht. Bei allen wesentlichen Vorgängen hat man es also mit Quellcode zu tun. Für wurde eine Kombination von Verfahren gesucht, die dies für sich allein zwar nicht erreichen, aber in Kombination ihre jeweiligen Schwächen geschickt ausgleichen. Für müssen daher alle für definierten Verfahren umgesetzt werden, damit funktionieren kann.

12 Extreme Programming - Einleitung Der Name Extreme Programming basiert auf dem Konzept der Maximierung bekannter Software-Entwicklungs-Prinzipien. Also von allem extrem viel mehr... Code-Reviews sind gut? Dann gibt es sie ständig (Pair-Programming) Testen ist gut? Dann wird ständig getestet (sogar vom Kunden). Design ist gut? Dann wird ständig am Design gearbeitet (Refactoring) Einfachheit ist gut? Dann wird die einfachste Lösung gewählt (simple Design) Architektur ist wichtig? Dann definiert und verbessert jeder die Architektur (Metaphern) Integrationstests sind gut? Dann wird jeden Tag integriert und werden System- Integrationstests gemacht (fortlaufende Integration) kurze Iterationszyklen sind gut? Dann sollen sie extrem kurz sein : Sekunden, Minuten, Stunden anstelle von Tagen, Wochen und Monaten (Das Planungsspiel).

13 Konzepte : Übersicht basiert auf 12 Konzepten : 1) Coding Standards - einheitlicher Code erleichtert PairProgramming 2) Simples Design - erleichert Refactoring & Arbeit am Systemcode 3) Umfangreiches Testen - erhöht das Vertrauen in den Programmcode 4) Refactoring - verbessert Design, korrigiert Architekturfehler 5) Kontinuierliche Integration - erhöht Vertrauen in das System 6) kleine Releases - erhöht Vertrauen des Kunden 7) 40-Stunden Woche - reduziert Fehler duch Überarbeitung 8) immer verfügbarer Kunde - erlaubt regelmäßige Spezifikationsverbesserung schreibt StoryCards 9) Planspiel - Projekt-Planung 10)Metaphern - vereinfachte Architekturbeschreibung 11) Pair Programming - reduziert Fehler, erhöht Systemkenntnisse 12) Collective Ownership -flache Bürokratie, alle fühlen Verantwortung

14 Spieler : Kunde und Entwickler Konzepte : Planungsspiel 3 Spielphasen : Erforschen Verpflichtung Steuerung Erforschen Storycard schreiben (Kunde) Storycard Aufwand einschätzen (Entwickler) Storycard bei zu hohem Aufwand aufteilen (Kunde) Verpflichtung Nach Wert sortieren (Kunde) Nach Risiko sortieren (Entwickler) Geschwindigkeit festlegen (Entwickler) Umfang festlegen (Kunde)

15 Konzepte : Planungsspiel Steuerung Iterationsumfang festlegen (Kunde) Plankorrektur bei Verzögerungen (Entwickler verhandeln mit Kunde) Neues Leistungsmerkmal einbringen (Kunde schreibt neue Storycard) Neueunschätzung (Entwickler schätzen mit mehr Erfahurng den Aufwand) Iteration : Aufgabenverteilung Projektmanagement bittet um Verantwortungsübernahme. Alle Entwickler übernehmen für bestimmte Storycards Verantwortung. Keine Zuweisung durch das PM! Iteration : neues Planungsspiel (diesmal mit Taskcards)

16 Konzepte : Planungsspiel Erforschungsphase - Aufgabe beschreiben (Storycard => Taskcards) - Aufgabe einteilen/kombinieren Tasks nach Aufwand überarbeiten Verpflichtungsphase - Aufgabe übernehmen (Programmierer nimmt TaskCard) - Aufgabe einschätzen (Programmierer schätzt Aufwand) - Belastungsfaktor und Belastungsausgleich festlegen Steuerungsphase - Aufgabe implementieren - Arbeitsfortschritt protokollieren - Plankorrektur (Bitte um Unterstützung, Aufteilung in mehr Tasks) - Leistungsmerkmal verifizieren (testen)

17 Konzepte : Pair Programming 2 Entwickler sitzen an einem Rechner. Unterschiedliche Aufgaben : Entwickler 1 (mit Tastatur und Maus) programmiert lokal eine konkrete Problemlösung (Klasse, Methode etc.). Konzentriert sich auf Schleifen, IF- THEN-ELSE, Typisierung etc. Entwickler 2 denkt über die übergeordnete Struktur nach (Refactoring- Ansätze, Zusammenhang mit dem gesamten System) und eignet sich bei Bedarf benötigtes Wissen an (liest API oder Doku). Konzentriert sich auf Klassen, Parameterlisten, Logik, Testfälle. Beide denken sich Testfälle aus. Zur Implementierung der Testfälle oder nach einem frei gewählten Zeitraum kann der Platz getauscht werden. Ein Pair besteht jeweils nur für eine kurze Zeit und nicht permanent.

18 Rollen Programmierer - schreiben das Programm und Tests so einfach wie möglich, kommunizieren mit ihren Kollegen Kunde - schreibt die Story-Cards und funktionale Tests Führt funktionale Tests regelmäßig aus. Tester - Helfen beim Schreiben funktionaler Tests Termin-Manager - Beobachtet das Projekt und das Einhalten des Zeitplans. Macht Aufwandsabschätzungen Coach - Ist der -Experte. Steht dem Team beratend zur Seite. Wacht über die Anwendung von. Berater - Ist ein Domain Experte. Berät das Team bei bei zu seiner Domain. Big Boss - Trifft Entscheidungen. Kommuniziert viel mit allen Beteiligten um die Situation abzuschätzen

19 Extreme Programming : Lifecycle

20 Extreme Programming : Exploration Exploration Phase : - Kunde schreibt Story-Cards. - Entwickler machen sich inzwischen mit dem System/den Technologien/den Tools vertraut und testet die Technologien und Tools. Eine experimentelle Architektur wird erstellt und mit einem Prototyp nach diesem Schema getestet. - Dauer : einige Wochen einige Monate (je nach Komplexität)

21 Extreme Programming : Planning Planning Phase : - Die Priorität für die Implentierung der Stories wird festgelegt und ihr Aufwand abgeschätzt. - Die nächste geplante Iterationsphase soll maximal 2 Monate dauern. - Die Planungsphase benötigt einige Tage

22 Extreme Programming : Release Iterations Release Iterations : - das Scheduling der Planungsphase wird in Iterationen unterteilt. Die erste Iterationen sollen dabei systematisch die Systemarchitektur aufbauen. Dafür werden geeignete Stories ausgewählt und umgesetzt. - Der Kunde bestimmt, welche Stories in jeder Iteration tatsächlich umgesetzt werden sollen. Anschließend führt er Funktionstests durch. - eine Iteration dauert 1 4 Wochen.

23 Extreme Programming : Produktion Produktions Phase : - die Iteration wird zum System hinzugefügt. - Ein Integrationstest wird gemacht. - Der Kunde beurteilt das System und gibt Feedback

24 Extreme Programming : Maintanance & Death Maintanance & Death : - Jede neue Iteration aktualisiert das vorhandene System. Da sich das gesamte System dadurch ändern kann, muß es gegebenenfalls angepasst werden, damit es weiterhin stabil läuft (Anpassung der Datensätze etc.) - Das Projekt ist beendet, wenn alle Stories abgearbeitet sind und dem Kunden keine neuen Stories mehr einfallen. Alle Randbedingungen müssen erfüllt sein. - Die Dokumentation für das finale System wird geschrieben.

25 Vorteile Der Kunde ist sehr stark mit einbezogen. Es wird mit ihm in für ihn verständlichen Metaphern und Vorgängen (Stories) kommuniziert. Der Kunde testet kontinuierlich das System. Er kann sofort Änderungswünsche äußern. Eine aufwändige Architektur-Planung entfällt. Zeigt die Architektur Mängel, findet ein Refactoring statt. Es wird gleich Programmcode produziert. Der Overhead für eine umfassende Diagramm-Pflege entfällt. Der Programmcode ist zugleich die Dokumentation.

26 Feature Driven Development

27 Feature Driven Development - Übersicht Einleitung Rollen Konzepte Feature Feature Hierarchie Feature Teams Design & Code Reviews 5 Entwicklungs-Phasen 1. Modell-Entwicklung 2. Feature Liste erstellen 3. Plan by Feature 4. Design by Feature 5. Build by Feature Vorteile Beispiel-Diagramme zur Projekt-Fortschrittsmessung

28 Feature Driven Development () Entwickelt von Stephen Palmer und Peter Coad, 1999 verfolgt ein auf Features aufbauendes Entwicklungskonzept. beinhaltet Rollen, Artefakte und Prozesse. stützt sich auf UML und objektorientierte Entwicklung soll sich auch für kritische Systeme eignen Entwicklung ist iterativ und produziert viele lauffähige Zwischenversionen gute Überwachung des Projekt-Verlaufs möglich

29 Feature Driven Development Develop an Overall Model Build a Features List Plan by Feature Design by Feature Build by Feature besteht aus 5 Phasen Die ersten drei Phasen stellen die initialen Einarbeitungsschritte für das System dar, die notwendig sind, um mit der eigentlichen Arbeit zu beginnen. Ihr Zeitaufwand sollte bei ca. 23% der Entwicklungszeit liegen. die letzten zwei Phasen (Design by Feature und Build by Feature) werden für jedes Feature wiederholt. Die kombinierte Zeitdauer dieser beiden Phasen soll zwei Wochen nicht überschreiten.

30 Rollen Projekt Manager : Verantwortlich für den zeitlichen Ablauf Chief Architect : Verantwortlich für die System-Architektur Chief Programmers : Verantwortlich für einzelne Features Domain Experts : Spezialisten für das Anwendungsgebiet, die Spezifikation und Constraints (z.b. Sicherheit). Class Owner : Jeder Entwickler trägt für einen Satz von Klassen allein die Verantwortung. Sonstige : Tester Doku-Schreiber Language/Tech. Spezialist System-Admin Toolsmith

31 Konzepte : Feature Format : <action> <result> <object> in Begriffen, die der Kunde kennt! Beispiel : display courses of student Jedes Feature soll maximal 2 Wochen Entwicklungszeit benötigen. Wenn mehr Zeit benötigt wird, muß das Feature in Mehrere geteilt werden. Die meisten Features benötigen wesentlich weniger als 2 Wochen Zeit. Modellierung der Features erfolgt über dem Niveau von getter- und setter- Routinen

32 Konzepte : Feature Feature-Sets : Ein Feature-Set umfasst alle Features, die für die Implementierung eines Business-Tasks notwendig sind. Erst während des iterativen Entwicklungsprozesses eines Features, wird es in einzelne, technische Arbeitsschritte zergliedert. Dazu werden alle an dem Feature beteiligten Klassen festgestellt. Dann werden alle Personen, welchen diese Klassen gehören dem Feature Team zugewiesen. Die Änderungen an den Klassen werden geplant. Jeder implementiert die Änderungen an seiner Klasse. Die Klassen werden getestet. Das Feature wird getestet. Sind alle Fehler behoben, wird es zum System hinzugefügt.

33 Konzepte : Feature Hierarchie System / \ Aufgabenfeld Aufgabenfeld(Domain) / \ Business Activity Business Activity Feature Sets Feature Sets / \ / Feature Feature Feature

34 Konzepte : Feature Teams Jedem Feature ist ein Chef-Programmierer zugeordnet Teams werden für jedes Feature vom Chef-Programmierer neu zusammengestellt Ein Team enthält alle ClassOwner, die der Chef-Programmierer für nötig hält Jeder ClassOwner kann gleichzeitig in mehreren FeatureTeams sein. Er besitzt eine eigene ToDo-Liste für jede seiner Klassen, die von den ChefProgrammierern und beim gemeinsamen FeatureDesign gefüllt wird. Der Chef-Programmierer überwacht die Feature-Entwicklung und stößt Der Chef-Programmierer überwacht die Feature-Entwicklung und stößt klassenübergreifende Tests und den Integrationstest an.

35 Konzepte : Design & Code-Reviews Bei einem Design-Review betracht das ganze Feature-Team gemeinsam das zuletzt entwickelte Design für ein Feature und prüft es auf Vollständigkeit, Fehlerfreiheit und Nützlichkeit. Bei einem Code-Review betrachtet das ganze Feature-Team gemeinsam den zuletzt geschriebenen Programmcode von jedem Feature-Team-Mitglied Ziel ist es, mögliche Fehler zu finden, die Testfälle zu verfeinern oder Verbesserungsvorschläge machen zu können. Je mehr Augen den Code betrachten, umso wahrscheinlicher ist es, daß ein Problem erkannt wird. Ein gemeinsamer Code-Standard wird dadurch indirekt erzwungen (damit jeder den Code der anderen möglichst einfach lesen kann).

36 Phase 1 : Modell-Entwicklung Voraussetzung : Domain Experten, Chef-Programmierer und Chef-Architekt wurden ausgewählt. Requirements sind ermittelt 1) Die Modelling Teams werden benannt 2) Die Domain-Experten erklären das Anwendungsumfeld und den Kundenauftrag, das Projektziel. 3) Es wird sich in ein bestehendes System oder eine Technologie eingearbeitet 4) Jeweils 3 Leute (ein Modelling Team) modellieren einen Teilbereich (Klassen-Diagramme) 5) Zusammen mit dem Chef-Architekten werden alle Modelle vereint und bei Bedarf überarbeitet. 6) Die Modell-Entwicklungsphase wird dokumentiert. Alternative Architekturideen werden festgehalten. 7) Die Modell-Entwicklungsphase wird gemeinsam mit dem Kunden analysiert. Bei Bedarf wird iteriert.

37 Phase 1 : Modell-Entwicklung Artefakte der Modell-Entwicklungs-Phase : - Klassen-Diagramm, das folgende beantwortet: - Welche Klassen sind in der Domain? - Wie sind sie miteinander verbunden? - Welche Randbedingungen gibt es? (Dies Klassen-Diagramm modelliert die Domain, und nicht unbedingt die Anwendungs-Architektur) - Methoden und Attribute werden identifiziert und aufgeschrieben. - Sequenz-Diagramme werden bei Bedarf erstellt. - Modell-Notizen und Hinweise - Diese Phase sollte ~14% Der Entwicklungszeit benötigen

38 Phase 2 : Feature Liste erstellen Es wird eine Team zusammengestellt, welches die gewünschten und die notwendigen Features ermitteln soll. Das Team erstellt eine Liste mit allen ermittelten Features aus den Artefakten von Phase 1 soll ~5% der Projektzeit benötigen Artefakte : Eine Liste mit Business Activities wird für jede Domain erstellt. für jede Business Activity wird eine Feature Liste erstellt Jede Featureliste enthält eine Sammlung von Features

39 Phase 3 : Plan by Feature Die Features aus Phase 2 werden auf ihre Zusammenhänge analysiert. ihre Komplexität wird eingeschätzt. Es wird festgelegt, welche Klassen für welches Feature benötigt werden. Die Klassen werden in Abhängigkeit von ihrer Komplexität auf die Entwickler verteilt. Die Class Ownership wird damit festgelegt. Durch die Bestimmung der Klassen eines Features ist so auch das Feature Team bestimmt. Ein Chief Programmer für jede Business Activity und damit auch für jedes zugehörige Feature wird bestimmt. ein grobes Release-Datum für jedes Feature wird festgelegt. Artefakt : Klassendiagramm mit ClassOwnerships. Release Dates für Domains.

40 Phase 4 & 5 : Überblick Phasen 4 und 5 werden jeweils mit einem Feature aus der Feature-Liste durchlaufen. Pro Feature existieren 6 eindeutig definierte Meilensteine mit approximierter Zeitvorgabe Domain Walkthrough Design Design Inspection Code Code Inspection Promote to Build 1% 40% 3% 45% 10% 1%

41 Phase 4 : Design by Feature (iterativ) Feature Teams werden zusammengestellt Eine Übersicht über das Feature wird vom Domain Experten gegeben Vorhandene Doku wird gelesen (optional) Sequenzdiagramme werden entwickelt. Ein Objektmodell wird erstellt Klassen- und Methoden-Rümpfe werden erstellt. Das Design wird gemeinsam diskutiert und auf Fehler geprüft

42 Phase 5 : Build by Feature (iterativ) Die Methoden-Rümpfe und Klassen werden implementiert Testfälle werden geschrieben. Jede Methode wird getestet. Der Programmcode von jedem Programmierer wird gemeinsam untersucht und besprochen Das Feature wird getestet. Wenn es funktioniert, wird es in das System integriert. Ein System-Integrationstest wird gemacht.

43 Vorteile I große Zeitnähe zwischen Design und Implementierung. Das Team arbeitet gemeinsam am Design Aufgrund der ClassOwnerships weiß Jeder, was er zu jedem Zeitpunkt zu tun hat, und wofür er zuständig ist. Geht ein Mitarbeiter verloren, so braucht ein Ersatz sich nur in die ihm zugeteilten Klassen einarbeiten und wird dadurch schnell zu einem produktiven Teammitglied. Ein neues Teammitglied ist automatisch in alle Teams eingebunden, die mit seinen Klassen zu tun haben und bekommt so schnell eine Übersicht über die globalen Zusammenhänge seiner Klassen innerhalb des Systems.

44 Vorteile II ClassOwner können über mehrere Projekte und Produktlinien hinweg eingesetzt werden. Mehrere Projekte, die auf gemeinsamen Klassen basieren, können gleichzeitig entwickelt werden. Der Projekt-Fortschritt kann gut anhand der implementierten Features gemessen werden. Jedes Feature ist getestet und funktioniert! Der Kunde sieht sofort einen Fortschritt, weil für ihn wichtige Features schnell vorzeigbar und demonstrierbar sind. Der Kunde kann anhand der vorhandenen Features schnell Verbesserungsvorschläge unterbreiten. Die Vorstellung des Kunden vom Gesamtsystem wird zunehmend präziser, so daß es ihm leichter fällt, festzustellen, was er eigentlich will und was nicht.

45 Beispiel : Fortschrittsanzeige für Feature Set

46 Major feature set Beispiel : Fortschritt von Subject Areas Feature set Selling Products (22) CP-1 Shipping Products (19) CP-1 Product Sale Management (PS) Delivering Products (10) CP-3 Invoicing Sales (33) CP-1 CP-2 Setting up Product Agreements (13) CP-1 Making Product Assessments (14) 99% 10% 30% 3% 75% Nov 2001 Dec 2001 Dec 2001 Dec 2001 Dec 2001 Dec 2001 Evaluating Account Applications (23) Customer A/C Mgmt (CA) CP-2 CP-2 CP-2 CP-3 Opening New Accounts (11) Logging Account Transactions (30) Establishing Storage Units (26) Inventory Mgmt (IM) CP-3 Accepting Movement Requests (18) Moving Content (19) CP-3 95% 100% 82% 100% 97% 82% Oct 2001 Oct 2001 Nov 2001 Nov 2001 Nov 2001 Nov 2001 KEY: Work In Progress Attention Completed Progress Bar Not Started

47 Beispiel : Projekt Übersicht KEY: Work In Progress Attention Completed Not Started

48 zwischen und

49 zwischen und Extreme Programming Feature Driven Development Quellcode-zentriert Feature-zentriert collective Code-Ownership individuelle Class Ownership Pair Programming 3er Teams und Code-Reviews Gemeinsame Planung Chief-Architect, Chief-Programmer sehr viel Refactoring wenig Refactoring Fortschritt schwer meßbar Fortschritt gut meßbar Kollektives Wissen Experten-Wissen

50 zwischen und Extreme Programming Feature Driven Development skaliert schlecht mit Team- Größe, da jeder mit jedem kommunizieren muß skaliert sehr gut, da Feature-Teams immer klein bleiben und Modellierungsteams immer auf 3 Personen beschränkt sind. benötigt geringe Modellierungs benötigt gute Modellierungskenntnisse. kenntnisse (UML). sehr informell vorgegebene Artefakte. Diagramme

51

52 Wo stehen wir bisher? Näher an, oder Wasserfall? Team-Struktur Ticket-System Dokumentations-System Projekt-Struktur Wie wollen wir entwickeln? Was wollen wir lernen? Ist eines der Verfahren besser für uns geeignet? Warum? Sind agile Methoden eine gute Alternative zur klassischen Wasserfall- Entwicklung?