Carola Lilienthal

Kennen Sie das auch? Sie entwerfen eine gut strukturierte Softwarearchitektur in Form von Diagrammen und nutzen sie als Blaupause für Ihr Softwaresystem. Während der Implementierung weichen Ihre Entwickler ungewollt mehr und mehr von diesen Vorgaben ab: Einerseits macht der Projektdruck Abweichungen notwendig, andererseits entstehen die Abweichungen ungewollt und unbemerkt. Die Architektur Ihres Systems erodiert und Sie bauen Schritt für Schritt technische Schulden auf. Wartung und Erweiterung der Software werden immer teurer bis zu dem Punkt, an dem jede Änderung zu einer schmerzhaften Anstrengung wird. In diesem Vortrag berichte ich von meinen Erfahrungen der letzten zehn Jahre mit der Analyse von Softwarearchitekturen in Java, C++, C# und ABAP: Wie entstehen technische Schulden? Wie können technische Schulden vermieden werden?
Um technische Schulden sichtbar zu machen und ihnen rechtzeitig entgegenzusteuern, wurden in den letzten zehn Jahren verschiedene Architekturanalysewerkzeuge entwickelt (Sotograph, SonarQube, JDepend, XRadar, Axovion Bauhaus, Structure101, Lattix u.v.m.). Ich werde Ihnen im Vortrag einen Überblick über diese Werkzeuge und ihre Einsatzmöglichkeiten geben. Die Zuhörer wissen nach meinem Vortrag, welche Fehler sie in ihren Softwareprojekten bei der Umsetzung der Architektur in Sourcecode nicht machen sollten, welche Prinzipien Sie einhalten sollen, um technische Schulden nicht entstehen zu lassen, welche Tools helfen, technische Schulden aufzuspüren und wie technische Schulden abgebaut werden können.

Softwareentwicklung gleicht oftmals einer Fahrt im Nebel: Ziel klar, Sicht schlecht – und für die gesamte Besatzung stellt sich die Frage: Wie organisieren wir unsere Arbeit, um so sicher wie möglich ans Ziel zu kommen? In der Vergangenheit planten die Beteiligten meist einzelne Phasen, die jeweils mit einem definierten Ergebnis abgeschlossen werden sollten. Das hat selten gut funktionierte und häufig zusätzlich hohe Kosten sowie unzufriedene Kunden und Entwicklungsteam erzeugt.
Als Ausweg aus dem Dilemma wird seit rund 15 Jahren agiles Vorgehen unter verschiedenen Namen gepredigt: Extreme Programming (XP) , Feature Driven Development, (FDD), Rational Unified Process (RUP), SCRUM, V-Model, XT, Lean Software Development, Kanban. In welche Firma man heute auch kommt, die Frage nach dem Vorgehen in IT-Projekten wird durchgehend beantwortet mit: Wir gehen nach SCRUM vor! Wir sind agil! Eine andere Antwort ist heutzutage gerade zu peinlich, wenn nicht gar verpönt.
Beobachtet man die Projekte einige Zeit, so muss man leider feststellen: manche der mit solchen Techniken umgesetzte Projekte sind erfolgreich, andere aber leiden an den selben oder ähnlichen Symptomen wie die verteufelten klassischen Projekte.
In diesem Vortrag werde ich den Zuhörern vermitteln, was meiner Erfahrung nach die entscheidenden Zutaten für agile Projekte sind. Die Zuhörer wissen nach dem Vortrag, was sie bei ihren agilen Projekten unbedingt beachten müssen, damit Agilität ihre beeindruckende Kraft entfaltet.