AGIL
DOKUMENTIEREN
MIT CARDS+
Agil?
DREI
Schritte für
agiles RE.
FÜNF
Schritte für
SCRUM.
Wir sind agil, weil wir Wissen
erfassen, wann es entsteht, von den
Personen, die es erarbeiten.
Wir sind agil, weil wir uns
laufend verbessern und
voneinander lernen.
Scrum
Agiles RE
24h
2-4w
+Epic
+Case
+Layout
+Service
+Decision
+Code
+Test
+Epic
+Case
Bewertung
Validierung
Backlog
+Top...
Wir begrüßen Veränderungen.
Darum ist Dokumentieren eine
Aufgabe des ganzen Teams.
Einfach?
Wir verwenden ein Wiki, eine
klare Struktur.
Systembeschreibung
Architektur-
entscheidungen
Architektur-
komponenten
Glossar+Fachklassen
Die konsequente Pflege eines
Glossar hilft uns, eine
gemeinsame Sprache
zu entwickeln, von Stakeholdern,
für Projektmitarb...
Wir nutzen Begriffe aus dem
Glossar als Stichworte, um
beliebige Zusammenhänge
zwischen den Bausteinen
herzustellen.
Wir verwenden für die
Systembeschreibung nur
wenige klar definierte Bausteine:
Topic, Epic, Case und Layout.
DialogWindow Panel
Topic Glossar
Epic
CaseLayout
Systembeschreibung
Wir verwenden für die
Dokumentation jeder wichtigen
Entscheidung einen
definierten Baustein: Decision.
Wir verwenden für die
Systemkomponenten nur
wenige klar definierte Bausteine:
Domain, Service, Entity und Event.
Domain
Architekturdefintion
Service Entity Event
Decision
Prüfbar?
Wir wollen Feedback zu jeder
Zeit, von jedem Projektmitarbeiter.
Wir nutzen Reviews, um Fehler
in der Dokumentation frühzeitig zu
finden.
Feedback
Disziplin
Motivation
Leichtigkeit
Stichworte
Suchen
Markup
Review
Wir beschränken uns auf das
Notwendige. Aber das tun wir
in hoher Qualität.
Die Produktdokumentation
ist wie Code am Ende eines
Sprints „fertig“.
Wertvoll?
Software
Wissen
Werte
In der agilen Methode
wird ständig nach
dem Wert gefragt.
Das Manifest für agile
Softwareentwicklung...
Wir unterscheiden ganz klar
zwischen Projekt- und
Produktdokumentation.
Änderungskonzept?
Schätzung?
UML
Diagramm?
Komponenten-
spezifikation?
Nur die
Produktdokumentation
pflegen wir nachhaltig.
Verdorbene Dokumente sind
wie toter Code. Sie
verwirren uns, führen zu
Fehleinschätzungen.
Sauber?
Eine saubere
Produktdokumentation enthält nur
gültige Dokumente.
Saubere
Produktdokumentation
Die Hemmschwelle für
Änderungen muss so gering
wie möglich sein.
Wir nutzen das Feedback aller
Projektmitarbeiter für die
kontinuierliche
Verbesserung der
Dokumentation.
Wir nutzen ein Review von
Experten für die gezielte
Verbesserung der
Dokumentation.
Änderungen an den
Dokumenten müssen für jeden
nachvollziehbar sein.
Abgrenzung
In der
Sprache der
Stakeholder
Big
Picture Vision
Ein Topic beschreibt ein
Geschäftsfeld des Unternehmens,
in dem die Software eine Rolle
spielt. Es vermittelt dem Projekt
...
Ein Topic dokumentiert die
ursprüngliche Idee der Stakeholder
beim Start des Projektes. Es hilft bei
der Abgrenzungzu ande...
Ein Topic vermittelt die
Motivation und die Ziele der
Stakeholder. Es gibt dem Projekt
eine Vision.
Ein Topic bündelt eine laufend
wachsende Menge von Epics.
Ergebnis der
Anforderungs-
analyse
In der Sprache
der NutzerBig
Story
Ein Epic ist ein Ergebnis der
agilen Anforderungsanalyse.
Ein Epic beantwortet die Fragen:
 Wer sind die Nutzer?
 Warum benötigen Nutzer es?
 Wann verwenden Nutzer es?
In einem Epic nutzen wir Bilder
und Diagramme, um den fachlichen
Sachverhalt einer Anforderung
„begreifbar“ zu machen.
Ein Epic bündelt eine laufend
wachsende Menge von Cases.
In der Sprache
der Nutzer
User
Story Lösung als
Übergang in
die Technik
Ein Case ist ein Ergebnis der
agilen Anforderungsanalyse.
Ein Case enthält das Wissen der
Nutzer über einen konkreten
Anwendungsfall einer
Anforderung.
Einen Case erstellen wir während
der Entwicklung, wenn das Team
einen Sonderfall entdeckt,
den wir berücksichtigen.
Einen Case nutzen wir auch zur
Beschreibung einer Situation
ohne Lösung. Wir
dokumentieren in diesem Fall die
Entscheidung.
Ein Case ist Grundlage für die
Realisierung. Ein Case hilft beim
Entwurf, die Lösung befindet sich
aber im Code.
Der Code ist wesentlicher Teil der
Produktdokumentation.
Wir habe darum hohe Ansprüche an
die Lesbarkeit von Code.
CARDS+
Feste Struktur
Produktwissen
Hohe Qualität
Freie Struktur
Viel Wissen
Große Vielfalt
ist der Versuch, mit einer festen
Struktur und bewährten Prinzipien und
Praktiken Effizienz und Qualität in
eine Produktdo...
DIE
METHODE
CARDS+
REALWORLDSCRUM.DE
Agil dokumentieren für Stakeholder und Projektmitarbeiter
Nächste SlideShare
Wird geladen in …5
×

Agil dokumentieren für Stakeholder und Projektmitarbeiter

4.333 Aufrufe

Veröffentlicht am

Die Methode CARDS+ ist der Versuch, mit einer festen Struktur und Prinzipien und Praktiken der Entwickler Effizienz und Qualität in die Erstellung und Pflege einer Produktdokumentation zu bringen. CARDS+ definiert keinen eigenen Prozess, sondern verbindet Prozesse für Anforderungsanalyse und agile Entwicklung, um wertvolles Produktwissen während der Durchführung eines Projekts direkt von den Wissensträgern einzusammeln und als Produktdokumentation in einem Wiki zur Verfügung zu stellen. CARDS+ gibt eine sehr einfache Struktur für eine Produktdokumentation vor. Ein Glossar ist zentraler Bestandteil. Die Systembeschreibung (fachliche Entscheidungen, funktionale Anforderungen) besteht aus den Bausteinen Topic/Feature/Case und Layout. Die Architekturdefinition (technische Entscheidungen, nicht-funktionale Anforderungen) besteht aus den Bausteinen Decision und Domain mit Service/Event/Entity.

http://realworldscrum.de/cards-auf-einer-seite/ soll die Idee sehr kompakt vermitteln. Das geht halt nicht ohne Buzzwords. Dafür passt der Inhalt doppelseitig gedruckt auf ein Blatt Papier.

http://realworldscrum.de/cards-auf-einen-blick/ geht schon etwas tiefer, so mit Bild und schrittweiser Erklärung der Idee.

http://realworldscrum.de/category/real-world-scrum/cards/bilderbuch/ ist eine Artikelserie, die auf viele verschiedene Aspekte gezielt und noch etwas detaillierter eingeht.

http://realworldscrum.de/cards/ ist ein komplettes Inhaltsverzeichnis der Artikel des Blogs, aufgeteilt nach Themen.

https://www.xing.com/communities/groups/agil-dokumentieren-2ec4-1084817 ist eine moderierte Gruppe auf XING zur Diskussion von CARDS+ und agiler Dokumentation.

https://plus.google.com/collection/okNA2 ist eine Sammlung auf Google+ zur Diskussion von CARDS+ und agiler Dokumentation.

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

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.333
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
306
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Agil dokumentieren für Stakeholder und Projektmitarbeiter

  1. 1. AGIL DOKUMENTIEREN MIT CARDS+
  2. 2. Agil?
  3. 3. DREI Schritte für agiles RE.
  4. 4. FÜNF Schritte für SCRUM.
  5. 5. Wir sind agil, weil wir Wissen erfassen, wann es entsteht, von den Personen, die es erarbeiten.
  6. 6. Wir sind agil, weil wir uns laufend verbessern und voneinander lernen.
  7. 7. Scrum Agiles RE 24h 2-4w +Epic +Case +Layout +Service +Decision +Code +Test +Epic +Case Bewertung Validierung Backlog +Topic +Topic +Epic +Epic +Case +Layout Refinement Review Planning +Epic +Case +Layout +Service +Decision 2-4w
  8. 8. Wir begrüßen Veränderungen. Darum ist Dokumentieren eine Aufgabe des ganzen Teams.
  9. 9. Einfach?
  10. 10. Wir verwenden ein Wiki, eine klare Struktur.
  11. 11. Systembeschreibung Architektur- entscheidungen Architektur- komponenten Glossar+Fachklassen
  12. 12. Die konsequente Pflege eines Glossar hilft uns, eine gemeinsame Sprache zu entwickeln, von Stakeholdern, für Projektmitarbeiter.
  13. 13. Wir nutzen Begriffe aus dem Glossar als Stichworte, um beliebige Zusammenhänge zwischen den Bausteinen herzustellen.
  14. 14. Wir verwenden für die Systembeschreibung nur wenige klar definierte Bausteine: Topic, Epic, Case und Layout.
  15. 15. DialogWindow Panel Topic Glossar Epic CaseLayout Systembeschreibung
  16. 16. Wir verwenden für die Dokumentation jeder wichtigen Entscheidung einen definierten Baustein: Decision.
  17. 17. Wir verwenden für die Systemkomponenten nur wenige klar definierte Bausteine: Domain, Service, Entity und Event.
  18. 18. Domain Architekturdefintion Service Entity Event Decision
  19. 19. Prüfbar?
  20. 20. Wir wollen Feedback zu jeder Zeit, von jedem Projektmitarbeiter.
  21. 21. Wir nutzen Reviews, um Fehler in der Dokumentation frühzeitig zu finden.
  22. 22. Feedback Disziplin Motivation Leichtigkeit Stichworte Suchen Markup Review
  23. 23. Wir beschränken uns auf das Notwendige. Aber das tun wir in hoher Qualität.
  24. 24. Die Produktdokumentation ist wie Code am Ende eines Sprints „fertig“.
  25. 25. Wertvoll?
  26. 26. Software Wissen Werte In der agilen Methode wird ständig nach dem Wert gefragt. Das Manifest für agile Softwareentwicklung legt in Punkt 2 den Fokus auf eine funktionierende Software. Eine funktionierende Software liegt vor, wenn die geforderte Produktdokumentation vollständig ist.
  27. 27. Wir unterscheiden ganz klar zwischen Projekt- und Produktdokumentation.
  28. 28. Änderungskonzept? Schätzung? UML Diagramm? Komponenten- spezifikation?
  29. 29. Nur die Produktdokumentation pflegen wir nachhaltig.
  30. 30. Verdorbene Dokumente sind wie toter Code. Sie verwirren uns, führen zu Fehleinschätzungen.
  31. 31. Sauber?
  32. 32. Eine saubere Produktdokumentation enthält nur gültige Dokumente.
  33. 33. Saubere Produktdokumentation
  34. 34. Die Hemmschwelle für Änderungen muss so gering wie möglich sein.
  35. 35. Wir nutzen das Feedback aller Projektmitarbeiter für die kontinuierliche Verbesserung der Dokumentation.
  36. 36. Wir nutzen ein Review von Experten für die gezielte Verbesserung der Dokumentation.
  37. 37. Änderungen an den Dokumenten müssen für jeden nachvollziehbar sein.
  38. 38. Abgrenzung In der Sprache der Stakeholder Big Picture Vision
  39. 39. Ein Topic beschreibt ein Geschäftsfeld des Unternehmens, in dem die Software eine Rolle spielt. Es vermittelt dem Projekt das Big Picture.
  40. 40. Ein Topic dokumentiert die ursprüngliche Idee der Stakeholder beim Start des Projektes. Es hilft bei der Abgrenzungzu anderen Projekten.
  41. 41. Ein Topic vermittelt die Motivation und die Ziele der Stakeholder. Es gibt dem Projekt eine Vision.
  42. 42. Ein Topic bündelt eine laufend wachsende Menge von Epics.
  43. 43. Ergebnis der Anforderungs- analyse In der Sprache der NutzerBig Story
  44. 44. Ein Epic ist ein Ergebnis der agilen Anforderungsanalyse.
  45. 45. Ein Epic beantwortet die Fragen:  Wer sind die Nutzer?  Warum benötigen Nutzer es?  Wann verwenden Nutzer es?
  46. 46. In einem Epic nutzen wir Bilder und Diagramme, um den fachlichen Sachverhalt einer Anforderung „begreifbar“ zu machen.
  47. 47. Ein Epic bündelt eine laufend wachsende Menge von Cases.
  48. 48. In der Sprache der Nutzer User Story Lösung als Übergang in die Technik
  49. 49. Ein Case ist ein Ergebnis der agilen Anforderungsanalyse.
  50. 50. Ein Case enthält das Wissen der Nutzer über einen konkreten Anwendungsfall einer Anforderung.
  51. 51. Einen Case erstellen wir während der Entwicklung, wenn das Team einen Sonderfall entdeckt, den wir berücksichtigen.
  52. 52. Einen Case nutzen wir auch zur Beschreibung einer Situation ohne Lösung. Wir dokumentieren in diesem Fall die Entscheidung.
  53. 53. Ein Case ist Grundlage für die Realisierung. Ein Case hilft beim Entwurf, die Lösung befindet sich aber im Code.
  54. 54. Der Code ist wesentlicher Teil der Produktdokumentation. Wir habe darum hohe Ansprüche an die Lesbarkeit von Code.
  55. 55. CARDS+ Feste Struktur Produktwissen Hohe Qualität Freie Struktur Viel Wissen Große Vielfalt
  56. 56. ist der Versuch, mit einer festen Struktur und bewährten Prinzipien und Praktiken Effizienz und Qualität in eine Produktdokumentation zu bringen.
  57. 57. DIE METHODE CARDS+ REALWORLDSCRUM.DE

×