Agil ist weit mehr als ein Trend. Seit das Agile Manifest im Jahr 2001 das Licht der Welt erblickt hat, hat die agile Arbeitsweise eine beispielhafte Erfolgsgeschichte geschrieben. Da aber bei aller Flexibilität und Dynamik die Dokumention weiterhin wichtig bleibt, empfiehlt Simon Krackrügge eine agile Dokumentation.
Was ist eigentlich Agil?
Agil bedeutet, dass wir unsere Projekte nicht mehr stur nach einem anfangs gefassten Plan abwickeln. Es bedeutet, dass wir uns vielmehr auf Unwägbarkeiten einstellen und diese zulassen. Denn IT-Projekte sind wie Reisen: Egal, wie wasserdicht die Planung vor Reiseantritt erscheint, das Unerwartete geschieht.
Dies gilt insbesondere dort, wo die Technologien anspruchsvoll die Anforderungen komplex sind. Außerdem gibt es im laufenden Projekt auch fachliche Änderungswünsche, die beim Start noch nicht unbedingt abzusehen waren. Sei es, dass weitere Systeme angebunden werden müssen, sei es, dass die Nutzerlandschaft sich verändert hat oder dass weitere Dienste und Features zu integrieren sind: Die Liste der Eventualitäten ist lang.
Manifest für Agile Softwareentwicklung
Und so lautet das Manifest wörtlich:
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Verfasser: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Erscheinungsjahr: 2001
http://agilemanifesto.org/...
… Und was ist dann Agile Dokumentation?
Hier setzt der TECH TALK von Simon Krackrügge an. Agile Methoden sind ja nicht von sich aus dokumentationsaffin. Sie sind im Gegenteil eher von Flexibilität geprägt und legen größeren Wert auf die spontane Handlungsfähigkeit innerhalb eines Projektes als auf dessen Dokumentation für die „Ewigkeit“. Entsprechend sind auch die Werkzeuge eher spontan: Zettel, Kanban-Boards, mündlicher Dialog.
Dokumentation bleibt aber weiterhin sehr wichtig. Denn Zettel, Dialoge und User Stories ersetzen einfach nicht die nachhaltige Speicherung von Wissen. Denn natürlich wollen wir dieses Wissen nicht nur simultan vermitteln, sondern auch über den engeren Wirkungskreis hinaus langfristig festhalten.
Die Vorteile nachhaltiger Dokumentation
Jeder kann sie in seinem Tempo lesen
Jeder liest sie dann, wenn er sich bestmöglich darauf konzentrieren kann
Die Teilhaberschaft ist insgesamt breiter
Wie verbinden wir also die Vorteile Nachhaltigkeit und Agilität in der Dokumentation?
Die Antwort lautet: Agile Dokumentation! Heißt: Wir dokumentieren bedarfsgerecht! Das gelingt uns, wenn wir uns im Vorfeld über die Leserschaft Gedanken machen – und darauf ausgerichtet Form und Inhalt wählen. So hängt beispielsweise die Beschreibung einer Software und ihrer Features oder die technische Detailtiefe davon ab, wer das Dokument am Ende liest. Denn weder wollen wir Leser der Fachseite mit technischen Einzelheiten quälen, noch die Leser aus dem IT-Bereich mit Überblicksdarstellungen vergraulen.
Wir fragen uns also „Wer liest das eigentlich? Und welche Informationen verspricht sich dieser Leser von der Lektüre?“ Das klingt banal, ist es aber nicht. Denn von der Leser-Zielgruppe hängt nicht nur ab, was, sondern auch wie wir es dokumentieren. Benutzerhandbuch ist nicht gleich Installationshandbuch ist nicht gleich Projektdokumentation.
Hier ein paar Beispiele
Produktdokumentation: Diese geschieht mittels verschiedener Handbücher (Benutzerhandbuch, Betriebshandbuch, Online-Hilfe). Diese basieren in aller Regel auf den Formatvorlagen des Kunden und sind strengen Regeln unterworfen. Leserschaft: Je nach Handbuch die Nutzer, die Administratoren oder der Support einer Software
Systemdokumentation: Diese liefert eine Innensicht. Sie gibt Auskunft über Datenmodell, Architekturentscheidungen, Software- und UI-Design und hält Code-Kommentare fest. Leserschaft: Alle am Projekt beteiligten Stakeholder mit technischem Hintergrund
Projektdokumentation: Alles, was es zur Zielsetzung und zum Verlauf eines Projektes zu sagen gibt, wird hier festgehalten: User Stories, Epics, Backlogs, Use Cases. Leserschaft: Alle am Projekt beteiligten Stakeholder mit fachlichem Hintergrund
Prozessdokumentation: Hier geht es um die Frage nach dem Wie: Definition of Ready, Definition of Done, diverse Workflows auf Basis von Git, JIRA etc. Leserschaft: Projektmanagement, Entwicklungsmanagement
Was ist eigentlich Agil?
Agil bedeutet, dass wir unsere Projekte nicht mehr stur nach einem anfangs gefassten Plan abwickeln. Es bedeutet, dass wir uns vielmehr auf Unwägbarkeiten einstellen und diese zulassen. Denn IT-Projekte sind wie Reisen: Egal, wie wasserdicht die Planung vor Reiseantritt erscheint, das Unerwartete geschieht.
Dies gilt insbesondere dort, wo die Technologien anspruchsvoll die Anforderungen komplex sind. Außerdem gibt es im laufenden Projekt auch fachliche Änderungswünsche, die beim Start noch nicht unbedingt abzusehen waren. Sei es, dass weitere Systeme angebunden werden müssen, sei es, dass die Nutzerlandschaft sich verändert hat oder dass weitere Dienste und Features zu integrieren sind: Die Liste der Eventualitäten ist lang.
Manifest für Agile Softwareentwicklung
Und so lautet das Manifest wörtlich:
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Verfasser: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Erscheinungsjahr: 2001
http://agilemanifesto.org/...
… Und was ist dann Agile Dokumentation?
Hier setzt der TECH TALK von Simon Krackrügge an. Agile Methoden sind ja nicht von sich aus dokumentationsaffin. Sie sind im Gegenteil eher von Flexibilität geprägt und legen größeren Wert auf die spontane Handlungsfähigkeit innerhalb eines Projektes als auf dessen Dokumentation für die „Ewigkeit“. Entsprechend sind auch die Werkzeuge eher spontan: Zettel, Kanban-Boards, mündlicher Dialog.
Dokumentation bleibt aber weiterhin sehr wichtig. Denn Zettel, Dialoge und User Stories ersetzen einfach nicht die nachhaltige Speicherung von Wissen. Denn natürlich wollen wir dieses Wissen nicht nur simultan vermitteln, sondern auch über den engeren Wirkungskreis hinaus langfristig festhalten.
Die Vorteile nachhaltiger Dokumentation
Jeder kann sie in seinem Tempo lesen
Jeder liest sie dann, wenn er sich bestmöglich darauf konzentrieren kann
Die Teilhaberschaft ist insgesamt breiter
Wie verbinden wir also die Vorteile Nachhaltigkeit und Agilität in der Dokumentation?
Die Antwort lautet: Agile Dokumentation! Heißt: Wir dokumentieren bedarfsgerecht! Das gelingt uns, wenn wir uns im Vorfeld über die Leserschaft Gedanken machen – und darauf ausgerichtet Form und Inhalt wählen. So hängt beispielsweise die Beschreibung einer Software und ihrer Features oder die technische Detailtiefe davon ab, wer das Dokument am Ende liest. Denn weder wollen wir Leser der Fachseite mit technischen Einzelheiten quälen, noch die Leser aus dem IT-Bereich mit Überblicksdarstellungen vergraulen.
Wir fragen uns also „Wer liest das eigentlich? Und welche Informationen verspricht sich dieser Leser von der Lektüre?“ Das klingt banal, ist es aber nicht. Denn von der Leser-Zielgruppe hängt nicht nur ab, was, sondern auch wie wir es dokumentieren. Benutzerhandbuch ist nicht gleich Installationshandbuch ist nicht gleich Projektdokumentation.
Hier ein paar Beispiele
Produktdokumentation: Diese geschieht mittels verschiedener Handbücher (Benutzerhandbuch, Betriebshandbuch, Online-Hilfe). Diese basieren in aller Regel auf den Formatvorlagen des Kunden und sind strengen Regeln unterworfen. Leserschaft: Je nach Handbuch die Nutzer, die Administratoren oder der Support einer Software
Systemdokumentation: Diese liefert eine Innensicht. Sie gibt Auskunft über Datenmodell, Architekturentscheidungen, Software- und UI-Design und hält Code-Kommentare fest. Leserschaft: Alle am Projekt beteiligten Stakeholder mit technischem Hintergrund
Projektdokumentation: Alles, was es zur Zielsetzung und zum Verlauf eines Projektes zu sagen gibt, wird hier festgehalten: User Stories, Epics, Backlogs, Use Cases. Leserschaft: Alle am Projekt beteiligten Stakeholder mit fachlichem Hintergrund
Prozessdokumentation: Hier geht es um die Frage nach dem Wie: Definition of Ready, Definition of Done, diverse Workflows auf Basis von Git, JIRA etc. Leserschaft: Projektmanagement, Entwicklungsmanagement
