Maschinenbau im digitalen Zeitalter
Neuigkeiten, Themen & Blog rund um Maschinenbau, Software & Automatisierung

Agile Softwareentwicklung im Maschinenbau: Praxiserfahrungen bei der Einführung

von Peter Klotz, Geschäftsführer
Agile Scrum Funktionsweise

Klotz und Kinmatec bilden eine Einheit obwohl die Geschäftsfelder auf den ersten Blick unterschiedlich sind. Bei Klotz werden Maschinen und Anlagen konstruiert und produziert, bei Kinmatec wird Automatisierungs- und Steuerungssoftware entwickelt. Beides zusammen ergibt den von Firmengründer Peter Klotz geprägten Maschinenbau 4.0. Was im fertigen Produkt zusammenkommt, entsteht auf unterschiedliche Weise. Der Maschinenbau hat eine Arbeitsweise, die von der Konstruktionsarbeit geprägt ist, während in der Softwareentwicklung eine unterschiedliche Struktur gelebt wird. Zwei unterschiedliche Arbeitsweisen und das signifikante Wachstum im Entwicklungsbereich haben Klotz und Kinmatec dazu veranlasst die agile Softwareentwicklung einzuführen. Im Interview mit Reinhard Seefried, dem Leiter der Entwicklungsabteilung, wollen wir über die Herausforderungen, Erfahrungen und die Reaktion der Mitarbeiter sprechen.

Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität in der Softwareentwicklung. Je nach Ausführung der Prozesse findet die Entwicklung beispielsweise nach Scrum oder Kanban statt. Agile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams, sowie eine iterative und inkrementelle Vorgehensweise aus. Es wird versucht, mit geringem bürokratischem Aufwand und Regeln auszukommen und sich schnell an Veränderungen anzupassen, ohne dabei das Risiko für Fehler zu erhöhen. Im Vergleich zur traditionellen Wasserfall-Entwicklung finden bei der agilen Entwicklung kurze, iterative Sprints statt, um frühzeitig Risiken zu erkennen und Fehlentwicklungen zu vermeiden. Weitere Informationen finden Sie auf der Seite der Scrum Alliance.

 

Agile Scrum Funktionsweise

 

Herr Seefried, wenn Sie zurückblicken auf die letzten Monate, würden Sie sagen, dass sich die Umstellung gelohnt hat?

Natürlich mussten wir einige Herausforderungen meistern und eine derart eingreifende Umstellung der Arbeitsweise erfordert gute Kommunikation. Wir sind jetzt in der Lage, den aktuellen Entwicklungsstand viel präziser zu beurteilen. Unsere Kunden haben mehr Transparenz darüber, an welchem Punkt wir im Plan stehen. Das vereinfacht die Zusammenarbeit und macht die Prozesse effektiver.

Können Sie uns die Gründe für die Einführung nennen?

Wir haben eine permanente Zunahme an Softwareaufgaben, man denkt nur an die Automatisierung und die Themen rund um die Industrie 4.0 In jeder Maschine steckt heute Software und die wird von uns selbst entwickelt. Deshalb haben wir unser Entwicklungsteam um fast 50 Prozent ausgebaut. Bislang fehlte uns das Rahmenwerk für eine moderne Softwareentwicklung. Ohne ein Issue Management ist es schwer, Entwicklungsaufgaben strukturiert anzugehen und zu wissen, wie lange für eine Aufgabe gebraucht wird? Wie lange dauert die Implementierung eines Features, wie aufwändig ist der Bugfix? Das sind typische Fragen, deren Beantwortung großen Einfluss auf die Entwicklungszeit und –kosten hat. Für unser Team ist es enorm wichtig eine agile Umgebung zu haben, um frühzeitig erkennen zu können, ob die Entwicklung in die richtige Richtung geht. Und zwar von unserer Seite aus, aber auch was die Anforderungen des Kunden angeht.

Was waren die größten Herausforderungen?

Wir mussten zunächst damit beginnen, genau herauszufinden, wer wie arbeitet und was die Gründe dafür sind. Es gab ja auch bisher eine funktionierende Softwareentwicklung und es ist nicht alles schwarz und weiß. Wir wollten bewährte und funktionierende Prozesse behalten und sie in die neue Umgebung einbinden. Dafür ist es auch wichtig zu sehen, welche Tools genutzt werden. Auch da hat jeder seine Präferenzen. So eine tiefgreifende Veränderung muss gut vorbereitet sein und braucht die Unterstützung des Teams.

Wie haben Sie die Mitarbeiter auf die Änderungen vorbereitet?

Im ersten Moment bedeutet Veränderung für die Mitarbeiter, dass sie gewohnte Strukturen verlassen. Dieses Verlassen der Komfortzone wird häufig kritisch betrachtet. Unsere Mitarbeiter sind sehr offen und bringen sich viel ein. Anfangs mussten wir erklären, warum wir die agile Entwicklung einführen wollen. An Praxisbeispielen konnten die Mitarbeiter schnell sehen, dass die vermeintliche negative Veränderung für jeden im Team Probleme löst, über die er sich häufig ärgert. Nach dieser ersten Erklärphase konnten wir das Team aktiv einbinden und involvieren. Letztendlich kamen viele Ansätze zur Einführung von den Mitarbeitern selbst. Die Experimentierfreude stieg an obwohl es auch immer wieder kritische Phasen gab.

Welche Verbesserungen konnten Sie mit der Einführung von „Agile“ erreichen?

Generell sehen wir eine flüssigere Entwicklung. Wir wissen wo wir uns im Entwicklungsprozess befinden und haben einen besseren Überblick. Bei der Software haben wir uns für JIRA von Atlassian entschieden, das durch Ergänzungen wie Confluence eine professionelle Dokumentation in einem Wiki erlaubt. Wir wissen exakt, was an Aufgaben ansteht, wer welche Aufgabe bearbeitet, in welchem Zustand ist die Aufgabe und welche Priorität hat sie im Vergleich zu anderen Themen. Die Werkzeuge folgen jetzt potenziell der Arbeitsweise und nicht andersherum. Und wir haben Potenzial um die Qualität unserer Software aktiv zu verbessern. Das Beste daran ist, dass der Prozess nicht abgeschlossen ist, sondern wir in kleinen Schritten Verbesserungen vornehmen können. Dazu kommt das Feedback aus der täglichen Arbeit des Teams. Auf dieselbe Art wie wir die agile Entwicklung für unsere Software nutzen, hilft uns das agile Vorgehen bei der Einführung und den weiteren Maßnahmen. Einführen, Testen, Feedback einsammeln und Verbessern. Das ist eine Arbeitsweise, die sich bei uns im Team manifestiert und die wir auch auf andere Unternehmensbereiche übertragen können.

Gab es auch Rückschritte durch die neue Arbeitsweise?

Zunächst haben wir Bitbucket von Atlassian als Versionskontrollsystem verwendet. Mit Hilfe von Pull Requests können hier sehr komfortabel Code-Reviews durchgeführt werden. Auch können Kommentare direkt in Bezug zum Quellcode erstellt und Diskussionen darüber geführt werden. Nach einigen Wochen haben wir jedoch festgestellt, dass wir mit Bitbucket an gewisse Grenzen stoßen. Nach Tests von diversen Alternativen haben wir uns für Gerrit als Review-System für Git entschieden und dies in unseren Ablauf integriert. Wichtig war für uns hierbei, dass das gesamte Team die Entscheidung mitträgt.

 

Klotz Agile Scrum

 

Wie lassen sich die Verbesserungen bei Klotz und Kinmatec messen?

Es ist noch zu früh, um konkrete Zahlen zu nennen. Wir sehen aber gerade die gesteigerte Transparenz als einen großen Erfolg an. Dabei hilft uns der Einsatz von Jenkins, einem erweiterbaren Software-System zur kontinuierlichen Integration von Komponenten in einem Anwendungsprogramm. Wir können schon jetzt nach dieser kurzen Zeit von wenigen Wochen erkennen, welches Potenzial für uns in der agilen Softwareentwicklung steckt und gleichzeitig auch welche weiteren Schritte wir machen können.

Welche Vorteile haben Ihre Kunden aufgrund der Einführung?

Wir erhöhen die Transparenz in der Entwicklung und vermeiden dadurch unnötige Kosten. Die agile Entwicklung orientiert sich stärker an den Anforderungen der Kunden und wir können schneller reagieren. Unsere Kunden sehen genau, an was wir arbeiten und was an Aufgaben ansteht. Dies schafft eine Vertrauensbasis.

Welche Schritte sind als Nächstes geplant?

Anfang September geht ein Bugtracking-Tool online. Damit haben unsere Kunden direkt online die Möglichkeit, einen Fehler oder einen Feature-Wunsch an uns heranzutragen. Ferner sehen Sie jederzeit den aktuellen Status des jeweiligen Tickets. Über jede Änderung am Status können Sie sich auf Wunsch automatisiert eine E-Mail zusenden lassen. Wir haben uns hier für den „Mantis Bug Tracker“ entschieden, nachdem wir drei verschiedene Systeme auf Herz und Nieren getestet haben. Mantis lässt sich auch sehr gut mit JIRA kombinieren.

peter klotz
Über den Autor

Peter Klotz ist Gründer und Geschäftsführer des Softwareunternehmens Kinmatec sowie Geschäftsführer der Klotz GmbH, einem mittelständischen Maschinenbauer. Seit mehr als zehn Jahren befasst er sich mit der Verknüpfung von klassischem Maschinenbau mit Software und Algorithmen. Sowohl aus der Ingenieurs- wie aus der Entwicklerperspektive befasst er sich mit Themen wie Industrie 4.0 und dem Internet of Things.

Hinterlasse einen Kommentar