Letztens hat TechCrunch Death to JIRA veröffentlicht, einen Artikel, der die Herausforderungen der Software-Entwicklung am Beispiel eines der mächtigsten Tools am Markt thematisiert hat. Autor John Evans hat agile Entwicklung sinnlos verdreht, um Argumente für eine bessere Kommunikation in Software-Projekten zu haben. Ich möchte einige Punkte über agile Entwicklung aufklären, bei denen der Autor daneben lag.
Im Grunde ist JIRA ins Fadenkreuz geraten, weil es so ein populäres agiles Tool ist – ganz so, wie in einem Artikel über Taschentücher Kleenex im Zentrum gestanden hätte. Nach Evans' Erfahrungen ist Ticketing problematisch, weil Teams es nutzen, um ihre Projektanforderungen zu definieren. Seine Lösung ist "gute Prosa". Speziell erklärt Evans, dass "... ein gut geschriebenes achtseitiges Dokument die Nuancen eines komplizierten Systems weitaus besser definieren kann als die ganze schwerfällige Flottille von miteinander verknüpften JIRA-Tickets". Evans erklärt nicht, was in dem achtseitigen Dokument stehen soll (abgesehen von "Wörtern in einer Reihe"). Und er sagt, dass Sie das Dokument automatisch in kleinere Elemente aufteilen sollten oder, falls Sie das müssen, in Tickets (auch bekannt als Vorgänge oder Stories).
Laut Evans "steht das Design von JIRA guter Software-Entwicklung fundamental entgegen, wenn es für irgend etwas genutzt wird, das über simples Bugtracking hinausgeht". Aber wie Evans später eingesteht: "Die große Sünde von JIRA besteht nur darin, das erfolgreichste und am weitesten verbreitete Ticketsystem zu sein. Die Vorstellung, ein Software-Projekt mit einem Set von Tickets zu spezifizieren, ist an sich der Feind."
Mit anderen Worten: Der Text ist in Wirklichkeit eine Tirade gegen Entwicklungsteams, die am Ausarbeiten ihrer Projektanforderungen scheitern. Aber "Warum Sie acht Seiten schreiben sollten, um Ihr Software-Projekt zu definieren" ist keine so griffige Überschrift wie "Death to JIRA".
Die Sache ist die: Ticketsysteme für die agile Entwicklung sind nicht designt, um die Nuancen eines komplizierten Systems abzubilden. cPrime hat JIRA in mehr als 500 Unternehmen aller Größen implementiert. Wir trainieren unsere Kunden darin, die Bedeutung der Dokumentation von Projektanforderungen zu verstehen. "Death to JIRA" übergeht diverse Produkte auf dem Markt (wie Google Docs und Atlassians eigene Lösung Confluence, die es seit 2004 gibt), die exakt für dieses Thema entwickelt wurden. Agile Entwickler nutzen sie parallel mit Tools wie JIRA.
Tools zur Zusammenarbeit an Dokumenten sind dazu da, Produktanforderungen abzubilden, eine Roadmap, Release-Termine und andere Infos, die in dem Achtseiter auftauchen würden. Entwickler nutzen diese Tools, um Anforderungen in Epics, Sub-Stories und Releases in ihren agilen Entwicklungswerkzeugen zu übersetzen. Nach unseren Erfahrungen sind Kunden erfolgreich damit, Produkte wie JIRA als Plattform für Planungszwecke, für das Abbilden von Abhängigkeiten und für das Erstellen einer Roadmap und eines Release-Plans zu nutzen. Das Ticketsystem übersetzt Anforderungen einfach in eine Reihe kohärenter, zuweisbarer Aufgaben.
Also will Evans die Leser Glauben machen, dass JIRA (das heißt: der agile Ansatz) "guter Software-Entwicklung entgegensteht", weil Unternehmen solche Plattformen missbrauchen können. Wenn Sie mal versucht haben, einen Weihnachtsbaum mit einem Vorschlaghammer abzuhacken, und daran gescheitert sind, könnten Sie nach derselben Logik einen Artikel mit dem Titel "Tod dem Vorschlaghammer" schreiben. Wenn man ein Werkzeug falsch gebraucht und es nicht klappt, ist es verlockend, die Schuld beim Werkzeug zu suchen.
Wenn DevOps-Teams moderne Entwicklungs-Software nutzen, können sie all das tun, von dem Evans behauptet, sie könnten es nicht. Sie können die komplexen Beziehungen zwischen Stories (Tickets) abbilden. Sie können an Subsystem A, Subsystem B und Interface AB iterativ arbeiten, weil die Entwickler unabhängige, automatisierte, Cloud-basierte Testumgebungen haben. Sie fühlen sich nicht psychologisch unter Druck gesetzt, nie mehr als eine Story zu einer Zeit zu bearbeiten. Tatsächlich halten viele Teams ihre Stories absichtlich offen und schließen sie am Ende eines Sprints. Und nein, Stories beanspruchen die Software-Architektur nicht für sich – die Anforderungen, die im Anforderungsdokument dargelegt sind, bilden die Architektur, die wiederum die Stories formt.
Nun denken wir mal über Evans' achtseitiges Dokument nach: Wie entwickelt sich das in einem dynamischen, iterativen Projekt, ohne jedermann zu verwirren? Die meisten Software-Produkte werden nicht in der Isolation von einem einzelnen Individuum entwickelt. Sie werden von Teams gebaut oder oft sogar von vielen Teams. Das achtseitige Dokument kann nicht skalieren, wenn ein Software-Team auf 50, von 50 auf 100, von 100 auf 500, von 500 auf 5.000 Mitarbeiter wächst.
Atlassian Confluence auf der anderen Seite stellt fest, wenn Teammitglieder Aufgaben fertigstellen und Aktualisierungen teilen. Änderungen in Confluence ändern die Stories. Wenn Sie den Achtseiter erstmal in Zuweisungen aufgegliedert haben, wie es Evans empfiehlt, würde die Rückverfolgung chaotisch. Fein, Sie könnten den Achtseiter in ein Cloud-Dokument packen und die Mitarbeiter es modifizieren lassen. Aber wenn Sie mal die Schmerzen erlebt haben, ein Cloud-Dokument gemeinsam mit fünf Leuten zu editieren, verstehen Sie, warum es ins totale Fiasko führen würde, es mit 2.000 Entwicklern zu teilen.
"Death to JIRA" ist lediglich eine Ode an die Wasserfallentwicklung, wieder aufgewärmt im Namen guter Prosa. Beim Skalieren untergräbt die Hyper-Zentralisierung des Wasserfallmodells den iterativen Prozess, den Evans zu wertschätzen behauptet. Agile Entwicklung, DevOps und Plattformen wie JIRA sind Reaktionen auf den Wasserfall. Sie haben Entwicklern geholfen, Geschwindigkeit, Produktivität, Qualitätssicherung, Uptime und andere Kennzeichen einer guten Software-Entwicklung zu verbessern. Ich möchte darauf hinweisen, dass Evans' eigener Arbeitgeber in seinen Stellenanzeigen JIRA-Skills sucht, so wie es eine lange Liste von Unternehmen tut, die bahnbrechende Software entwickeln.
Ein Ticketsystem kommuniziert keine Systemanforderungen; es übersetzt sie in Aufgaben. Geben wir uns aber keinen Illusionen hin: JIRA ist eine komplexe Software. Wie Salesfoce, NetSuite und andere mächtige Produkte, muss auch JIRA ordentlich konfiguriert sein.
"Death to JIRA" bläst nicht gegen Agile zum Angriff, sondern ist eher ein Ruf nach besserer Kommunikation in der Software-Entwicklung. Ich kann das verstehen, aber es gab keinen Grund, Agile zu verdrehen, um darauf hinzuweisen.
Dieser Artikel ist am 23. Dezember 2016 unter dem Titel Untangling Agile Development Misconceptions im Weblog von cPrime erschienen. Der Autor ist Zubin Irani. cPrime gehört zu den führenden Dienstleistern für Lösungen, die Unternehmen helfen, agile Entwicklungsmethoden zu adaptieren, zu transformieren und zu skalieren. Dabei fokussiert sich cPrime auf die Harmonisierung von Menschen, Prozessen und Technologien, um Frameworks aufzubauen und zu optimieren, die geschäftliches Wachstum mit hoher Geschwindigkeit und hoher Qualität unterstützen. Die Website von cPrime erreichen Sie unter www.cprime.com.
