Anforderungen haben immer Schuld
•
5 gefällt mir•2,400 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Anforderungen haben immer Schuld
Ähnlich wie Anforderungen haben immer Schuld (20)
Mehr von Frank Düsterbeck
Mehr von Frank Düsterbeck (8)
Anforderungen haben immer Schuld
- 1. Anforderungen haben immer Schuld Komplexität mit gutem Anforderungsmanagement beherrschen Frank Düsterbeck @fduesterbeck
- 2. DAS AGILE QUIZ Warum haben Anforderungen oft Schuld? DAS AGILE QUIZ ???Weil sie schlecht sind (wenn sie da sind) und sich andauernd ändern!
- 4. IT ODER DIENSTLEISTER? FACHBEREICH, BA UND IT? ANFORDERUNGEN LASTEN LASTENHEFT JETZT GEHT’S (ENDLICH) LOS??? (ER-)LÖSUNG DER LASTEN (PFLICHTEN) PFLICHTENHEFT
- 6. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
- 8. DAS GROSSE HEFT DER LASTEN (1602 SEITEN)
- 9. WIE MAN ES BESSER MACHEN KANN (SOLLTE, MUSS)
- 10. Was ist die Grundlage für gutes Anforderungs- management?
- 11. PO ENTREPRENEUR Repräsentiert die Endkundenbedürfnisse VEREINT PRODUKT- UND PROJEKTMANAGEMENT
- 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
- 15. > 60 Jahre > 1.000.000 Gehalt Verheiratet > 1 Kind Lebt in einer Großstadt Personas
- 16. Personas Jetzt weiß ich auch wer das System nutzt und welche Bedürfnisse und Probleme er hat
- 18. Produkt- planung
- 19. Gemeinsames Verständnis Das ist eine Schlange Das ist ein Baum Das ist eine Höhle Das ist ein Berg
- 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
- 23. Muster anwenden
- 25. Und wie beschreibe ich Anforderungen?
- 26. USER STORIES Als Rolle (wer) Möchte ich Ziel (was) Damit Nutzen (wozu)
- 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)
- 28. Sollten denn alle Stories möglichst klein sein? Was sind überhaupt Epics?
- 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
- 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≠∑
- 33. Und wie sichere ich die Qualität der User Stories?
- 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 *
- 36. Confirmation Akzeptanzkriterien (Testbasis) Herstellung der Messbarkeit Ready (DoR) Bereit zur Umsetzung Fertig (DoD) Bereit zur Inspektion
- 38. 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.
- 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
- 42. Man soll also viel reden! Gibt‘s da noch mehr?
- 43. Conversation BDD
- 45. UBIQUITÄRE SPRACHE GHERKIN ALLE VERSTEHEN ES SZENARIEN MIT GIVEN WHEN THEN ANGENOMMEN WENN DANN
- 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% |
- 48. … und das geht auch automatisiert? Wie denn?
- 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
- 55. Detailed Appropriatly (angemessen Ausdetailliert) Emergent (sich entwickelnd / dynamisch) Estimated (geschätzt) Prioritized (in „Reihenfolge“ gebracht)
- 56. Und wie mache ich das Projectscoping? Wie weiß ich was ich zuerst bauen soll?
- 58. Das minimale Set an Funktionen... ...die für uns den maximalen… ...Lerneffekt herstellen. Schick Benutzbar Wertvoll Funktional
- 59. 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
- 61. Das Unbekannte kennen... ...über den ganzen Geschäftsprozess(e)... ...über alle Hauptkomponenten.
- 62. Das ist mir irgendwie noch zu unkonkret!
- 63. 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
- 64. 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
- 65. Warenkorb Story Mapping SucheLogin Bestellung ... * Jeff Patton Benutzer- verwaltung Bestellprozess
- 66. RELEASE 1: MINISHOP RELEASE 2: AUKTIONEN RELEASE 3: MARKTPLATZ
- 67. DAS GROSSE HEFT DER LASTEN (1602 SEITEN) UNDURCHSUCHBAR UNAKTUELL UNNÜTZ
- 69. Und was ist mit den nicht funktionalen Anforderungen?
- 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
- 72. Epos 31 Epos 19 Epos 12 Epos 9 Epos 4 Epos 7 Epos 2 Funktion Test FunktionSpikeDesign Tools Infrastruktur Technische Unterstützung Funktion
- 73. Gibt‘s noch was?
- 74. DON‘T WANT STORIES Als Rolle Möchte ich nicht, dass... Weil / Damit ich sonst...
- 75. Und wie sieht der Prozess für Stories bzw. Anforderungen aus?
- 76. 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
- 78. TICKETSYSTEM Offen Bereit zur Umsetzung (Ready) In Bearbeitung WIKI Fertig (Done) DIE GROSSE SYSTEMDOKUMENTATION Das muss ich tun
- 79. DAS FAZIT
- 80. Anforderungen haben immer Schuld Komplexität mit gutem Anforderungsmanagement beherrschen Frank Düsterbeck @fduesterbeck
- 81. Anforderungen haben nimmer Schuld Komplexität mit gutem Anforderungsmanagement gerecht werden Frank Düsterbeck @fduesterbeck