Anforderungen haben immer Schuld! Schuld an schlechten Tests, Schuld an schlechter Entwicklung, Schuld für viele Änderungen, Schuld an einfach allem. Wie macht man also gutes Anforderungsmanagement und schafft es dadurch noch Komplexität zu reduzieren und so Softwareprojekte einfacher zu gestalten? Wie kriegt man den Kunden dazu seine 1000-seitigen Lastenhefte zu entsorgen und durch etwas Geeigneteres zu ersetzen? Mittels moderner agiler Verfahren und Praktiken. Wie diese genau aussehen, welche Hindernisse auftauchen können und wie diese aus dem Weg geschafft werden können zeigt dieser Vortrag – immer mit dem Fokus auf Einfachheit und Praktikabilität. Der Vortrag ist gerichtet an Projektleiter, Entwickler, Abteilungs-, Team und Bereichsleiter, Scrum Master, Product Owner, Business Analysten.
4. IT ODER DIENSTLEISTER?
FACHBEREICH, BA UND IT?
ANFORDERUNGEN
LASTEN
LASTENHEFT
JETZT GEHT’S
(ENDLICH)
LOS???
(ER-)LÖSUNG
DER LASTEN
(PFLICHTEN)
PFLICHTENHEFT
12. Und was ist noch
Grundlage für gutes
Anforderungs-
management?
13. VisionZiel des Projektes
Erstellung eines Produktes
Ergebnis des Produktes
Welche Veränderung soll erzielt werden?
Nutzen des Produktes
Welche Verbesserung soll aus dem
Ergebnis resultieren?
Zielgruppe
Wer soll mit dem Produkt arbeiten?
Business
Case
20. Ein Satz zu
meiner Vision
Meine
neuen Stärken
Wer möchte
was und wozu
Die
„messbaren“
Ziele
Meine
Stakeholder
Risiken und
Chancen
Als wer
Möchte ich was
ganz großes
Damit wozu
Als wer
Möchte ich was
ganz großes
Damit wozu
DAS SUPER
PRODUKT
VISION
POSTER
21. Stakeholder
Freunde, Feinde und Neutrale
Einfluss auf das Projekt
Interessen und Hintergründe
Weitere Treiber und Bremser
Gesetze, Projekte
Risiken und Chancen
Eintrittswahrscheinlichkeit, Auswirkung
Vorbeugen, reduzieren, übertragen, akzeptieren
Ergreifen, steigern, teilen, ablehnen
Historie
Ursprung des Projektes
Probleme in der Vergangenheit
27. Independent (von anderen unabhängig)
Negotiable (kein Gesetz)
Valuable (haben (Mehr-)Wert)
Estimable (überschau- und damit schätzbar)
Small (passen in eine Iteration)
Testable (ohne Test kein Erfolg)
29. Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
Das muss
ich tun
PO
Als wer
Möchte ich was
ganz großes
Damit wozu
PO
TD
30.
31. Muss die Summe der
Schätzung der
zerlegten Stories
eigentlich gleich der
original Story sein?
32. Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu≠∑
35. *Haben nicht den Anspruch Anforderungen umfassend zu dokumentieren
Card
Conversation
Confirmation
Als Benutzer
möchte ich Zahlen addieren können
damit ich Zeit beim Rechnen spare
*
39. Wer muss speichern?
Wann speichern stattfinden?
Wann ist speichern komplett abgeschlossen?
Wie kann speichern genau durchgeführt werden?
Wie häufig / oft / groß / schnell soll speichern sein?
Wo / Wie kann geprüftwerden, ob speichern durchgeführt wurde?
Wurde sichergestellt, dass speichern alle Daten / Aspekte berücksichtigt?
Was geschieht, wenn man nicht speichern kann?
Was könnte speichern verhindern und was wird dann erwartet?
Welche möglichen Fehleingaben müssen beim speichern abgefangen werden?
Welche Inhalte kommen in Profil vor?
Welche optionalen / verpflichtende Aspekte gelten für Profil ?
Welche Inhalte von Profil und nach welchen Regeln soll überprüft werden?
Wie sieht das Layout für Profil aus?
40. Und was ist wenn ich
jetzt total viel
Akzeptanzkriterien
habe?
41. Akzeptanzkriterien
• Der Premium-Kunde soll bei einer Buchung auswählen können, ob die Buchung als Abo laufen soll
• Der ausgewählte Termin ist der Starttermin
• Er kann verschiedene Intervalle für sein Abo auswählen
– Täglich
• Er kann zwischen bestimmten Wochentagen oder allen Arbeitstagen auswählen
– Wöchtlich
• Rhythmus von jeder, zweiter, dritter…Woche
– Monatlich
• Bestimmter Wochentag (letzter Freitag im Monat)
• Bestimmter Tag, wie der 1. eines Monats
• Er kann einen Endtermin für sein Abo bestimmen
– Bestimmtes Datum
– Nach einer bestimmten Anzahl an Wochen
• Er kann in seinem Kundenkonto die ausgewählten Abos einsehen, ändern und löschen
• Er kann in seinem Kundenkonto die Kosten anzeigen
• Er kann einen Zahlungsrhythmus für das Abo auswählen
– Im Voraus
– Je Termin
– monatlich
46. Akzeptanzkriterien
Szenario: Marmelade abonnieren monatlicher Rhythmus
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max als Intervall monatlich auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird monatlich versendet
Und er bekommt 10% Rabatt
Szenario: Marmelade abonnieren wöchentlicher Rhythmus
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max als Intervall wöchentlich auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird wöchentlich versendet
Und er bekommt 5% Rabatt
47. Akzeptanzkriterien
Szenario: Marmelade abonnieren
Angenommen ein Kunde Max
Und Max ist Premium Kunde
Und Max aktiviert den Aboservice
Wenn Max ein als Intervall <intervall> auswählt
Dann bekommt Max eine Nachricht
Und die Marmelade wird <intervall> versendet
Und er bekommt <rabatt> Rabatt
Beispiele:
|intervall |rabatt |
|wöchentlich |5% |
|monatlich |10% |
50. Als Benutzer
möchte ich Zahlen addieren können
damit ich Zeit beim Rechnen spare
User Story schreiben
Akzeptanzkriterien ausarbeiten
Glue Code schreiben
Unittest Code schreiben
Code schreiben
Ready
Done
[Then(@"the result should be (.*) on the screen")]
public void ThenTheResultShouldBeOnTheScreen(decimal p0)
{
Assert.AreEqual(p0, result);
}
Assert.AreEqual(130, calculator.result);
51. User Story schreiben
Akzeptanzkriterien ausarbeiten
Glue Code schreiben
Unittest Code schreiben
Code schreiben
Fachbereich und
Anforderungsmanager haben eine
einfache Sprache, ...
… Anforderungsmanager, Entwickler
und Tester müssen jetzt eng
zusammenarbeiten, …
… die Entwickler können dann
direkt gegen das erwartete
Verhalten (den Test) entwickeln, …
… alle kriegen sofort eine
Rückmeldung, ob sie alles richtig
gemacht haben, …
… am Ende braucht man
nicht mehr soviel testen, …
… und wir haben eine
lebende Dokumentation!!!
52. Das ist ja alles ganz
toll aber wie werde
ich damit den
Anforderungen an
moderne
Softwareentwicklung
gerecht?
53. K O M P L E X I TÄT R E D U Z I E R E N
R I S I K O M I N I M I E R E N
54. Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7
Epos 2
User Story 4 User Story 33
User Story 14User Story 13User Story 3
User Story 1
User Story 6
User Story 2
User Story 5
Status Ready
K O M P L E X I TÄT R E D U Z I E R E N
71. Unsere
Story Map
Unsere
Rahmenbedingungen
DoD
Als Kunde
möchte ich, dass das System 99,99%
Erreichbarkeit hat
Als Administrator
möchte ich, dass das System in einem
Fail-Over Cluster läuft
Als Kunde
möchte ich, dass das System mobile
Endgeräte unterstützt
Als ausländischer Kunde
möchte ich, dass das System meine
Sprache anbietet
Aufbau der
Testinfra-
struktur