bei agiler Entwicklung sollen möglichst wenig Dokumente erzeugt werden, da diese erfahrungsgemäß schnell an Aktualität verlieren und die Entwicklung nicht mehr unterstützen bzw. sogar behindern (→ falsche/überholte Anforderungen etc.)
Entwickler müssen vor/bei der konkreten Implementierung im Kontakt mit dem Kunden die aktuellen Details klären → möglichst wenig Zeitverlust zwischen Definition der Details und Implementierung
grundsätzliche Haltung: so wenig wie möglich aufschreiben → mehr Arbeitszeit für Entwicklung
nur der Kunde kann die Details definieren, die Entwickler können implementieren aber kennen sich nicht (zwangsläufig) in der fachlichen Domäne aus
optimal: Vertreter des Kunden oder der Kunde selbst ist bei der Entwicklung vor Ort und steht als direkter Ansprechpartner zur Verfügung (andersherum geht es auch: die Entwickler richten ihren Arbeitsplatz beim Kunden ein)
die Dokumentation der geklärten Details erfolgt am Besten in Form von Tests und nicht in Dokumenten, dies hat auch gleich einen erheblichen Mehrwert für die Entwicklung und Qualitätssicherung
kleinere Details, dür die kein Test benötigt wird, können im Quelltext selbst dokumentiert werden (warum wurde genau diese Art der Implementierung gewählt?)
Anforderungen müssen aber mindestens so genau aufgenommen werden, dass eine
Aufwandsschätzung durch die Entwickler möglich ist, um die Iterationen zu planen
die Entwickler lernen mehr über die Prozesse der Anwender während sie auf Basis der groben Anforderungen und ständiges Nachfragen oder Beobachten entwickeln, als wenn sie lange und meist missverständliche Dokumente lesen müssen
Anforderungen sollten als (User-)Storys erfasst werden, die textuell jeweils eine Anforderung gerade so präzise beschreiben, dass ein Aufwand dafür geschätzt werden kann
die Storys werden vom Kunden aufgeschrieben z.B. nach Feature Driven Development in der Form <Aktion> <Ergebnis> <Objekt>
Achtung: Aktionen wie "Verwalten" reichen nicht aus, da völlig unterschiedliche Dinge darunter verstanden werden können
auch (für den Kunden) selbstverständliche Dinge (z.B. Drucken von Daten etc.) müssen als Story vorliegen, damit nichts verloren geht
in XP wird die Story als Versprechen verstanden, dass der Entwickler sich beim Implementieren der Story noch einmal intensiv mit dem Kunden darüber unterhält und die Details klärt
Storys können gut auf Karteikarten oder Postits untergebracht werden (was auch gleichzeitig deren Länge einschränkt)
Anforderungen an Software müssen möglichst früh erfasst werden, um die Erwartungen auf allen Seiten einzugrenzen, "Feature Creep" zu vermeiden und die Angst der Entwickler zu verringern
Entwickler sollten nicht anfangen zu programmieren, bevor eine adequate Spezifikation vorliegt, der die Kunden zustimmen
Design Spezifikationen veralten sehr schnell (Problem der Synchronisation mit dem Code) und sollten daher nicht erstellt werden. Vielmehr sollte der Code sich selbst dokumentieren →
API-Doku
lange Anforderungsdefinitionsphasen sind verschwendete Zeit für die Entwickler, aber ohne Spezifikation sollte man nicht entwickeln → Anforderungen als User Storys erfassen
Informationen in einer Spezifikation müssen sein:
Correct: korrekt und unmissverständlich
Comprehensible: jeder Leser muss sie verstehen können, klar definierte Worte verwenden (should, must, may etc.)
Complete: nicht alle Informationen müssen drin stehen (→ Referenzen auf andere Dokumente) und das Level der Abstraktion sollte weit über dem des Codes liegen
Verifiable: aus der Spezifikation sollten direkt Tests ableitbar sein
Modifiable: keine PDF-Dateien usw. da Änderungen meist sehr wahrscheinlich sind
Self-describing: drin sein sollten Titelseite, Einleitung, Begriffserklärungen, Referenzen, History
Traceable: auch Spezifikationen sollten versioniert werden
"What is written without effort is in general read without pleasure." [Samuel Johnson]
"Niemand wird meine Spezifikation je lesen" denken sich viele Entwickler und schreiben keine! Aber wichtiger als das Lesen ist der Prozess, der beim Schreiben im Kopf des Entwicklers vorgeht. Er muss sich nämlich intensiv mit seinem Thema auseinandersetzen, was zu besseren Ergebnissen führt.
Die Zeit, die man meint einsparen zu können, indem man auf eine Spezifikation verzichtet, wird deutlich von der Zeit übertroffen werden, die man ohne Spezifikation für die Abstimmung von Anforderungen etc. aufbringen muss (→ deutlich ineffektivere Kommunikation, die gleichen Dinge müssen mehrmals erklärt werden etc.)