Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Anforderungen haben immer Schuld

1,492 views

Published on

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.

Published in: Software
  • Be the first to comment

Anforderungen haben immer Schuld

  1. 1. Anforderungen haben immer Schuld Komplexität mit gutem Anforderungsmanagement beherrschen Frank Düsterbeck @fduesterbeck
  2. 2. DAS AGILE QUIZ Warum haben Anforderungen oft Schuld? DAS AGILE QUIZ ???Weil sie schlecht sind (wenn sie da sind) und sich andauernd ändern!
  3. 3. WAS BISHER GESCHAH
  4. 4. IT ODER DIENSTLEISTER? FACHBEREICH, BA UND IT? ANFORDERUNGEN LASTEN LASTENHEFT JETZT GEHT’S (ENDLICH) LOS??? (ER-)LÖSUNG DER LASTEN (PFLICHTEN) PFLICHTENHEFT
  5. 5. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
  6. 6. DAS GROSSE HEFT DER LASTEN (1602 SEITEN)
  7. 7. WIE MAN ES BESSER MACHEN KANN (SOLLTE, MUSS)
  8. 8. Was ist die Grundlage für gutes Anforderungs- management?
  9. 9. PO ENTREPRENEUR Repräsentiert die Endkundenbedürfnisse VEREINT PRODUKT- UND PROJEKTMANAGEMENT
  10. 10. Und was ist noch Grundlage für gutes Anforderungs- management?
  11. 11. 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
  12. 12. Personas Persona erstellen Zielgruppen erkennen und gruppieren
  13. 13. > 60 Jahre > 1.000.000 Gehalt Verheiratet > 1 Kind Lebt in einer Großstadt Personas
  14. 14. Personas Jetzt weiß ich auch wer das System nutzt und welche Bedürfnisse und Probleme er hat
  15. 15. Probleme Wesentliche Informationen Ziele Bedürfnisse DAS SUPER PERSONAS POSTER Alternativen
  16. 16. Produkt- planung
  17. 17. Gemeinsames Verständnis Das ist eine Schlange Das ist ein Baum Das ist eine Höhle Das ist ein Berg
  18. 18. 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
  19. 19. 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
  20. 20. Produktvision Textmuster Elevator Pitch
  21. 21. Muster anwenden
  22. 22. Produktvision Was Tolles! Karton
  23. 23. Und wie beschreibe ich Anforderungen?
  24. 24. USER STORIES Als Rolle (wer) Möchte ich Ziel (was) Damit Nutzen (wozu)
  25. 25. 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)
  26. 26. Sollten denn alle Stories möglichst klein sein? Was sind überhaupt Epics?
  27. 27. 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
  28. 28. Muss die Summe der Schätzung der zerlegten Stories eigentlich gleich der original Story sein?
  29. 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 Damit wozu Als wer Möchte ich was Damit wozu Als wer Möchte ich was Damit wozu≠∑
  30. 30. Und wie sichere ich die Qualität der User Stories?
  31. 31. Conversation Definition of Ready Qualitätssicherung für User Stories
  32. 32. *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 *
  33. 33. Confirmation Akzeptanzkriterien (Testbasis) Herstellung der Messbarkeit Ready (DoR)  Bereit zur Umsetzung Fertig (DoD)  Bereit zur Inspektion
  34. 34. Schlüssel- wörter identifizieren Fragen- katalog verwenden Fragen im Team diskutieren Akzeptanz- kriterien ableiten Testfälle spezifizieren Confirmation
  35. 35. 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.
  36. 36.  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?
  37. 37. Und was ist wenn ich jetzt total viel Akzeptanzkriterien habe?
  38. 38. 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
  39. 39. Man soll also viel reden! Gibt‘s da noch mehr?
  40. 40. Conversation BDD
  41. 41. VERHALTEN TREIBT ENTWICKLUNG BEHAVIOR DRIVEN DEVELOPMENT
  42. 42. UBIQUITÄRE SPRACHE GHERKIN ALLE VERSTEHEN ES SZENARIEN MIT GIVEN WHEN THEN ANGENOMMEN WENN DANN
  43. 43. 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
  44. 44. 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% |
  45. 45. … und das geht auch automatisiert? Wie denn?
  46. 46. Client View Model Businesslogik Controller Ressourcen Request Response Select ? ?
  47. 47. 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);
  48. 48. 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!!!
  49. 49. Das ist ja alles ganz toll aber wie werde ich damit den Anforderungen an moderne Softwareentwicklung gerecht?
  50. 50. 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
  51. 51. 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
  52. 52. Detailed Appropriatly (angemessen Ausdetailliert) Emergent (sich entwickelnd / dynamisch) Estimated (geschätzt) Prioritized (in „Reihenfolge“ gebracht)
  53. 53. Und wie mache ich das Projectscoping? Wie weiß ich was ich zuerst bauen soll?
  54. 54. Das minimale Set an Funktionen... ...die für uns den maximalen… ...Lerneffekt herstellen. Schick Benutzbar Wertvoll Funktional
  55. 55. REICHT DAS? 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
  56. 56. Das Unbekannte kennen... ...über den ganzen Geschäftsprozess(e)... ...über alle Hauptkomponenten.
  57. 57. Das ist mir irgendwie noch zu unkonkret!
  58. 58. Pre-Suche Einloggen Account anlegen Suchen Passwort ä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 Versandservice auswählen Einfache Einkaufs- möglichkeit
  59. 59. Pre-Suche Einloggen Account anlegen Suchen Passwort ändern Filtern Details ansehen In den Warenkorb legen Aus dem Warenkorb löschen Versandservice auswählen Bewerten Eigene Marmelade zusammenstellen Detaillierte Inhaltsliste anzeigen Abo anlegen Anzahl im Warenkorb ändern BestellungWarenkorbSucheLogin Bestellen Bewertung Einfache Einkaufs- möglichkeit
  60. 60. Warenkorb Story Mapping SucheLogin Bestellung ... *   Jeff Patton Benutzer- verwaltung Bestellprozess
  61. 61. RELEASE 1: MINISHOP RELEASE 2: AUKTIONEN RELEASE 3: MARKTPLATZ
  62. 62. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
  63. 63. DURCHSUCHBAR AKTUELL NÜTZLICH
  64. 64. Und was ist mit den nicht funktionalen Anforderungen?
  65. 65. reliability availability portability scalability usability maintainability security performance correctness … robustness
  66. 66. 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
  67. 67. Epos 31 Epos 19 Epos 12 Epos 9 Epos 4 Epos 7 Epos 2 Funktion Test FunktionSpikeDesign Tools Infrastruktur Technische Unterstützung Funktion
  68. 68. Gibt‘s noch was?
  69. 69. DON‘T WANT STORIES Als Rolle Möchte ich nicht, dass... Weil / Damit ich sonst...
  70. 70. Und wie sieht der Prozess für Stories bzw. Anforderungen aus?
  71. 71. DAILY SCRUM SPRINT PLANNING Product Backlog Product Backlog SPRINT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT BACKLOG PRODUCT REVIEW RETROSPECTIVE STORY TODO IN PROGRESS DONE SCRUM BOARD (VISUALISIERUNG) REFINEMENT
  72. 72. REFINEMENT SPRINT PLANNING
  73. 73. TICKETSYSTEM Offen Bereit zur Umsetzung (Ready) In Bearbeitung WIKI Fertig (Done) DIE GROSSE SYSTEMDOKUMENTATION Das muss ich tun
  74. 74. DAS FAZIT
  75. 75. Anforderungen haben immer Schuld Komplexität mit gutem Anforderungsmanagement beherrschen Frank Düsterbeck @fduesterbeck
  76. 76. Anforderungen haben nimmer Schuld Komplexität mit gutem Anforderungsmanagement gerecht werden Frank Düsterbeck @fduesterbeck
  77. 77. Frank Düsterbeck frank.duesterbeck@HEC.de @fduesterbeck de.slideshare.net/fduesterbeck

×