Schlagwortarchiv für: wartungsteam

.NET Legacy Software: Mit Approval Tests und Specflow fit für die Wartung

/von

Wer kennt das nicht: Eine Software läuft seit Jahren stabil. Nun ändert sich die Rechtslage. Oder Teile der Infrastruktur, mit der sie läuft, werden vom Hersteller nicht mehr unterstützt. Häufig ist die Software jedoch nicht ausreichend mit Tests ausgestattet, um die notwendigen Änderungen durchzuführen. Entwickler stehen dadurch vor dem Problem, dass sie mit jeder vorgenommenen Änderung unvorhersehbare Nebeneffekte auslösen können. Ein Risiko, das kein Entwickler gerne eingeht. 

In diesem Artikel zeigen wir Ihnen drei Möglichkeiten, um Ihre Legacy Software zu warten, wenn diese nicht ausreichend mit Tests ausgestattet ist. Neben den jeweiligen Vor- und Nachteilen gehen wir vor allem auf den Einsatz des Approval Test Frameworks in Kombination mit Specflow ein. 

Wir haben diesen Ansatz gewählt, weil er kosteneffizient ist und die Testfälle ohne Programmierung erstellt werden können.

3 gängige Ansätze für die Qualitätssicherung von Altanwendungen

In der Praxis gibt es im Wesentlichen drei Strategien, mit der Qualität von Legacy Software umzugehen. Nicht alle erfüllen jedoch moderne Standards der Softwareentwicklung:

Testing beschränkt auf manuelle Tests
Es werden keine automatisierten Tests durchgeführt. Das heißt: Alle Tests müssen manuell durchgeführt werden. Das führt in der Regel zu einer höheren Unsicherheit. Beim manuellen Testen sind die Entwickler bzw. Tester stark von dem Know-how über die Anwendung abhängig. Automatisierte Tests kann hingegen jeder laufen lassen. Wenn ein Test fehlschlägt, muss der Entwickler nur die entsprechende Stelle analysieren.

Zusätzlich wird deutlich mehr Zeit benötigt, um manuelle Tests durchzuführen. Gleichzeitig ist die Wahrscheinlichkeit für (weitere) Fehlermeldungen höher. Manuell können selbst die besten Tester mal etwas vergessen. Der automatisierte Test läuft hingegen immer und prüft verlässlich alle definierten Szenarien.

Nachträgliche Ausstattung mit automatisierten Tests
Eine weitere Option ist es, dass Sie die Altanwendung nachträglich mit automatisierten Tests, wie zum Beispiel Unit Tests, oder automatisierten Akzeptanztests ausstatten. Letzteres ist die Standardlösung für neue Anwendungen. Sie wird daher als Erstes angedacht, wenn die Effizienz der Wartung von bestehenden Lösungen erhöht werden soll.

Eine nachträgliche Ausstattung ist in der Regel jedoch sehr teuer. Zudem muss tiefes Know-how über die Zusammenhänge der Domäne (wie die Logik der Anwendung) vorhanden sein. Daher ist diese Option nur mit großem Arbeitsaufwand umsetzbar. In einigen Fällen kann sie aufgrund der Architektur auch gar nicht eingesetzt werden.

Specflow-unterstützte Approval Tests
Mit einer Kombination aus Approval Tests und Specflow kann die Stabilität von Legacy Software nachgewiesen werden. Hierfür werden End-to-End-Tests eingesetzt. Das führt zu deutlich geringeren Kosten als die Nutzung von Unit Testing oder automatisierten Akzeptanztests (wenn man sie im Nachhinein einführt).

Denn mit Specflow-unterstützten Approval Tests lässt sich ein automatisierter Vergleich zwischen dem bestehenden Verhalten und dem Verhalten nach Änderungen umsetzen. So können die Entwickler nach Änderungen überprüfen, ob sich die Software insgesamt noch gleich verhält wie zuvor.

Approval Tests mit Specflow bietet aus unserer Sicht eine schlanke, erweiterbare, und gleichzeitig sichere Möglichkeit, um die Stabilität und Wartbarkeit einer Legacy Anwendung zu erhöhen.

So funktionieren specflow-unterstützte Approval Tests

Zur Umsetzung von Approval Tests mit Specflow werden folgende Schritte durchgeführt: 

  1. Feature Files erstellen: Es werden Feature Files (gherkins) erstellt, die die Eingangsparameter beschreiben und diese mit dem dazugehörigen Methodenaufruf verknüpfen.  
  2. Ergebnisse aufzeichnen: Beim Aufruf der Methode zeichnet das Approval Test Framework die Ergebnisse auf, die die Anwendung für die definierten Eingangsparameter liefert. 
  3. Golden Master erstellen: Die Ergebnisse werden als sogenannter Golden Master gespeichert. 
  4. Weitere Durchläufe: Bei weiteren Durchläufen (nach Umsetzung von Änderungen) dient dieser Master als Vergleichsbasis für den Integritätscheck des Verhaltens. 

Durch dieses Vorgehen ergibt sich eine Reihe von Vorteilen: 

  • Es entsteht kein Programmieraufwand für die Tests. 
  • Die Tests werden stets aktuell gehalten. Denn für jedes korrekt geänderte Verhalten wird der Master überschrieben. 
  • Außerdem können Sie diese Lösung schrittweise aufbauen, da sie für jede technische bzw. inhaltliche Komponente separat implementierbar ist. 
  • Ein weiterer Vorteil gegenüber z. B. Unit Tests ist, dass die Tests das Verhalten aus Usersicht prüfen. Damit ist es möglich, voll integriert zu testen.

Mehr Sicherheit und weniger Aufwand bei der Wartung von Legacy Software

Specflow-unterstützte Approval Tests bieten uns bei TechTalk die nötige Sicherheit, auch Anwendungen im letzten Drittel ihres Lifecycle verlässlich ändern und ausliefern zu können. Der Aufwand ist deutlich geringer als der Aufwand für eine nachträgliche Ausstattung mit Unit Tests. 

Für stark UI-lastige Anwendungen, vor allem wenn viel Logik im UI implementiert ist, empfehlen wir sie nicht. Bis auf diese Ausnahme ist die Methode theoretisch für alle Fälle geeignet. Aus unserer Sicht ist diese Methode vor allem für datengetriebene Verwaltungs-Domänen sinnvoll. 

Im Einzelfall muss jedoch stets die konkrete Architektur der Legacy Software betrachtet werden, um eine Entscheidung über die bestmögliche Methode zu treffen. Denn die gewählte Lösung muss immer zur jeweiligen Software passen.

Haben Sie Fragen?

  • Sie wollen mehr zum Thema specflow-unterstützte Approval Tests wissen?
  • Sie benötigen Unterstützung bei der Wartung Ihrer Legacy Software?

Thomas Korosa steht Ihnen für weitere Fragen über Xing oder Mail zur Verfügung.

Haben Sie eine Legacy Software im Einsatz die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

Unverbindlich & kostenlos anfragen

4 Mythen über agile Software Wartung, denen Sie keinen Glauben schenken sollten

/von

„Wir können nicht agil arbeiten, wir machen nur Wartung!“ – Kommt Ihnen diese Aussage bekannt vor?

Finden Sie heraus, wie Sie mit den dahinterstehenden Annahmen aufräumen können und wie Sie mit einer agilen Arbeitsweise in der Wartung Ihre Geschäftsziele leichter erreichen.

Mythos 1: die ideale User Story

Das Team sagt: „Wir können nicht mit User Stories arbeiten, weil wir Issues zur Bearbeitung bekommen und kaum Features entwickeln.“ 

Egal, ob Sie in Ihrem Team von Issues, Fehlermeldung oder Bugs reden: Dieses Argument ist auf eine Idealvorstellung einer User Story zurückzuführen, die in den Schulungen vermittelt wird. Tatsächlich ist es auch bei laufender Software sinnvoll, Anforderungen nach den INVEST Kriterien zu formulieren, um sicherzustellen, dass sie effizient und effektiv umgesetzt werden können. 

Was sind die Besonderheiten der INVEST Kriterien in der Softwarewartung?

  • Independent: Die meisten Issues zu laufender Software sind unabhängig, da sie sich auf einen einzelnen Aspekt beziehen, der nicht oder nicht mehr wunschgemäß funktioniert. Wenn der Issue komplexer ist, spricht alles dafür, ihn in unabhängige Backlog Items aufzuteilen, damit die Umsetzung planbar wird.

  • Negotiable: Das Ergebnis einer User Story muss verhandelbar sein. Auch für Issues in laufender Software gibt es meistens mehr als eine mögliche Lösung. Auch in der Softwarewartung ist es sinnvoll, über die Lösung zu verhandeln, die die Anforderungen zu den geringstmöglichen Kosten erfüllt. 

  • Valuable: Eine User Story muss einen klar herausgearbeiteten Business Value haben. In der Wartung spielt es sogar eine noch größere Rolle, dass der Wert der Lösungen klar ist. Denn die Bereitschaft zu investieren, sinkt mit zunehmender Lebensdauer der Anwendung. Der Wert ist die Voraussetzung für eine Priorisierung, bei der jeweils der Issue umgesetzt wird, der aktuell den höchsten Business Value bringt. 

  • Estimable: User Stories müssen schätzbar sein, damit das Umsetzungsteam sich zu einem Umsetzungsplan verpflichten kann. Es spielt dabei keine Rolle, ob es sich um eine Neuentwicklung oder eine Änderung einer Software handelt. 

  • Small: User Stories müssen klein genug sein, dass sie innerhalb des Planungszeitraums, zum Beispiel eines Sprints, einen Business Value liefern. Die Diskussion darüber wird im Team hauptsächlich geführt, damit die Erwartungen auf den Tisch kommen. Dies gilt für Neuentwicklungen und Weiterentwicklungen, sowie Fehlerbehebungen gleichermaßen. 

  • Testable: Um nachweisen zu können, dass der vereinbarte Business Value geliefert wurde, muss jedes Backlog Item testbar sein. In der Wartung ist der Nachweis der Funktionsfähigkeit, abhängig vom Release-Zyklus, oft noch wichtiger als im Verlauf der Neuentwicklung.

Fazit: Es ist nicht unbedingt notwendig, dass jede Anforderung sich in eine idealtypische Story verpacken lässt. Die Orientierung an den INVEST Kriterien ist auch bei Altanwendungen sinnvoll und möglich.

Mythos 2: Scope Management ist unnötig

Der Produktmanager sagt: „Wir brauchen kein Backlog, wir machen ohnehin nur mehr Dinge, die wir unbedingt machen müssen.“

Diese Meinung drückt die Erwartung aus, dass die Benutzer nur absolut notwendige Arbeiten in Auftrag geben, da die Anwendung ihr Einsatzende fast erreicht hat. Diese Anwendungen wurden meistens nach dem Wasserfall-Modell entwickelt, das heißt alle Funktionalitäten wurden vorab spezifiziert und – häufig Jahre später – umgesetzt ohne noch einmal nach dem Nutzen zu fragen. Im Wasserfall-Modell geht man davon aus, dass alles umgesetzt werden muss, was spezifiziert wurde.

Gerade bei Altanwendungen am Ende ihres Lebenszyklus hilft ein agiles Vorgehen, weil es die Optimierung des Business Value in den Mittelpunkt stellt. Durch eindeutige Priorisierung und Umsetzung mit dem Business Value im Fokus kann die Entwicklung jederzeit beendet werden, sobald der zusätzliche Nutzen geringer ist als die zusätzlichen Kosten. Die Praxis zeigt, dass Benutzer und Umsetzer am besten gemeinsam über die optimale Nutzung des bereitgestellten Budgets entscheiden können. 

Fazit: Aktives Scope Management ist die Voraussetzung dafür, dass nicht nur das Budget im Rahmen bleibt, sondern auch das Ergebnis optimiert wird. Das gilt in der Wartung genauso wie bei der Neuentwicklung.

Mythos 3: Störungen haben Vorrang

Das Team sagt: „Wir können nicht mit der Bearbeitung dringender Fehlermeldungen warten, bis der Sprint vorbei ist. Wir müssen uns sofort darum kümmern.“ 

Dieser Mythos ist auf die herrschende Meinung zurückzuführen, dass nur eine sofortige Reaktion auf alle Inputs von Kunden oder Benutzerinnen als kundenfreundlich gilt. Nach dem Push-Prinzip werden alle Anforderungen, die vom Kunden dokumentiert wurden, sofort in Bearbeitung genommen. Viele werden aber lange nicht fertig, zum Beispiel weil es offene Fragen gibt oder weil das bemängelte Verhalten auf dem Testsystem nicht reproduzierbar ist. Die Konsequenz ist häufig, dass sich eine lange Liste von Issues „in Bearbeitung“ befindet. 

Die Wahrheit ist: Die meisten Issues sind gar nicht so dringend. Eine bewusste Priorisierung hilft dabei, die richtigen Anforderungen umzusetzen und so den Business Value zu optimieren. Das agile Team bearbeitet immer nur so viele Issues, wie tatsächlich umgesetzt werden können. Es stellt diese fertig, bevor es neue aus dem Backlog annimmt. 

Fazit: Wer nach dem Pull-Prinzip vorgeht, statt nach dem Push-Prinzip, arbeitet effizienter, erledigt mehr und wird mit den wirklich wichtigen Aufgaben verlässlich fertig. Dies gilt auch in der Wartung.

Mythos 4: das Highlander Syndrom

Die Entwickler sagen: „Wir sind kein Team. Jeder von uns hat sein Spezialgebiet.”

In der Vergangenheit waren Produktentwicklungsteams häufig eher eine Gruppe von Spezialisten als ein Team. Die zugrundeliegende Annahme war, dass Experten Probleme aufgrund ihres tiefen Wissens effizienter lösen, jedoch wurden bald die Nachteile dieser Arbeitsteilung evident:

  • Viele Kommunikationsschnittstellen zwischen den einzelnen Experten 
  • Langwierige Fehleranalysen unter Beteiligung mehrerer Experten 
  • Jede Person wird zum Flaschenhals für das ganze System und verursacht bei Abwesenheit oder zu hoher Auslastung lange Wartezeiten für das gesamte System

Mit der Verlagerung zu Full-Stack Entwicklung und T-Shaped oder M-Shaped Skills rückt auch die Zusammenarbeit stärker in den Vordergrund. Teams mit bewusst gestalteter Zusammenarbeit bauen gemeinsames Wissen auf und können gerade komplexe Probleme in Altanwendungen schneller lösen. Personalwechsel können so auch wesentlich leichter kompensiert werden. In Summe überwiegen die Vorteile der Zusammenarbeit nach agilen Prinzipien.  

Fazit: Agile Teamarbeit unterstützt die hohen Anforderungen, die in der Softwarewartung an Reaktionsfähigkeit und Aufrechterhaltung des Wissens gestellt werden, besser als Expertentum.  

Kein Mythos: die wahre Herausforderung für Agilität in der Softwarewartung

Die wahre Herausforderung für Agilität liegt bei Altanwendungen meistens in der Qualitätssicherung. Mangelnde Wissensteilung, geringe Abdeckung mit dokumentierten – am besten automatisierten – Tests und eine intransparente Schnittstelle zum Betrieb sind die unausgesprochenen Gründe, warum viele Entwickler nicht in der Wartung arbeiten wollen. 

Hinzu kommt ein hoher Aufwand für die Qualitätssicherung auf allen festgelegten Ebenen (Stages). Es muss sichergestellt sein, dass Änderungen im Code keine unerwünschten Nebenwirkungen verursachen. Hierfür sind zahlreiche manuelle Schritte mit langen Wartezeiten und enormem Koordinationsaufwand notwendig.

Zu den wichtigsten agilen Prinzipien gehört, häufig zu releasen und inkrementelle Änderungen für die Benutzer bereitzustellen. Bei Altanwendungen hilft das agile Vorgehen oft, die Flaschenhälse zu identifizieren und Schritt für Schritt zu beseitigen.

Schlussendlich wird auch eine Releaseplanung mit fixen Releasezeitpunkten durch agiles Arbeiten unterstützt. Durch laufende Priorisierung wird sichergestellt, dass die jeweils wichtigsten Features (bzw. Fehlerbehebungen) umgesetzt werden und der Releasetermin eingehalten wird.  

Wie schaut agiles Arbeiten in der Softwarewartung konkret aus?  

Bei TechTalk arbeiten wir in der Wartung agil mit einem fixen Team. Das bedeutet für unsere Kunden geteiltes Wissen und garantierte Reaktionsfähigkeit – auch langfristig. 

Wir kombinieren ein Kanbanboard mit regelmäßigen Retrospektiven und Plannings nach Scrum. Das Kanbanboard erlaubt einerseits flexible Reaktion, wenn ein dringender Fehler gemeldet wird, unterstützt aber andererseits auch jederzeit die Selbstorganisation des Teams. Die Prioritäten werden klar abgebildet, was kontinuierliche fokussierte Umsetzung bedeutet. Die sogenannte „Emergency Lane“ zeigt auf einen Blick, ob etwas Dringendes außerplanmäßig zu erledigen ist.  

Sowohl Kanban als auch Scrum bieten einen Rahmen, in dem Entwickler fokussiert arbeiten können.  

Die Elemente aus Scrum erleichtern den Abgleich mit der Roadmap aus der Planung und unterstützen die laufende Evaluierung und Anpassung der Prozesse. Durch die regelmäßige rollierende Planung haben auch unsere Kunden mehr Transparenz. Planänderungen können von beiden Seiten frühzeitig eingebracht und auf ihre Konsequenzen geprüft werden.  

Im Umsetzungsteam sind agile Praktiken etabliert, mit denen ein durchgängiger Qualitätsstandard sichergestellt wird. Mehr Informationen dazu finden sich im Experteninterview mit Thomas Korosa. 

Haben Sie eine Legacy Software im Einsatz, die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

Unverbindlich & kostenlos anfragen

Wartung von Altanwendungen bei TechTalk: Interview mit Softwarearchitekt Thomas Korosa

/von

In unserer Interviewserie „Get to know TechTalk“ stellen wir regelmäßig Mitarbeiter der TechTalk vor. Diesmal verrät uns Softwarearchitekt Thomas Korosa, wie er mit den Herausforderungen bei der Wartung von Altanwendungen umgeht und was seine Arbeitsweise bei der Übernahme sowie Betreuung der Altanwendungen besonders macht.

Was ist Deine Rolle bzw. Dein Betätigungsfeld bei TechTalk?

Zu meinen Aufgaben gehören neben der Programmierung einerseits die Unterstützung und Weiterentwicklung der anderen Developer im Team, andererseits die Unterstützung der internen Product Owner und der Kunden. Den Product Owner unterstütze ich in der Planung und bei der Analyse von Anforderungen, besonders wenn diese nicht nahtlos in die bestehende Anwendung passen. 

Typische Themen im Rahmen der Wartung von Altanwendungen sind bei uns: 

  • Evaluierung und Nach-Dokumentation einer Domain
  • Quick Wins für Refactoring finden, die die Wartbarkeit verbessern und auch mit schonendem Umbau umgesetzt werden können
  • Altanwendungen welche auch oft einen hohen Anteil von Legacy-Code beinhalten 
  • die Erhöhung der Testabdeckung im Nachhinein. 

Das Betätigungsfeld ist also sehr vielfältig.

Worauf legst du besonderen Wert bei der Weiterentwicklung und Zusammenarbeit Deines Developer-Teams?

Bei der Weiterentwicklung von Developern setze ich auf Mentoring. Die Unterstützung ist ganzheitlich und betrifft sowohl Technologien oder Programmier-Patterns, als  auch die Entwicklung des Verständnisses, was Coding Standards und deren konsequente Einhaltung bringen oder welche Auswirkung Knowledge Sharing auf die Effizienz und die Effektivität eines Teams hat – und am Ende auch auf die Motivation. Letztlich ist es mein Ziel, Nachhaltigkeit in Projekten sowohl in technischer als auch in organisatorischer Hinsicht herzustellen. Das bewirkt auch, dass die Teammitglieder von Anfang an viele Aufgaben selbständig lösen können – Eine wichtige Voraussetzung, um Altanwendungen als Team effizient warten zu können.

Welchen Fokus setzt Du bei der Übernahme von Altanwendungen?

Der Fokus liegt auf der behutsamen Modernisierung der bestehenden Architekturen, und weniger auf dem Bau neuer Architekturen. Refactoring so einzusetzen, dass man den Code sukzessive im Zuge der Weiterentwicklung modernisiert und dabei die Anwendung stabil in Betrieb hält, erfordert spezielles Wissen und folgt anderen Kriterien, was das Handling von Code anbelangt, als eine Neuentwicklung.  Das Gleiche gilt für die Modernisierung von Infrastruktur oder Komponenten.

Ist die Betreuung von Altanwendungen nicht ziemlich aufwändig?

Es stimmt schon, dass die Betreuung von Altanwendungen ein paar Herausforderungen mit sich bringt, z.B. häufig geringe Testabdeckung und unzureichende Dokumentation. Oft gibt es keine inhaltlichen oder technischen Ansprechpartner beim Kunden, die uns bei der Übernahme unterstützen könnten. Das alles erhöht den Aufwand für Änderungen an der Software.  Wir haben jedoch genau mit diesen Herausforderungen viel Erfahrung und Routine und können daher unsere Kunden besonders gut dabei unterstützen.

Was schaust Du Dir als Erstes an, wenn ein neuer Kunde mit seiner Altanwendung zu dir kommt?

Bei der Erstanalyse ist unser Ziel, die mindestens notwendigen Umbauarbeiten zu erkennen und Quick Wins zu finden, die leicht realisierbar sind, die Wartung erleichtern und Verbesserungen für die Benutzer*innen bringen. Dabei achten wir besonders auf den Business Value und auf inkrementelle Änderung.  Das heißt wir können relativ schnell eine realistische Empfehlung geben, wie der weitere Betrieb der Software unter Berücksichtigung von Domäne, Technologien und Business Value aussehen sollte.

Wie profitiert ein neuer Kunde, wenn er mit TechTalk seine Altanwendungen verwaltet?

Ich glaube, dass der größte Vorteil für einen neuen Kunden ist, dass wir wissen, was wir brauchen, um seine Software zu übernehmen. Wir integrieren diese in unsere  bestehenden Abläufe, sodass der Betrieb der Anwendung in der gewohnten Qualität kosteneffizient weiterhin gewährleistet ist. 

In organisatorischer Hinsicht profitieren unsere Kunden davon, dass wir mit State-of-the-Art-Tools (DevOps) im Code für Ordnung sorgen und mit unserem –  für die Wartung maßgeschneiderten – agilen Vorgehen auch organisatorisch den Überblick bewahren. Wir arbeiten dabei mit einem Kanban Board und synchronisieren uns regelmäßig mit den Product Ownern im Sprint-Rhythmus von zwei Wochen.

Der Vorteil für die Kunden ist, dass einheitliche Standards für alle Projekte implementiert sind und gelebt werden, die gewährleisten, dass wir im Team transparent und effizient zusammenarbeiten können. Diese Transparenz hilft auch dem Product Owner die Effektivität unserer Arbeit optimal zu unterstützen, sodass wir das Richtige umsetzen, und regelmäßig mit dem Kunden die Prioritäten im Backlog anpassen können, wenn von ihm gewünscht. Das ist in der Wartung besonders relevant, weil sich die Schwerpunkte bei Anwendungen, die bereits in Betrieb sind, oft schneller ändern. Für den Kunden verbessert das also die Kosteneffizienz und Planbarkeit. Zusätzlich erleichtert es die Einbindung weiterer Teammitglieder, was auch das Problem nicht mehr vorhandener Ansprechpartner reduziert. 

Und welche Vorteile ergeben sich aus technischer Hinsicht für den Kunden?

Auch in technischer Hinsicht bieten wir den Kunden Vorteile. Dadurch, dass wir gängige Technologien im Auge behalten, können wir unseren Kunden passende Komponenten vorschlagen, wie zum Beispiel Kibana für die Systemüberwachung. Ein anderes Beispiel ist, dass wir erkennen, wenn eine Komponente deprecated, also veraltet, ist oder Sicherheitslücken bekannt werden. Der Kunde muss sich nicht selbst um solche Probleme kümmern.

Inwiefern ist die Zusammenarbeit mit Kunden in der Wartung anders als bei Neuentwicklungen? 

Der Kontakt zu Kunden unterscheidet sich von der Neuentwicklung vor allem dadurch , dass wir bis zu 5 verschiedene Kunden in jedem Sprint betreuen und oft auch in technischer Hinsicht eng zusammenarbeiten. Die Inhalte reichen dabei von der Analyse eines Problems in der Infrastruktur, wie z.B. dem korrekten Aufruf einer Schnittstelle, bis hin zur Beratung, welche die optimale Lösung für den Benutzer aus Domänen- und Usability-Sicht ist.

Was motiviert Dich besonders bei deiner Arbeit mit Altanwendungen?

Mich motivieren am meisten drei Aspekte meiner Arbeit.

Erstens, wenn es mir gelingt, zu meinen Kunden ein gutes Verhältnis aufzubauen und partnerschaftlich zusammenzuarbeiten. Wenn das gelingt, motiviert es mich besonders, weil gerade in der Wartung oft Probleme schnell gelöst werden müssen und da ist eine gute Beziehung zum Kunden besonders wichtig.

Zweitens kann ich in meiner Rolle junge Kollegen*innen weiterbilden und an den vielfältigen Projekten wachsen lassen – und lerne dabei auch immer selbst dazu .

Drittens analysiere ich gerne, versuche die Domäne und die Implementierung von Anwendungen zu verstehen und freue mich, wenn ich dadurch Lücken schließen kann, die entstanden sind weil im Team des Kunden die  wissenden Personen – Entwickler oder Produktmanager – nicht mehr verfügbar sind. 

Wie bleibst Du am Ball? 

Ich schaue auf einen ständigen Austausch mit Kollegen*innen –  auch mit Juniors – und lasse mich gerne auch von ihnen challengen. 

Außerdem ist es mir wichtig, auch in Legacy-Projekten den Fokus auf die Einhaltung der State-of-the-Art-Qualitätsstandards zu legen. Last but not least lernt man sowieso durch die Unterschiedlichkeit der Lösungen in den Altanwendungen flexibel zu sein und sich effiziente und effektive Lösungen zu überlegen.

Welche Soft Skills hast du im Zuge deiner Tätigkeit weiterentwickelt?

Die wichtigsten Dinge, die ich gelernt habe, sind mehrere verschiedene parallele Aufgaben effizient zu organisieren, mit vielen verschiedenen Standpunkten umgehen zu können und zwischen den Meinungen zu vermitteln. Zuhören und Reflektieren führt zu einer gemeinsamen, ganzheitlichen Sicht und ermöglicht die beste Lösung.

Möchtest du mehr über die Methoden zur Wartung von Altanwendungen bei der TechTalk erfahren?

Armin Fürst steht dir für weitere Fragen über Mail zur Verfügung.

Haben Sie eine Legacy Software im Einsatz die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

Unverbindlich & kostenlos anfragen