Anforderungsmanagement mit Jira und Confluence

Gastbeitrag von | 31.05.2019

Es ist immer wieder erstaunlich, wie viele Organisationen ihre Anforderungen noch mit Word und Excel verwalten. Irgendwann kommt man aber in größeren Softwareprojekten an den Punkt, an dem der Ruf nach einem dedizierten Tool fürs Anforderungsmanagement im Team immer lauter wird.

Die Einführung eines Anforderungstools ist jedoch oft mit hohem Aufwand verbunden. Dabei lassen sich auch bestehende Tools hervorragend für die Verwaltung von Anforderungen nutzen – frei nach dem Motto „Mach’ mehr aus dem, was du hast!“ Über ein Ticketing-System und auch ein Enterprise-Wiki verfügen mittlerweile recht viele Firmen. Weit verbreitet sind hier Jira und Confluence der Firma Atlassian. Beide Tools lassen sich in Kombination sehr gut für ein integriertes Anforderungsmanagement in agilen Projekten nutzen. Wie das in der Praxis aussehen kann, möchte ich in diesem Artikel beschreiben.

A fool with a tool …

Während die strukturierte Analyse und Dokumentation von Softwareanforderungen in der Luft- und Raumfahrt sowie in der Automobilindustrie schon seit langem üblich ist, ist dies in anderen Organisationen, die sich mit Softwareentwicklung beschäftigen, nicht unbedingt selbstverständlich. Dies gilt insbesondere für Organisationen, bei denen Softwareentwicklung nicht zur Kernkompetenz gehört, sondern der Unternehmensschwerpunkt in anderen Bereichen (z. B. Handel, Produktion oder sonstige Dienstleistungen) liegt.

Da IT jedoch mittlerweile so gut wie alle Bereiche des täglichen Lebens durchdringt, stehen auch diese Unternehmen vor der Herausforderung, große und komplexe Softwareprojekte zu realisieren – entweder als Inhouse-Projekt oder über externe Dienstleister.

Während sich in kleineren Softwareprojekten mit wenigen Beteiligten die Anforderungen vielleicht noch mehr oder weniger unproblematisch in einem Word-Dokument oder einer Excel-Liste verwalten lassen, stößt dieser Ansatz mit wachsender Projektgröße an seine Grenzen. Eingeschränkte Mehrbenutzerfähigkeit, die unzureichende Unterstützung von verteilten Teams, schwierige Versionierung von Anforderungen und Probleme bei der Suche und Filterung sind nur einige Nachteile, die zu nennen sind.

Außerdem machen die komplizierte Nachvollziehbarkeit von Anforderungsquellen und -änderungen sowie die fehlende Integration in den Entwicklungsprozess den Anforderungsmanagern, die nur mit Office-Tools arbeiten, das Leben schwer.

Andererseits verursachen dedizierte RE-Tools häufig relativ hohe Lizenzkosten, sie bringen einen nicht unerheblichen Schulungsaufwand mit sich und müssen dann meistens noch aufwändig an die eigenen Prozesse angepasst werden. Hinzu kommt, dass die Funktionen der Tools häufig gar nicht „ausgereizt“ werden – im übertragenden Sinn kauft man also einen Ferrari und fährt ihn doch nur wie einen Trabi.

Verwendung von Ticketing-Systemen zur Anforderungsverwaltung

Was macht man aber nun, wenn man der Nachteile von Pen & Paper oder Office-Tools leid ist, die Anschaffung eines teuren RE-Tools aber nicht unbedingt gerechtfertigt ist?

Diese Lücke lässt sich mit den webbasierten Anwendungen Jira und Confluence schließen, die man vielleicht ohnehin schon für den Entwicklungsprozess und die Projektdokumentation im Haus hat.  Jira und Confluence sind mittlerweile im Unternehmensumfeld so weit verbreitet, dass man diese Tools nicht mehr groß vorstellen muss. Ich will trotzdem kurz stichwortartig aufzeigen, wo die jeweiligen Schwerpunkte der Tools, sowie Vor- und Nachteile im Kontext des Anforderungsmanagements liegen.

Kurzvorstellung Jira

Jira ist eine webbasierte Anwendung, mit der sich Trouble Ticketing und das Aufgabenmanagement in Projekten abbilden lassen. Es wird vor allem in der Softwareentwicklung eingesetzt und ermöglicht die Definition eigener Workflows, eigener Vorgangstypen sowie eigener Eingabemasken.

Standardmäßig umfasst Jira für die Softwareentwicklung die Vorgangstypen Epic, Story und Bug. Ein Standardvorgang in Jira verfügt unter anderem über eine ID, einen Titel, einen Status, eine Beschreibung und die Möglichkeit, Screenshots oder andere Anhänge hinzuzufügen. Außerdem gibt es zu jedem Vorgang eine Kommentarfunktion, über die Nutzer Bemerkungen zu dem Vorgang hinzufügen können. In der Praxis wird diese Funktion allerdings häufig als eine Art „Chat“ missbraucht. Statt bei offenen Punkten das direkte Gespräch miteinander zu suchen, spielen Kunde, Projektleiter und Entwickler dann mitunter ein fröhliches Jira-Kommentar-Pingpong.

Für einfache kleine Funktionsergänzungen oder Fehlermeldungen sind die Möglichkeiten von Jira aber in der Regel mehr als ausreichend. Wenn es jedoch um komplexere und umfangreichere Anforderungen geht, gerät man mit der Nutzung von Jira als alleiniges Anforderungstool irgendwann an Grenzen.

Durch die exzessive Verwendung des Kommentarfeatures und der Funktion „Anhänge hinzufügen“ kann es dann schnell zu einer fragmentierten Darstellung von Informationen kommen. Dies gilt besonders dann, wenn Anforderungen sich häufig ändern und Kommentare oder Anhänge mit veraltetem Wissensstand nicht aus dem Vorgang entfernt werden. Der finale Stand der Anforderung ist dann meist schlecht erkennbar und Entwickler und Tester müssen sich die aktuellen Informationen mühsam zusammensuchen.

Kritisch wird es vor allem dann, wenn zusätzliche Informationen benötigt werden, um die Anforderung detaillierter zu dokumentieren (z. B. Wireframes, Use Case-Abläufe, Akzeptanzkriterien, Prozessdiagramme). Abgesehen von der Nutzung einer Wiki-Markdown-Sprache in der Vorgangsbeschreibung bzw. den Kommentaren oder dem Hinzufügen von Anhängen gibt es dazu keine Möglichkeit.

Die Projekterfahrung zeigt, dass man oft aber genau diese zusätzlichen Informationen benötigt, um Anforderungen für das Entwicklerteam verständlicher zu machen. So kann beispielsweise ein umfangreicher Checkout-Prozess in dem Online-Shop eines Baumarktes mit ca. 50 Entscheidungen als Prozessmodell viel übersichtlicher dargestellt werden, als mit einer reinen textuellen Beschreibung. Ein anderes Beispiel ist die Rabattberechnung für einen Fashion-Onlineshop mit einem Kunden aus der Türkei. Aufgrund der Sprachbarriere und der Komplexität der Berechnungen wurden hier umfangreiche Rechenszenarien erarbeitet, die als Basis für die Akzeptanzkriterien der entsprechenden User Story dienten. Und ganz generell sind bei der Definition von Eingabemasken Tabellen und Wireframes oft hilfreicher, als die Eingabeelemente in einzelnen Anforderungen zu beschreiben.

Da sich diese zusätzlichen Informationen in Jira nicht übersichtlich darstellen lassen, ist von der alleinigen Nutzung von Jira als Requirements Engineering-Tool eher abzuraten. Jira ist zwar hilfreich, um Anforderungen zu verwalten, aber es ist kein Dokumentationswerkzeug.

Nutzung von Confluence zur Anforderungsdokumentation

Zur Dokumentation von Anforderungen hingegen eignet sich Confluence, ein Enterprise Wiki für Kommunikation und Wissensmanagement in Unternehmen. Dieses ebenfalls webbasierte Tool verfügt unter anderem über einen WYSIWYG-Editor, sowie Möglichkeiten zur Definition von Seitentemplates, dem Versionsvergleich und der Wiederherstellung alter Versionsstände. Außerdem können Standardgliederungen hinterlegt werden. Genauso wie Jira ist Confluence über den Atlassian-Marketplace durch eine Vielzahl von Add-Ons erweiterbar, z. B. durch einen Word-Export.

Allerdings hat auch Confluence im Alleingang einige Nachteile in Bezug auf das Anforderungsmanagement. Confluence verfügt zwar über eine rudimentäre Aufgabenverwaltung, eine vollausgebaute Workflow-Engine besitzt es jedoch nicht. Darüber hinaus bietet Confluence keine wirkliche Integration in den Softwareentwicklungsprozess. Ein Tracing von Anforderungen bis auf Quellcode-Ebene ist somit nicht möglich und auch der Planungsprozess agiler Teams wird nicht unterstützt.

Effektives Anforderungsmanagement durch Kombination der Tools

Auch Confluence allein hilft uns also auf dem Weg zu einem effektiven und effizienten Anforderungsmanagement auch nicht weiter. Wie so oft im Leben gilt hier das Prinzip „Die Mischung macht’s!“, denn in Kombination spielen die beiden Tools ihre Stärken optimal aus.

Wichtig ist es hierzu, zunächst eine strikte Aufgabenteilung zwischen Jira und Confluence zu etablieren, so wie in Abbildung 1 dargestellt.

Aufgabenteilung von Jira und Confluence im Requirements Engineering
Für ein Projekt sollte jeweils genau ein Jira-Projekt und ein Confluence-Bereich angelegt werden. So haben alle Projektbeteiligten eine „Single source of information“ und müssen nicht in unzähligen Dokumenten oder beispielsweise Doors-Modulen nach verteilten Informationen suchen.

Jede Anforderung oder User Story wird in Jira durch einen Vorgang repräsentiert. Sollten zum Verständnis der Anforderung weitere Informationen notwendig sein, werden diese auf einer zu der Anforderung gehörenden Confluence-Seite hinterlegt. Der Link zu dieser Confluence-Seite wird in ein benutzerdefiniertes Attribut des Jira-Vorgangs eingebunden.

Der Jira-Vorgang durchläuft während des Backlog Refinements einen eigens dafür angelegten Workflow (siehe Abbildung 2). Je nach gewünschtem Umfang der Nachverfolgbarkeit kann der Workflow mit der Freigabe der Anforderung für die Entwicklung enden oder noch um die Umsetzung der Anforderung erweitert werden.

Ein Workflow kann in Jira mit Hilfe des WYSIWYG-Workflow-Editors leicht erstellt und bearbeitet werden. Die Kästen in Abbildung 2 repräsentieren hierbei den Status der Vorgänge. Über ein Vorgangsstatistik-Gadget für die Jira-Startseite sieht man so auf einen Blick, wie viele Anforderungen sich in einem bestimmten Status befinden. Und auch das Mapping der Vorgangsstatus auf ein entsprechendes Kanban-Board in Jira ist schnell erledigt.

Beispielhafter Anforderungsmanagement-Workflow in Jira

Um die Verknüpfung zwischen einem Jira-Vorgang und der dazugehörigen Confluence-Seite bidirektional navigierbar zu machen, kann der Jira-Vorgang über eine Anwendungsverknüpfung in Confluence eingebettet werden. So sieht man aus der Dokumentation heraus jederzeit, in welchem Workflow-Status sich die Anforderung befindet.

In der Regel werden aus der Anforderung bzw. User Story schließlich im Planungsprozess entsprechende Aufgaben für die Entwicklung abgeleitet. Hier tritt dann Jira als Aufgabenverwaltungstool in den Vordergrund. Die Aufgaben können in Jira ebenfalls als Vorgang angelegt und mit der Anforderung verknüpft werden. Da Jira die Möglichkeit bietet, verschiedene Versionsverwaltungssysteme zu integrieren, ist auch ein Tracing der Anforderung bis zum Quellcode möglich (siehe Abbildung 3). In welchem dedizierten Anforderungsmanagementtool hat man schon diese Möglichkeit?

Tracing von Anforderungen bis zum Quellcode

Grenzen des Anforderungsmanagements mit Jira und Confluence

Den Vergleich mit vollumfänglichen Anforderungsmanagement-Tools müssen Jira und Confluence also durchaus nicht scheuen. Ganz an deren Funktionsumfang kommen die beiden Anwendungen allerdings auch in Kombination nicht heran.

In Confluence ist beispielsweise aktuell kein Baselining der gesamten Dokumentation möglich. Dies kann wünschenswert sein, wenn man später den Gesamtstand der Dokumentation zu einem bestimmten Zeitpunkt schnell einsehen oder ggf. sogar als Basis für eine weitere Bearbeitung verwenden möchte. Leider versioniert Confluence die Wiki-Seiten nur auf Ebene der einzelnen Seite. Behelfen kann man sich mit hier mit einem Export des gesamten Confluence-Bereichs in das PDF- oder Word-Format. Um auf Basis dieses Standes weiterarbeiten zu können, müsste dieser allerdings erst wieder in Confluence importiert werden.

Fazit

Wer in agilen Projekten auf Baselines oder automatisch generierte Tracing-Matrixen als Standardfeature verzichten kann und von Excel-Listen die Nase voll hat, findet in Jira und Confluence ein bewährtes und leichtgewichtiges Duo für das Anforderungsmanagement. Um die Vorteile der Tools optimal auszureizen, ist die Etablierung und Einhaltung einer Aufgabenteilung zwischen den beiden essentiell: Für die Pflege der Anforderungsattribute wie ID und Titel sowie die Steuerung des Anforderungsprozesses ist Jira prädestiniert, während umfangreiche Detailinformationen zur Anforderung in Confluence besser und übersichtlicher dargestellt werden können.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

Kathrin Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u.a.

t2informatik Blog: Die agile Dokumentation in der Softwareentwicklung

Die agile Dokumentation in der Softwareentwicklung

t2informatik Blog: Das SWAT-Team in Scrum

Das SWAT-Team in Scrum

t2informatik Blog: Das Problem mit dem Stolz

Das Problem mit dem Stolz

Kathrin Herrmann
Kathrin Herrmann

Kathrin Herrmann ist agile Requirements Engineer, Scrum Master und Coach. Seit 2004 ist sie im Softwarebereich tätig und kennt sehr gut die täglichen Herausforderungen, die Softwareprojekte mit sich bringen. Ihre beruflichen Stationen führten sie bisher in so unterschiedliche Branchen wie Handel und E-Commerce, Ver- und Entsorgungswirtschaft, Wohnungswirtschaft, Logistik, Militär und Raumfahrt. Agilität auch in traditionsreiche Branchen zu bringen ist ihr ein wichtiges Anliegen. Sie verfügt über Zertifizierungen des IREB (CPRE Advanced Level Elicitation and Consolidation), der Scrum Alliance (Certified Scrum Master & Certified Scrum Product Owner) und des iSAQB (Certified Professional for Software Architecture – Foundation Level).