Susanne Mühlbauer
REConf 2015
Continuous Documentation statt Endless
Specification
Fokus auf die nachhaltigen Artefakte
Quelle: http://stateofagile.versionone.com/
Wozu agil?
Festes Team
Interdisziplinär
(alle Skills)
Produktverantwortung
über den
gesamten
Lebenszyklus
Water – Scrum - Fall
Idee->
Termin->
Spezifikation -> Release
Projektstart:
• Termin fix
• Requirements fix
• Budget fix
R...
Qualität ist nicht verhandelbar
BudgetTermin
variabel
Requirements
Requirements
Fix
InvestitionTermin
Werte
Prinzipien
Helping you to help yourself
*: Standish Group Study reported at XP2002 by Jim Johnson
45% aller Features...
Value-Orientiertes RE
Feature
Spielraum
Spielraum
Release Release
Vision ->
Backlog
Entwicklung + RE + Test
Scrum
Überblick
Was bekommen
wir?
Was macht das
System?
Was bekommen
wir?
Product Canvas
Vision Board
Use Case Model
Vision
Statement
Product Canvas
Use Case
Model
Backlog
Person...
Was macht das
System?
Spezifikation Dokumentation
Vorher:
Was soll das System tun
Nachher:
Was tut das System
=
Informationsmodell
Kunden-
anforderungen
System-
anforderungen
Design-
anforderungen
Implementierung
Fachliche Doku
System...
Wir brauchen keine Spezifikation
Sprint
Backlog
Fachliche Doku
System-Doku
Design-Doku
Code
Wozu
Was
Wie
Vision
Statement
...
Langfristig relevantes und
sofort nutzbares Wissen
Software-
Nutzung
Software-
Entwicklung
Entwicklungs-
phase
Betriebs-/W...
Beispiele
Auf allen Ebenen:
• Überblick
• Benutzerhandbuch
• Fachliche Architektur
• Szenarien/ Use Cases
• Tests, z.B.
Us...
Voraussetzungen
Langfristige Produktverantwortung
RE-
Know How
im Team
Investition in Qualität
• Automatisiertes Testen
• ...
Was kostet das?
20 Tage RE
100 Tage
Entwicklung
20 Tage RE
5 Entwickler
X
2 Sprints
X
10 Tage
= 100 Tage
1 RE
X
2 Sprints
...
Festes Team
RE-Know How im Team
Dokumentation statt Spezifikation
Was noch?
Susanne.Muehlbauer@HOOD-Group.com
Twitter: @susemuehlbauer
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
T...
Agilität erleben: Jeden Tag gemeinsam einen Mehrwert schaffen. Ein Umdenken beginnt,
neue Ideen sind gesät und und ein mut...
Nächste SlideShare
Wird geladen in …5
×

Continuous Documentation statt Endless Specification - Fokus auf die nachhaltigen Artefakte legen

1.209 Aufrufe

Veröffentlicht am

Anforderungen sind die Brücke für Firmen, die bisher klassisch entwickelt haben in agile Vorgehensweisen.
Agile Vorgehensweisen setzen auf kontinuierliche Konversation; nach der Umsetzung dürfen die Anforderungen bzw. Backlog Items weggeworfen werden. Konventionelle Vorgehensweisen nutzen eine schriftliche Anforderungsspezifikation und halten diese laufend aktuell.

Obwohl immer mehr Organisationen mit Scrum arbeiten, beinhaltet das nicht immer den gesamten Entwicklungsprozess. Wir sprechen dann von "Water-Scrum-Fall", wenn wie bisher komplette Vorabspezifikationen erstellt, diese in der Entwicklung in Sprints abgearbeitet werden und dann die Testphase beginnt.

Der Vortrag beleuchtet, wie man mittels Continuous Documentation von der (Vorab-) Spezifikation zu einer stets aktuellen Dokumentation kommen kann und damit mehr Nutzen aus seiner Scrum-Implementierung ziehen kann.

Veröffentlicht in: Ingenieurwesen
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.209
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
19
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Continuous Documentation statt Endless Specification - Fokus auf die nachhaltigen Artefakte legen

  1. 1. Susanne Mühlbauer REConf 2015 Continuous Documentation statt Endless Specification Fokus auf die nachhaltigen Artefakte
  2. 2. Quelle: http://stateofagile.versionone.com/ Wozu agil?
  3. 3. Festes Team Interdisziplinär (alle Skills) Produktverantwortung über den gesamten Lebenszyklus
  4. 4. Water – Scrum - Fall Idee-> Termin-> Spezifikation -> Release Projektstart: • Termin fix • Requirements fix • Budget fix RE Test
  5. 5. Qualität ist nicht verhandelbar BudgetTermin variabel Requirements Requirements Fix InvestitionTermin
  6. 6. Werte Prinzipien Helping you to help yourself *: Standish Group Study reported at XP2002 by Jim Johnson 45% aller Features werden nie genutzt*
  7. 7. Value-Orientiertes RE Feature Spielraum Spielraum
  8. 8. Release Release Vision -> Backlog Entwicklung + RE + Test Scrum
  9. 9. Überblick Was bekommen wir? Was macht das System?
  10. 10. Was bekommen wir? Product Canvas Vision Board Use Case Model Vision Statement Product Canvas Use Case Model Backlog Persona Szenario Ready Epic GUI NFA Roman Pichler, Ivar Jacobson
  11. 11. Was macht das System? Spezifikation Dokumentation Vorher: Was soll das System tun Nachher: Was tut das System =
  12. 12. Informationsmodell Kunden- anforderungen System- anforderungen Design- anforderungen Implementierung Fachliche Doku System-Doku Design-Doku Code Wozu Was Wie Spezifikation Dokumentation
  13. 13. Wir brauchen keine Spezifikation Sprint Backlog Fachliche Doku System-Doku Design-Doku Code Wozu Was Wie Vision Statement Kontinuierliche Dokumentation
  14. 14. Langfristig relevantes und sofort nutzbares Wissen Software- Nutzung Software- Entwicklung Entwicklungs- phase Betriebs-/Wartungs-/Weiterentwicklungsphase Quelle: Andreas Rüping, Dokumentation in agilen Projekten, dpunkt.verlag
  15. 15. Beispiele Auf allen Ebenen: • Überblick • Benutzerhandbuch • Fachliche Architektur • Szenarien/ Use Cases • Tests, z.B. User Acceptance Tests • Nachweise • … • Designprinzipien • Schichtenmodell • Frameworks • Coding Guidelines • … • Technische Architektur • Schnittstellen • Tests z.B. funktionale Tests, Performance Tests • Nachweise • … • Code • Inline-Doku • Tests z.B. Unit Tests • Modelle –> Reverse Engineering • … Fachliche Doku System-Doku Design-Doku Code • Beweggründe • Optionen • Entscheidungen • Trade-Offs • Detail
  16. 16. Voraussetzungen Langfristige Produktverantwortung RE- Know How im Team Investition in Qualität • Automatisiertes Testen • Continuous Delivery • Refactoring Test-Know How Doku Know-How
  17. 17. Was kostet das? 20 Tage RE 100 Tage Entwicklung 20 Tage RE 5 Entwickler X 2 Sprints X 10 Tage = 100 Tage 1 RE X 2 Sprints X 10 Tage = 20 Tage Quelle: SwissQ Trends Benchmark 2014 Ø RE-Aufwand: 16-20%
  18. 18. Festes Team RE-Know How im Team Dokumentation statt Spezifikation Was noch?
  19. 19. Susanne.Muehlbauer@HOOD-Group.com Twitter: @susemuehlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.Agile-by-HOOD.com
  20. 20. Agilität erleben: Jeden Tag gemeinsam einen Mehrwert schaffen. Ein Umdenken beginnt, neue Ideen sind gesät und und ein mutiger Schritt ist gewagt. Seit mehr als 25 Jahren berät und unterstützt HOOD erfolgreich seine Kunden bei der Entwicklung komplexer Software und Systeme durch Requirements Engineering-Prinzipien. Mit der Marke Agile-by-HOOD bündelt HOOD das Angebot im agilen Umfeld und macht somit einen weiteren konsequenten Schritt zur zielgerichteten Unterstützung von Organisationen, die entweder bereits agil arbeiten oder sich vorgenommen haben, in Zukunft ihre Entwicklung auf Scrum, Kanban oder ähnliche Vorgehensweisen umzustellen. HOOD kann dabei auf langjährige Erfahrungen im Agile Coaching und fundierte Expertise im Requirements Engineering zurückgreifen, um große Unternehmen beim Umstieg von klassischer auf agile Vorgehensweise zu begleiten. Das Thema agil-skaliert ist uns ein besonderes Anliegen - wir verstehen auch die Entwicklung komplexer Produkte und Systeme mit vielen Teams und großen Organisationen. Agile-by-HOOD ist ein Angebot der HOOD GmbH

×