Einleitung

Anforderungsmanagement mit JIRA

Atlassian’s JIRA hat in den vergangenen Jahren einen bemerkenswerten Einzug in eine Vielzahl von Unternehmen gehalten und es ist mehr als ein Gefühl, dass fast jedes Unternehmen, in dem Softwareentwicklung eine Rolle spielt, inzwischen JIRA (oder ähnliche Produkte wie Microsoft’s Team Foundation Server) im Einsatz hat. Ursprünglich als Anwendung für Fehlermanagement, Problembehandlung und operatives Projektmanagement verwendet, nutzen immer mehr Firmen JIRA auch für das Aufgaben- und Anforderungsmanagements innerhalb der (agilen) Softwareentwicklung. Böse Zungen behaupten inzwischen deshalb nicht ganz zu Unrecht, dass JIRA das neue Excel sei, also ein Tool mit dem Unternehmen versuchen, möglichst alles zu erschlagen.

Im Hinblick auf das Anforderungsmanagement und andere Aufgaben des Requirements Engineering stellt sich daher berechtigt die Frage, welchen Nutzen JIRA in diesem Umfeld liefern kann. Zweifelsfrei bietet JIRA grundlegende Features für das Anforderungsmanagement und kann somit in vielen Aspekten mit expliziten Anforderungsmanagement-Werkzeugen (RM Tools) mithalten. Dennoch stellen zunehmend immer mehr Unternehmen fest, dass sich durch die Nutzung von JIRA (oder ähnlicher Werkzeuge) nicht automatisch Projekterfolg einstellt oder die Kommunikation zwischen Fachbereich und IT nur ansatzweise verbessert werden kann. Sofern keine ausreichend methodische Basis bei den Projektbeteiligten vorliegt, greift auch in diesem Zusammenhang der alte Spruch „A fool with a tool is still a fool“ oder auch die noch drastischere Erkenntnis „Shit in, shit out“.

Zweifelsohne bietet JIRA exzellente Möglichkeiten für das Aufgabenmanagement und die zugehörige Statuskontrolle vor, während und nach der Entwicklung. Doch um überhaupt zu wissen, welche Aufgaben zu erledigen sind (sprich welche Anforderungen einer Umsetzung in einem gewissen Sprint oder Release bedürfen) braucht es mehr als das. Gutes Requirements Engineering umfasst noch immer zentrale Kernfragen wie beispielsweise

  • Wer sind meine Stakeholder?
  • Was sind Ihre Bedürfnisse?
  • Welche Systemeigenschaften und -fähigkeiten (Anforderungen) resultieren daraus?
  • Wie wichtig sind diese Anforderungen jeweils?
  • Wie stehen die Anforderungen miteinander in Beziehung und welche Verfeinerung gibt es zwischen ihnen?
  • Haben wir wichtige Anforderungen vergessen oder unzureichend spezifiziert?
  • etc.

Bekannte Werkzeuge am Markt können dies natürlich kaum bis gar nicht beantworten. Der Nutzen von JIRA, aber genauso anderer altbekannter RM Tools im Hinblick auf die Qualität der Anforderungen hängt daher nachwievor einzig und allein von der individuellen Expertise einzelner Projektbeteiligten ab.

Die Anforderungsmanagement-Software ReqSuite®

Mit OSSENO’s ReqSuite® (siehe Abb. 1) wurde in den vergangenen Jahren jedoch ein Werkzeug für das Anforderungsmanagement präsentiert, das auch inhaltliche und methodische Fragestellungen unterstützt und durch intelligente Assistenzfunktionen die Qualität und Vollständigkeit von Anforderungen von Beginn an sicherstellen kann. Analog zu einem Programm für die Erstellung von Einkommenssteuererklärungen, das auch unerfahrene Personen bei der korrekten und vollständigen Erstellung standardisierter Steuererklärungen unterstützt, bietet ReqSuite® Konzepte um (ausreichend) gute Anforderungsdokumente in standardisierter Weise ungeachtet persönlicher Expertise im Bereich „Requirements Engineering“ zu entwickeln. Somit bietet die Assistenz von ReqSuite® auch bei der Beantwortung oben genannter Kernfragen Hilfestellungen und weist daneben auf Unvollständigkeiten oder Inkonsistenzen direkt während der Anforderungsdokumentation hin. Der Spruch „A fool with a tool is still a fool“ greift daher in diesem Kontext nur noch begrenzt.

Abb. 1: Beispielhafte Maske von ReqSuite®

Die Vorteile liegen auf der Hand und wurden bereits bei einer Vielzahl von Kunden bestätigt: Unklarheiten und Unvollständigkeiten, die zu kostspieligen Nacharbeiten vor, während oder gar nach der Entwicklung führen, werden proaktiv reduziert. Zugleich besteht stets eine Übersicht über noch unzureichend geklärte Aspekte, was (sofern man nicht wasserfallartig entwickelt) insbesondere bei der Festlegung parallel zur Analyse laufender Sprints erfolgsentscheidend ist. Schließlich automatisiert ReqSuite® auch Formulierungen und Formatierungen, so dass sich Anwender ganz auf die Inhalte von Anforderungen und weniger deren Syntax fokussieren können. Das schafft schließlich nicht nur mehr Freiraum für inhaltliche Arbeit, sondern erhöht auch die Akzeptanz von dem bisweilen häufig als schwergewichtig und antiquiert wahrgenommenen Requirements Engineering im Ganzen.

Doch sollte man jetzt sein etabliertes JIRA abschalten und nur noch mit ReqSuite® arbeiten? Ganz klar nein! Auch wenn die korrekte Antwort stets im individuellen Einzelfall beantwortet werden muss, so lässt sich grundsätzlich sagen, dass JIRA für viele Arbeitsschritte in der Softwareentwicklung eine Vielzahl wertvoller Features anbietet, die von ReqSuite® bis dato nicht angemessen substituiert werden möchten. Gleichwohl bietet ReqSuite® enorme Mehrwerte für das Requirements Engineering und ähnlich geartete Disziplinen, die von JIRA und seinen Erweiterungen und begleitenden Tools wie z.B. Confluence nur unzureichend erreicht werden können.

Entsprechend ist es vielversprechend, die gemeinsame und integrierte Nutzung von JIRA und ReqSuite® nachfolgend zu beleuchten.

Methodische Integration

Die methodische Integration von JIRA mit ReqSuite® ist stark davon abhängig, in welchem Unternehmens- und Entwicklungskontext man sich befindet. Dies betrifft einerseits den Entwicklungsgegenstand (z.B. die Weiterentwicklung eines Bestandssystems in einer Versicherung vs. die Entwicklung eines Steuermoduls im Maschinenbau), andererseits aber auch den Umfang der Entwicklungsaktivitäten (z.B. Projekt vs. Portfolio).

Dennoch lässt sich kontextübegreifend für eine Integration folgende Best Practice postulieren:

„ReqSuite® verwaltet die Inhalte (wozu auch Anforderungen gehören) und JIRA die Aufgaben innerhalb eines Portfolios oder Projekts.“

Gemäß dieser Best Practice macht es bei der Integration von JIRA und ReqSuite® wenig Sinn die Inhalte von ReqSuite® eins zu eins nach JIRA zu kopieren und quasi eine Redundanz in beiden Werkzeugen herzustellen. Vielmehr sollte eine inhaltliche Abstraktionsebene festgelegt werden, die als geeignete Ausgangsbasis zur Synchronisation eingesetzt werden kann.

Die wesentliche Herausforderung bei der methodischen Integration (aber auch generell bei der Definition eines sauberen methodischen Vorgehens) besteht folglich darin, die inhaltliche Verfeinerungsstruktur von Anforderungen bis hin auf die Ebene von Entwicklungsaktivitäten zu definieren. Hierfür gibt es in der Regel kein pauschales Modell, da diese Struktur maßgeblich vom Entwicklungsgegenstand abhängig ist.  Im Umfeld eines betrieblichen Informationssystemen könnte diese Struktur beispielsweise Anforderungen hinsichtlich der Geschäftsprozesse, Organisationseinheiten, Use Cases, Systemfunktionen, Geschäftsdaten und Schnittstellen beinhalten, die angemessen auf entsprechende Entwicklungsaktivitäten abgebildet werden müssten (lesen Sie hierzu auch unser WhitePaper zur Definition maßgeschneiderter Anforderungsprozesse).

Deshalb kann für den Zweck dieses Beitrags auch nur eine abstrakte Verfeinerungsstruktur aufgezeigt werden, die eine mögliche Aufteilung zwischen ReqSuite® und JIRA darstellt (siehe Abb. 2).

Abb. 2: Konzeptioneller Zusammenhang von Elementen in ReqSuite® und JIRA

Gemäß dieses Modells umfasst ReqSuite® Informationen über Stakeholder, ihren Kontext, ihren Bedarf sowie die daraus resultierenden Themen, Projekte und Anforderungen. In JIRA werden ergänzend die aus den Anforderungen resultierenden Entwicklungsaktivitäten gepflegt. Projekte und Projektbeteiligte werden ggf. redundant in beiden Tools gepflegt.

Melden nun Stakeholder Bedarfe, so werden diese in Form von Themenbeschreibungen innerhalb eines zugehörigen Portfolios in ReqSuite® spezifiziert. Portfolio- oder Programmmanager können dann nach entsprechender Prüfung und Priorisierung der Themen diese auf konkrete Projekte abbilden. Innerhalb von Projekten bietet ReqSuite® dann die oben erwähnte Assistenzfunktionen an, um die Projektbeteiligten bei einer sukzessiven und qualitätsgesicherten Herausarbeitung der Projektanforderungen unter Berücksichtigung des Kontextes angemessen zu unterstützen.

Zu beliebigen, aber auch fest definierbaren Zeitpunkten lassen sich dann automatisiert Entwicklungsaktivitäten (Tickets) auf Basis der Anforderungen ableiten und in das zugehörige JIRA-Projekt exportieren. Dabei kann, sofern konfiguriert, auch eine automatische Zuweisung auf die für die Umsetzung zuständigen Projektbeteiligten erfolgen. Nach entsprechender Erledigung ihrer Aufgaben können Sie dann den Status ihrer Aktivitäten aktualisieren, der dann bei der nächsten Synchronisation automatisch nach ReqSuite zurückgespiegelt wird und somit den Erfüllungsstatus der Anforderungen dokumentiert.

Eine wichtige Frage an dieser Stelle bleibt jedoch, wie schließlich einzelne (System-)Anforderungen auf Entwicklungsanforderungen für jeweilige Entwicklungsaktivitäten abgebildet werden können. Auch dies hängt maßgeblich vom Entwicklungskontext ab. So wäre es im obigen Beispiel denkbar, geschäftliche Anforderungen über verschiedene Abstraktionsebenen wie Geschäftsprozesse und Use Cases schrittweise bis auf die Ebene feingranularer Systemfunktionen herunterzubrechen, die zugleich den Inhalt einzelner Entwicklungsanforderungen darstellen. So würde beispielsweise die Anforderung „Als Sachbearbeiter Lebensversicherung möchte ich den Rückkaufwert eines Vertrages auf der Vertragsübersicht sehen, damit ich den Kunden schneller beauskunften kann.“ aus ReqSuite® wortgleich als Entwicklungsanforderung (Ticket) in JIRA übernommen und die resultierenden Entwicklungsaktivitäten für die Entwickler implizit sichtbar. Alternativ denkbare wäre jedoch auch eine weitere Verfeinerung der Anforderung in tatsächliche Aktivitätsbeschreibungen wie „Erweiterung der Maske LV-Ü1 um ein ReadOnly-Feld Rückkaufwert“. Letztere hätten den Nachteil erhöhter Spezifikationsaufwände, jedoch den Vorteil einer präziseren Aufgabenbeschreibung und eines feingranulareren Trackings.

Technische Integration

Ein Hauptargument, das zuweilen gegen die Verwendung mehrerer Werkzeuge angeführt wird, sind Integrations- und Konsistenzprobleme. Können Daten nur manuell oder ausschließlich teilautomatisiert zwischen verschiedenen Werkzeugen ausgetauscht werden, stellt dies nicht nur ein Effizienzhindernis, sondern auch eine enorme Fehlerquelle dar. Neben methodischen Integrationsaspekten spielt daher auch die technische Integrationsfähigkeit eine entscheidende Rolle. Die technische Integration von JIRA und ReqSuite® wurde daher mehrstufig, dynamisch und bidirektional ausgelegt.

Mehrstufige Integration

Auf der obersten Ebene der Integration steht die Verknüpfung von Projekten in ReqSuite® mit entsprechenden Projekten in JIRA in Form von einer 0..* – 0..1-Beziehung. Zu jedem Projekt in ReqSuite® kann max. ein Projekt in JIRA hinterlegt werden. Anders herum können aber mehrere ReqSuite®-Projekte Inhalte mit einem JIRA-Projekt synchronisieren. Der Grund für diese unsymetrische Beziehung ist, dass aus Sicht von ReqSuite® jeweils ein klarer „Abnehmer“ für die Anforderungen definiert sein soll. Anders herum kann jedoch ein JIRA-Projekte Inhalte aus verschiedenen ReqSuite®-Projekten konsolidieren, da ggf. der Zuschnitt innerhalb der Entwicklung anders organisiert wird wie auf Ebene der fachlichen Projekte innerhalb des Themenportfolios. In Abb. 3 ist beispielsweise zu sehen, dass das Projekt „IT-Anforderungen“ aus ReqSuite® mit dem Projekt „ReConf2017“ synchronisiert werden soll.

Abb. 3: Mapping von Projekten mit Auswahl der zu synchronisierenden Anforderungstypen

Auf der zweiten Ebene der Integration steht dann die Verknüpfung der Anforderungstypen aus ReqSuite® mit Issue Types in JIRA ebenfalls in Form einer 0..* – 0..1-Beziehung. In jedem Projekt lässt sich somit definieren, ob die Anforderungen eines gewissen Typs aus ReqSuite® überhaupt nach JIRA exportiert werden sollen, und, wenn ja, in Form welches Issue Types. Im oben genannten Beispiel könnte man somit einstellen, dass nur Anforderungen des Typs „Funktion“ mit JIRA synchronisiert werden sollen (siehe Abb. 3) und zwar in Form des Issue Types „Task“ (siehe Abb. 4).

Auf der dritten Ebene der Integration lässt sich schließlich ein feingranulares Attributmapping zwischen ReqSuite® und JIRA definieren. Neben einem Standardmapping (Name -> Summary und Beschreibung –> Description), lässt sich sehr individuell einstellen, wie einzelne Felder aus ReqSuite® mit JIRA-Feldern zusammenhängen. Dabei lassen sich auch die Projektbeteiligten automatisch mappen, so dass bereits in ReqSuite® die zur Umsetzung verantwortlichen Assignees in JIRA definiert werden können.

Abb. 4: Mapping von Anforderungstypen auf Issue Types sowie der zugehörigen Attribute

Dynamische Integration

Bei der Integration von ReqSuite® mit JIRA wurde großen Wert auf Flexibilität und Konfigurierbarkeit gelegt. Folglich wurde die Schnittstelle so entwickelt, dass kaum statische Mappings vordefiniert wurden, sondern vollständig zur Laufzeit ausgewählt werden können. Die integrierbaren Projekte, Anforderungstypen, Issue Types und Attribute sowohl in ReqSuite® als auch in JIRA werden dynamisch zur Laufzeit ermittelt und können dann entsprechend miteinander in Beziehung gesetzt werden. Somit ist es auch möglich, sogenannte Custom Types und Custom Attributes, also selbst definierte Typen und Felder, bei der Abbildung zu berücksichtigen.

Bidirektionale Integration

Unter bidirektionaler Integration versteht sich die Möglichkeit, nicht nur Inhalte von ReqSuite® nach JIRA zu übertragen, sondern auch bedarfsweise zurückzuspiegeln. Bei der Konfiguration der Schnittstelle lässt sich daher definieren, ob eine (bidirektionale) Synchronisation oder nur ein (unidirektionaler) Export von ReqSuite® nach JIRA gewünscht ist. Im Falle einer echten Synchronisation ist die Schnittstelle in der Lage, Änderungen auf beiden Seiten zusammenzuführen bzw. im Falle eines Konfliktes automatisch auf Basis hinterlegter Regeln aufzulösen. Dadurch können Reibungsverluste durch Inkonsistenzen nahezu ausgeschlossen werden.

Wann macht eine Integration Sinn?

Eine Integration von JIRA und ReqSuite® kann viele Vorteile für das Requirements Engineering und Management mit sich bringen. Konkret macht eine Nutzung von ReqSuite® zusätzlich zu JIRA insbesondere im Falle folgender Gegebenheiten Sinn.

Wenn Qualität oder Vollständigkeit der Anforderungen unzureichend sind

Wenn die Qualität, Vollständigkeit oder auch Standardisierung von Anforderungen nicht zufriedenstellend ist, bietet ReqSuite® exzellente Möglichkeiten um hierfür Abhilft zu schaffen. Dies ist häufig (aber nicht nur) dann der Fall, wenn technisch weniger versierte Kollegen und Kolleginnen aus Fachbereichen involviert werden sollen, die kaum Erfahrung mit dem Schreiben guter Anforderungen besitzen. Diese ohne Assistenz direkt in JIRA oder vorgelagerte Werkzeuge wie Confluence ihre Wünsche und Anforderungen schreiben zu lassen, bringt i.d.R. unvermeidbar nachträgliche und ggf. kostspielige Klärungen und Anpassungen mit sich.

Wenn neben „Tickets“ auch noch Dokumente benötigt werden

In vielen Organisationen werden im Rahmen der Projektarbeit diverse Dokumente benötigt, selbst wenn letztendlich agil entwickelt werden soll. Durch eine sauberere Trennung von Inhalt und Repräsentation in ReqSuite® kann zu diesem Zweck ReqSuite® automatisch alle benötigten Dokumente und Reports wie Projektanträge, Fachkonzepte, IT-Konzepte, Abnahmekonzepte, Angebote, etc. im gewünschten Corporate Design auf Knopfdruck generieren. JIRA ist hinsichtlich der Generierung solcher Dokumente stark limitiert.

Wenn eine gute Zusammenarbeit zwischen Fachbereich und IT gewünscht ist

Wenn eine gute Zusammenarbeit zwischen Fachbereich und IT gewünscht ist, macht auch eine klare Trennung von inhaltlichen Beschreibungen und entwicklungsrelevanten Aufgaben Sinn. Insbesondere ist es hierbei notwendig, die Sprache der Fachbereiche angemessen zu adressieren (die beispielsweise in Abläufen, Aufgaben und Dokumenten denken) und von technische Details oder Konzepten zu abstrahieren. Ein weiterer Vorteil der Trennung von Inhalt und Entwicklungsaufgabe ist, dass konkrete Entwicklungsaufgaben, die i.d.R. nur einmal im Rahmen eines konkreten Projektes vorgenommen werden müssen, klar von den darin umgesetzten Inhalten getrennt werden können, die sich ggf. projektübergreifend wiederholen (z.B. Datenglossare).

Wenn Projektbeteiligte nicht mit JIRA arbeiten können oder wollen

Auch wenn JIRA recht einfach zu bedienen ist, ist es nach wie vor ein Werkzeug von Entwicklern für Entwickler und keins in dem sich Fachbereichsmitarbeiter zu Hause fühlen. Insbesondere dann, wenn unklar ist, was eigentlich die Anforderungen sind und wie sie systematisch hergeleitet werden können, reicht die Vorgabe einfacher Schablonen für beispielsweise Epics und User Stories nicht aus, um die Bedarfe der Fachbereiche angemessen zu ermitteln. Hier macht es Sinn durch zielgruppenspezifischere Erfassungsmasken und Assistenzfunktionen die entsprechende Arbeit zu unterstützen. Während dies in JIRA nur aufwändig implementiert werden muss, bringt ReqSuite® einfache, aber mächtige Features von Haus aus mit.

Fazit

Der Erfolg und Nutzen von JIRA ist unbestritten und soll in diesem Artikel in keinster Weise geschmälert werden. Dennoch ist insbesondere bei einer bereichsübergreifenden Zusammenarbeit die Nutzung zusätzlicher Werkzeuge insbesondere auf Seiten der Fachbereiche wünschenswert. Vielumworbene Produkte, die gerne im Bundle mit JIRA beworben werden, bieten jedoch keine wirkliche Arbeitsassistenz für Projektbeteiligte und stellen oft nicht mehr als eine webbasierte Word-Alternative dar; mit allen Vor- und Nachteilen wie man sie aus der Arbeit mit Office-Produkten bis dato kannte. Sofern oben genannte Aspekte gegeben sind, sollte daher über die ergänzende Nutzung von ReqSuite® als übergreifendes und vor allem inhaltsfokussiertes Portfolio- und Anforderungswerkzeug nachgedacht werden.