Im Stich gelassen: SWKammer-Köln

Warum wir und als Software-Team um bessere Anforderungen kümmern sollten - und wie!

Vortrag mit Daniel Lauxtermann.

Transcript

1. Im Stich gelassen? Dr. Gernot Starke Fellow Daniel Lauxtermann Senior Consultant
2. Dr. Gernot Starke Fellow • Gründer arc42, aim42 • Mitgründer iSAQB e.V. Daniel Lauxtermann Senior Consultant • Requirements Engineer • Product Owner, Business Analyst
3. garbage in, garbage out
4. Input Output
5. Input Output ? Photo by John Cameron on Unsplash
6. Requirements-Chaos Statt „echter“ Product-Owner: • Konkurrierende Fachabteilungen • Ständig wechselnde Prioritäten • Unklare Vorgaben • Diffuse Begriffe
7. Wer bekommt Prügel? Entwicklungsteam L Photo by Aimee Vogelsang on Unsplash
8. Ziele: Entwicklungsteams („Architekt:innen) in die Lage versetzen, • fehlende, • schlechte, • unpassende Anforderungen verbessern, gemeinsam mit Stakeholdern! Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
9. Nicht-Ziele Requirements-Engineering oder Business-Analyse: • ersetzen • abschaffen • vom Entwicklungsteam übernehmen lassen
10. Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
11. Anforderungen + Randbedingungen • Stakeholder • Kontextabgrenzung • Funktionale Anforderungen • Qualitätsanforderungen • Randbedingungen • Nicht-Anforderungen Was soll das System/ Produkt tun? Wie schnell, sicher, flexibel, zuverlässig, teuer, ......? Unter welchen Einschränkungen entwickeln und betreiben (Technik, Team, Ressourcen, Prozessen, bestehenden Systemen...)? Was nicht tun/leisten? externe Schnittstellen, Scope? W er hat Anforderungen?
12. Beispiel: Meinungen… • Konkurrierende Fachabteilungen • Unklare Vorgaben Product • Id • Name • revenueAcc Characteristic • name • valueType • value Name Anz. Preis Ich will flexibel individuelle Dinge verkaufen und manuelle Aufwände reduzieren Performance Management machen wir auf Basis von Produkten. Erlöse müssen korrekt kontiert werden. Anforderung
13. Stakeholder Photo by Yiran Ding on Unsplash Management, Auftraggeber, Projekt-Steuerkreis, sonstige Projekt-Gremien, PMO, Projektmanager, Produktmanager, Fachbereich, Unternehmens- /Enterprise-Architekt, Architektur-Abteilung, Methoden-Abteilung, QS- Abteilung, IT-Strategie, Software-Architekt, Software-Designer, Entwickler, Tester, Konfigurationsmanager, Build-Manager, Release- Manager, Wartungsteam, externe Dienstleister, Zulieferer, Hardware- Designer, Rollout-Manager, Infrastruktur-Planer, Sicherheitsbeauftragter, Behörde, Aufsichtsgremium, Auditor, Mitbewerber/Konkurrent, Endanwender, Fachpresse, Fachadministrator, Systemadministrator, Operator, Hotline, Betriebsrat, Lieferant von Standardsoftware, verbundene Projekte, Normierungsgremium, Gesetzgeber...
14. Photo by Yiran Ding on Unsplash kennen wir deren Anforderungen?
15. Stakeholder vergessene Stakeholder bedeuten vergessene Anforderungen Photo by Yiran Ding on Unsplash
16. Tipp (mehrere!) Stakeholder involvieren: • Fachbereiche • User • Betrieb / Hardware • (Top-)Management • Verantwortliche von Nachbarsystemen
17. Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: »schnellere Pferde« (Angebliches Zitat von Henry Ford) © Volkan Furuncu / Picture Alliance
18. Kontextabgrenzung / Scope Was liegt „im“ System, was „außen“? Zeigt externe Schnittstellen Macht klar, was im Fokus steht Systemgrenze trennt innen und außen
19. Tipps Externe Schnittstellen kennen: • fachliche Bedeutung • „Gegenstelle“ • Volatilität • Q-Anforderungen: Volumen, Durchsatz, Reaktionszeit, Verfügbarkeit
20. Funktionale Anforderungen Überblick schaffen, Gesamtprozess verstehen Geschäftsprozess , Systemprozess, Use Case, oder User Story (unser) System other... other... API
21. Funktionale Anforderungen Überblick schaffen, Gesamtprozess verstehen iterativ / inkrementell
22. Funktionale Anforderungen Idee: Top-Down...
23. Hierarchie von Anforderungen... ausführbar Vision ausführbare Spezifikationen (Code) konkret abstrakt …..
24. Hierarchie von Anforderungen... ausführbar
25. Geht auch mit JIRA/Confluence Tabelle (Business) Use Case Diagramm Ticketart / Komponente / Stichwort / Link Epic User Story JIRA Lorem Ipsum DoD
26. Link zur Architekturdoku A B C Links Plugin System A1 A2 C1 (System) Use Case Diagramm (Business) Use Case Diagramm Links Excerpt Das gleiche Muster lässt sich für andere Kapitel wiederholen
27. Tipps • Business-Ziele explizit aufschreiben (lassen) • High-Level („Ende-zu-Ende“) Prozesse kennen • Mehrwert für Nutzer*innen kennen • Iterativ verfeinern
28. Was bei DDD fehlt...!
29. Domain-Driven Analysis and Design treffender wäre DDAD:
30. Domain-Driven (Analysis and) Design Zentrale DDD- Praktiken gehören zur Anforderungsklärung... Legend Ubiquitous Language Core Domain Generic Subdomains Bounded Context Context Map avoid overinvesting problem space solution space names enter cultivate rich model with Model-Driven Design cultivate rich model with assess / overview relationsships with Domain Events express model with work in autonomous, clean
32. verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen verfeinert durch verfeinert durch Quellcode des Systems verwendet ausführbare Specs als Verfeinerung Vision ausführbare Spezifikationen (Code) konkret abstrakt …..
33. Given-When-Then... Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen Given a web browser is on the Google page When the search phrase "panda" is entered Then results for "panda" are shown
34. Tools für BDD verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen verfeinert durch verfeinert durch In Gherkin Feature-Files Quellcode des Systems verwendet spockframework
35. BDD: Behaviour-Driven Development
36. Ausführbare Specs Aktueller Status im Überblick
37. Tipps • Eines der BDD-Tools ausprobieren • Given-When-Then Beschreibung von Anforderungen im Team versuchen • Fachbereich involvieren („3-Amigo-Session“, Biz+Test+Dev)
38. Die Sache mit der Qualität (DIN 9000:2015-11) „Grad, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt“. Häh?
39. Die Sache mit der Qualität... Konkrete Informationen wie z.B.: • Wie lange Zeit bis XY-Operation fertig? • Wieviele Daten/User? • Wie lange für welche Art Änderung?
40. Qualität - konkreter Prio Q-Merkmal Konkretisierung 1 Flexibilität Neues csv- oder Fix-Field Importformat in <4h konfigurierbar 2 Last / Performance 100.000 per Batch/ftp gelieferte Fotos inkl. Metadaten innerhalb von 4h prozessiert 3 Datensicherheit • Mandant kann niemals Zugriff auf Daten anderer Mandanten erhalten • Datenlieferung grundsätzlich einem Mandaten zugeordnet 4 Änderbarkeit Grafisches Subsystem innerhalb von 20PT an neuen Grafik- Chip anpassbar Voraussetzung: neuer Chip verfügt über notwendigen Low-Level Funktionen
41. Qualitätsanforderungen ermitteln Reliability Testability Security Performance Availability Modifiability Operability Usability <…> <…> <…> Quality Attribute Web [Keeling-17] …. …. …. …. …. …. …. ….
42. Tipps 1. Qualitätsanforderungen explizit machen 2. Falls keine vorhanden: educated guess
43. Zusammenarbeit im Team DISCOVER DELIVER https://www.discovertodeliver.com/index.php Nach: Ellen Gottesdiener
44. Zusammenarbeit - konkreter DISCOVER DELIVER Story Map Top Level Epics Selected Stories Release https://www.discovertodeliver.com/index.php
45. Tipps 1. Mit Fachbereich/Business auf discover- deliver Schleife einigen 2. PO in „Requirements Engineering“ ausbilden
46. 5-Punkte Plan 1. Business-Ziele 2. externe Schnittstellen 3. High-Level Prozesse 4. (ausführbare) Beispiele 5. Qualitätsanforderungen
47. Quellen Peter Hruschka, Gernot Starke Im Stich gelassen? Requirements Skills erfolgreicher Softwareteams https://leanpub.com/requirements-skills/c/swkkoeln-meetup-06-21
48. Gutschein… https://leanpub.com/requirements-skills/c/swkkoeln-meetup-06-21
49. Quellen (3) • Michael Keeling: Design It! Pragmatic Programmers. • T+A Hathaway: Getting and Writing IT Requirements in Lean and Agile World. Leanpub. • Hruschka: Business Analysis and Requirements Engineering. Hanser. • Smart: BDD in Action. Manning.