Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung Beide Seiten der Revision | |||
se:iterationsplanung [2008-12-27 19:55] stefan angelegt |
se:iterationsplanung [2008-12-27 20:00] stefan |
||
---|---|---|---|
Zeile 2: | Zeile 2: | ||
* Was zuerst implementiert wird, entscheidet der Kunde! -> Priorisierung | * Was zuerst implementiert wird, entscheidet der Kunde! -> Priorisierung | ||
* Vorgehen nach {[quellen:Bleek2008|S. 43]} | * Vorgehen nach {[quellen:Bleek2008|S. 43]} | ||
- | - Ausgangspunkt sind Storys, die Features (Nutzen für den Anwender) beschreiben | + | * Ausgangspunkt sind Storys, die Features (Nutzen für den Anwender) beschreiben |
- | - Kunde wählt die wichtigsten Storys aus und Entwickler schätzen die Storys -> nun ist Reihenfolge anhand Kosten/Nutzen möglich | + | * Kunde wählt die wichtigsten Storys aus und Entwickler schätzen die Storys -> nun ist Reihenfolge anhand Kosten/Nutzen möglich |
- | - Erkennen und Zerteilen der zu großen Anforderungen | + | * Erkennen und Zerteilen der zu großen Anforderungen |
- | - bei umfangreichen Systemen kann nun nach dem Ansatz der Quick Wins oder Low-Hanging-Fruits vorgegangen werden: was kann schnell umgesetzt werden und verschafft dem Kunden einen hohen Mehrwert (insbesondere wichtig bei Ablösung von Altsystemen, da sonst ständig nur die bereits vorhandenen Funktionen nachprogrammiert werden) | + | * bei umfangreichen Systemen kann nun nach dem Ansatz der Quick Wins oder Low-Hanging-Fruits vorgegangen werden: was kann schnell umgesetzt werden und verschafft dem Kunden einen hohen Mehrwert (insbesondere wichtig bei Ablösung von Altsystemen, da sonst ständig nur die bereits vorhandenen Funktionen nachprogrammiert werden) |
+ | * Hilfen: Abhängigkeitsgraph (Anforderung 1 muss vor Anforderung 2 implementiert werden) und Graph, der die positiven Auswirkungen von Anforderungen zeigt (Anforderung 2 kann schneller, besser, einfacher implementiert werden, wenn Anforderung 1 bereits implementiert ist) | ||
+ | * zusätzlich zu den fachlichen Anforderungen können auch technische Anforderungen (z.B. Refactorings) als Storys eingebracht werden, für die dann z.B. ein gewisser Teil der Arbeitszeit aufgewendet werden kann | ||
===== Abhängigkeiten zwischen Anforderungen ===== | ===== Abhängigkeiten zwischen Anforderungen ===== |