ALM-Prognosen #2: ALM aus einer Hand stirbt aus

Da kein Software-Stack im Application Lifecycle Management dem anderen gleicht, schützen sich zunehmend Vertreter aus Entwicklung und Management vor der komplizierten Implementierung der ALM-Komponenten, indem sie sich unabhängigen Softwareherstellern anvertrauen.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 9 Min.
Von
  • Mik Kersten
Inhaltsverzeichnis

Da kein Software-Stack im Application Lifecycle Management dem anderen gleicht, schützen sich zunehmend Vertreter aus Entwicklung und Management vor der komplizierten Implementierung der ALM-Komponenten, indem sie sich unabhängigen Softwareherstellern anvertrauen.

Die Entwicklungsleiter bei Firmen mit großen Software-Stacks für das Application Lifecycle Management hatten einst ein schönes Leben. Die einzelnen ALM-Komponenten waren gut integriert, spielten schön zusammen, und wenn das nicht der Fall war, konnte man sich an jemand anderen wenden. Im Laufe der Zeit schlichen sich aber "leichtgewichtige" Issue Tracker in die Organisation ein und wurden aufgrund ihrer Funktionen zur einfacheren Kollaboration zwischen Entwicklern zunehmend beliebter. Da sie günstiger oder sogar kostenlos zu erwerben waren, wurden sie oft einfach ohne vorherige Absprache der jeweiligen IT-Abteilung eingeführt.

Dann kamen agile Projekt-Tracking-Tools dazu, und wegen der ganzen Aufregung rund um "Agile" führten Teamleiter und Produktmanager diese ein, ohne dafür in den Firmen einen standardisierten Prozess zu erwägen. Jedoch waren Qualitätssicherungswerkzeuge wie HPs Quality Center in ihrem Bereich so etabliert und vom Management geschätzt, dass sie nicht durch die neueren Tools ersetzt wurden. Das Ergebnis hiervon ist, dass die Tool-Stacks dieser Organisationen an ein ALM-Geschichtsmuseum erinnern, das von den alten, immer noch verwendeten Fehler-Trackern der Firma selbst bis zu neu installierten Kanban-Tools reicht, die die Ernüchterung rund um die Erfahrungen mit Scrum verdecken sollen.

Kein ALM-Stack gleicht also dem anderen. Der Erfolg von Open-Source-Komponenten im ALM-Markt brachte Vielfältigkeit selbst in die kleinsten Software-Shops, und so ist heute Heterogenität die Norm in der ALM-Tool Landschaft. Während das den Vorteil mit sich bringt, das für einen beste Produkt wählen zu können, bedeutet das auch, mit der neuen Komplexität durch die vielen Tools umgehen zu müssen, sobald darüber nachgedacht wird, wie sich der ALM-Stack modernisieren lässt, um eine agile Entwicklung zu unterstützen.

Dieser Artikel gibt eine kurze Anleitung zum Bewältigen eben dieser Komplexität, indem man sich auf die Issue-, Projekt- und auch die Change-Management-Schicht konzentriert. Die Unterstützung durch Werkzeuge in diesen Bereichen besteht im Wesentlichen daraus, die einzelnen Schritte und Abstufungen von Aufgaben der Softwareentwicklung festzuhalten.

Grundlegend gibt es Tasks, die mit dem Code selbst verknüpft sind und sich aus Fehlermeldungen, Feature-Requests und Tests zusammensetzen. Auf der nächsten Ebene gibt es eine weitere Abstraktion, um entwicklungsspezifische, ebenfalls als Tasks festgehaltene Items auch für das Management und die Planung zu verwenden, wie User Stories und Anforderungen. Genau hierbei ist die neue Generation agiler Tools beliebt. Schließlich gibt es noch die großen ALM-Tool-Suiten, mit denen sich übergreifend sowohl Produkte, Releases und Portfolios festhalten und nachvollziehen lassen.

Planungsstufen der Tasks

2010 zählte eine Studie im Bereich ALM mehr als 100 Issue Tracker und Change-Management-Tools. Die enorme Vielfalt hat als innovatives Ergebnis zur Folge, dass Anbieter ihre Angebote unterscheidbarer gestalten, damit sie noch Kunden gewinnen und Profit aus dem stetig steigenden Vermarktungsgrad im Open-Source-Bereich zu schlagen können. In den letzten Jahren war zudem festzustellen, dass im Fall der Issue Tracker die Preise für Supportleistungen bei kleinen Teams rapide gefallen sind. Hinsichtlich ihrer Funktionen beginnen die Issue-Tracker-Systeme sich allerdings immer mehr anzugleichen, und ihre offensichtlichsten Unterschiede sind die Farbkombinationen und das Design der Bedienoberflächen.

Zu konstatieren ist, dass der Issue Tracker Massenware geworden ist. Es sollte bei einem Issue Tracker darauf geachtet werden, dass er die Zusammenarbeit der Entwickler unterstützt und benutzerfreundlich hinsichtlich der Kommentare und Veränderungen sowie im Arbeitsablauf des Entwicklers integriert ist. Auch sollten ihre Planungen ihre Entsprechung im Issue Tracker haben. Handelt es sich um ein kleines Team oder eine kleine Firma, kann das genauso einfach sein, wie ein Release oder eine Iteration zu verwalten oder ein Wiki-basiertes Kanban Board mit Hyperlinks zu den Issues hinzuzufügen. Aber bei größeren Teams sollten Tools mit dem Planungsprozess über Teams und verschiedene Standorte hinweg skalieren.