Vom Lastenheft zur User-Story Matthias Strößner

Transkript

1 Vom Lastenheft zur User Story Migrationsszenarien vom V-Modell zu Scrum SOPHIST GmbH Vordere Cramergasse Nürnberg Deutschland Tel.:+49 (0) Fax:+49 (0)

2 Vom Lastenheft zur User-Story Matthias Strößner Berater, Trainer, Autor Seit 2009 bei den SOPHISTen Requirements Engineer Begleitet RE- Einführungsprojekte

3 Wer schreibt, der bleibt Die Bücher der SOPHISTen Vortragstitel

4 Unsere Kunden Auszug aus unserer Kundenliste Vortragstitel

5 1 2 3 Grundsatzüberlegungen Gründe für Dokumentation Dokumentieren im Projekt 4 5 Der Umstieg Gretchenfrage Dokumentieren in agilen Projekten

6 RE-Disziplinen Dokumentation abschaffen Für wen dokumentieren wir? Für uns selbst Für Andere Grundsatzüberlegungen

7 Vortragstitel

8 Was dokumentiere ich wann und wie in agilen Projekte?

9 Vortragstitel HardCore-Ansatz: nichts dokumentieren, außer jemand zwingt mich dazu. SOPHIST GmbH Seite 9

10 Wer könnte mich zwingen? Für wen dokumentiere ich?

11 Manchmal dokumentieren wir für uns Vortragstitel

12 Der Umstieg manchmal für Andere

13 Dokumentieren für Andere Wissend unwissend, kooperativ unkooperativ Dokumentieren Kapitelname im Projekt SOPHIST GmbH unwissend wissend Gleicher Arbeitgeber, gleiche Ziele, gleicher Hintergrund kooperativ In die eigene Tasche wirtschaften, unterschiedliche Sprache, Hauptziel: Profitmaximierung unkooperativ Seite 13

14 Wissen verfällt Missverständnisse vermeiden Informationen verteilen Überblick behalten Gründe für Dokumentation

15 Wissen verfällt Vergessenskurve nach Ebbinghausen Gründe für Dokumentation nach 30 min [Stangl] Vergessenskurve nach Ebbinghaus Dokumentieren bewahrt das Wissen SOPHIST GmbH Seite 15

16 Wissen verfällt Zeigarnik- oder Cliffhanger-Effekt Gründe für Dokumentation DONE [Spritzer] Spitzer, Manfred (2012): Digitale Demenz. Haken dran weg ist das Wissen SOPHIST GmbH Seite 16

17 Missverständnisse Explikation von Wissen vermeiden ermöglicht Konfliktlösung Dokumentieren im Projekt Konsolidierungstechniken helfen Konflikte lösen [Cowan] Robin; Foray, Dominique: SOPHIST GmbH The economics #.2 of codification Seite 17 and the diffusion of knowledge.

18 Informationen verteilen Informationen müssen verteilt werden Der Umstieg

19 Informationen verteilen Verbale Verteilung von Informationen A A/C A/B/C B/C C SOPHIST GmbH Seite 19 Gründe für Dokumentation

20 Informationen verteilen Schriftliche Verteilung von Informationen Gründe für Dokumentation A/B/C A/B/C A/B/C A/B/C A/B/C SOPHIST GmbH Seite 20

21 Vortragstitel Wissensvermittlung statt Dokumentation in agilen Projekten erfordert die gleichzeitige Anwesenheit aller

22 Gesamtüberblick erhalten Wo bin ich? SOPHIST GmbH Seite 22 Gründe für Dokumentation

23 Fazit Warum dokumentieren? Gründe für Dokumentation Für sich selbst dokumentieren: Bewahrung von Wissen Nutzung von Detailwissen für die Problemlösung Für Andere dokumentieren: Senkung des Konfliktpotenzials durch Explikation von Wissen und Konsolidierung Verteilung von gleichem Wissen im Projekt Qualitativ hochwertige Dokumentation sorgt für eindeutiges Verständnis beim Empfänger. SOPHIST GmbH Seite 23

24 Ausgangspunkt Wer dokumentiert? Wann dokumentieren? Was dokumentieren? Zusammenfassung Dokumentieren im Projekt

25 Ausgangspunkt Dokumentieren Kapitelname im Projekt Annahme: Wir wollen für Andere dokumentieren Dann stellen sich die Fragen: Wer? Wann? Wie / In welcher Form? Was? in welchem Reifegrad SOPHIST GmbH Seite 25

26 Wer dokumentiert? Die Rollen im Scrum-Projekt Dokumentieren Kapitelname im Projekt Eventuell sind je nach dem Dokumentationszeitpunkt noch andere Rollen integriert SOPHIST GmbH Seite 26

27 Wann dokumentieren? Dokumentieren Kapitelname im Projekt vor der Entwicklung während der Entwicklung Dokumentation kann prinzipiell vor, während und nach der Entwicklung stattfinden nach der Entwicklung SOPHIST GmbH Seite 27

28 Wann dokumentieren? Vor der Entwicklung Dokumentieren Kapitelname im Projekt Mögliche Kriterien/Indizien Ausschreibungsverfahren (konventionelles AG/AN-Verhältnis) Gefordert durch Verordnungen FDA in der Medizintechnik FuSi in der Automobilbranche (ISO26262) Für das Team neue Domäne SOPHIST GmbH Seite 28

29 Wann dokumentieren? Nach der Entwicklung Dokumentieren im Projekt Mögliche Kriterien/Indizien Lösungen werden erst während des Projekts erarbeitet Stark iterative Entwicklung mit vielem Refactoring Integration muss beschrieben werden SOPHIST GmbH Seite 29

30 Wann dokumentieren? Während der Entwicklung Dokumentieren Kapitelname im Projekt Zu Beginn des Sprints Iterationsbeginn Während des Sprints Am Ende des Sprints Iterationsende Dokumentation in die DoD aufnehmen SOPHIST GmbH Seite 30

31 Wann dokumentieren? Während der Entwicklung Dokumentieren im Projekt Mögliche Kriterien / Indizien Vor einem Sprint Problem oder Lösung sind noch nicht durchdrungen Während eines Sprints Eingearbeitetes Team Nach einem Sprint Problem oder Lösungen werden erst während des Sprints erarbeitet SOPHIST GmbH Seite 31

32 Was dokumentieren? Inhalte und Reifegrad nach Bedürfnissen der Projektdisziplinen SOPHIST GmbH Seite 32 Dokumentieren Kapitelname im Projekt

33 Zusammenfassung Erst nachdenken SOPHIST GmbH Seite 33 Dokumentieren Kapitelname im Projekt

34 Zusammenfassung um nicht so zu enden SOPHIST GmbH Seite 34 Dokumentieren Kapitelname im Projekt

35 Überblick Klassisches RE & Agile Entwicklung Agiles RE & Agile Entwicklung Zusammenfassung Der Umstieg

36 Überblick Der Umstieg Klassisches RE & Agile Entwicklung Nur die Entwicklung des Produkts erfolgt agil Die Spezifikationen werden nach traditionellem Vorgehen erstellt Customer Requirements dienen als Basis für das Product Backlog müssen rechtzeitig in das Product Backlog überführt werden Agiles RE & Agile Entwicklung Entwicklung des Produkts und der Spezifikationen erfolgen agil Entweder ein Product Owner-Team oder das Entwicklungsteam spezifizieren die Technical System Requirements und die Testspezifikation SOPHIST GmbH Seite 36

37 Klassisches RE & Agile Entwicklung Der Umstieg Spezifiziert wird nach traditionellem Vorgehensmodell Die Produktentwicklung erfolgt agil Customer Requirements sind Basis für das Product Backlog SOPHIST GmbH Seite 37

38 Klassisches RE & Agile Entwicklung Vorteile Nachteile Der Umstieg Gut steuerbar durch traditionellen Gesamtprozess hohe Transparenz durch agile Regelmeetings Kurze Entwicklungszyklen Selbstorganisation des Entwicklungsteams Customer Requirements müssen vor der Entwicklungsphase spezifiziert sein Querbezüge zwischen Product Backog und anderen Spezifikationen müssen erstellt und gepflegt werden SOPHIST GmbH Seite 38

39 Agiles RE & Agile Entwicklung Variante 1 mit Product Owner Team Der Umstieg Die Spezifikation erfolgt agil ein PO-Team erstellt das Product Backlog, die Customer Requirements, und die Technical System Requirements Die Produktentwicklung erfolgt agil auf Basis des Product Backlogs + Specs SOPHIST GmbH Seite 39

40 Agiles RE & Agile Entwicklung Variante 1 mit Product Owner Team Vorteile Nachteile Der Umstieg Agile Anpassung der Spezifikationen an die Projektumstände möglich Pflege des Product Backlogs ist nicht von einer einzelnen Person abhängig Vereinfachter Aufbau von Traceability zwischen den Spezifikationen durch gleiche Verantwortlichkeit Zeitliche Abstimmung von Spezifikations- und Entwicklungssprints notwendig Höherer Kommunikationsaufwand durch unterschiedliche Verantwortliche für Produkt/Technical System Requirements und Realisierung SOPHIST GmbH Seite 40

41 Agiles RE & Agile Entwicklung Variante 2 mit Spezifikation als Team-Task Der Umstieg Stakeholder Product Owner Team Customer Requirements Product Backlog Die Spezifikation erfolgt agil das PO-Team erstellt die Customer Requirements und das Product Backlog Die Entwicklung erfolgt agil Das Team erstellt das Produkt und die Technical System Requirements SOPHIST GmbH Seite 41

42 Agiles RE & Agile Entwicklung Variante 2 mit Spezifikation als Team-Task Vorteile Nachteile Der Umstieg Agile Anpassung der Spezifikationen an die Projektumstände möglich Paralleles Wachstum der Technical System Requirements und des Produkts Erhöhter Kommunikations- aufwand für Traceability zwischen Customer Requirements und Technical System Requirements Niedrigere Velocity durch zusätzliche Dokumentationstasks für das Entwicklungsteam SOPHIST GmbH Seite 42

43 Agiles RE & Agile Entwicklung Variante 3 Entwicklung und Spezifikation in einem Team Der Umstieg Die Spezifikation und Entwicklung erfolgen agil in einem cross-funktionalen Team Das Team entwickelt das Produkt, erweitert das Product Backlog und die Customer Requirements und erstellt die Technical System Requirements Das Team pflegt die Querverbindungen zwischen den Spezifikationen. Der PO steuert durch Priorisierung des Product Backlog die Entwicklung SOPHIST GmbH Seite 43

44 Agiles RE & Agile Entwicklung Variante 3 Entwicklung und Spezifikation in einem Team Vorteile Nachteile Der Umstieg Agile Anpassung der Spezifikationen an die Projektumstände möglich Keine Abstimmung von Spezifikations- und Entwicklungssprints Vereinfachter Aufbau von einer gemeinsamen Sicht auf das Produkt im Team Potentiell mehr Interaktion zwischen Team und Stakeholdern notwendig Erhöhte Präsenz/ Erreichbarkeit des Product Owners nötig Potentiell niedrigere Velocity durch zusätzliche Dokumentationstasks Teamgröße steigt. SOPHIST GmbH Seite 44

45 Reality bites Die goldene Regel Wissensvermittlung ohne Dokumentation Herausforderungen Wiederverwendung Rückblick - Ausblick

46 Vortragstitel Reality bites Die Realität bestimmt die Methode Methodendogmatismus ist out

47 Die goldene Regel: Grundsatzüberlegungen Wer das Gold hat macht die Regeln

48 Dokumentieren im Projekt Wissensvermittlung ohne Dokumentation will gelernt sein

49 oft mehr als agiles Neuentwickeln!!! Grundsatzüberlegungen Grundsatzüberlegungen Wiederverwendung bringt

50 Die moderne Gretchenfrage: Nun sag, wie hast du s mit der Dokumentation? Du bist ein herzlich guter Mann, allein ich glaub, du hältst nicht viel davon. Vortragstitel

51 Haben Sie weitere Fragen? SOPHIST GmbH Seite 51

52 Infos der SOPHISTen Vortragstitel Was Sie bei uns erwartet: Buchkapitel zum Thema Der Vortrag als PDF Login in den Downloadbereich Newsletter zu OO und RE Geniale Events Was tun: Widerstand zwecklos! Schicken Sie uns eine mit Ihren Adressdaten an wir schicken Ihnen einen Link auf unseren Downloadbereich. Stichwort: SOPHISTDay 2014 Gespannt? Dann sind Sie bei uns genau richtig. Weitere Informationen finden Sie unter

53 Literaturquellen [Cowan] Robin; Foray, Dominique: The economics of codification and the diffusion of knowledge. Online verfügbar unter zuletzt geprüft am [Stangl] Werner: Die Vergessenskurve. Online verfügbar unter zuletzt geprüft am [Miller] George A.: The Magical Number Seven, Plus or Minus Two Some Limits on Our Capacity for Processing Information. Online verfügbar unter 0Seven%20Psych%20Review% pdf, zuletzt geprüft am [Baddeley] Alan: Working Memory: Theories, Models, and Controversies. Online verfügbar unter zuletzt geprüft am oder auf Wiki: SOPHIST GmbH Seite 53

54 Literaturquellen Rupp, Chris (2009): Requirements-Engineering und -Management. Professionelle, iterative Anforderungsanalyse für die Praxis. 5., aktualisierte und erw. Aufl. München, Wien: Hanser. [Spitzer] Manfred (2012): Digitale Demenz. Wie wir uns und unsere Kinder um den Verstand bringen. München: Droemer (Beck'sche Reihe). SOPHIST GmbH Seite 54

55 Quellenverzeichnis - Fotos Titel: Mechanical engineering Quelle: istockphoto Autor: Baris Simsek Titel: Young Man Portrait Quelle: istockphoto Autor: drbimages Titel: Black angel beauty Quelle: istockphoto Autor: Fmbackx Titel: Master Greeter Quelle: istockphoto Autor: andrew Rich Titel: Start Quelle: istockphoto Autor: Mehli Titel: Scientists Quelle: istockphoto Autor: H-Gall Titel: Blackboard Series Quelle: istockphoto Autor: Muharrem Öner Titel: human brain simplified anatomic illustration Quelle: istockphoto Autor: Alenai Stock Titel: abstract cognitive intelligence Quelle: istockphoto Autor: Jorgenmac Titel: Iceberg Quelle: Autor: microsoft SOPHIST GmbH Seite 55

56 Quellenverzeichnis - Fotos Titel: I Quit Quelle: istockphoto Autor: Trista Titel: Colleagues holding question mark signs in front of their faces Quelle: istockphoto Autor: Roland Dick Titel: Computer Training Quelle: istockphoto Autor: Alexander Raths Titel: Earth in Space Quelle: istockphoto Autor: Anton Balazh Titel: Human Brain Weathered Quelle: istockphoto Autor: Tharisson Titel: Thinking young woman Quelle: istockphoto Autor: drbimages Titel: Too much work Quelle: istockphoto Autor: TommL Titel: Gray Rabbit Quelle: istockphoto Autor: Alan 64 Titel: Desicion Making Quelle: istockphoto Autor: mattjeacock Titel: In gold we trust Quelle: istockphoto Autor: pcuk SOPHIST GmbH Seite 56

57 Quellenverzeichnis - Fotos Titel: Thinking young woman Quelle: istockphoto Autor: drbimages Titel: Business Team Meeting Quelle: istockphoto Autor: Jhorrocks Titel: Zeitungsschnipsel Quelle: SOPHIST Autor: Chris Rupp Titel: Angry Men Quelle: SOPHIST Autor: Chris Rupp Titel: Vergessenskurve nach Ebbinghaus Quelle: wikipedia Autor: Rdb Titel: Erst planen, dann bauen Quelle: aboutpixel.de Autor: Thorwald Hoffmann SOPHIST GmbH Seite 57

58 Haben Sie weitere Fragen? Ein rücksichtsloser Rückblick und ein aussichtsloser Ausblick.