Anforderungen haben immer Schuld

Post on 23-Jan-2018

1.166 views 0 download

Transcript of Anforderungen haben immer Schuld

Anforderungen haben

immer SchuldKomplexität mit gutem Anforderungsmanagement

beherrschenFrank Düsterbeck

@fduesterbeck

DAS AGILE QUIZ

Warum haben Anforderungen oft Schuld?

DAS

AGILE

QUIZ

???Weil sie schlecht sind (wenn sie da sind) und

sich andauernd ändern!

WAS BISHER GESCHAH

IT ODER DIENSTLEISTER?

FACHBEREICH, BA UND IT?

ANFORDERUNGEN

LASTEN

LASTENHEFT

JETZT GEHT’S (ENDLICH)

LOS???

(ER-)LÖSUNG DER LASTEN(PFLICHTEN)

PFLICHTENHEFT

DAS GROSSE HEFT DER LASTEN

(1602 SEITEN)

UNDURCHSUCHBAR

UNAKTUELLUNNÜTZ

DAS GROSSE HEFT DER LASTEN

(1602 SEITEN)

WIE MAN ES BESSER

MACHEN KANN

(SOLLTE, MUSS)

Was ist die Grundlage für gutes Anforderungs-

management?

PO

ENTREPRENEUR

Repräsentiert die Endkundenbedürfnisse

VEREINT PRODUKT- UND PROJEKTMANAGEMENT

Und was ist noch Grundlage für gutes

Anforderungs-management?

VisionZiel des Projektes Erstellung eines Produktes

Ergebnis des ProduktesWelche Veränderung soll erzielt werden?

Nutzen des ProduktesWelche Verbesserung soll aus demErgebnis resultieren?

ZielgruppeWer soll mit dem Produkt arbeiten?

Bu

sin

ess

Cas

e

PersonasPersona erstellen

Zielgruppen erkennen und gruppieren

> 60 Jahre> 1.000.000 GehaltVerheiratet> 1 KindLebt in einer Großstadt

Personas

PersonasJetzt weiß ich auch wer das System nutzt und welche

Bedürfnisse und Probleme er hat

Probleme

Wesentliche Informationen

ZieleBedürfnisse

DAS SUPER

PERSONAS POSTER

Alternativen

Produkt-planung

Gemeinsames Verständnis

Das ist eine

Schlange

Das ist ein Baum

Das ist eine Höhle

Das ist ein Berg

Ein Satz zu meiner Vision

Meine neuen Stärken

Wer möchte was und wozu

Die „messbaren“

Ziele

Meine Stakeholder

Risiken und Chancen

Als werMöchte ich was ganz großesDamit wozu

Als werMöchte ich was ganz großesDamit wozu

DAS SUPER

PRODUKT VISION POSTER

StakeholderFreunde, Feinde und Neutrale

Einfluss auf das ProjektInteressen und Hintergründe

Weitere Treiber und BremserGesetze, Projekte

Risiken und ChancenEintrittswahrscheinlichkeit, Auswirkung

Vorbeugen, reduzieren, übertragen, akzeptierenErgreifen, steigern, teilen, ablehnen

HistorieUrsprung des Projektes

Probleme in der Vergangenheit

Produktvision

Textmuster Elevator Pitch

Muster anwenden

Produktvision

Was Tolles!

Karton

Und wie beschreibe ich Anforderungen?

USER STORIES

Als Rolle (wer)Möchte ich Ziel (was) Damit Nutzen (wozu)

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)

Sollten denn alle Stories möglichst klein sein? Was sind überhaupt Epics?

Als werMöchte ich was großesDamit wozu

Als werMöchte ich wasDamit wozu

Als werMöchte ich was großesDamit wozu

Als werMöchte ich was großesDamit wozu

Als werMöchte ich wasDamit wozuAls werMöchte ich wasDamit wozu

Als werMöchte ich wasDamit wozu

Das muss ich tun

Das muss ich tun

Das muss ich tunDas muss ich tun

Das muss ich tun

PO

Als werMöchte ich was ganz großesDamit wozu

PO

TD

Muss die Summe der Schätzung der zerlegten Stories eigentlich gleich der original Story sein?

Als werMöchte ich was großesDamit wozu

Als werMöchte ich wasDamit wozu

Als werMöchte ich wasDamit wozuAls werMöchte ich wasDamit wozu

Als werMöchte ich wasDamit wozu≠∑

Und wie sichere ich die Qualität der User Stories?

ConversationDefinition of Ready

Qualitätssicherungfür

User Stories

*Haben nicht den Anspruch Anforderungen umfassend zu dokumentieren

Card

Conversation

Confirmation

Als Benutzermöchte ich Zahlen addieren könnendamit ich Zeit beim Rechnen spare

*

Confirmation

Akzeptanzkriterien (Testbasis)

Herstellung der Messbarkeit

Ready (DoR) Bereit zur Umsetzung

Fertig (DoD) Bereit zur Inspektion

Schlüssel-wörter

identifizieren

Fragen-katalog

verwenden

Fragen im Team

diskutieren

Akzeptanz-kriterien ableiten

Testfälle spezifizieren

Confirmation

Schlüssel-wörter

identifizieren

Confirmation

Als Benutzer möchte ich mein Profil speichern können,damit ich meine Daten nicht immer wieder neu eingeben muss.

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?

Und was ist wenn ich jetzt total viel Akzeptanzkriterien habe?

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

Man soll also viel reden!

Gibt‘s da noch mehr?

Conversation

BDD

VERHALTEN

TREIBT

ENTWICKLUNG

BEHAVIOR

DRIVEN

DEVELOPMENT

UBIQUITÄRE SPRACHEGHERKIN

ALLE VERSTEHEN ES

SZENARIEN MIT

GIVEN WHEN THENANGENOMMEN WENN DANN

Akzeptanzkriterien

Szenario: Marmelade abonnieren monatlicher RhythmusAngenommen ein Kunde MaxUnd Max ist Premium KundeUnd Max aktiviert den AboserviceWenn Max als Intervall monatlich auswähltDann bekommt Max eine Nachricht Und die Marmelade wird monatlich versendetUnd er bekommt 10% Rabatt

Szenario: Marmelade abonnieren wöchentlicher RhythmusAngenommen ein Kunde MaxUnd Max ist Premium KundeUnd Max aktiviert den AboserviceWenn Max als Intervall wöchentlich auswähltDann bekommt Max eine Nachricht Und die Marmelade wird wöchentlich versendetUnd er bekommt 5% Rabatt

Akzeptanzkriterien

Szenario: Marmelade abonnierenAngenommen ein Kunde MaxUnd Max ist Premium KundeUnd Max aktiviert den AboserviceWenn Max ein als Intervall <intervall> auswähltDann bekommt Max eine Nachricht Und die Marmelade wird <intervall> versendetUnd er bekommt <rabatt> Rabatt

Beispiele:|intervall |rabatt ||wöchentlich |5% ||monatlich |10% |

… und das geht auch automatisiert?

Wie denn?

Client

View

ModelBusinesslogik

Controller

Ressourcen

Request

Response

Select

??

Als Benutzermöchte ich Zahlen addieren könnendamit 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);

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!!!

Das ist ja alles ganz toll aber wie werde

ich damit den Anforderungen an

moderne Softwareentwicklung

gerecht?

K O M P L E X I T Ä T R E D U Z I E R E NR I S I K O M I N I M I E R E N

Epos 31

Epos 19Epos 12

Epos 9Epos 4

Epos 7Epos 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

Detailed Appropriatly (angemessen Ausdetailliert)

Emergent (sich entwickelnd / dynamisch)

Estimated (geschätzt)

Prioritized (in „Reihenfolge“ gebracht)

Und wie mache ich das Projectscoping?

Wie weiß ich was ich zuerst bauen soll?

Das minimale Set an Funktionen...

...die für uns den maximalen…

...Lerneffekt herstellen.

Schick

Benutzbar

Wertvoll

Funktional

REICHT DAS?

K O M P L E X I T Ä T R E D U Z I E R E NR I S I K O M I N I M I E R E N

Das Unbekannte kennen...

...über den ganzen Geschäftsprozess(e)...

...über alle Hauptkomponenten.

Das ist mir irgendwie noch zu unkonkret!

Pre-Suche

Einloggen

Account anlegen

SuchenPasswort ändern

Filtern Details ansehen

Anzahl im Warenkorb

ändern

In den Warenkorb legen

Aus dem Warenkorb

löschen

Bestellen

Bewerten

Eigene Marmelade

zusammenstellen

Detaillierte Inhaltsliste anzeigen

Abo anlegen

Versandserviceauswählen

Einfache Einkaufs-

möglichkeit

Pre-Suche

Einloggen

Account anlegen

Suchen

Passwort ändern Filtern

Details ansehen

In den Warenkorb legen

Aus dem Warenkorb

löschen

Versandserviceauswählen

Bewerten

Eigene Marmelade

zusammenstellen

Detaillierte Inhaltsliste anzeigen

Abo anlegen

Anzahl im Warenkorb

ändern

BestellungWarenkorbSucheLogin

Bestellen

Bewertung

Einfache Einkaufs-

möglichkeit

Warenkorb

Story MappingSucheLogin Bestellung ...

*

Jeff Patton

Benutzer-verwaltung

Bestellprozess

RELEASE 1:MINISHOP

RELEASE 2:AUKTIONEN

RELEASE 3:MARKTPLATZ

DAS GROSSE HEFT DER LASTEN

(1602 SEITEN)

UNDURCHSUCHBAR

UNAKTUELLUNNÜTZ

DURCHSUCHBAR

AKTUELLNÜTZLICH

Und was ist mit den nicht funktionalen Anforderungen?

reliability

availability

portability

scalability

usability

maintainability

security

performance

correctness

robustness

Unsere

Story Map

Unsere

Rahmenbedingungen

DoD

Als Kundemöchte ich, dass das System 99,99% Erreichbarkeit hat

Als Administratormöchte ich, dass das System in einem Fail-Over Cluster läuft

Als Kundemöchte ich, dass das System mobile Endgeräte unterstützt

Als ausländischer Kundemöchte ich, dass das System meine Sprache anbietet

Aufbau der Testinfra-struktur

Epos 31

Epos 19Epos 12

Epos 9Epos 4

Epos 7Epos 2

Funktion Test

FunktionSpikeDesign

Tools

Infrastruktur

Technische

Unterstützung

Funktion

Gibt‘s noch was?

DON‘T WANT STORIES

Als RolleMöchte ich nicht, dass...Weil / Damit ich sonst...

Und wie sieht der Prozess für Stories bzw. Anforderungen aus?

DAILY

SCRUM

SPRINT

PLANNING

Product

BacklogProduct

BacklogSPRINT

BACKLOG

PRODUCT

BACKLOGPRODUCT

BACKLOGPRODUCT

BACKLOGPRODUCT

BACKLOGPRODUCT

BACKLOGPRODUCT

BACKLOG

PRODUCT

REVIEW

RETROSPECTIVE

STORY TODOIN

PROGRESS DONE

SCRUM BOARD (VISUALISIERUNG)

REFINEMENT

REFINEMENT

SPRINT PLANNING

TICKETSYSTEM

Offen

Bereit zur Umsetzung

(Ready)

In Bearbeitung

WIKI

Fertig(Done)

DIE GROSSE SYSTEMDOKUMENTATION

Das muss ich tun

DAS FAZIT

Anforderungen haben

immer SchuldKomplexität mit gutem Anforderungsmanagement

beherrschenFrank Düsterbeck

@fduesterbeck

Anforderungen haben

nimmer SchuldKomplexität mit gutem Anforderungsmanagement

gerecht werdenFrank Düsterbeck

@fduesterbeck

Frank Düsterbeck

frank.duesterbeck@HEC.de

@fduesterbeck

de.slideshare.net/fduesterbeck