Information: YAKINDU Traceability Is Now itemis ANALYZE
Agiles Arbeiten steht bei vielen Unternehmen auf der Tagesordnung. Mal funktioniert es besser, mal schlechter – je nachdem wie gut die agilen Prinzipien und Werte verstanden und gelebt werden. Doch ob ein Unternehmen mit klassischen Projektmanagement-Methoden arbeitet oder agile Frameworks wie Scrum einsetzt, gewisse Anforderungen bleiben gleich. So sollte ein Projekt Transparenz und Traceability – also die Nachverfolgbarkeit von Anforderungen – beispielsweise durch Status-Tracking gewährleisten können.
Warum Nachverfolgbarkeit so wichtig ist
In vielen meiner bisherigen Projekte haben wir mit Jira oder anderen Projektmanagement-Werkzeugen gearbeitet, um Transparenz gewährleisten zu können. Durch die Nutzung eines Jira Agile Boards lassen sich beispielsweise nicht nur einfach Sprints planen und überwachen, auch der Status eines Produktes lässt sich mit Hilfe von Release-Plänen nachverfolgen und verwalten.
Wenn wir uns nun Branchen und Projekte anschauen, in denen das Thema Nachverfolgbarkeit und Verlinkung von Arbeitsartefakten einen teilweise noch viel höheren Stellenwert hat, dann stößt man mit einem reinen Projektmanagement-Werkzeug schnell an seine Grenzen. Vor allem dann, wenn die Anforderungen aus verschiedenen Dokumenten und Quellen stammen. Nehmen wir als Beispiel die Automobilindustrie: Die Rückverfolgbarkeit ist in dieser Branche ein zentraler Aspekt und beispielsweise eine notwendige Voraussetzung für ein erfolgreiches Automotive SPICE Assessment. Bei Automotive SPICE handelt es sich um einen Qualitätsstandard, der eine Bewertung der Leistungsfähigkeit der Entwicklungsprozesse von Zulieferern durch den Automobilhersteller ermöglicht. Im Kern ist das Ziel von Traceability somit, den Status der Umsetzung eines Requirements nachzuverfolgen und sichtbar zu machen. Die Projektleitung kann somit zu jeder Zeit den Grad der Umsetzung ihrer Anforderungen nachweisen und besser planen. Außerdem können die Auswirkungen bei Änderungen sicher identifiziert und der erneute Test ausreichend durchgeführt und dokumentiert werden.
Doch wie lässt sich diese notwendige Nachverfolgbarkeit nun in einem agilen Prozess gewährleisten? Wie kann man dafür sorgen, dass, alle System- und Stakeholder-Anforderungen korrekt mit Testfällen oder Implementierungen verknüpft sind?
Dies möchte ich an einem Beispielszenario zeigen:
Nehmen wir dazu an, ein Projektteam aus der Automobilbranche nutzt ein Jira Agile Board, um seine Arbeit innerhalb der Sprints zu tracken. Wie schafft es das Team nun, die initialen Anforderungen über mehrere Stufen hinweg nachverfolgbar zu machen?
Nachverfolgbarkeit mit Jira in agilen Projekten
Prinzipiell lassen sich in Jira Testpläne erstellen und gleichzeitig mit User Stories, bzw. Anforderungen, verknüpfen. Weiterhin ist es möglich, diese Testpläne zu durchlaufen und automatisiert Bugs erstellen zu lassen, die sich aus der Nicht-Erfüllung eines Testplans ergeben. Diese Bugs stehen dann in direkter Verbindung zu der jeweiligen User Story und demnach der initialen Anforderung. Das funktioniert solange gut, wie die Anforderungen als User Story, Tasks, Epics oder ähnlichem in Jira formuliert werden. Befinden sich die Anforderungen oder Test Cases jedoch nicht ausschließlich in Jira, sondern auch in anderen Dokumenten (Word, Excel oder Anforderungs-Werkzeugen wie PTC Integrity oder IBM DOORS), dann kann die einwandfreie Nachverfolgbarkeit nicht mehr gewährleistet werden. Darüber hinaus lassen sich mit Jira alleine beispielsweise auch keine Anforderungsdokumente miteinander verknüpfen oder gar Änderungen an diesen Dokumenten nachverfolgen.
Nachverfolgbarkeit mit Werkzeugunterstützung sicherstellen
Natürlich gibt es auch andere Wege, solche Anforderungen nachzuverfolgen und miteinander zu verknüpfen, beispielsweise mit der Hilfe eines dedizierten Traceability- Werkzeugs wie YAKINDU Traceability (now itemis ANALYZE) (YT). In diesem Tool kann der Nutzer Artefakte aus verschiedenen Datenquellen miteinander verbinden und anschließend analysieren, unabhängig davon, ob es sich um direkte oder indirekte Verlinkungen handelt. Direkt meint in diesem Fall, dass eine direkte Verbindung – z. B. zwischen einer Anforderung (gespeichert in DOORS) und einem Test Case (erfasst in Excel) – vorliegt, wohingegen indirekt eine implizite Verbindung – beispielsweise zwischen dem Test Case und der Implementierung (umgesetzt in Simulink) – bedeutet (s. Abbildung 1).
Abbildung 1: Beispielhafte Darstellung von verlinkten Arbeitsartefakten
Die Möglichkeiten mit YAKINDU Traceability (now itemis ANALYZE) sind vielfältig – von der reinen Darstellung der bestehenden Verknüpfungen, dem Ziehen von neuen Links, der Analyse bestehender Links oder dem Aufdecken von kaputten und fehlenden Verlinkungen. Allerdings ist YT kein agiles Projektmanagement-Werkzeug und schon gar kein Ticketsystem. Für genau solche Arbeiten eignen sich, wie bereits erwähnt, Werkzeuge wie Jira. Wünschenswert wäre eine Kombination der beiden beschriebenen Ansätze, um in agilen Projekten zum einen den aktuellen Status sichtbar zu haben und zum anderen die Nachverfolgbarkeit über alle Anforderungen hinweg zu gewährleisten.
Projektmanagement und Traceability verknüpfen
Ich möchte euch gerne anhand eines konkreten Beispiels die Möglichkeiten von YAKINDU Traceability (now itemis ANALYZE) im Zusammenhang mit Jira vorstellen.
Wir sehen in Abbildung 2 ein recht übersichtliches Product Backlog, in welchem sich User Stories für die Funktionalitäten einer Scheibenwischanlage befinden. Der erste Sprint ist bereits geplant und befindet sich gerade in der Durchführung. Die User Stories WW-3 und WW-4 sind sogar schon abgeschlossen. Darüber hinaus ist jede User Story einem Epic zugeordnet (“Auto Wiping” oder “Disable Wiper Washer”) und besitzt eine Versionsnummer wie z. B. “WW (1.0.1)”. Die initialen Anforderungen an dieses Produkt stammen aus DOORS und werden dort in Stakeholder und System Requirements unterteilt. Aus den System Requirements wurden in diesem Beispiel die User Stories verfasst.
Abbildung 2: Jira Agile Board “Wiper Washer”
Jetzt möchte das Projektmanagement oder in unserem Fall der Product Owner wissen, zu welchem Zeitpunkt ein bestimmtes Stakeholder Requirement umgesetzt ist. In diesem Fall lässt sich mit YAKINDU Traceability (now itemis ANALYZE) ein Report erstellen, der alle Stakeholder Requirements auflistet und die verlinkten User Stories anzeigt. In unserem Beispiel sehen wir, dass es zudem mehrere Stakeholder Requirements gibt, die gar nicht verlinkt sind (s. Abbildung 3, Zeile 2-10).
Abbildung 3: YAKINDU Traceability (now itemis ANALYZE) Report für das Projekt “Wiper Washer”
Wir sehen jedoch auch, welche Stakeholder Requirements verlinkt wurden, welche User Stories dazu gehören – inklusive der geschätzten Story Points – und welche Release-Version sie besitzen. Da die Projektleitung in unserem Beispiel lediglich die Stakeholder Requirements interessieren und nicht die System Requirements, werden nur erstere in dem Report aufgelistet. Die Anforderung SH-R: 2.1.2 Configurable sensitivity of auto wiping hängt beispielsweise von drei verschiedenen User Stories ab und wird erst im zweiten Release (WW 1.0.2) fertiggestellt. Was sich aus diesem Report nicht ablesen lässt ist, welche der drei verlinkten User Stories der genaue Auslöser für diesen Zeitplan ist.
Diese Information lässt sich jedoch aus dem YT Overview ableiten (s. Abbildung 4). Hier ist zunächst zu erkennen, dass aus dem Stakeholder Requirement SH-R: 2.1.2 das System Requirement Sys-R: 2.1.2 abgeleitet wurde und mit diesem wiederum die drei User Stories WW-4, WW-5 und WW-6 verknüpft sind.
Abbildung 4: YAKINDU Traceability (now itemis ANALYZE) Overview für das Projekt “Wiper Washer”
Da auch die Release Version in dieser Übersicht dargestellt wird, können die Projektleitung oder der Product Owner sehr schnell sehen, dass die User Story WW-5 für die Verzögerung im Zeitplan verantwortlich ist, da sie erst für das zweite Release eingeplant ist. Ebenfalls im YT Overview zu sehen, ist die Anforderung SH-R: 2.1.1, welche mit einem System Requirement verlinkt ist, das wiederum nur durch eine User Story (WW-3) im Jira ausgedrückt wird.
Das Ergebnis des YT Overviews wurde mit Hilfe der folgenden YT Query erzielt:
Abbildung 5: YAKINDU Traceability (now itemis ANALYZE) Query für das Projekt “Wiper Washer”
Für diejenigen, die sich weiter zu Queries informieren möchten, empfehle ich den Blogbeitrag “A Language to Analyse Trace Data Efficiently”.
Mittels YT Report und dem YT Overview lassen sich so Anforderungen aus verschiedenen Quellen (in unserem Beispiel aus DOORS) auswerten und Aussagen über ihre Umsetzung bzw. Fertigstellung treffen. In Zusammenarbeit können Jira und YAKINDU Traceability (now itemis ANALYZE) somit zum agilen Werkzeug für die Planung von Anforderungen werden, das den Product Owner unterstützt, wenn es um die Zusammenführung und Nachverfolgbarkeit der Anforderungen aus verschiedenen Quellen geht.
Fazit: agil und transparent
Transparenz spielt nicht nur im agilen Umfeld eine wichtige Rolle. Insbesondere in der Automobilbranche ist eine lückenlose Traceability von der initialen Anforderung bis hin zu den entsprechenden Testfällen im Hinblick auf Standards wie Automotive SPICE gefordert. Doch auch in anderen Bereichen und Projekten kann es sinnvoll sein, sich mit dem Thema der Nachverfolgbarkeit von Anforderungen auseinander zu setzen, wie auch eine Studie von Prof. Dr. Patrick Mäder et. al. gezeigt hat. Mit Jira lassen sich gerade im agilen Umfeld Projekte transparent planen und mit Hilfe von Sprints, Roadmaps und Reporting-Möglichkeiten nachverfolgen. Doch nicht immer sind alle Projektanforderungen in Form von Jira-Tickets erfasst, sodass eine Nachverfolgbarkeit über alle Anforderungen hinweg nicht mehr vollends gewährleistet werden kann. In diesem Fall hilft ein dediziertes Werkzeug wie YAKINDU Traceability (now itemis ANALYZE) weiter, indem es die Anforderungen aus verschiedensten Dokumenten und Quellen mit den entsprechenden Jira-Tickets verknüpft. So haben wir über den gesamten Projektverlauf nicht nur die Möglichkeit, nachzuvollziehen, welche Anforderungen bereits umgesetzt wurden, sondern auch in welchem Status sie sich befinden, in welchem Sprint sie eingeplant sind oder für welche Anforderung noch keine User Story existiert.
Wenn ihr noch mehr über die Funktionalitäten und Anwendungsmöglichkeiten von YAKINDU Traceability (now itemis ANALYZE) wissen wollt, dann schaut auf unserer Produktseite vorbei.
Kommentare