Info-Portal > Artikel

Agile Software-Entwicklung – der Redakteur sprintet mit

Agile Software-Entwicklungsteams sprinten. Ein Sprint ist ein Entwicklungszyklus von einer bis vier Wochen. Die genaue Länge legt das Team fest und gilt für die ganze Laufzeit des Projekts. Am Ende jedes Sprints steht ein funktionsfähiger Zwischenstand der Software.

  • Bild: © sportpoint - stock.adobe.com

Agile Prozesse bringen neue Herausforderungen für die Technische Dokumentation, denn das Agile Manifest fordert, kritisch zu überdenken, welche Arten der Dokumentation und welcher Umfang für ein Projekt relevant sind. Die agile Arbeitsweise eröffnet aber auch neue Chancen, denn die funktionsfähigen Produktinkremente, die am Ende jedes Sprints zur Verfügung stehen, bieten die Möglichkeit, dass der Redakteur den Projektfortschritt verfolgen, das Produkt mit testen und schon früh mit der Dokumentation beginnen kann.

Der folgende Erfahrungsbericht beschreibt, wie ein Software Usability Manager und ein Dokumentations-Dienstleister zusammengearbeitet haben, um bereits ab Version 1.0 eine hochwertige Produktdokumentation der Software mitzuliefern.

Agile Werte

Das Agile Manifest von 2001 definiert die Werte, die agilen Prozessen zugrunde liegen. Als Gegenreaktion auf die unflexiblen, prozess-lastigen Projektmanagement-Verfahren der 1990er-Jahre wurde darin gefordert:

  • Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
  • Funktionsfähige Produkte haben Vorrang vor umfassender Dokumentation.
  • Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
  • Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Diese Werte wurden ursprünglich für die Software-Entwicklung formuliert und dann später verallgemeinert. Der neue Ansatz verabschiedet sich damit von Projektmanagement-Verfahren, bei denen jegliche Information, die in einer bestimmten Projektphase benötigt wurde, vor dem Programmieren schriftlich niedergelegt werden musste, was dazu führte, dass große Mengen an Dokumentation aufgrund neuer Anforderungen bereits veraltet waren, bevor sie in Code umgesetzt wurden.

Auf der Grundlage der agilen Werte haben sich verschiedene agile Prozesse etabliert. Dazu gehören u.a. Extreme Programming (XP), Feature Driven Development (FDD), Scrum und Kanban. Im Folgenden wird die Scrum-Terminologie verwendet.

Die Arbeitsweise agiler Teams

Seit einigen Jahren setzen Software-Unternehmen zunehmend auf agile Prozesse, um die Produktivität ihrer Teams zu erhöhen, flexibel auf veränderte Anforderungen an die Software zu reagieren und termingerecht zu liefern.

Agile Teams setzen auf den direkten Austausch von Informationen und organisieren sich mit folgenden Rollen:

Product Owner

Der Product Owner kümmert sich um die Anforderungen an das Produkt. Dazu kommuniziert er mit den Stakeholdern des Projekts, also Kunden, Managern oder Institutionen. Er ist dafür verantwortlich, dass das Produkt zum gesetzten Zeitpunkt fertig ist und die gewünschte Funktionalität bietet.

Er sammelt die Anforderungen an das Produkt im sogenannten Product Backlog und priorisiert sie nach ihrem Geschäftswert. Im Verlauf des Projekts kann er neue Anforderungen hinzunehmen oder bereits erfasste Anforderungen verwerfen oder deren Umsetzung auf einen späteren Zeitpunkt verschieben. Der Product Backlog wird also fortlaufend aktualisiert.

Die Anforderungen im Product Backlog werden als Stories bezeichnet. Eine Story gibt vor, eventuell auch in referenzierten Dokumenten, wie die jeweilige Anforderung umgesetzt werden soll.

Entwicklungsteam

Das Entwicklungsteam besteht aus 3 bis 9 Personen und organisiert sich selbst, um möglichst effizient zu arbeiten. Im idealen Team fallen die Expertenrollen weg, jeder kann alles und kann somit jede beliebige Aufgabe aus dem Product Backlog übernehmen.

Zu Beginn eines Sprints entscheiden das Team und der Product Owner, was sie im nächsten Sprint erreichen wollen. Sie schätzen den Aufwand an Arbeitstagen (Story Points) für jede neue Anforderung im Product Backlog. Wenn ein Sprint zum Beispiel drei Wochen dauert, stehen je Sprint 15 Arbeitstage zur Verfügung. Abzüglich eines Tages für die Meetings, in denen der Sprint geplant und ausgewertet wird, bleiben dann 14 Arbeitstage für die Entwicklungsarbeit am Produkt. Wenn ein Entwicklungsteam fünf Mitglieder hat und alle da sind, können also je Sprint 70 Story Points abgearbeitet werden.

Das Team entscheidet anhand der Prioritäten und der Story Points, welche Anforderungen sie im nächsten Sprint umsetzen wollen. Diese Anforderungen werden im Sprint Backlog festgehalten. Das Team ist gemeinsam für die Umsetzung bis zum Ende des Sprints verantwortlich. Anforderungen, die nicht umgesetzt wurden, werden in den nächsten Sprint übernommen. Im Sprint Backlog wird das Abschmelzen der Story Points über die Dauer des Sprints als Sprint Burndown angezeigt.

Zu Beginn jedes Arbeitstages trifft sich das Team zum Daily Scrum, einem viertelstündigen Meeting im Stehen, bei dem die Team-Mitglieder einander kurz mitteilen, was sie am Vortag erreicht haben, was sie aktuell vorhaben und wo sie gegebenenfalls Unterstützung brauchen. Der Product Owner und Scrum Master sind anwesend, aber nur passiv beteiligt.

Am Ende eines Sprints trifft sich das Team mit dem Product Owner und den Stakeholdern zum Sprint Review, einem etwa einstündigen Meeting, in dem die Team-Mitglieder ihre Ergebnisse vorstellen und geprüft wird, inwieweit das angestrebte Ziel erreicht wurde.

Im Product Backlog kann anhand der Story Points, die einerseits pro Sprint abgearbeitet werden, und die andererseits noch bis zur Fertigstellung des nächsten Release verbleiben, geschätzt werden, wann das Release fertig ist. Wenn dieser Termin nicht mit dem geforderten Termin übereinstimmt, können in Rücksprache mit den Stakeholdern die Anforderungen für das Release angepasst werden, zum Beispiel, indem Stories in den Backlog für das darauffolgende Release verschoben werden.

Scrum Master

Der Scrum Master stellt sicher, dass der agile Prozess korrekt angewendet wird und die Rollen eingehalten werden. Er moderiert die Sprint Retrospective, das interne Treffen des Teams am Ende eines Sprints, bei dem die Entwickler und der Product Owner zusammen überlegen, wie sie den agilen Prozess weiter verbessern können.

Agile Werte und die Technische Dokumentation

Das Agile Manifest fordert, dass das funktionsfähige Produkt Vorrang vor der Dokumentation hat. Das betrifft alle Arten von Dokumentation:

  • Produktdokumentation: erklärt dem Anwender, was die Software leistet und wie sie zu bedienen ist.
  • Systemdokumentation: beschreibt, wie die Software intern funktioniert und unterstützt den Entwicklungsprozess.
  • Projektdokumentation: dokumentiert den Projektfortschritt.
  • Prozessdokumentation: beschreibt, welche Prozesse der Arbeit an dem Projekt zugrunde liegen.

Nur was wirklich gebraucht wird, soll dokumentiert werden. Nicht mehr, aber auch nicht weniger. Denn was nützt eine funktionierende Software, wenn der Anwender nicht weiß, wie sie zu bedienen ist. Oder wenn internes Know-how undokumentiert bleibt und Entwicklungen später nicht nachvollzogen werden können.

Die System-, Projekt- und Prozessdokumentation des konkreten Projekts wurden vom Team selbst und insbesondere durch den Project Owner gestaltet und verwaltet.

Für die Produktdokumentation formulierte das agile Team folgende Anforderungen:

  • Vollständigkeit
  • Auf dem aktuellen Stand zum Release
  • Prägnante Formulierung
  • Maximal 120 Seiten
  • Englisch
  • Als PDF und kontext-sensitive Hilfe verfügbar
  • Lieferung vor dem Release

Der Ansprechpartner im agilen Team

Der Usability Manager des agilen Teams übernahm die Verantwortung, einen Dienstleister zu finden, der die Produktdokumentation begleitend zu den Sprints erstellen sollte. Als erfahrener Ingenieur in seinem Spezialgebiet, mit einigen Jahren Berufserfahrung in der Technischen Dokumentation, wusste er, wonach er suchte.

Es wurde entschieden, zwei Doku-Dienstleister je eine Probearbeit anfertigen zu lassen. Die beiden Dienstleister erhielten eine Einführung zu den technischen Hintergründen, zur Benutzeroberfläche und eine ausführliche Demo der zu beschreibenden Handlungssequenzen. Anhand der Probearbeiten entschied das Management in Rücksprache mit dem agilen Team, wer die weiteren Arbeiten ausführen sollte. Zu diesem Zeitpunkt lief das Projekt bereits anderthalb Jahre und hatte noch ein weiteres Jahr bis zum ersten Release vor sich.

Der Usability Manager traf sich nun monatlich einmal für einen halben Tag mit dem Redakteur des Dienstleisters, um ihm zunächst den aktuellen Stand und später jeweils die neuen Features des letzten Sprints detailliert zu erklären. Der Redakteur filmte während dieser Treffen, um später anhand von Bild, Ton und dem aktuellen, funktionsfähigen Zwischenstand der Software die Erklärungen nachzuvollziehen und die Software zu dokumentieren. Wenn er Fehler in der Software entdeckte, meldete er sie an seinen Ansprechpartner und fungierte so auch als Tester. Der Ansprechpartner gab regelmäßig Feedback zu den neu dokumentierten Features.

Fazit

Durch die frühe Einbindung eines Technischen Redakteurs und dessen kompetente Betreuung durch eine Schlüsselperson des agilen Teams konnte die Produktdokumentation mit der Software-Entwicklung Schritt halten. Das Dokument stand termingerecht, auch als kontext-sensitive Hilfe, zur Verfügung. Diese Vorteile wiegen sicher auf, dass nicht nur das Team, sondern auch der assoziierte Redakteur bisweilen agil auf veränderte Produktanforderungen und damit auf Veränderungen in der Oberfläche und Funktionalität der Software reagieren musste.

Inzwischen haben die Doku-Arbeiten für das nächste Release begonnen.

Quellen

  • CollabNet, Inc.; VersionOne Inc. (2018): 12th Annual State of AgileTM Report, https://explore.versionone.com/, Stand: 25.02.2019.
  • microTOOL GmbH (2017): Agiles Projektmanagement und Scrum kompakt. Whitepaper: Wie Sie Projekte agil und mittels Scrum managen, https://www.microtool.de/, Stand: 25.02.2019.
  • Beck, Kent; Andres, Cynthia (2004): Extreme Programming Explained - Embrace Change, 2nd ed, Pearson Education, New Jersey.
  • Rüping, Andreas (2013): Dokumentation in agilen Projekten - Lösungsmuster für ein bedarfsgerechtes Vorgehen, dpunkt.verlag, Heidelberg.

Der Autor

Michael Endl studierte Mathematik und Physik und arbeitete zunächst als Systementwickler für ein Software-Unternehmen. Später studierte er noch Linguistik und Theologie und arbeitete viele Jahre als Sprachwissenschaftler und Übersetzungsberater im Ausland. Seit 2008 ist er als Technischer Redakteur bei commatec und hat seither unterschiedlichste Dokumentationsprojekte aus den Bereichen Software, Medizintechnik, Maschinenbau und Messtechnik realisiert.

Aktuelle Artikel

Info-Portal

Info-Portal