Agile Geschäftsprozeßanalyse (GPA), objektorientierte Analyse & Design (OOA/D) am Beispiel einer Seminarverwaltung

Transkript

1 Vortrag am Dienstag, 10. März 2009 Thema Agile Geschäftsprozeßanalyse (GPA), objektorientierte Analyse & Design (OOA/D) am Beispiel einer Seminarverwaltung Referent Dr. Frank Dopatka, GFU Cyrus AG Inhalt Das der GFU ( Ist-Zustand bis 2008 ) GPA/OOA: Story Cards, Use Cases, Aktivitäten, Objekte & Klassen, CRC-Karten, Risk/Value-Priorisierung, Planning Poker : Klassen-, Zustands- & Sequenz-Diagramme : Test Driven Development, Feature Driven Development, Scrum, Pair-Programming, Continous Integration der ideale Ziel ist eine Übersicht über alle Notationen/Verfahren & deren Verzahnung zu erkennen!

2 Das Was existierte bislang? Die GFU Cyrus AG verwendete von 1988 bis Ende 2008 ein in Cobol selbst geschriebenes Programm zur Verwaltung der Kunden, deren Ansprechpartner und zur Dokumentation der Kommunikation von GFU-Mitarbeitern mit den Kunden (Vorgänge). Auch zur Fakturierung verwendet. Über eine Kalenderfunktion wurden die Seminare, Anmeldungen von Teilnehmern, Hotel- & Parkplatzbelegung verwaltet. Folie 4

3 Was existierte bislang? Angebote: in den letzten Jahren in MS Word 97 erstellt Zusätzlich: 8 Jahre altes Programm zur Seminarverwaltung, das in VB6 geschrieben wurde Abgleich mit den Internet-Daten FrankDopatka@web.de Folie 5 So sah die Kundenverwaltung & Fakturierung aus... FrankDopatka@web.de Folie 6

4 So sah die Seminarverwaltung aus... Folie 7 Was soll verbessert werden? Das Cobol-Programm berechnet ab 2009 die Kalenderwochen falsch, eine Anpassung ist schwierig im Quellcode durchzuführen. Die Fakturierung soll automatisiert werden. Da keine relat. DB-Struktur verwendet wurde, waren Statistiken über Kurserfolge schwierig, z.b. Gewinn aus Schulungen der Kategorie Java ermitteln. Es sind im Cobol-Programm alte Funktionen vorhanden, die nicht mehr verwendet werden, u.a. - Verwaltung von Lizenznummern und - Verwaltung von Update-Abos...aus Zeiten, in denen bei der GFU noch Cobol-Compiler verkauft wurden. FrankDopatka@web.de Folie 8

5 Was wird im Vortrag behandelt? Im Folgenden wird exemplarisch gezeigt, wie man mit einer Geschäftsprozeß-Analyse (GPA) einer Objektorientierten Alalyse (OOA) und einem Objektorientierten Design () einen Lösungsansatz für die zu erstellende Software ermitteln kann. Im Fokus steht dabei der Zusammenhang der verschiedenen UML-Diagramme, deren Blickwinkel sowie die Anwendung agiler Methoden bei der Softwareentwicklung. Folie 9 GPA & Story Cards

6 Was macht man in der GPA & OOA? In der Analyse geht es darum, die Anforderungen zu erfassen: Fakten sammeln, darstellen, prüfen Objektorientierte Analysemodell: - fachliche Beschreibung mit OO-Konzepten -hebt das Wesentliche hervor und lässt Unwichtiges weg Bezug zur Informationstechnik ist unerwünscht! OOA-Modell sollte statische & dynamische Aspekte enthalten ( Datenstrukturen & Abläufe) FrankDopatka@web.de Folie 11 Was sind Story Cards? User Story ( Benutzergeschichte ): - eine in Alltagssprache formulierte Software- Anforderung - bewusst kurz gehalten: nicht mehr als zwei Sätze Jede User Story wird auf eine Story Card geschrieben. Autor: Kunde bzw. User Die Story Card ist die wichtigste Methode, um ein agiles Projekt zu steuern! Aus den Story Cards entwickeln sich in kooperativer Zusammenarbeit mit dem Kunden die Use Cases Workshops FrankDopatka@web.de Folie 12

7 Inhalt einer Story Card Datum, fortlaufende Nummer Nummer der übergeordneten Story Card Aktivität: neu / Fehler beheben / Funktion erweitern Funktion umgesetzt Priorität (Kunde/) Risiko & Aufwandschätzung kurze, präzise Beschreibung Notizen aktueller Fortschritt: Datum, Status, Aufgabe, Kommentar FrankDopatka@web.de Folie 13 Exemplarische Story Card: Seminarverwaltung

8 Use Cases Was genau sind Use Cases (Anwendungsfälle)? Interaktion zwischen Akteuren und dem betrachteten System: Dabei soll ein fachliches Ziel erreicht werden! Grafisches UML Use Case: Identifikation der Funktion & der beteiligten Akteure im Vordergrund Informationsgehalt eines graphischen Use Cases ist gering! Use Case Schablone Verlauf textuell beschreiben Bezug zum Geschäftsprozeß Basis kann Story Card sein! Folie 16

9 Perspektiven Use Cases können (wie auch alle anderen UML- Diagramme) in verschiedenen Abstraktions-Ebenen erstellt werden: Wolke Manager-View Drachen Meeres-Spiegel User-View Muschel Fisch Entwickler-View Folie 17 Exemplarischer grafischer Use Case der Seminarverwaltung (Manager-View) Folie 18

10 Etwas detailliertere Darstellung des Use Cases Seminare verwalten Folie 19 Exemplarischer textueller Use Case der Seminarverwaltung Buchen eines Seminars Ziel: Anmeldebestätigung an den Kunden geschickt. Vorbedingung: --- Nachbedingung Erfolg: Kunde ist angemeldet. Nachbedingung Fehlschlag: Mitteilung an Kunden, dass Veranstaltung ausgebucht ist, ausfällt oder nicht existiert. Akteure: Kunde, GFU-MA Auslösendes Ereignis: Anmeldung des Kunden liegt vor. Beschreibung: 1. Kundendaten abrufen 2. Seminar prüfen 3. Anmeldebestätigung erstellen Erweiterung: 1a. Kundendaten aktualisieren 1b. Wenn Kunde MA einer Firma ist, Firmendaten erfassen bzw. wenn vorhanden, dann abrufen und aktualisieren 1c. Zahlungsmoral prüfen Alternativen: 1a. Neukunden erfassen, wenn Kunde noch nicht existiert 1b. Auf alternative Veranstaltungen hinweisen, wenn ausgebucht 1c. Mitteilung Falsche Veranstaltung, falls Veranstaltung nicht existiert und auch nichts ähnliches

11 Aktivitäten, Szenarien & Geschäftsabläufe Wozu Aktivitäts-Diagramme? Geben die Struktur eines Prozesses als Fluss dynamisch wider Heben den Steuerungsfluss von Objekten im Geschäftsprozeß untereinander hervor Werden typischerweise aufgestellt, wenn die Use Cases fertig sind Ziel: grundsätzliche Abläufe darstellen Überschneidung der Ansicht zu einem textuellen Use Case ist groß Alternativ dazu anwenden?! Folie 22

12 Was ist ein Szenario? Eine spezifische Sequenz von Aktionen, die das Verhalten des Systems unter bestimmten Bedingungen beschreibt, z.b.: Login Bestellvorgang Rechnungsstellung Auszahlung von Geld Angebotserstellung Im Allgemeinen: Einen Geschäftsprozess des Unternehmens! Bei der Entwicklung werden alle wichtigen Szenarien in Aktivitäts-Diagrammen fest gehalten. Folie 23 Aktivitäts-Diagramm der Seminarverwaltung: erfolgreiche Anmeldung Kunde 1 Suchbegriff Java Einsteiger in die GFU-Seite eingegeben Seminar auswählen Seminarverwaltung Liste der Seminare zurückgeben pers. Daten eingeben Buchung abschicken :Seminar [status: buchend] [AnzTN=MaxTN-1] Daten prüfen und ggf. abgleichen :Seminar [status: ausgebucht] [AnzTN=MaxTN] FrankDopatka@web.de Bestätigung der Buchung senden Folie 24

13 Aktivitäts-Diagramm der Seminarverwaltung: fehlerhafte Anmeldung Folie 25 Objekte & Klassen in der Analyse

14 Warum noch Objekt-Diagramme? Objekt-Diagramme besitzen die gleiche Notation wie Klassen-Diagramme, stellen aber konkrete Beispiele/Instanzen dar: - derfrank: Dopatka, Frank, Schmiedeweg,... Kunde: Name, Vorname, Strasse,... In der Praxis als erster Schritt der Analyse leicht verständlich, da anwendungsnah Klassen: Abstraktionen der Objekte auf höherem Niveau! FrankDopatka@web.de Folie 27 Warum Klassen-Diagramme in der Analyse? Klassen-Diagramme existieren vereinfacht in einer Analyse-Form: Identifikation der Klassen und deren Beziehung zueinander im Vordergrund! Klassen und deren Beziehungen orientieren sich am Geschäftsprozeß nicht plötzlich falsch Beziehungen: textuell beschrieben FrankDopatka@web.de Folie 28

15 Exemplarisches Objekt-Diagramm: ein Seminar Folie 29 Exemplarisches Objekt-Diagramm: Bezug eines Seminars zu anderen Objekten Folie 30

16 Ausschnitt aus einem Klassen-Diagramm (OOA) der Seminarverwaltung Folie 31 CRC-Karten

17 Wie kommt man an die Objekte & Klassen? Durch Erfahrung! Indem Sie in Gesprächen und Beschreibungen achten auf: - nicht-triviale Hauptwörter (Raum, Kunde,...) Klassen - triviale Hauptwörter, die durch einzelne Zeichenketten, Zahlen oder wahr/falsch darstellbar sind (Name, Mail-Adresse,...) Attribute - Verben (anlegen, buchen, suchen, stornieren,...) Methoden - Ausdrücke wie ist ein bzw. besteht aus Vererbung bzw. Aggregation oder Komposition FrankDopatka@web.de Folie 33 Was ist eine CRC-Karte? Prinzip einer Class-Responsibility-Collaboration- Karte: für jede Klasse eine Karteikarte erstellen & auf dieser deren Eigenschaften zu notieren Eine solche Karte besteht aus folgenden Bereichen: - Name der Klasse - Aufgaben der Klasse, mit denen die beschriebene Klasse zusammenarbeitet - Rückseite: wichtigste Attribute und Methoden FrankDopatka@web.de Folie 34

18 Vorteile der CRC-Karten Einfache Handhabung: Problemlos Informationen hinzufügen oder streichen Unabhängig von Programmiersprachen & Tools begrenzte Platz auf die wesentlichen Aufgaben einer Klasse konzentrieren Folie 35 Vorgehensweise Mit dem Kunden typische Anwendungsfälle definieren Use Cases Anwendungsfälle nacheinander durchspielen Aktivitäten Auf den CRC-Karten neue Aufgaben und Partnerklassen festhalten Mit der Zeit ergibt sich ein vollständiges Bild. Wichtig: - Untersuchung aller typischen Anwendungsfälle & Szenarien - Festhalten aller Details FrankDopatka@web.de Folie 36

19 Beispielhafte CRC-Karte Seminar Klasse Seminar Seminar Aufgaben: Erstellen und verwalten von Seminaren und deren Inhalten. Man soll Seminare suchen können und im Internet veröffentlichen. Man kann sich anmelden, solange die max. TN-Tahl nicht erreicht ist. Abmelden geht auch jederzeit. Die GFU kann notfalls ein Seminar auch stornieren, wenn keine Anmeldung vorliegt oder der geplante Dozent krank ist und kein Ersatz gefunden werden konnte. Partnerklassen: Seminarverwaltung, Rechnung, Termin -> (Raum, Dozent, Anmeldungen -> (Teilnehmer)) Risk-Value Priorisierung & Planning Poker

20 Was wird wie priorisiert & welche Konsequenzen ergeben sich? Bereits bei den Story Cards wurden die Begriffe Priorität, Risiko und Aufwandschätzung für jede Funktionalität (Use Case) erwähnt. Jetzt wissen alle Beteiligten bereits mehr über die Funktionen & Abläufe. So langsam können Sie folgende Fragen beantworten... Folie 39 Was wird wie priorisiert & welche Konsequenzen ergeben sich? Wie wichtig ist unserem Kunden diese Funktionalität? Punkte K Wie wichtig sehen die die Integration der Funktionalität im Kontext der Anwendung?* Punkte P Wie sehen die die Schwierigkeit der technischen Umsetzung (Risiko) der Funktion?* Punkte S Wie (zeit-)aufwendig sehen die die Umsetzung?* Schätzverfahren COCOMO, Lines Of Code, Function Points Preis dieser Funktion * basierend auf ihrer Projekterfahrung FrankDopatka@web.de Folie 40

21 Womit fängt man jetzt an? K+P: 0-6 S: 0-3 K+P: S: 6-10 K+P: S: 0-3 Man beginnt mit dem höchsten Risiko und dem höchsten Wert! Folie 41 Exemplarische Priorisierung aus der Seminarverwaltung Planning Poker: Zusammen mit dem Kunden die nächsten Schritte planen! Wie detailliert? vgl. eine Scrum-Aufgabe <16 Mannstunden Folie 42

22 Klassen im Design Von den Klassen zum Code In der Design-Form beinhalten Klassen-Diagramme alle notwendigen Methoden und Attribute. mit Modellierungs-Werkzeuge Java- oder C#-Coderümpfe generieren Nur noch mit Funktionalität füllen Auch Beziehungen zwischen Klassen wie ein Kunde hat n Rechnungen können automatisch in Java-Collections abgebildet werden; u.a. mit ObjectIf von MicroTool FrankDopatka@web.de Folie 44

23 Von den Klassen zum Code Folie 45 Beispiel: Together Edition for SAP NetWeaver Developer Studio

24 Einige Klassen im Design aus der Seminarverwaltung Seminarverwaltung - Seminare: ArrayList - instance: Seminarverwaltung + getinstance(): Seminarverwaltung + suche (String Inhalt): Seminar + suche (Long ID): Seminar... * Seminar - ID: Long - Zustand: Enum {existiert, buchend, ausgebucht, durchgeführt, storniert, gelöscht} - Kurzbeschreibung: String - Inhalt: String - SeminarZiel: String - Ort: String - Dauer: Byte - minanztn: Byte - maxanztn: Byte -Preis: Decimal + Daten anzeigen (): String + Daten aktualisieren (Date von,...): String + anmelden (Termin T, Teilnehmer TN) + abmelden (Termin T, Teilnehmer TN) + stornieren (Termin T) + entfallen (Termin T) FrankDopatka@web.de + Termin hinzufügen(date von, Date bis) Folie Seminar-Termin -von: Date - bis: Date + DozentZuweisen (Dozent d) + RaumZuweisen (Raum r)... * 0: individuelles In-House Seminar Zustands-Diagramme

25 Wieso noch Zustandsdiagramme? Sicht auf alle möglichen Zustände eines Objektes bezieht sich auf genau eine Klasse Zustandsübergänge treten i.d.r. dadurch auf, dass das betreffende Objekt angetriggert wird Methodenaufruf Prinzipiell kann jede Methode eines Objektes jederzeit aufgerufen werden: Methodenaufruf Y im Zustand X erlaubt??? Zustandsdiagramm wenn nicht erlaubt Exception FrankDopatka@web.de Folie 49 Sichere Automaten! Vollständige Zustandsautomaten... Robustheit der Software: im Alltag werden oft einzelne Methodenaufrufe in bestimmten Zuständen vergessen Ein Objekt ist gegen seinen Zustandsautomaten testbar FrankDopatka@web.de Folie 50

26 Zustands-Diagramm aus der Seminarverwaltung Ein Objekt der Klasse Seminar : FrankDopatka@web.de Folie 51 Sequenz-Diagramme

27 Aktivitäten vs. Sequenzen Aktivitäts-Diagrammen: Abläufe aus Sicht des Geschäftsprozesses mit deren Zuständigkeiten modelliert Fachliches Modell Nun wurden bereits Klassen, deren Methoden und Beziehung ermittelt... Sequenz-Diagramm: Darstellung des technisch modellierten Ablaufs darstellen Technisches Modell Ablauf von Nachrichten von Objekten untereinander durch gegenseitige Methoden- Aufrufe Auslöser: Akteur, der einen Use-Case initiiert Sequenz-Diagramm aus der Seminarverwaltung: Buchung vornehmen

28 Test Driven Development & Feature Driven Development Was ist Testgetriebene Entwicklung? Ziel: Software-Tests vor den zu testenden Komponenten erstellen! Erstellte Unit-Tests sind Grey-Box-Tests statt klassischer White-Box-Tests Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. eigentliche Programmierung in kleinen & wiederholten Schritten eine Iteration (Dauer: wenige Minuten) hat drei Hauptteile: Folie 56

29 Was ist Testgetriebene Entwicklung? 1. Schreiben Sie einen Test für das erwünschte fehlerfreie Verhalten, das implementiert werden soll. Dieser Test wird erst einmal nicht erfüllt bzw. es gibt den Code gibt es noch gar nicht. 2. Änderen/schreiben Sie den Code mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden. 3. Räumen Sie im Code auf (Refactoring): - Wiederholungen entfernen - Code abstrahieren - Code nach Konventionen ausrichten testen! FrankDopatka@web.de Folie 57 Test-Entwurf aus der Seminarverwaltung Test: Seminar anlegen Vorbedingung: --- prüfbare Nachbedingung Erfolg: Seminar wurde mit seinen Daten in der Seminarverwaltung aufgenommen und eine neue Seminar-ID wurde vergeben. Nachbedingung erwarteter Fehlschlag: Seminar mit diesem Titel existiert bereits. Test: Seminar buchen Vorbedingung: Seminar existriert bereits und ist zum gewählten Termin nicht ausgebucht prüfbare Nachbedingung Erfolg: Kunde wurde als TN in die Liste der TN zum gewählten Termin aufgenommen Nachbedingung erwarteter Fehlschlag: Meldung Nicht möglich: Kunde hat noch >3 offene Rechnungen! FrankDopatka@web.de Folie 58

30 Was ist Feature-getriebene Entwicklung? FDD wird eingesetzt, um ein (großes) zeitkritisches Projekt (z.b. 15 Monate, 50 Entwickler) durchzuführen. Jedes Feature stellt einen Mehrwert für den Kunden dar. Die Entwicklung wird anhand eines Feature-Plans organisiert. Eine wichtige Rolle spielt der Chef-Architekt, der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält. Folie 59 Prozesse der Feature-getriebenen Entwicklung 1. Entwicklen Sie ein Gesamtmodell: - Konsens über Inhalt und Umfang des zu entwickelnden Systems - fachliche Kernmodell grobe Use Cases 2. Erstellen Sie eine Feature-Liste: - nach dem einfachen Schema <Aktion> <Ergebnis> <Objekt> - Bsp.: Berechne Gesamtsumme der Verkäufe - max. zwei Wochen zur Realisierung Risk/Value & Planning Poker FrankDopatka@web.de Folie 60

31 Prozesse der Feature-getriebenen Entwicklung 3. Planen Sie jedes Feature - Reihenfolge der Realisierung festlegen - Fertigstellungstermine je Geschäftsaktivität - Projektleiter, Entwicklungsleiter sowie Senior- beteiligt 4. Entwurf jedes Features - Entwicklerteams zuweisen - Erstellung von Sequenz-Diagrammen - erste Klassen- und Methodenrümpfe 5. Ausprogrammierung der Features & TDD FrankDopatka@web.de Folie 61 Scrum

32 Was ist Scrum? Das Gedränge : agiles Vorgehensmodell Meetings, Artefakten, Rollen & Werten folgt dem Prinzip der Schlanken Produktion (lean production) Teammitglieder organisieren ihre Arbeit weitgehend selbst & wählen auch die eingesetzten Entwicklungswerkzeuge und -Methoden Entwicklung ist sehr komplex im Voraus weder in große abgeschlossene Phasen noch in einzelne Arbeitsschritte (Granularität von Mannstunden) planbar Selbst-Organisation! FrankDopatka@web.de Folie 63 Grundlegende Begriffe des Scrum Zentrales Element ist der Sprint: Umsetzung einer Iteration (ca. 30 Tage) Vor dem Sprint: Produkt-Anforderungen des Kunden in einem Product Backlog sammeln beinhaltet alle Funktionalitäten, die der Kunde wünscht Priorisierung der Funktionen Hoch priorisierte Features: von den Entwicklern im Aufwand geschätzt ins Sprint Backlog übernehmen: - enthält alle Aufgaben, um das Ziel des Sprints zu erfüllen - eine Aufgabe: < 16 Stunden - längere Aufgaben: in Teilaufgaben zerlegen

33 Meetings, Review & Retrospektive Täglich: Daily Scrum Meeting (max. 15min.) Team stellt sich gegenseitig folgende Fragen: Bist du gestern mit dem fertig geworden, was du dir vorgenommen hast? Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten? Gibt es ein Problem, das dich blockiert? Meetings, Review & Retrospektive Nach einem Sprint: Ergebnis einem informellen Review unterziehen: Team & Kunden Ergebnis des Sprints (laufende Software) vorführen Kunde prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht: Änderungswünsche Product Backlog Folie 66

34 Meetings, Review & Retrospektive Retrospektive: zurückliegende Sprint-Phase betrachten; zunächst wertfreien Rückblick auf die Ereignisse Teilnehmer notieren die wichtigen Ereignisse auf Zetteln. Anschließend schreiben die Teilnehmer Antworten auf die Fragen - Was war gut? (Best practice) - Was könnte verbessert werden? (Verbesserungspotential) Jedes Verbesserungspotential wird priorisiert und mit Zuständigkeiten versehen. FrankDopatka@web.de Folie 67 Pair Programming

35 Wie funktioniert Pair Programming? jeweils zwei an einem Rechner einer schreibt den Code, der andere: - nachdenken über die Problemstellungen -Code kontrollieren Probleme sofort ansprechen sofort lösen Rollen abwechseln & Zusammensetzung der Paare häufig ändern Ziel: Erhöhung der Software-Qualität FrankDopatka@web.de Folie 69 Vorteile des Pair Programming Höhere Disziplin: Paare entwickeln eher an der richtigen Stelle & machen kürzere Pausen Besserer Code: Man entwickelt man sich weniger leicht in Sackgassen. Höhere Moral: spannender & interessanter als alleine Collective Code Ownership: alle erlangen Wissen über die gesamte Codebasis, die gemeinsam erstellt wurde FrankDopatka@web.de Folie 70

36 Vorteile des Pair Programming Mentoring: Jeder hat Wissen, das andere nicht haben. einfache Wissensverbreitung Team-Bildung: Leute lernen sich gegenseitig schneller kennen Zusammenarbeit verbessert Weniger Unterbrechungen: Paare werden seltener unterbrochen. Folie 71 Continous Integration

37 Motivation Unit-und Modul-Tests... mit Werkzeugen wie JUnit mitlerweile automatisiert erstellbar! Wie können höhere Tests - z.b. Integrationstest, gehandhabt werden???? Motivation Gerade wenn bei der Integration der Komponenten Design-Fehler entdeckt werden, ist dies entsprechend teuer! FrankDopatka@web.de Folie 74

38 Die Idee der Continous Integration Kontinuierliche Integration: regelmäßiges, vollständiges Neubilden & Testen einer Anwendung Änderungen in die Versionsverwaltung einchecken Gesamtsystem neu bauen & automatisch testen alle Tests erfolgreich: Änderungen an die nächste Stufe geben Tests scheitern: Änderungen zurücknehmen (Rollback) zur Korrektur vorlegen Folie 75 Werkzeuge zur Continous Integration Voraussetzung: - Versionsverwaltungssystem - zeitnahes Check-In - nur funktional vollständige Blöcke eingecheckt Das Java-basierte CruiseControl hilft bei der Umsetzung der CI: - Benachrichtigung per , - Nutzung von Apache Ant & anderen Werkzeugen - Web-Oberfläche: aktuellen und vorherigen Zustand der Software anzeigen FrankDopatka@web.de Folie 76

39 Der ideale Kunde & Mit welchen Kunden funktionieren agile Methoden (nicht)? experimentierfreudig selbst erhebliche Ressourcen aufwenden Worin besteht das Gewek?... das durch den vereinbarten Preis erworben wird Kunde verzichtet auf formale Spezifikation und bindendes Angebot Es darf nicht die Mentalität das machen wir mal eben nebenbei vorherrschen Folie 78

40 Mit welchen Kunden funktionieren agile Methoden (nicht)? Vertreter des Kunden darf selbst nicht gezwungen sein, seinen Vorgesetzten eine - Planung im Vorfeld - Erfüllung bestimmter Funktionen zu festgelegten Terminen zu berichten "Kunde vor Ort"-Prinzip Mitarbeiter des Kunden benötigen selbst einen erheblichen Wissensumfang Sind diese Personen entbehrlich? FrankDopatka@web.de Folie 79 Mit welchen n funktionieren agile Methoden (nicht)? : sehr gute Fähigkeiten häufige Änderungen umfangreiche fahrung geeignete Werkzeuge ausgeprägtes Ego: große Überzeugung von richtigen Lösungen Besitzdenken des geschriebenen Codes äußert: Nicht jeder kann damit umgehen, dass sein Code von anderen verändert wird FrankDopatka@web.de Folie 80

41 Mit welchen n funktionieren agile Methoden (nicht)? XP weist eine Reihe von Merkmalen auf, - die hohe Disziplin erfordern TDD & CI, permanante Refactorings, Programmieren in Paaren - und andere, die eine gewisse Disziplinlosigkeit fördern das Auslassen von Spezifikation FrankDopatka@web.de Folie 81 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? Quellen des Vortrags: Wikipedia < Vorlesung Einführung in die Informatik II < Fowler, Scott: UML konzentriert; 2. Auflage; Addison Wesley Verlag; ISBN Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung; 2. Auflage; Spektrum-Verlag; ISBN Booch, Rumbaugh, Jacobson: Das UML Benutzerhandbuch; Addison-Wesley Verlag; ISBN