Projekt: Requirements Engineering Sommersemester Anforderungsspezifikation im X-Treme Programming

Größe: px

Ab Seite anzeigen:

Download "Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming"

Florian Hummel
vor 8 Jahren
Abrufe

1 Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch XP: User-Stories 3 Bezug zum Projekt 1

X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2

2 1 XP Eine kurze Einführung Einige Statements: Strukturierter Anarchismus Schlag gegen Software-Engineering XP-Projekte sind Expeditionen ins Ungewisse Back to the Basics IT-Kommunismus Historie entwickelt von Kent Beck (1995) Cunningham, Jeffries, Fowler Pilotprojekt: C3 (Lohnabrechnung Crysler) Motivation Probleme in der Software-Entwicklung: Analyse und Entwurf aufwendig Geschäftsziele können sich ändern Falsche Funktionsfülle Fehlerrate Personalwechsel Entwicklungsprozess ist teuer bei Missverständnissen oder Änderungen können Modelle schnell veralten bei starkem Kosten- bzw. Termindruck werden Modelle oft ignoriert 2

Probleme in der Software-Entwicklung: Analyse und Entwurf aufwendig Geschäftsziele können sich ändern Falsche Funktionsfülle Fehlerrate Personalwechsel

3 Es lohnt sich nicht, eine Lösung zu planen, weil a) der Endbenutzer den Plan nicht versteht, b) auch wenn er ihn verstünde, ihn nicht unterschreiben würde, bis er die Lösung zu sehen bekommt und c) weil er, falls er ihn doch noch verstünde, ihn jeden Tag auf den Kopf stellen würde. Idee Der Aufwand für Änderungen ist während der gesamten Softwareentwicklung gleich groß. Dazu wird das, was sich beim Software-Engineering bewährt hat, bis ins Extreme gesteigert. 3

verstünde, ihn jeden Tag auf den Kopf stellen würde.

4 Praktiken intensive Kommunikation Systemmetapher einfachstes Design für Problemlösung automatisierte Testfälle Refactoring Pair Programming ständige Integration von neuem Code kurze Iterationen (max. 4 Wochen) Small Releases (max. 3 Monate) Code ist Allgemeingut minimalisierte Dokumentation flexibles Management 4

Integration von neuem Code kurze Iterationen (max.

5 Grundwerte Kommunikation Feedback Einfachheit Mut Warum Mut? Aufstand der Programmierer Wir wollen wissen, was der Kunde in welcher Reihenfolge entwickelt haben möchte! Wir wollen unsere eigenen Abschätzungen machen und sie aktualisieren dürfen! Wir wollen Verantwortlichkeit übernehmen und sie nicht zugewiesen bekommen! Aufstand der Kunden Wir wollen den Projektfortschritt sehen! Wir wollen unsere Meinung ändern können! Wir wollen Planänderungen so früh wie möglich erfahren! 5

Wir wollen unsere eigenen Abschätzungen machen und sie aktualisieren dürfen!

6 Klassisch SE Code Reviews Testen Design Einfachheit Architektur Integrationstest Kurze Iterationen XP Der Code wird andauernd begutachtet (Pair-Programming). Jeder testet andauernd (Unit-Tests), auch der Kunde (Akzeptanztests). Design wird eine alltägliche Aufgabe. (Refactoring) Es wird stets die einfachste Problemlösung angestrebt. Jeder ist andauernd bemüht, die Architektur zu definieren und zu verbessern (Systemmetapher). Integrationstests werden mehrmals täglich durchgeführt (fortlaufende Integration). Die Iterationen sind wirklich kurz (Planspiel). Rahmenbedingungen 5-10 eigenverantwortliche Entwickler Arbeit am gleichen Ort zur gleichen Zeit ständige Kundennähe 6

(Refactoring) Es wird stets die einfachste Problemlösung angestrebt. Jeder ist andauernd bemüht, die Architektur zu definieren und zu verbessern (Systemmetapher).

7 Fazit XP ist ein hochgradig iterativer Entwicklungsprozess. XP hat alle Phasen eines herkömmlichen Prozesses. Es muss nicht XP sein! aber Oft kann es nicht XP sein! Entwicklungsprozess maßschneidern und kontinuierlich verbessern! 7

8 2 Anforderungsspezifikation Klassisch Dokument (Pflichtenheft) ist die wichtigste Phase in einem Softwareprojekt stellt Basis für erfolgreiche Implementierung dar ist häufig Grundlage eines Vertrags wird typischerweise für formale Abnahme verwendet XP: User-Stories The aim is to deliver software that matches the requirements at every release, not to match the requirements as they were misunderstood at the beginning of the project. Kent Beck These Anforderungsdefinition ist ein Dialog, kein Dokument User-Stories ein Stück Funktionalität (Feature) vom Kunden geschrieben passt auf eine Karteikarte wird zur passenden Zeit im Dialog verfeinert wird validiert durch Abnahmetest des Kunden Die Funktionalität des Systems wird auf einfache (!) Weise als Summe kleiner Bestandteile beschrieben. 8

misunderstood at the beginning of the project.

9 Planung 1. Storycard schreiben (Kunde) 2. Aufwand der Story einschätzen (Entwicklung) 3. Umfang für die Version festlegen (Kunde) Gute Stories verständlich, nicht zu detailliert Story muss einen Wert für den Kunden haben angemessener (inhaltlicher) Umfang möglichst unabhängig voneinander testbar Stories schreiben iterativ 2 bis 5 Stories formulieren (dann Aufwand schätzen) Kommunikation und Feedback immens wichtig nicht notwendigerweise alle sofort formulieren ständig Stories hinzufügen, löschen, splitten 9

haben angemessener (inhaltlicher) Umfang möglichst unabhängig voneinander testbar Stories schreiben iterativ 2 bis 5 Stories

10 Aufwand schätzen Konkretisierung kann erforderlich sein Zukunft = Vergangenheit + Erfahrung einfache Methoden (Halbieren, Verdoppeln) Einheit frei wählbar, aber eine für alle Stories Team-Entscheidung kann später korrigiert werden wenn keine Erfahrungen vorliegen, Stories pushen, die noch am sichersten zu schätzen sind exploritary programming Prioritätensetzung kein absolutes Ranking Kunde entscheidet, was in aktuelle Iteration kommt kann zum Splitten der Story führen Entwickler können Risiken sichtbar machen Stories splitten nicht ungewöhnlich Anlässe: Entwickler beurteilt die Story als zu umfangreich Story passt nicht in die Iteration zu viel Arbeit in der aktuellen Iteration Kunde und Entwickler (splitten und schätzen) Kriterium Priorität erfordert einige Übung 10

absolutes Ranking Kunde entscheidet, was in aktuelle Iteration kommt kann zum Splitten der Story führen Entwickler können Risiken sichtbar machen Stories splitten nicht ungewöhnlich Anlässe:

11 Story-Erweiterungen möglich, aber nicht empfohlen insbesondere vage Formulierungen vermeiden ( sollte,... wäre von Vorteil... usw.) Lebensdauer beendet mit positivem Akzeptanztest Information geht nicht verloren (Code und Test) Storycard wird nicht mehr benötigt 11

) Lebensdauer beendet mit positivem Akzeptanztest Information geht

12 3 Bezug zum Projekt Pro Teamgröße Projektgröße Contra (erst mal) reine Anforderungs-/Verhaltensspezifikation kaum dynamische Änderungen der Anforderungen Arbeitsorganisation (Kundennähe, Kommunikation) denkbar Programm als Summe vieler kleiner Features einfache Aussagen zur Aufwandsabschätzung für jedes Feature einen Test benennen 12

Arbeitsorganisation (Kundennähe, Kommunikation) denkbar Programm als Summe vieler

Ähnliche Dokumente

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001 Tammo Freese OFFIS, Oldenburg freese@acm.org http://www.tammofreese.de Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de