Inhaltsverzeichnis
1. Erst Scrum, dann ALM
2. Gesamte Entwicklungsplanung im ALM-System
3. Effiziente Reaktion auf Programmierfehler
4. Hohe Akzeptanz durch die Anwender
Application Lifecycle Management (ALM) ist keine neue Erfindung, sondern mindestens so alt wie die PLM-Systeme aus der mechanischen Konstruktion. Doch mit der zunehmenden Integration der Bereiche Mechanik, Elektronik und Software gewinnen ALM-Systeme und vor allem deren Kopplung mit PLM an Bedeutung. Und nimmt man das Schlagwort des „Digitalen Zwillings“ ernst, kommt man an ALM und an der Kopplung zwischen ALM und PLM nicht vorbei. Software beeinflusst die Funktionalität des Produkts, interagiert mit und steuert Elektronik und Mechanik. Ein umfassendes Bild des Produkts kann nur entstehen, wenn auch die Software, deren Anforderungen und Funktionen im Gesamtmodell berücksichtigt werden.
Diese Bedeutung zeigte sich unter anderem zum Ende des Jahres 2015, als Siemens Polarion Software sowie deren ALM-System Polarion ALM übernahm und von Anfang an die Integration der Software in sein PLM-System Teamcenter in den Vordergrund stellte. Der langjährige Siemens PLM Software Partner BCT Technology AG war, als die Übernahme durch Siemens bekannt wurde, mitten in der Evaluation von Polarion für die eigene Softwareentwicklung. Seit Ende 2016 arbeitet BCT bei der Entwicklung seiner eigenen Softwarelösungen mit Polarion. So kann das Systemhaus aus einem reichen Erfahrungsschatz heraus seine Kunden bei der Einführung einer ALM- beziehungsweise integrierten ALM/PLM–Lösung unterstützen. Business Development Manager Martin Anliker erläutert, was die Beweggründe der Kunden sind, sich mit ALM zu beschäftigen: „Die meisten kommen über das Thema regulatorische Vorschriften – ob SPICE in der Automobilbranche oder FDA-Regularien im Pharmabereich. Die Vorschriften, die in der Softwareentwicklung zu beachten sind, werden immer umfangreicher und komplexer. Im Maschinen- und Anlagenbau beschäftigt das Thema Funktionale Sicherheit die Firmen. Diese Anforderungen bekommt man ohne ALM irgendwann nicht mehr in den Griff.“ Ein zweiter Treiber für die ALM-Einführung ist die steigende Bedeutung unternehmensübergreifender Projektteams. Wenn man im Verbund mehrerer Unternehmen oder in gemeinsamen Projekten mit Kunden und Lieferanten Software entwickelt, ist eine geregelte und automatisierte Überwachung der Requirements unabdingbar. Die Interessenten lassen sich nach Angaben Anlikers in zwei Gruppen einordnen: Viele Unternehmen lernen Polarion beziehungsweise ALM in den erwähnten unternehmensübergreifenden Projektgruppen kennen, wenn einer der Partner ALM einsetzt. Anliker sagt: „Diese Kunden wissen meist genau, was sie wollen und was ALM leisten kann. Die andere Gruppe beschäftigt sich eher abstrakt mit ALM, sieht den Bedarf nach Management und Strukturierung der Softwareentwicklung, benötigt aber noch Informationen. Hier arbeiten wir mit Prozessberatung und Workshops, um den Bedarf zu konkretisieren und ein Verständnis für die Funktionen, die ALM abdecken kann, zu vermitteln.“
Erst Scrum, dann ALM
Polarion selbst ist ein Baukasten, aus dem mit Hilfe von Templates ein nutzbares Managementsystem entsteht. Diese Templates entwickelt das Willstätter Systemhaus in der Einführungsphase gemeinsam mit dem Kunden, der Hersteller bietet jedoch auch ein Extension Portal an, in dem vorgefertigte Vorlagen zum Download liegen. „Das Schöne an dieser ALM-Software ist die einfache Konfiguration“, erläutert Anliker, „dafür stellt sie eine webbasierte Oberfläche zur Verfügung, die den Anwender sehr schön durch die Konfiguration führt. Unsere Kunden sind sehr schnell in der Lage, ihre Software selbst anzupassen. Das zeigt sich auch in der Einführung – wo ein PLM-Projekt schnell mal 100 Projekttage umfassen kann, erfordert die Einführung eines Polarion-Systems 6–14 Projekttage.“ BCT vertreibt die ALM-Software nicht nur, sondern ist auch selbst Anwender – in Willstätt arbeiten die Softwareentwickler, die Zusatzanwendungen und Anpassungen für Teamcenter, NX und andere Softwareprodukte schreiben, mit dem ALM-System.
Im Jahr 2014 führte das Systemhaus in der gesamten Softwareentwicklung das Vorgehensmodell Scrum ein, das eine Umsetzung des Agile-Ansatzes ermöglicht. Scrum besteht aus wenigen Regeln, die fünf Aktivitäten, drei Artefakte und drei Rollen definieren. Softwareprojekte werden in einfache Teilaspekte heruntergebrochen, die mittels sogenannter User Stories beschrieben werden. Der Product Owner definiert die Anforderungen an das jeweilige Teilprojekt im Product Backlog und definiert gemeinsam mit dem Entwicklerteam eine Definition of Done, also die Definition des Fertigzustands – welche Anforderungen muss die Software(teil)lösung erfüllen, um als fertigprogrammiert angesehen zu werden.
Daraufhin erarbeitet das Entwicklerteam in einem Sprint, der bei dem Team in Willstätt circa vier Wochen dauert, die Softwarelösung. Integraler Bestandteil der Entwicklung sind Tests, die sicherstellen, dass die Definition of Done und die Anforderungen erfüllt sind. Im Sprint Review Meeting wird der Sprint abgeschlossen und die Ergebnisse dokumentiert, was wiederum die Grundlage für den nächsten Sprint ist.
„Wir hatten schon länger nach einem ALM-System gesucht,“ erinnert sich Gabriele Schulz, Senior Softwareentwicklerin bei BCT, „entschieden uns aber zur Einführung von Scrum erst einmal mit den bestehenden Werkzeugen, Excel-Tabellen und manuellen Listen weiterzuarbeiten. Wir wollten so vermeiden, dass wir unseren Prozess (bewusst oder unbewusst) an ein Werkzeug anpassen anstatt uns auf die bestmögliche Erfüllung unserer Anforderungen zu konzentrieren. Diese Phase dauerte sechs Monate, dann begannen wir in einer Bachelorarbeit, die Grundlagen für eine Softwareevaluation zu legen.“
Bevor es zu einer Entscheidung für ein ALM-System kam, wurde die Übernahme von Polarion durch Siemens angekündigt. „Als Bestandteil des Siemens PLM Portfolios hat sich die Evaluierung angeboten“, erinnert sich Schulz, „aber die letztendliche Entscheidung sollte für das für uns beste System fallen. Wir hätten auch die Möglichkeit gehabt, eine andere Lösung einzuführen, wenn diese unsere Arbeit besser unterstützt hätte.“ Im Oktober 2016 kam ein Consultant von Polarion für zwei Tage zu BCT, um gemeinsam mit den Willstätter Softwarespezialisten ein Umsetzungskonzept und ein Pilotprojekt zu entwickeln. Interessanterweise machte es der einfache Aufbau möglich, die Implementierung weitgehend selbst durchzuführen. Zwischen Ende 2016 und März 2017 folgte dann eine Proof-of-Concept-Phase, in der drei Teams einen Sprint komplett in der ALM-Software durchspielten. Das Ergebnis war ein positives Feedback, auch die Gegenprobe mit dem Anforderungsprofil aus der Bachelorarbeit ergab eine sehr gute Übereinstimmung. So fiel die Entscheidung für die Einführung von Polarion. Auch bei der Implementierung kam Scrum zum Einsatz. Die ALM-Software wurde im Juni 2017 in mehreren kurzen Go-Live-Sprints an die BCT-Anforderungen angepasst und schließlich im Juli in den Echtbetrieb übernommen.
Gesamte Entwicklungsplanung im ALM-System
Die ALM-Software assistiert den Anwender heute beim gesamten Entwicklungsprozess. Die Softwarespezialisten aus Willstätt definierten einen eigenen Datentyp „Requirement“, mit dem sie die Anforderungen aus dem Consulting oder vom Kunden an eine Entwicklung aufnehmen können. Die Prozesse lassen sich in der ALM-Software frei definieren, ein Anpassen der in der ersten Scrum-Nutzungsphase gefundenen Nutzungsweisen war nicht notwendig.
Heute plant das Produktmanagement sämtliche Entwicklungsaufgaben in Polarion. Das hat den Vorteil, dass Aufgaben, die von verschiedenen Stellen kommen, gemeinsam bearbeitet werden können. So entsteht das Product Backlog, in dem die Aufgaben priorisiert und in eine Reihenfolge gebracht werden, und daraus wiederum die Sprints. Da sich im ALM-System Informationen aller Art sehr bequem an ein Item anhängen lassen, sind jederzeit alle Informationen, die zu einer Entwicklungsaufgabe gehören, einsehbar.
Ein großer Vorteil sind die Dashboards, die Planungssitzungen und Daily Scrum Meetings vereinfachen, indem sie Informationen, Statusmeldungen und anderes visuell aufbereiten und darstellen. „Es ist wichtig“, sagt Schulz, „dass Entwickler und Product Owner auf demselben Informationsstand sind, um den Prozess reibungslos zu gestalten.“ Während des Sprints entstehen Neuentwicklungen oder Anpassungen der Software, die der Product Owner abnimmt; dabei hilft ihm eine konfigurierte Abfrage, die ihm alle Items zeigt, die den Status „in review“ haben. Gibt der Product Owner den Code frei, kann dieser in den Releasecode integriert werden (Merging).
„Sehr hilfreich ist es, dass die Anwender der ALM-Software ihre Extensions veröffentlichen und man diese einfach verwenden kann. Auf der entsprechenden Website haben auch wir einige wichtige Extensions gefunden, die wir einsetzen.“ Ein gutes Beispiel ist ein Mechanismus, der überprüft, ob alle notwendigen Anforderungen an ein Item erfüllt sind – Code-Review, Übersetzungen, automatisierte Tests und anderes. „Solange nicht alle Häkchen gesetzt sind, kann man das Item nicht fertigstellen“, so Schulz weiter.
Am Ende eines Sprints findet ein Sprint Review Meeting mit den Consultants statt, in dem diese informiert werden, welche Änderungen entwickelt wurden und im nächsten Patch zur Verfügung stehen. „Vor Einführung von Scrum konnten Consultants zur Veröffentlichung eines Patches das Changelog einsehen, aber vorab gab es Informationen nur auf Anfrage“, erinnert sich Schulz. „Heute werden wichtige neue Features und Bugfixes im Reviewmeeting besprochen und wo sinnvoll auch direkt in unserer Review-Umgebung gezeigt. Die Consultants können Feedback geben wie sie den Einsatz beim Kunden bewerten und die Entwickler können Hintergrundinformationen geben, die für den Support oder die Installation beim Kunden nützlich sein können.“ Auch das im Review Meeting gesammelte Feedback wird wiederum in Polarion festgehalten. Dort bietet es die Basis für weitere Verbesserungen.
Effiziente Reaktion auf Programmierfehler
Ein Highlight in Polarion ist nach Auskunft von Gabriele Schulz das Bugsystem. Bugmeldungen finden auf zwei Wegen ins ALM-System: Automatische Meldungen entstehen, wenn ein Test fehlschlägt, zusätzlich kann der Support Bugmeldungen, die vom Kunden kommen, einpflegen. Auch hier hängen die Informationen, die der Softwareentwickler zum Lösen des Problems benötigt, direkt am Datensatz: Logfiles ebenso wie die Schritte, um den Fehler zu reproduzieren oder die benutzten Softwareversionen. So kann gezielt und effizient auf Programmierfehler reagiert werden. Die Bugs werden vom Product Owner in die Planung einbezogen. Auch das ist einfacher als bisher, denn vor der Einführung der ALM-Software wurden Bugs und die User Stories, mit denen neue Funktionsanfragen beschrieben werden, in zwei unterschiedlichen Systemen geführt. Heute sind alle Anfragen an einer Stelle sichtbar und können besser gemeinsam geplant werden. Ist der Bug gefixt, wird dies – wenn es sich um einen Bug handelt, der in einer veröffentlichten Version auftritt – automatisch im Changelog eingetragen. Denn das Changelog ist nichts anderes als einer der vielen Reports, die die ALM-Software aus den gespeicherten Daten erstellen kann.
Hohe Akzeptanz durch die Anwender
Die guten Erfahrungen, die die Anwender mit dem ALM-System von Siemens gemacht haben, führen dazu, dass mit der Zeit weitere Prozessteile in Polarion integriert werden, beispielsweise die automatisierten Tests, die bisher in einem anderen System ablaufen. Es ist angedacht die Ergebnisse von der ALM-Software auswerten zu lassen. „Zudem lassen wir jetzt in einer Bachelorarbeit prüfen, wie wir die Codequalität messen und dokumentieren können.“
Das Projektmanagement ist von den Vorteilen, die die ALM-Software bietet, so überzeugt, dass man das System dort in Projekten einsetzen will, um beispielsweise die Tests nach einer Teamcenter-Installationen zu managen. Auch die Consultants geben positives Feedback und sehen einige Möglichkeiten, das System noch breiter zu nutzen. Begeistert waren viele Anwender davon, wie einfach die ALM-Software zu bedienen ist. Bei den Supportmitarbeitern reichte beispielsweise eine Stunde Schulung, damit diese in der ALM-Software arbeiten können. Auch für die Administratoren ist sie einfach zu verwalten, wie Schulz bestätigt.
„Wir arbeiten gerne mit Polarion“, fasst Gabriele Schulz zusammen. „Wir haben alle Informationen und Prozesse in einem System vereinigt, Redundanzen und Medienbrüche kommen nicht mehr vor. Die Workflows, die die Prozesse abbilden, verhindern, dass man etwas falsch macht – das System lässt mich nicht weitermachen, wenn ich nicht alle notwendigen Informationen angefügt habe.“ Da das System alle Workflows trackt und alle Informationen an den Items hängen, könne man jederzeit nachvollziehen, was wann warum gemacht wurde. Und die vorgefertigten und anpassbaren Reports seien extrem hilfreich, um den Status aller Projekte im Blick zu behalten. „Die Product Owner konnten es nach dem Proof of Concept gar nicht abwarten, dass Polarion eingeführt wird, weil es ihnen die Arbeit so sehr erleichtert“, so Schulz weiter. „Auch wir anderen, vom Softwareentwickler bis zum Supportmitarbeiter, arbeiten sehr gerne mit dem System. Die Akzeptanz durch die Anwender war von Beginn an gut. Und die Transparenz, die die ALM-Software von Siemens in die Daten und Abläufe bringt, ist unbezahlbar. Unsere Entscheidung hierfür war definitiv richtig, wir sind noch lange nicht am Ende der Möglichkeiten, die uns das System bietet.“ eve
Details zu Polarion ALM
BCT Technology AG
Im Lossenfeld 9
77731 Willstätt
Tel.: +49 7852 996-0
E-Mail: info@bct-technology.com
Vorstand:
Klaus Erdrich
Jürgen Hillemann
Martin Anliker, Business Development Manager, BCT Technology GmbH, SchweizBild: BCT Technology
„Im Maschinen- und Anlagenbau beschäftigt das Thema Funktionale Sicherheit die Firmen. Diese Anforderungen bekommt man ohne ALM irgendwann nicht mehr in den Griff.“
Gabriele Schulz, Senior Softwareentwicklerin, BCT TechnologyBild: BCT Technology
„Es ist wichtig, dass Entwickler und Product Owner auf demselben Informationsstand sind, um den Prozess reibungslos zu gestalten“
