Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Agil dokumentieren für Stakeholder und Projektmitarbeiter

4.794 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
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

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

×