In die Arbeit kommt Bewegung

Zugehörige Leistungen: Softwaredokumentation und Entwicklerdokumentation

Veröffentlicht in "technische kommunikation", Ausgabe 06, 2020

Agiles Arbeiten kommt aus der Softwareentwicklung und ist dort eine etablierte Vorgehensweise. Agile Prinzipien kommen aber mittlerweile auch in anderen Bereichen zur Anwendung. Wir beleuchten, was agil konkret bedeutet, wie agile Projekte funktionieren und welche Auswirkungen die agilen Prinzipien auf die Technische Redaktion haben.

Neugedachte Prinzipien

Im Jahr 2001 trafen sich 17 Experten aus der IT-Branche, um die Vorgehensweisen für Softwareprojekte neu zu denken. In den 1990er Jahren waren IT-Projekte oft sehr teuer, durch detaillierte und unnötige Dokumentation überfrachtet. Häufig wurden die Projekte nicht rechtzeitig fertig.

Als Ergebnis veröffentlichten die 17 Experten das "Agile Manifesto". Es definiert Prinzipien, auf denen alle agilen Methoden basieren:

Individuen und Interaktion vor Prozessen und Werkzeugen 

Die am Prozess beteiligten Personen und ihre Kommunikation untereinander sowie mit dem Kunden sind wichtiger als die Einhaltung starrer Prozesse und das Befolgen eines Plans, der anfangs entworfen wird und bereits nach kurzer Zeit schon teilweise veraltet ist.

Funktionierende Software vor umfassender Dokumentation

Im Fokus soll die Software stehen. Dokumentation soll nur gerade so gut sein wie notwendig. Gemeint ist hier vor allem die interne Prozess- und Projektdokumentation, nicht Anwenderdokumentation. Damit soll vermieden werden, dass Dokumentation nur geschrieben wird, um dem Prozess zu genügen. Dieses Prinzip besagt nicht, dass keine Dokumentation notwendig ist, was in den Entwicklungsteams gerne anders ausgelegt wird. Die Forderung nach Minimalismus und Qualität ist auch gut auf Anwenderdokumentation übertragbar.

Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen

Verträge sind ohne Frage wichtig, aber viel wichtiger ist eine vertrauensvolle Zusammenarbeit mit dem Kunden, zu der regelmäßige Abstimmungen und Neuverhandlungen der Prioritäten gehören.

Reagieren auf Veränderungen vor Befolgen eines Plans

Ein Plan ist oft bereits veraltet, sobald er verabschiedet wurde. In agilen Projekten ist daher die Grundannahme, dass sich Anforderungen durch veränderte Rahmenbedingungen, neu erlangtes Wissen oder angepasste Prioritäten stets ändern, sodass der Plan kontinuierlich angepasst werden muss. Ansätze, die sich als schlecht erweisen, sollen rechtzeitig verworfen werden, bevor unnötig Geld verbrannt wird, wenn ein Projekt in die falsche Richtung geht.

Die deutsche Übersetzung dieser Prinzipien aus dem Englischen stammt von Andreas Rüping.

Neue Kultur nötig

Das agile Arbeiten nach diesen Prinzipien ist zunächst keine bestimmte Methode, sondern vielmehr eine Haltung oder Denkweise. Gerade hier liegt oft das Problem. Denn viele Firmen setzen agile Methoden und Werkzeuge ein, ohne dabei ihre Haltung grundlegend zu überdenken und den gesamten Entwicklungsprozess in eine neue Kultur zu überführen. Ohne eine neue Kultur wird die Situation jedoch oft schlechter als vorher und Frustration macht sich breit. Es reicht auch nicht aus, nur die Entwicklungsabteilung agil arbeiten zu lassen, da angrenzende Bereiche wie Produktmanagement, Marketing oder Technische Redaktion als Stakeholder wichtige Rollen einnehmen.

Anwenderwünsche auf dem Zettel

Am Anfang agiler Entwicklungsprojekte stehen wie bei klassischen Projekten auch die Anforderungsanalyse und -definition. Ein agiles Projekt startet jedoch nicht mit einer detaillierten Feinspezifikation, sondern mit einer groben Liste der Anforderungen: Eine Art Vision des Produktes, die aus Sicht der Anwender als so genannte User Stories geschrieben ist. Die Liste der User Stories wird im Projektverlauf kontinuierlich neu betrachtet und bei Bedarf angepasst. Ein Beispiel dafür zeigt Abbildung 2. Tipp: Lesen Sie auch unseren Wissensartikel Karteikarten und Bierdeckel – Wie schreibt man gute User Storys?

Arbeit in kurzen Intervallen

Die Umsetzung der Anforderungen erfolgt in kurzen Intervallen, auch Iterationen genannt. Jedes Team verpflichtet sich, eine bestimmte Anzahl von Anforderungen in einer Iteration umzusetzen, sodass das entsprechende Feature am Ende der Iteration idealerweise fertig ausgeliefert werden kann. Das Beispiel einer Iteration zeigt Abbildung 02.

Die genaue technische Umsetzung der Anforderungen spezifiziert das Team am Anfang der Iteration. Erweist sich ein gewähltes Konzept als ungeeignet, wird es angepasst, und zwar solange, bis die gewünschte Qualität erreicht ist.

Der Projektfortschritt wird an der Menge der funktionierenden Software gemessen.

Funktionsumfang variabel

Oft sind Zeit und Kosten in einem agilen Projekt feste Ausgangsgrößen. Spielraum liefert der Inhalt, das heißt der genaue Funktionsumfang, der kontinuierlich im Projektverlauf neu ausgehandelt wird. Folgende Prioritäten können Anforderungen haben:

• Müssen unbedingt umgesetzt werden – Must have
• Sollen möglichst umgesetzt werden – Should have
• Können ggf. in einem Nachfolgeprojekt umgesetzt oder fallen gelassen werden – Could have und Won’t have

Diese Priorisierung folgt dem MoSCow-Prinzip.

Die Prioritäten verhandeln und bewerten die Produktmanager oder Vertreter der Anwender zu Beginn jeder Iteration mit den Teams neu. Die Ergebnisse werden in einem Ticketsystem festgehalten. Die Voraussetzung dafür, dass der Fortschritt bestimmt und die Prioritäten von allen Beteiligten neu ausgehandelt werden können, ist vollständige Transparenz. Dazu müssen alle Aufwände, Probleme und Fortschritte sichtbar gemacht werden. Vertrauen und Ehrlichkeit bilden die Basis für eine erfolgreiche Zusammenarbeit.

Regelmäßige Überprüfung

Zur Sicherstellung der Qualität werden die Ergebnisse regelmäßig überprüft. Jedes neue Feature geht bereits innerhalb der Iteration in die Qualitätssicherung und wird am Ende der Iteration anderen Stakeholdern vorgeführt. Werden dann Qualitätsmängel festgestellt, wird das Feature falls nötig komplett überarbeitet. Falls möglich, wird das gesamte Produkt nach jeder Iteration fertig zur Auslieferung gemacht und von einem größeren Nutzerkreis getestet.

Parallel dazu überprüft das Team regelmäßig die eigene Vorgehensweise und passt diese bei Bedarf an. In so genannten Retrospektiven setzen sich die Teammitglieder zusammen. Sie tauschen sich offen darüber aus, was gut gelaufen ist, wo es gehakt hat und welche Maßnahmen sie daraus ableiten und umsetzen müssen.

Eigenverantwortliches Arbeiten

In agilen Teams wird Eigenverantwortung großgeschrieben:

• Das gesamte Team ist für den erfolgreichen Abschluss einer Iteration verantwortlich.
• Alle Aufgaben werden transparent verwaltet und jedes Teammitglied kann sich eine Aufgabe zuordnen (Pull-Prinzip). Es gibt keinen Projektleiter, der Aufgaben zuteilt.
• Entwickeln, Testen und Dokumentieren erfolgen innerhalb des Teams, sodass jeder auch die Arbeit seiner Kollegen prüft.

Agile Teams sind idealerweise interdisziplinär. Technische Redakteure, Softwareentwickler, Tester, Usability-Designer und Informationsarchitekten sowie Fachleute aus anderen Sparten arbeiten zusammen. Damit entstehen praxistaugliche Lösungen und alle Teammitglieder eignen sich neues Wissen an.

Scrum als agiles Vorgehensmodell

Scrum ist eine Methode, die sich agile Prinzipien zunutze macht. Scrum ist sehr weit verbreitet und wird daher oft synonym zu agil verwendet. Scrum definiert Rollen, die für den Entwicklungsprozess unverzichtbar sind: Product Owner, Scrum Master und Scrum-Team.

Der Product Owner erstellt und priorisiert die Liste der Anforderungen, das so genannte Product Backlog. Er legt gemeinsam mit den Teams fest, welche Anforderungen als Nächstes umgesetzt werden. Der Product Owner nimmt die Sichtweise des Endbenutzers ein und steht stellvertretend für den Kunden – wenn er nicht selbst der Kunde ist. Am Ende jeder Iteration nimmt er die Ergebnisse seiner Teams ab und gibt diese frei oder fordert Anpassungen.

Der Scrum Master hat eine unterstützende Funktion. Er hilft Product Owner und Team bei der Pflege der Backlogs und der zugehörigen Tickets. Er moderiert Meetings, ist Ansprechpartner für organisatorische Probleme und überwacht die Einhaltung der Qualitätsvorgaben sowie den Status der Entwicklung. Kann ein Teammitglied zum Beispiel nicht weiterarbeiten, weil notwendige Informationen fehlen, versucht der Scrum Master, diese Informationen zu besorgen. Der Scrum Master hat idealerweise eine neutrale Position in Bezug auf die Feature-Entwicklung, das heißt, er ist nicht inhaltlich daran beteiligt, das Ziel der Iteration zu erreichen.

Das Scrum-Team steht im Zentrum des Entwicklungsprozesses. Das Team ist eine interdisziplinäre Gruppe, die eigenständig verantwortlich für ihre Aufgaben und Prozesse ist. Das Team schätzt, wie viele Anforderungen es in einem Sprint umsetzen kann, und übernimmt dann gemeinsam die Verantwortung dafür, dies auch zu schaffen. Je länger das Team stabil zusammenarbeitet, desto besser kann es abschätzen, wie viel umsetzbar ist. Bei der Umsetzung steht die Aufgabe im Fokus und nicht die eigene Stellenbeschreibung. Die Teammitglieder treffen sich regelmäßig, um sich kurz über den aktuellen Stand auszutauschen und Probleme zu besprechen (Standups).

Zusätzlich zu den Rollen können die Prozessbeteiligten auf hilfreiche Werkzeuge zugreifen: Sprints, Product increment, Taskboard, Definition of Done, Sprint Planning, Daily Standup, Review und Retrospektive.

Starten wir mit Sprints. So heißen in Scrum die Iterationen. Ein Sprint dauert typischerweise zwischen zwei und vier Wochen. Je kürzer die Zeit, desto schwieriger ist es, die Aufgaben klein genug zu schneiden. Je länger die Zeit, desto größer ist die Gefahr, dass der Prozess zu schwerfällig wird.

Das Ergebnis aller Teams am Ende eines Sprints wird Product increment genannt. Es handelt sich um ein potenziell auslieferbares Produkt, das auch dem Kunden und anderen Stakeholdern gezeigt wird.

Zum Überwachen des Status und der Aufwände eignet sich ein Taskboard, das die Prozessphasen abbildet und auf dem Karten von links nach rechts weitergeschoben werden. Abhängig vom Umfeld und der Vorliebe der Teams können diese Taskboards digital im Ticketsystem abgebildet oder auch physisch im Raum aufgestellt werden. Taskboards sind in der Regel für alle zugänglich und sorgen für maximale Transparenz – Abbildung 03.

Jedes Team führt eine Art Checkliste mit Akzeptanzkriterien, die erfüllt sein müssen, damit eine User Story in einem Sprint abgeschlossen werden darf. Diese Checkliste heißt Definition of Done oder kurz DOD. Sie ist sehr wichtig, um durchzusetzen, dass Testfälle und Dokumentation auch wirklich berücksichtigt werden.

Regelmäßige Meetings strukturieren die Abläufe. So steht am Anfang eines Sprints das Sprint Planning, bei dem das Team gemeinsam mit dem Product Owner die User Stories auswählt. Während des Sprints kommt das Team idealerweise täglich im Daily Standup zusammen. Das Daily Standup sollte nicht länger als 15 Minuten dauern. Am Ende des Sprints stehen dann ein Review, bei dem das Team seine Ergebnisse als Demo präsentiert, sowie die Retrospektive, in der die eigenen Vorgehensweisen kritisch hinterfragt werden.

Weitere agile Methoden sind zum Beispiel „Extreme Programming“, „Scaled Agile“, „Kanban“ oder „Feature-Driven Development“.

Agile Dokumentation

Agile Methoden liefern zunächst keine konkreten Antworten auf Fragen, die die Technische Dokumentation betreffen. Individuelle Lösungen sind erlaubt, solange sie den agilen Grundprinzipien nicht widersprechen. Technische Redakteure können von agilen Systemen profitieren. Sie können aber auch noch stärker abgehängt werden als zuvor. Der Erfolg steht und fällt mit der Integration der Redakteure in die agilen Prozesse und Teams.

Als Mitglieder in Scrum-Teams haben Technische Redakteure alle notwendigen Informationen zur Hand. Sie kennen die Stakeholder, sind in Meetings dabei, haben die Möglichkeit für Rückfragen und können die Entwickler und Product Owner für Reviews verpflichten. Das gesamte Team übernimmt idealerweise Verantwortung für das Thema Technische Dokumentation. Zudem haben die Technischen Redakteure Einfluss auf das Design der Software und beraten bei der Usability. Sie stehen für sprachliche Fragen zur Verfügung und können etwa beim konsistenten Benennen der Bedienelemente helfen.

Allerdings ist die Zeit ein Problem. Da eine Iteration kurz ist und die Entwickler oft bis zum Ende programmieren, sind kreative Lösungen und Pragmatismus gefragt. Alle Teammitglieder müssen mithelfen. Die Entwickler können zum Beispiel verpflichtet werden, am Ende der Iteration an der Qualitätssicherung zu arbeiten, Input für die Redakteure zu schreiben oder neue Aufgaben vorzubereiten. Reicht das nicht aus, können die User Stories auch damit abgeschlossen werden, dass die Technische Dokumentation für die Redakteure in Form von Notizen im Ticketsystem vorbereitet wird. So können die Redakteure die Dokumentation zeitversetzt in der nächsten Iteration schreiben.

Andererseits kommt es oft vor, dass Technische Redakteure nicht in die Scrum-Teams integriert werden und zeitlich unabhängig von der Entwicklung arbeiten. Dann ist es ein Nachteil, dass den Redakteuren kaum schriftlicher Input zur Verfügung steht. Einige Monate später wird es oft schwierig, die notwendigen Informationen zu besorgen. Die meisten Ansprechpartner sind dann mit anderen Aufgaben beschäftigt.

Ein weiteres Problem ist die Quantität. Der Aufwand für die Technische Dokumentation wird in Firmen häufig unterschätzt. Oft ist eine Redakteurin oder ein Redakteur für mehrere agile Teams zuständig. Abhängig von den Rahmenbedingungen sind zwei bis drei Teams für Redakteure gut zu schaffen. Aber spätestens bei zehn hört die Freude auf. Rechnen Sie sich einfach selbst aus, wie viele Plannings, Daily Standups, Retrospektiven und Reviews bereits bei drei Teams anfallen. Hier gilt es, Prioritäten zu setzen, welche Meetings wichtig sind, und ansonsten einen Stellvertreter zu haben, der bei anderen Meetings die Ohren spitzt. Für diese Aufgabe eignet sich der Scrum Master hervorragend.

Werfen wir einen Blick auf einen weiteren Aspekt, der die Technische Redaktion betrifft: die Infrastruktur. Grundvoraussetzung für das Dokumentieren in einer agilen Umgebung ist eine modulare und möglichst hochautomatisierte Redaktionsumgebung. In einem topicbasierten Ansatz mit oder ohne Redaktionssystem können die Technischen Redakteure die User Stories für das aufgabenbasierte Dokumentieren verwenden. Je mehr die User Stories aus Nutzersicht beschrieben sind, umso besser lassen sie sich analog dazu in der Technischen Dokumentation abbilden. Wenn die Dokumentation dann genauso wie der Programmcode automatisiert über Nacht gebaut werden kann, steht einem erfolgreichen Zwischenrelease am Ende des Sprints nichts mehr im Weg.

Vorteile von agilem Arbeiten

Agiles Arbeiten erfordert einen hohen Aufwand bei der Einführung der Methoden und in den Projekten einen höheren Kommunikationsaufwand. Aber es bietet viele Vorteile.

Umsetzung ohne Altlasten 

Agile Projekte treten nicht mit dem Anspruch an, dass alle Anforderungen zum Projektstart bis ins Detail definiert sind und vollständig im Entwurf der Systemarchitektur abgebildet werden müssen. Stattdessen werden Anforderungen und Umsetzung über die Iterationen verfeinert.

Diese iterative Vorgehensweise ist ein großer Vorteil, weil erfahrungsgemäß erst während der Umsetzung eines Projekts bestimmte Nebenwirkungen und Zusammenhänge deutlich werden. Dadurch, dass nicht die gesamte Architektur der Lösung schon vorab ausgearbeitet wird, sondern diese iterativ entsteht, können die Produktteams notwendige Änderungen schnell umsetzen und schleppen keine Altlasten aus der Planungsphase mit.

Nutzwert entscheidend 

Die Auswahl von Anforderungen für die nächste Iteration richtet sich bei agilen Projekten primär an den Anforderungen der Anwender aus. Die absolute Fokussierung auf die Anwender einer Lösung ist einer der größten Vorteile agiler Vorgehensweise. Die Sicht des Anwenders zwingt die Experten dazu, die Funktionen mit dem höchsten Nutzerwert zu priorisieren. Die fortlaufende Prüfung der Iterationsergebnisse unter Einbeziehung echter Anwender sorgt zusätzlich dafür, dass die Lösungen anwendergerecht werden.

Die Konzentration auf die Anwender fördert auch die zielgruppengerechte Dokumentation von Software.

Ständiges Feedback

Da am Ende jeder Iteration ein lauffähiges Produktinkrement stehen soll, muss auch jede Iteration ein vorführbares Ergebnis liefern. Diese fortlaufende Prüfung der Ergebnisse verhindert, dass ein Projekt über einen längeren Zeitraum ungehindert in die falsche Richtung läuft. Stattdessen erhält das Team fortlaufend Feedback. Das ist einer der wichtigsten Gründe dafür, dass agile Projekte weniger häufig scheitern als klassisch durchgeführte Projekte. Das konstante Feedback stellt aber auch hohe Anforderungen an die Sozialkompetenz der Teammitglieder – ein konstruktiver Feedbackprozess und eine etablierte Fehlerkultur sind hier notwendig.

Technische Redakteure als Mitglieder agiler Teams können die Technische Dokumentation als Teil der Produktinkremente liefern und in regelmäßigen Abständen Feedback zur Dokumentation einholen. Das steigert die Qualität der Technischen Dokumentation.

Nötige Änderungen frühzeitig erkennen 

Aufgrund der ständigen Verfeinerung von Anforderungen und der fortlaufenden Prüfung von Ergebnissen kommt es in agilen Projekten sehr häufig zu Änderungen. Agile Teams betrachten Änderungen als notwendig und als Bestandteil ihrer Arbeit.

Natürlich sind Änderungen aufwändig. So müssen sogar bestehende Teile der Lösung verworfen und neu implementiert werden. Da jedoch in kleinen Inkrementen gearbeitet wird, ist das weniger tragisch als wenn die komplette Lösung scheitert, weil erst nach langer Implementierungszeit eine Lücke in der Anforderungsdefinition festgestellt wird. Nicht tragfähige Konzepte können in agilen Projekten frühzeitig identifiziert und ausgetauscht werden.

Einsatzmöglichkeiten der Methode

Agile Entwicklung ist keine Wunderwaffe und schon gar keine Religion (wie manche meinen). Wenn bereits laufende Prozesse gut funktionieren, alle Beteiligten die notwendigen Informationen haben und das Projekt rechtzeitig und im Budget fertig wird, besteht kein Grund, auf agile Entwicklung umzusteigen.

Sind agile Prinzipien ein Garant für eine pünktliche Projektauslieferung? Natürlich nicht, denn auch in agilen Projekten können unerwartete Probleme auftauchen und manches Projekt wird vorzeitig beendet. Allerdings sind agile Projekte besser darauf eingestellt, auf diese Probleme zu reagieren.

Agile Prinzipien unterstützen bei allen Projekten, in denen komplexe Probleme zu lösen sind. Das gilt zum Beispiel auch für Projekte wie die Auswahl eines geeigneten Redaktionssystems oder die Entwicklung einer Content-Delivery-Lösung für ein Unternehmen.

Agile Vorgehensweisen machen unsere Arbeit erfolgreicher. Aus unserer Sicht können vor allem folgende agile Prinzipien auch auf andere Bereiche neben der Softwareentwicklung übertragen werden:

Eigenverantwortliches Arbeiten in interdisziplinären Teams

Ein hoher Grad an selbstbestimmtem Arbeiten fördert die Zufriedenheit. Wenn innerhalb eines Teams die Aufgaben eigenverantwortlich verteilt und abgearbeitet werden, entstehen oft sehr gute Ergebnisse, ohne dass ein Projektleiter jede Aufgabe bis ins Detail plant.

User Stories und iteratives Arbeiten 

Nicht nur die Anforderungen an die Entwicklung einer Software lassen sich als User Story formulieren. Dieses Prinzip kann man auch für die Auswahl eines Redaktionssystems verwenden. Die Anforderungen können dann in Iterationen umgesetzt werden, um flexibler zu werden und Zwischenergebnisse zu erhalten. So kann man leichter auf Veränderungen reagieren.

Standups

Standup-Meetings als kurzer, 15-minütiger Austausch zum aktuellen Status eines Projekts und das mehrmals pro Woche sind ein gutes Mittel, um Blockaden zu identifizieren oder um weitere inhaltliche Meetings zu organisieren. So kann schneller reagiert werden, wenn jemand Informationen oder Ansprechpartner benötigt.

Retrospektiven

Auch wenn in einem Unternehmen eine gute Fehler- und Feedbackkultur existiert, haben sich regelmäßige Retrospektiven bewährt. Sie bieten die Möglichkeit, sich in einem geschützten Raum mit den positiven und negativen Ergebnissen eines Projekts auseinanderzusetzen und sich gegenseitig Feedback zu geben. So werden Folgeprojekte erfolgreicher. 

Transparenz

Eine transparente Aufgabenverfolgung ist auch für Schwerpunkt klassische Projekte sehr wertvoll, weil sie Überlastungen und Blockierungen schnell sichtbar und steuerbar macht.

Agiles Arbeiten löst zwar einige der Probleme, die klassische Vorgehensweisen wie das V-Modell und das Wasserfall-Modell haben (Abbildungen 9 und 10). Allerdings werden diese klassischen Methoden nicht komplett von agiler Arbeitsweise abgelöst. V-Modell und Wasserfall sind in Unternehmen außerhalb der Softwareentwicklung und IT weit verbreitet. Das liegt auch daran, dass agile Methoden nicht pauschal für alle Entwicklungsprozesse besser sind, zum Beispiel für die Entwicklung von Hardware. Aus diesem Grund verwenden viele Unternehmen gemischte Vorgehensweisen aus klassischen und agilen Methoden.