SlideShare ist ein Scribd-Unternehmen logo

Dokumentation in agilen Projekten - WebMontag Edition

Auch in agilen Projekten spielt die Dokumentation ein Rolle. Aber wie kann die Erstellung bedarfsgerecht passieren? Wer liest eigentlich die Dokumente und ist die Art und der Umfang für den Leserkreis geeignet? Braucht es neben der Definition of Ready und der Definition of Done noch eine Definition of agile Documentation?

1 von 71
Downloaden Sie, um offline zu lesen
Dokumentation in
agilen Projekten
Dokumentation in agilen Projekten - WebMontag Edition
https://giphy.com/gifs/yeah-awwwww-8g63zqQ5RPt60
Dokumentation in agilen Projekten - WebMontag Edition
https://giphy.com/gifs/yeah-awwwww-8g63zqQ5RPt60
Also doch
Dokumentation
aber warum?
–Robert Bruckbauer
„Eine User-Story kann Wissen zwar sehr effizient
vermitteln, aber das Wissen wird nicht in einer
nachhaltigen Form gespeichert.“
Agil hat die Art wie wir
Entwickeln zum positiven
verändert.
Dann lasst uns auch
Dokumentation
bedarfsgerecht machen.
Was wollen wir eigentlich
Dokumentieren?
Produktdokumentation
• Fokus auf das Softwareprodukt
• Alle Dokumente für Betrieb und Nutzung der
Software
• Anforderung an Umfang und Format durch
Auftraggeber
Systemdokumentation
• Fokus auf das Softwareprodukt - aber Innensicht
• Beschreibt, wie die Software funktioniert
• Hilft bei Entwicklung und Weiterentwicklung der
Software
Projektdokumentation
• Fokus auf das Projekt
• Dokumentiert und Unterstützt Projektfortschritt
• Liegt in der Verantwortung des Teams
Prozessdokumentation
• Wie gehen wir im Projekt vor
• Welche Prozesse liegen dem Projekt zugrunde
Und wie kriegen wir
das alles
Bedarfsgerecht?
Wer ließt das
eigentlich?
Ist das Dokument für diesen
Leserkreis geeignet?
Ist die Detailtiefe für den
Leserkreis geeignet?
Bietet das Dokument dem
Leserkreis den gewünschten
Nutzen?
Wer hätte einen Nachteil,
wenn wir das Dokument nicht
schreiben?
Ein Dokument das keiner
ließt brauche ich nicht
schreiben.
Was lohnt es sich
aufzuschreiben?
„Dokumentation ist wie guter
Rotwein, der Wert steigt mit
der Zeit…“
https://www.codecentric.de/publikation/optimale-systemdokumentation-mit-agilen-prinzipien/
Ein grober Überblick
Motivation, Begründung
und Alternativen von
Entscheidungen
https://giphy.com/gifs/oc-the-rachel-bilson-yhcqymRLlv7K8/
Tools ≠ Lösung
Word, Confluence, Jira,
Excel, JavaDoc, md,
HTML, LaTex,
AsciiDoc?
Nutze was für dein Team
passt.
Aber nutzt wenige Tools, mit
denen alle arbeiten können.
Egal, Hauptsache
du dokumentierst
es.
Wiki-Systeme
Für Projekt und Systemdokumentation
• Teamwork bei der Erstellung
• Struktur durch Verlinkung
• Formatierung
• Ablage von Dokumenten/Bildern/Diagrammen
• Suchfunktion
• Änderungshistorie / Versionsvergleich
Dokumentation in agilen Projekten - WebMontag Edition
Wann soll ich
eigentlich
dokumentieren?
Der richtige
Zeitpunkt ist:
anhängig vom Thema…
aber eigentlich immer
SO SPÄT WIE
MÖGLICH.
Dokumentation in agilen Projekten - WebMontag Edition
Was bedeutet
das jetzt?
Anforderungen müssen erst zu
dem Zeitpunkt beschrieben sein,
zu dem die Implementierung der
Funktionalität begonnen wird.
Aber das BIG PICTURE
muss allen am Anfang
des Projektes klar sein.
Wie verhindere ich
das ich den richtigen
Zeitpunkt verpasse?
Die Erstellung von
Dokumenten fließt als
Arbeitspaket mit in die
Sprints ein.
Dokumentationsaufgabe
• Welcher Vorraussetzungen müssen erfüllt sein um
die Aufgabe umzusetzen?
• Welcher Aufwand ist nötig / gerechtfertigt?
• Wer kann die Aufgabe übernehmen?
• Welche Priorität hat diese Aufgabe im Vergleich
mit anderen Aufgaben?
• Bis wann soll die Aufgabe abgeschlossen sein?
Dokumente, werden
wie Software
inkrementell erstellt.
Dokumentations-Inkrement
• Sukzessive Erweiterung der Dokumentation
• Passend zur Software werden neue Kapitel ergänzt
• Bei Bedarf werden bestehende Kapitel aktualisiert
https://media.giphy.com/media/cS83sLRzgVOeY/giphy.gif
Clean Code Developers
=
Clean Doc Developers?
Wir schreiben Text für Dokumente und
Epics bzw. Stories in der Sprache
unseres Kunden, wie wir
"Programmtexte" in Sprachen
schreiben, die Computersysteme
verstehen.
Wir wenden das Prinzip "Keep it
simple, stupid" der
Programmierer an, damit Inhalte
im Wiki nicht zu schnell
verderben.
Wir wenden das Prinzip "Don´t
Repeat Yourself" (DRY) der
Programmierer an, um die
Inhalte im Wiki weitestgehend
frei von Redundanzen zu halten.
Wir wenden die
Pfadfinderregel an und führen
Reviews durch, um die Qualität
unserer Dokumentation laufend
zu verbessern.
Wir nutzen das Prinzip
"Separation of Concerns"
(SoC), indem wir fachliche und
technische Belange klar von
einander trennen.
Genauso wichtig wie "Source Code Conventions" für
Code, sind die Regeln und Vorlagen zur Erstellung
von Inhalten im Wiki.
Wir definieren klare Regeln für den Aufbau jedes
Artefaktes.
Wir unterstützen die Autoren durch Vorlagen für jedes
Artefakt.
Handbücher unterliegen teilweise noch strengeren
Richtlinien.
Das Prinzip des "Single Level of
Abstraction" (SLA) fördert wie bei Code die
Lesbarkeit von Inhalten im Wiki.
Autoren können sich auf eine konkrete
Aufgabenstellung konzentrieren.
Reviewer können Inhalte effizienter prüfen.
Was sollte ich mir bis
jetzt gemerkt haben?
BIG PICTURE
Mehr als
Lösungen
Nachvollziehbar!
Sei besser lesbar
Beipackzettel
Ein Diagramm sagt
mehr als tausend Worte
Tabellen können Informationen systematisch
und übersichtlich Präsentieren
Beispielsweise
Key-Value
Paare
Vor und
Nachteile
Produktvergleic
he
Abfolgen von
Handlungen
aber sie sind kein Ersatz
für Fließtext helfen aber in vielen Fällen
DOAD
Definition of agile Documentation
• Wir sichern Wissen auf lange Zeit mit hoher Qualität.
• Wir beschränken uns auf das Wesentliche und
Notwendige.
• Wir dokumentieren die Ergebnisse von Diskussionen.
• Wir vermeiden persönliche Arbeitsunterlagen!
• Wir definieren Grenzen: Was muss sein, was brauchen wir
nicht.
• Wir unterscheiden flüchtige und dauerhafte Informationen.
Definition of agile Documentation
• Wir vermitteln ein "Big Picture" für alle Zielgruppen.
• Wir etablieren eine gemeinsame Sprache im
Projekt.
• Wir pflegen von Anfang an ein Glossar.
• Wir pflegen externe Quellen in einer Linksammlung.
• Wir legen einen allen im Team bekannten Weg zum
Erfassen von Inhalten fest.
Definition of agile Documentation
• Jede Information ist dort, wo sie sein soll – und nur dort!
• Wir verbessern uns laufend.
• Wir sind flexibel bei Änderungen an der Vision des
Produktes.
• Wir zerlegen die Aufgaben im Projekt in "handliche
Portionen".
• Wir sind robust im Zusammenhang mit nicht-
funktionalen Anforderungen.
Literaturtipps und Quellen
• Dokumentation in agilen
Projekten - Andreas Rüping
• Agile Dokumentation für
Stakeholder und
Projektmitarbeiter - Robert
Bruckbauer
• http://agilere.org/
https://giphy.com/gifs/school-travel-bill-f46qTLldcwMi4
simon
krackrügge
anforderungsmanager,
product owner
@micromata
https://twitter.com/Kdotde

Recomendados

DevOps day - feature teams
DevOps day  - feature teamsDevOps day  - feature teams
DevOps day - feature teamsWalter Strametz
 
Continuous Everything
Continuous EverythingContinuous Everything
Continuous Everythingcusy GmbH
 
Quo vadis DevOps
Quo vadis DevOpsQuo vadis DevOps
Quo vadis DevOpscusy GmbH
 
Cusy Developer-Baukasten
Cusy Developer-BaukastenCusy Developer-Baukasten
Cusy Developer-Baukastencusy GmbH
 
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...Nico Meisenzahl
 
Virtuelle Konferenzen | Digital Konferenz mit dexp.one
Virtuelle Konferenzen | Digital Konferenz mit dexp.oneVirtuelle Konferenzen | Digital Konferenz mit dexp.one
Virtuelle Konferenzen | Digital Konferenz mit dexp.oneKlaus Motoki Tonn
 
Devops ohne root
Devops ohne rootDevops ohne root
Devops ohne rootcusy GmbH
 

Más contenido relacionado

Was ist angesagt?

Das Kung Fu des Code Reviews
Das Kung Fu des Code ReviewsDas Kung Fu des Code Reviews
Das Kung Fu des Code ReviewsChristian Erhardt
 
Warum gRPC? – und wie in Python implementieren?
Warum gRPC? – und wie in Python implementieren?Warum gRPC? – und wie in Python implementieren?
Warum gRPC? – und wie in Python implementieren?cusy GmbH
 
DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?Digicomp Academy AG
 
TWT One Pager – Google Apps
TWT One Pager – Google AppsTWT One Pager – Google Apps
TWT One Pager – Google AppsTWT
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
Scrum live erleben // ADC Frankenthal
Scrum live erleben // ADC FrankenthalScrum live erleben // ADC Frankenthal
Scrum live erleben // ADC FrankenthalHolger Wendel
 
Scrum live erleben // ADC Wien
Scrum live erleben // ADC WienScrum live erleben // ADC Wien
Scrum live erleben // ADC WienHolger Wendel
 

Was ist angesagt? (8)

Das Kung Fu des Code Reviews
Das Kung Fu des Code ReviewsDas Kung Fu des Code Reviews
Das Kung Fu des Code Reviews
 
Warum gRPC? – und wie in Python implementieren?
Warum gRPC? – und wie in Python implementieren?Warum gRPC? – und wie in Python implementieren?
Warum gRPC? – und wie in Python implementieren?
 
DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?
 
Google apps (1)
Google apps (1)Google apps (1)
Google apps (1)
 
TWT One Pager – Google Apps
TWT One Pager – Google AppsTWT One Pager – Google Apps
TWT One Pager – Google Apps
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Scrum live erleben // ADC Frankenthal
Scrum live erleben // ADC FrankenthalScrum live erleben // ADC Frankenthal
Scrum live erleben // ADC Frankenthal
 
Scrum live erleben // ADC Wien
Scrum live erleben // ADC WienScrum live erleben // ADC Wien
Scrum live erleben // ADC Wien
 

Ähnlich wie Dokumentation in agilen Projekten - WebMontag Edition

Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklungrico.fritzsche
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Renate Pinggera
 
Mach Deinen Nutzer happy! Usability und UX
Mach Deinen Nutzer happy! Usability und UXMach Deinen Nutzer happy! Usability und UX
Mach Deinen Nutzer happy! Usability und UXAstrid Beck
 
Infogem vortrag pohle_v1
Infogem vortrag pohle_v1Infogem vortrag pohle_v1
Infogem vortrag pohle_v1Matthias Pohle
 
Erfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMUErfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMUMartin Koser
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!JanWeinschenker
 
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AG
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AGCCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AG
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AGCommunardo GmbH
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECChristian Seedig
 
Responsive Content Experience
Responsive Content ExperienceResponsive Content Experience
Responsive Content ExperiencePeter Rozek
 
Remote leadership in Krisenzeiten #3
Remote leadership in Krisenzeiten #3Remote leadership in Krisenzeiten #3
Remote leadership in Krisenzeiten #3ChristianeBernecker
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ MigrosJoël Krapf
 
Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013superflomo
 
Agile und Projektmanagement - Kein entweder-oder sondern anders
Agile und Projektmanagement - Kein entweder-oder sondern andersAgile und Projektmanagement - Kein entweder-oder sondern anders
Agile und Projektmanagement - Kein entweder-oder sondern andersSteffen Thols
 
New Work & Virtuelle Zusammenarbeit
New Work & Virtuelle ZusammenarbeitNew Work & Virtuelle Zusammenarbeit
New Work & Virtuelle ZusammenarbeitMarc Wagner
 
Bernhard Wick - appserver.io - code.talks 2015
 Bernhard Wick - appserver.io - code.talks 2015 Bernhard Wick - appserver.io - code.talks 2015
Bernhard Wick - appserver.io - code.talks 2015AboutYouGmbH
 
Config as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as CodeConfig as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as CodeDevOps Meetup Bern
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?HOOD Group
 
Onno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenOnno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenlernet
 
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections WebinarreiheIBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections WebinarreiheBeck et al. GmbH
 

Ähnlich wie Dokumentation in agilen Projekten - WebMontag Edition (20)

Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklung
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
 
Lean Collaboration
Lean CollaborationLean Collaboration
Lean Collaboration
 
Mach Deinen Nutzer happy! Usability und UX
Mach Deinen Nutzer happy! Usability und UXMach Deinen Nutzer happy! Usability und UX
Mach Deinen Nutzer happy! Usability und UX
 
Infogem vortrag pohle_v1
Infogem vortrag pohle_v1Infogem vortrag pohle_v1
Infogem vortrag pohle_v1
 
Erfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMUErfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMU
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!
 
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AG
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AGCCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AG
CCD 2012: Wissensmanagement @MPS - Sören Krasel, Daimler AG
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
 
Responsive Content Experience
Responsive Content ExperienceResponsive Content Experience
Responsive Content Experience
 
Remote leadership in Krisenzeiten #3
Remote leadership in Krisenzeiten #3Remote leadership in Krisenzeiten #3
Remote leadership in Krisenzeiten #3
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ Migros
 
Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013
 
Agile und Projektmanagement - Kein entweder-oder sondern anders
Agile und Projektmanagement - Kein entweder-oder sondern andersAgile und Projektmanagement - Kein entweder-oder sondern anders
Agile und Projektmanagement - Kein entweder-oder sondern anders
 
New Work & Virtuelle Zusammenarbeit
New Work & Virtuelle ZusammenarbeitNew Work & Virtuelle Zusammenarbeit
New Work & Virtuelle Zusammenarbeit
 
Bernhard Wick - appserver.io - code.talks 2015
 Bernhard Wick - appserver.io - code.talks 2015 Bernhard Wick - appserver.io - code.talks 2015
Bernhard Wick - appserver.io - code.talks 2015
 
Config as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as CodeConfig as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as Code
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Onno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenOnno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellen
 
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections WebinarreiheIBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
 

Dokumentation in agilen Projekten - WebMontag Edition

Hinweis der Redaktion

  1. Die letzte Session am Abend und dann auch noch mit Dokumentation im Titel - und ihr seid trotzdem hie geblieben. Danke
  2. Funktionierende Software mehr als umfassende Dokumentation. Viele Entwickler lesen das und..
  3. Die Party geht los. Coders gone Code. Endlich wieder nur Softwareentwickler statt Tippse. Und dieser Gedanke hat sich auch bei vielen Festgesetzt. Agil braucht keine Dokumentation Schaut man sich das Agile Manifest genauer an steht da am Ende noch ein Satz.
  4. Hmm. Die Werte auf der rechten Seite sind also auch wichtig und gehören dazu.
  5. Die Party geht los. Coders gone Code. Endlich wieder nur Softwareentwickler statt Tippse. Warum finden das alle so großartig. Entwicklung in den 90ern hieß oft. Schwergewichtig. Lange Zyklen. Die Rechner waren langsamer. Bauen und kompilieren - Time 4 Coffee Und dieser Gedanke hat sich auch bei vielen Festgesetzt. Agil braucht keine Dokumentation Schaut man sich das Agile Manifest genauer an steht da am Ende noch ein Satz.
  6. Agil ist doch 1 zu 1 und direkt Fragen klären. UND wir haben User Stories
  7. Warum ist das so. Beim arbeiten mit einem physischen ScrumBoard steht am ende ein Mülleimer und da wandern die Zettel rein.
  8. Die Teams tauschen untereinander Wissen aus Wir erkennen Probleme und Missstände viel schneller Wir sind in der Lage auf Veränderungen zu reagieren und können Bedarfsgerechte Software entwicklen.
  9. Wir werden uns anhand von Fragen durch die Themengebiete der agilen Dokumentation tasten.
  10. Was gibt es alles für Dokumentationstypen in Softwareprojekten - auch in agilen.
  11. Produktdokumentation ist, wie der Name schon sagt ein Teil des Produktes. In Kunden Projekten ist Format und Inhalt oft vorgegeben und die Lieferung ist Teil des Vertrags. Nutzungshandbuch, Installationshandbuch, Betriebshandbuch, Servicehandbuch und z.B. Online-Hilfe Auch für unsere eigenen Produkte wie ProjectForge, Baumeister etc. gibt es diese Dokumente, in von uns gewählter Form
  12. Architekturentscheidung, Code Kommentare, Softwaredesign, Datenmodell Hier ist das Team im Fokus und auch die Form der Dokumentation liegt meist in unserer Hand.
  13. UserStories, Backlog, Epic Jira und das Team Confluence sind alles Teil der Projektdokumentation.   Glossar, Use-Cases, Testfälle, Leistungsbeschreibung Hier ist klar was das Projekt macht.
  14. Die Prozessdokumentation beschriebt wie das Team etwas macht. DOR und DOD.  Arbeitsweisen Richtlinien Freigaben und Workflows. Workflow mit GIT, Jenkins unsw.- Wann wird ein Branch erstellt etc. alles Teil der Prozessdokumentation
  15. Das ist ja doch ganz schön viel an Dokumentation. Fang und frag dich..
  16. Als erstes schauen wir - Wer ist der Leserkreis dieses Dokumentes. Und wenn es nicht jetzt gelesen wird, Wer wird es vielleicht in Zukunft lesen.
  17. Der Fachbereich braucht andere Information als die IT. Ein Entwickler braucht andere Informationen als ein Supportmitarbeiter der Hotline
  18. Details können den Nutzer erschlagen oder das Dokument für die Arbeit erst hilfreich machen.
  19. Manchmal ist der Nutzen auch nur das „haben, weil es der Prozess erfordert.“ Und ganz wichtig.
  20. Wenn wir diese Fragen nicht genau Beantworten können, sollten wir über das Dokument nochmal nachdenken. Denn
  21. Es sei den es ist Teil meiner Beauftragung und ich werde dafür bezahlt. Aber auch dann kann ich bei der Detailtiefe und dem Aufwand genau schauen das er im Rahmen bleibt.
  22. Alles was heute oder morgen einen Nutzen hat.
  23. .. und von zu viel bekommt man einen dicken Kopf.
  24. Wir entwickeln und betreiben Projekte mit unseren Partnern und Kunden die oft einen langen Lebenszyklus haben und über einen langen Zeitraum weiterentwickelt werden. Das was ich heute gut Dokumentiere hat vielleicht erst einen Wert, wenn ich selbst schon nicht mehr im Team bin. Also was lohnt sich immer?
  25. Auch über die Funktion einzelner Features - Erlaubt auch nach Monaten und Jahren einen schnellen Zugang zum Projekt und erleichtert den Einstieg.
  26. Warum haben wir das damals so gemacht? Was wären unsere Alternativen Überlegungen? Fachliche und technische Architektur können Auge zu Auge besprochen werden - aber das Ergebnis muss für die Nachwelt dokumentiert werden
  27. Mit welchen Tools dokumentier ich am besten?
  28. Ein Tool kann dich unterstützen, aber kann nicht die Arbeit für dich erledigen.
  29. Wir können heute aus einer Vielzahl von Tools auswählen und wenn wir über den Zaun schauen finden wir da draußen auch Tools bei denen das Gras noch viel Grüner ist und wo der Kerl im YouTube Video eigentlich gar nichts mehr macht und es kommt eine super Dokumentation raus. Aber ein Ferrari ohne Fahrer ist das gleiche Verkehrshindernis wie ein Golf ohne Fahrer. Wichtig ist das Ihr damit arbeitet.
  30. Als Faustregel für die Bewertung gilt:
  31. Als kleiner Praxistipp: Nutzt Confluence - und nutzt die Möglichkeiten von Confluence
  32. Warum? Schauen wir wieder ins agile Manifest.
  33. Dafür haben die Definition of Ready als Quality Gate für den Einzug einer Anforderungen in den Sprint. Die wir als Teil der Prozessdokumenttation erstellt haben bevor Sie gebraucht wird. Um mit der Implementierung zu beginnen muss die Anforderung bewertet und der DOR entsprechen.
  34. Die Produktvision steht am Anfang der Entwicklung und sollte auch allen im Team klar sein. Nur so sind alle im Team in der Lage auch Feedback auf Anforderungen zu geben, die evtl. diese Vision nicht unterstützten - Stichwort Bedarfsgerecht.
  35. Bei den einzelnen Aufgaben ist das klar - die müssen ja zur Entwicklung den Sprung vom Backlog ins Speintlog schaffen. Aber wie ist das z.B. mit der Produktdokumentation
  36. Und wenn ich eine Dokumentation als Arbeitspaket plane stellen sich einige Fragen.
  37. Folie lesen Und wir sind ja Agil - also ..
  38. Wer zu lange wartet mit der Dokumentation wird am Ende von einer Welle überrollt.
  39. Lasst uns mal schauen, welche Werte und Prinzipien der Clean Code Bewegung wir für Dokumentation nutzen und adaptieren können.
  40. Dabei hilft z.B. ein Glossar für ein einheitliches Verständnis
  41. Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert. und erschwert die spätere Änderung
  42. Jede Doppelung von Code oder auch nur Handgriffen leistet Inkonsistenzen und Fehlern Vorschub. Das Prinzip motiviert uns auch, Stichworte und Begriffsdefinitionen in einem Glossar zu verwenden.
  43. Wer kennt die Pfadfinderregel? Hinterlasse den Rastplatz immer sauberer als er bei deiner Ankunft war.
  44. Wenn eine Codeeinheit keine klare Aufgabe hat ist es schwer sie zu verstehen, sie anzuwenden und sie ggf. zu korrigieren oder zu erweitern. Epic, und User Story dienen ausschließlich der fachlichen Beschreibung. Layouts verwenden wir nur für die Spezifikation der Benutzeroberfläche (Zielgruppe Entwickler). Das Benutzerhandbuch (Zielgruppen Tester und User) verwenden wir nur für die Beschreibung der Verwendung der Benutzeroberfläche. Das Betriebshandbuch (Zielgruppen Tester und Operatoren) nutzen wir nur für die technischen Aspekte der Software.
  45. Code wird häufiger gelesen als geschrieben. Daher sind Konventionen wichtig, die ein schnelles Lesen und Erfassen des Codes unterstützen.
  46. Die Einhaltung eines Abstraktionsniveaus fördert die Lesbarkeit. Damit Dokumentation gut zu lesen und zu verstehen ist, sollte in einer Beschreibung/Format nur ein Abstraktionsniveau verwendet werden. Andernfalls fällt es dem Leser schwer, Essentielles von Details zu unterscheiden. Wenn Detailauseinandersetzungen erforderlich sind, sollten diese nicht mit dem groben Überblick einer Funktion vermischt werden.
  47. Ich muss nicht alles dokumentieren was ich weiß. Was würde du einen neuen Teammitglied an den ersten beiden Tagen erzählen um ihn einen guten Start in das Projekt zu ermöglichen.
  48. Der Nutzen der Systemspezifikation steigt enorm, wenn nicht nur Entscheidungen / das gewählte Konzept beschrieben wird, sondern auch kurz die Alternativen betrachtet werden und die Gründe, die für die Entscheidung ausschlaggebend waren. In 2 Jahren weiß keiner mehr, warum das damals so entschieden wurde und die Reise geht evtl. neu los.
  49. Schreib ein Drehbuch. Erstell eine Schritt für Schritt Anleitung der Installation. Für Nutzenfälle. Für das Aufsetzen der eigenen Entwicklungsumgebung.
  50. Du schreibst lesbaren Code und hast einen hast einen konsistenten Code-Style. - warum dann ein unstrukturiertes Dokument? Nutze Kapitel, Unterkapitel. Fettdruck und Kursiv. Kurzfassungen und Absätze im Highlight fördern das Querlesen und das leichtere Finden von Informationen.
  51. Für Wenn ist das Dokument. Welchen Zweck hat das Dokument. Ein kurzes Wer bin ich reicht um zu verhindern das der Fachbereich das Klassenmodell in die Hand nimmt und..
  52. Der gezielte Einsatz von Diagrammen erhöht das Verständnis deutlich. Aber der Aufwand der Erstellung ist hoch und nur gerechtfertigt wenn auch ein Mehrwert entsteht. UML, GUI Skizzen Screenshots
  53. Tabellen können helfen - müssen aber nicht.
  54. Wir haben Definition of Ready und Definition of Done - lasst uns auch eine Definition of agile Documentation für uns erstellen.