Toolchain: Einer um uns alle zu knechten?

Atlassian Jira & Confluence

Sie werden es vielleicht bereits ahnen, welches Tool ich meine: das Konvolut aus Atlassian Jira & Confluence. In unserem Projektalltag sehen wir kaum ein (IT) Unternehmen, das noch nicht (zu welchen Teilen auch immer) auf dieses dynamische Duo setzt - insofern darf ein Artikel dazu natürlich nicht fehlen.

Dabei sind die Anwendungsgebiete teils wirklich überraschend: Von der Grundidee, Issues (oder wer es in Deutsch nutzt: Vorgänge) zu verwalten ist man dabei meistens bereits meilenweit entfernt. Durch die (äußerst) komplexe und (überbordend) umfangreiche Möglichkeit ein Jira Projekt anzupassen ist es defakto möglich, *alles* in einem Jira Projekt abzubilden. Da findet man neben den (mittlerweile) Standard Einsatzgebieten wie das Management kompletter agiler Projekte, oder der Verwaltung einfacher ToDo-Listen auch etwas kuriosere Konfigurationen wie die Abbildung des Jahresabschlusses der Finanzabteilung oder die Sammlung und Auswertung von Unternehmens-Gamifications

Toollandschaft beibehalten oder ablösen?

Als SEQIS-Mitarbeiter versuchen wir immer die vorhandenen Produkte unserer Kunden zu berücksichtigen: passt das aktuell eingesetzte Tool noch ins Zielbild, welche Gaps, Probleme oder Workarounds werden nötig sein und wie verhält sich das zu einem Umstieg auf ein oder mehrere neue Tools?

Zumeist bleibt man bei der vorhandenen Toollandschaft, das ist dann oft Atlassian. Unter uns: haben Sie schon mal das lang verwendete Tool X durch Tool Y in Ihrem Unternehmen abgelöst? Solche Vorhaben führen fast immer zu sehr spannenden Projekten! Also bleiben wir bei den Atlassian Produkten, die können ja eh alles... mehr oder weniger. Durch das Tester Auge betrachtet kann Jira in Wahrheit gar nicht so viel. Klar, man kann Jira schon so herrichten, dass alle testrelevanten Artefakte und Informationen persistiert und analysiert werden können, nur das führt entweder zu 1) erheblichen Abstrichen bei der Benutzbarkeit, Intuivität und auch im Punkto Funktionsumfang oder 2) zu kostenpflichtigen AddOns (Zephyr und XRay seien hier genannt) und nicht ganz so hohen Abstrichen der Punkte unter 1).

Wie man es dreht und wendet, Jira ist aus Test und Testmanagement Sicht sicher nicht das Tool ganz oben auf der Liste der potentiellen Kandidaten (nicht, dass die Liste so lange wäre...). Die Ursache ist auch einfach zu nennen: Jira ist und bleibt ein Ticketing Tool! Testen und Testmanagement bedingt eben mehr als das: unter anderem sollen parametrisierbare Komponenten zu Testfällen verknüpft werden, Anforderungen abgedeckt, Testfälle zu TestSets gruppiert, Testsessions geplant, durchgeführt und dokumentiert, Abweichungen erfasst und der aktuelle Qualitätszustand über alle Teststufen jederzeit einfach dargestellt werden können. Und auch wenn Einiges davon durch die beiden genannten AddOns möglich ist, es fühlt sich trotzdem nicht gut an.

Wer passt sich an?

Spätestens jetzt stellt sich die Frage: wollen wir uns und unsere Arbeitsweise an ein Tool anpassen oder soll sich die Toolchain an unsere Anforderungen anpassen? Bei dieser Fragestellung werden fast alle mit "natürlich muss sich die Toolchain anpassen" antworten, aber wieso tut sie das im Regelfall dann doch nicht? Atlassian hat das schon ganz geschickt gemacht: der Einstieg in die Produkte ist schnell, einfach und günstig. Und ehe man sich versieht, will man sie nicht mehr hergeben. Dann beginnt man mit AddOns und Customisierungen die wachsenden Anforderungen doch noch irgendwie ins Jira hineinzubekommen, und letztendlich ist man genau dort: wir passen uns an das Tool an und nicht mehr umgekehrt.