Herzlich willkommen DevDay Zürich 2016

Größe: px

Ab Seite anzeigen:

Download "Herzlich willkommen DevDay Zürich 2016"

Nele Böhm
vor 7 Jahren
Abrufe

1 Herzlich willkommen DevDay Zürich

2 2 Von einem der auszog, das Dokumentieren zu lernen Es war einmal Wir wollen zusammen eine neue Fabrik! Baut uns eine!

3 3 Wir müssen etwas bauen. Kannst Du das für uns ausführen? Wir wollen es selber weiter ausbauen können. Geht das? Klar! Kein Problem!

4 4 Dokumentation eines Projekts DIN 69901, ordentliche Projektdokumentation: «Eine Zusammenstellung ausgewählter, wesentlicher Daten über Konfiguration, Organisation, Mitteleinsatz, Lösungswege, Ablauf und erreichte Ziele des Projekts» Wie jetzt? Geht das bitte etwas genauer Wer erstellt sie und was ist der Leserkreis? Wie ist sie zusammengestellt und was sind die Mittel? In welchem Bereich entstehen damit wie viele Aufwände? Was sind Qualitätsaspekte? Kosten?

5 5 «Wildwuchs» an Dokumenten ist keine Dokumentation Storybook Vision Grobkonzept Konzept Angebot Pflichtenheft Legal CI/CD «Kleinkonzept» Kochbuch Detailkonzept «Kleindoku» Styleguide Funktionsübersicht Template Abnahmeprotokoll Vertrag Lastenheft Projektorganisation Spezifikation Projektplan CR Testplan Epic Entwicklerleitfaden Traktandenliste Story Sitzungsprotokoll Testbericht Beschluss Projektstatusbericht Architekturdokument Textkonserven Unterhalt und Überwachung Infrastrukturdokument Schulungsunterlagen

6 6 Weshalb Dokumente nicht erstellt werden Code ist Dokumentation (CleanCode: Code erzählt Geschichte) Tests sind Dokumentation Javadoc ist Dokumentation Wir arbeiten agil und schätzen lauffähigen Code höher als Dokumentation Keine Lust Anderes ist dringender Nicht wissen, wie (eher Realität als Ausrede)

7 7 «Populäre» Werkzeuge und Hilfsmittel Visio PowerPoint Excel Word Enterprise Architect GIT SVN Wiki Jira SharePoint Fileablage Dokument Management System

8 8 Notationen, Diagramme und Methodik RUP UML Archimate BPMN Use Case Wasserfall Klassendiagramm Fliesstext Activity AGILE Sequenzdiagramm Requirement-Diagramm ERD Balanced Score Card Artefakt Timing Deployment HERMES

9 9 Organisation führt zu Dokumentation «Hilfe, ich will doch nicht in allen Dokumenten suchen gehen» Und nochmals zurück weshalb erstelle ich die Dokumente Sie ist Mittel zum Zweck Sie ist auf ein bestimmtes Zielpublikum ausgelegt Sie hat das Ziel, bestimmte Informationen zu vermitteln Sehr oft gehöre ich direkt zum Zielpublikum Wie ordne ich Dokumente Wie werden meine Dokumente gefunden

10 10 Ziele und Zielpublikum Ein Dokument vermittelt Wissen. Um welches Wissen es sich handelt und auf wen es abzielt, sollte am Anfang feststehen Die Voraussetzungen zum Leserkreis sollten kurz erwähnt werden Es sollte darauf geachtet werden, auf welche weiteren Dokumente verwiesen wird Dokumentverweise zur Vermeidung von Redundanzen sind gut Dokumentverweise «aus Faulheit» eher nicht Zielpublikum muss Zugriff auf die entsprechenden Dokumente haben und diese einfach finden können

11 11 Architekturdokumentation für Projektmitarbeiter Warum Bewertbarkeit des Systems Fördert Kommunikation Hilft beim Denken Hilft Fehler zu vermeiden Erleichtert Einarbeitung

12 12 Planung und Überwachung für das Management Angebot und Vertrag (Anforderungen) Planung Projektenscheide Protokolle Konzept- und Detailkonzept In verschiedenen Dokumenten ein Kapitel «Management Summary»

13 13 Produktbeschreibung für Anwender Anwenderhandbuch vs. Schulungsunterlagen Richtig Vollständig Übersichtlich Verständlich (Zielgruppengerecht) Sicher nicht vom Entwickler geschrieben

14 14 Hürden Zeit und Aufwand Nutzen Zuständigkeit Nutzen Richtigkeit und Aktualität Konflikte bei Teamarbeit an Dokumentation

15 15 Autoren und Beteiligte Don Quijote Dogmatiker Perfektionist Doku-Knecht Pragmatiker

16 16 Acceptance Test Driven Development Nicht zwangsweise Methodik, sondern Konzept verwenden Festlegen, wie Fachlichkeit getestet wird, schafft Verständnis für das Produkt Kann nicht vom Entwickler kommen, er kann nur erklären, wie Bedeutet, Verantwortung zu übernehmen Und wie weiter, wenn der Kunde hier nicht unterstützt

17 17 Meine Erfahrungen 1. Es braucht einen Leader 2. Es muss eine Zielgruppe identifiziert werden 3. Der Inhalt muss zielgruppengerecht festgelegt werden 4. Die Medien müssen zielgruppengerecht festgelegt werden 5. Die Umsetzung muss auf Teamarbeit hin geplant werden 6. Erstellen, ablegen und verteilen 7. Feedback muss eingefordert und eingepflegt werden

Ähnliche Dokumente

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/