Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Marlis Friedl Christina Wirth Comet Computer GmbH tekom-jahrestagung 2010 5. November, UA 17
Überblick Die agile Software-Entwicklung Prozesse in der Software-Entwicklung Neue Bedingungen durch agile Software- Entwicklung Lösungen und Probleme der agilen Dokumentation Auswirkungen auf ausgewählte Aspekte Beispiel Scrum Ausblick
Die agile Software-Entwicklung Agiles Manifest im Februar 2001 Antwort auf die Probleme bisheriger Prozesse in der Software-Entwicklung Neues Prozessmodell Betonung auf direkte Kommunikation Agile Software-Entwicklung als Überbegriff Methoden: extreme Programming, Scrum, Feature-driven Development Begriffe: Daily Scrum, Stand-Up-Meeting, Sprint, Iteration, Backlog, Pair Programming
Wasserfall-Modell und Dokumentation Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Wasserfall-Modell und lineares Phasenmodell für Software-Entwicklung und Technische Dokumentation
Prozesse bei agiler Software-Entwicklung Iteration n Iteration 2 Iteration 1 Phase 1 Phasen 2, 3, 4 Phase 5
Neue Bedingungen durch agile Software-Entwicklung Prozesse mit kürzeren Planungs- und Entwicklungszyklen Prozesse der Dokumentation kürzer getaktet Software-Funktionen modularer entwickelt Input hat kürzere Geltungsdauer Päckchen oder Häppchen für die Dokumentation Projektinterne Dokumentation ist fragmentiert, stärker mündlich Andere Arbeitsmittel, neue Output-Formen Recherche und Projektorganisation wichtiger
Lösungen der agilen Dokumentation Bekanntes nutzen Redaktionssysteme Modularisierung, Topicorientierung, Single Sourcing Neues aufnehmen Veränderungen im Prozess eingeplant Transparenz der Aufgaben und Prozesse Rückkanal und Gestaltungsmöglichkeiten Iterative Erstellung der Inhalte
Probleme der agilen Dokumentation Arbeitsaufwand für die Dokumentation ist ungleich verteilt Fokus auf Einzelprojekte erschwert die Wiederverwendbarkeit der Inhalte Aktualisierung der bestehenden Inhalte beachten
Aspekte 1: Rolle der Kunden in agilen Projekten Wichtige Position in der (frühen) Theorie Kunden sind Teil des Teams Kunden stellen und konkretisieren die Anforderungen In der Praxis meist eine Rolle des Produktmanagements oder von Domänenexperten Nutzersicht wird für die Dokumentation selten genutzt
Aspekte 2: Neue Aufgaben für f r die Technische Dokumentation Technische RedakteurInnen sind Teil agiler Entwicklungsteams Übernehmen Aufgaben rund um die Software Oberflächentexte, GUI-Design, Tests, Usability Erstellen projektinterne Dokumentation Bearbeiten Kundenfeedback Unterstützen bei Marketing-Texten, Schulungsunterlagen
Aspekte 3: Usability Testing bei agiler Entwicklung Usability der Software und Usability der Dokumentation Ähnliche Problemstellung: Zeitliche Verschränkung mit agilem Prozess Verbindendes: Interesse an Nutzerfreundlichkeit, Rolle der Kunden Als Aufgabe im agilen Projekt einplanbar
Beispiel: Scrum
Scrum-Team Rollen Scrum Master Coach Product Owner Rolle des Kunden Definiert Backlog Entwicklung (Quality Engineer) Technische Redaktion (Übersetzung)
Meetings innerhalb eines Sprints Sprint-Planung Daily Scrums Sprint-Review Retrospektive
Sprint-Planung Product Owner Stellt den Selected Backlog vor Entwicklung Plant Aufgaben, die für die Umsetzung der Backlog Items erforderlich sind, und schätzt den Aufwand für diese Aufgaben (in Stunden) Technische Redaktion Welche Entwicklungspunkte müssen dokumentiert werden? Plant Aufgaben für Dokumentation, z.b. welche Dokumentationsarten für welche Entwicklungspunkte (Release Notes, Online-Dokumentation, Feldhilfen, UI- Texte, etc.)
Daily Scrum Was habe ich gestern gemacht? Was habe ich heute vor? Was blockiert mich in meiner Arbeit? Status der Aufgaben aktualisieren -> Transparenz Dokumentation Gelegenheit, Status zu erfahren und z.b. nach Input zu fragen
Sprint-Review Demo der neuen Funktionen Welche Funktionen sind abgeschlossen Evtl. Demo der fertigen Dokumentation
Retrospektive Was lief gut? Was kann verbessert werden? Teil des Verbesserungsprozesses Technischer Redakteur, Technische Redakteurin kann Vorschläge zur Verbesserung des Prozesses aus eigener Sicht machen
Input Kaum standardisierte Dokumente, wie Spezifikation, Software Design Andere Formen, z.b. Wiki Stärker mündlich, häufig ergibt sich bei Daily Scrums ein Austausch
Abgaben Generell: häufigere Abgaben Aber nicht immer wird auch neue Dokumentation am Ende des Sprints publiziert, sondern nach wie vor am Ende eines Releases
Ausblick Synergien mit weiteren Trends in der Technischen Dokumentation Online und digital Verteilte Erstellung von Inhalten Strukturierung und Modularisierung
Vielen Dank! Ihre Fragen?
Zum Weiterlesen Dogs, Carsten; Klimmer, Timo (2005): Agile Software-Entwicklung kompakt. Bonn: mitp. Eckstein, Jutta (2004): Agile Softwareentwicklung im Großen : Ein Eintauchen in die Untiefen erfolgreicher Projekte. Heidelberg: dpunkt.verlag. Hüttermann, Michael (2008): Agile Java-Entwicklung in der Praxis. Beijing u.a.:o Reilly Bildnachweise Folie 4: Wasserfall-Modell nach Spielmann, Heinz-Jürgen (2007): Softwaretechnik. In: Schneider, Uwe; Werner, Dieter (Hrsg.): Taschenbuch der Informatik. 6., neu bearbeitete Auflage, S. 220-259: S. 225, 228. Folie 4: Lineares Phasenmodell nach Hackos, JoAnn T. (2007): Information Development : Managing Your Documentation Projects, Portfolio, and People. Indianapolis, Indiana: Wiley Publishing: S. 554. Folie 11: Scrum auf einem Bierdeckel, www.computerwoche.de