Softwareprojekte deluxe?


Anlass zu diesem Blogeintrag gab mir die Unterhaltung mit einem IT-Bereichsleiter vor ein paar Tagen, der im Begriff ist, die IT in seinem Unternehmen zu modernisieren. Dabei ging es um Prozessoptimierungen, agile Vorgehensweisen in Teams und die Erstellung von Dokumentationen.
Angetrieben von dem Wunsch, von nun an alles besser und effektiver zu machen und schneller Software zu entwickeln bei gleichzeitiger Kosteneinsparung sind dann auch direkt einige Buzz-Words aus der Welt der modernen Softwareentwicklung gefallen - Agilität, Scrum, Continuous-Integration, Microservices und andere.
Mittlerweile existieren eine Menge guter Werkzeuge und bewährte Vorgehensweisen, um auf einem qualitativ hochwertigem Niveau Softwareenwicklung zu betreiben. Aber Hand aufs Herz, wie oft erlebt man das perfekte Projekt? Ein agiles Projekt, wo jede Entwurfsentscheidung goldrichtig war und die Implementierung an Eleganz und Ausdruckskraft keinen Anlass zu weiterer Optimierung gibt. Es ist nämlich gar nicht so einfach, Vorgehensweisen gut umzusetzen oder vermeintlich immerzu erfolgreiche Strategien auf den eigenen Unternehmenskontext abzubilden.
Aber warum ist das eigentlich so? Warum treten auch bei maximal motivierten Teams, Probleme bei der Softwareentwicklung auf? Warum funktioniert ein in der Praxis vielfach erprobter Prozess nicht im eigenen Unternehmen?
In meiner über 20 jährigen Erfahrung bei der Mitarbeit in professionellen Softwareentwicklungsprojekten in den unterschiedlichsten Branchen, treten häufig die immer gleichen Probleme auf. Im Folgenden werde ich einige dieser Probleme herausgreifen und kommentieren. Dabei habe ich insbesondere an mittelgroße bis große Projekte in mittelgroßen bis großen Konzernen gedacht. Kleine Projekte oder Software mit einer von vorneherein begrenzten Lebensdauer können anders betrachtet werden. Und in schlanken Startups, in denen schon die geringeren Budgets zu echter Agilität zwingen, um schnell und effizient Ergebnisse zu generieren, wird das ein oder andere im Folgenden beschriebene Problem auch nicht auftauchen.

Häufig wiederkehrenden Probleme


Mangelhafte Anforderungen

Die Grundlage für zukünftige Probleme werden häufig schon mit den Anforderungen gelegt. Im Folgenden werden drei Arten von mangelhaften Anforderungen unterschieden.

  1. Unvollständige Anforderungen
    In jedem Projekt wird es Anforderungen geben, die im Laufe der Entwicklung nachgebessert werden müssen. Das ist nicht ideal, aber normal. Das führt zu Codeänderungen und Umbaumaßnahmen in unterschiedlichen Umfang. Um diesen fast schon sicher eintretenden Herausforderungen gut begegnen zu können, ist nicht nur die Architekturplanung entscheidend, sondern auch die Qualität der Anforderung. Eine sauber formulierte und auf den Punkt gebrachte Anforderung, die genau einen kleinen Teilaspekt behandelt, wird nicht so viele Implikationen bei einer Änderung nach sich ziehen als eine weitgefasste Anforderung.
  2. Zu weit gefasste Anforderungen
    Manchmal sind Anforderungen sehr weit bzw. allgemein gefasst, um auf viele Eventualitäten der Zukunft vorbereitet zu sein. Manchmal sind diese aber auch nur Ausdruck von Unkenntnis dessen, was genau benötigt wird. Das Problem hierbei ist, dass bei der Umsetzung solcher Anforderungen sehr viel mehr Programmcode produziert wird als nötig ist und auch konzeptionell mehr geleistet werden muss. Neben der Kostensteigerung, steigt dadurch auch die Komplexität des Systems.
  3. Falsche Anforderungen
    Anforderungen, die sich zu einem späteren Zeitpunkt als falsch erweisen oder aber aus anderen Gründen gestrichen werden, sind besonders dann schlimm, wenn diese einen entscheidenden Einfluss auf die Architekturentscheidungen des Systems gehabt haben.

Bei der Betrachtung mangelhafter Anforderungen werden zwei Dinge klar. Zum einen muss die Gesamtsicht des zu erstellenden Systems bis zum einem gewissen Grad wirklich klar und verstanden sein und zum anderen wird jeder Softwareentwicklungsprozess durch mangelhafte Anforderungen kompromittiert. Das bedeutet konkret, dass bei einer Modernisierung des Entwicklungsprozesses im gleichen Maße eine Modernisierung der Fachabteilungen stattfinden muss. Agile Methoden können nahezu verpuffen, wenn die umgebenen Abteilungen nicht in den Gesamtprozess auf gleiche Art eingebunden sind.
Ein gutes Softwareprojekt beginnt daher bereits in den Fachabteilungen.

Zeitdruck

Nicht selten werden in Projekten zu Anfang die Deadlines ausgegeben bis hin zum Datum, an dem die Software fertig sein soll. Die Grundlage bildet dabei häufig nur eine grob geschätzte Skizze des späteren Konzepts. Der Zeitdruck ist hier bereits vorprogrammiert. Auch neue Anforderungen während der Entwicklung, deren Umsetzung ebenfalls Zeit benötigt, bilden eher die Regel als die Ausnahme. Wenn die Zeit dann knapp wird bis zur nächsten Deadline oder der Vorstellung des aktuellen Standes gegenüber der Geschäftsführung, dann wird häufig nicht mehr konzeptionell sauber gearbeitet. Das Ergebnis sind Bestandteile der Software, die einem späteren Refactoring unterzogen werden müssen, also die sogenannten technischen Schulden.
Auch Zeitdruck ist etwas eher normales in Projekten, da gerade in der Softwareentwicklung immer Probleme auftauchen können, mit denen vorher niemand gerechnet hat. Mit einer guten Planung und Durchführung ist dieses Problem aber beherrschbar.

Technische Schulden

Die aus dem Zeitdruck oft entstehenden technischen Schulden können natürlich auch auf anderem Wege zustande kommen. Gemeinsam ist ihnen, dass es sich um Dinge handelt, die das Team in nicht bestimmbarer Zukunft einmal angehen wird, wenn Zeit vorhanden ist. Nicht selten tritt dieser Zeitpunkt dann nie ein. Manchmal werden technische Schulden aber auch gar nicht als solche erkannt oder sie sind Gegenstand von Diskussionen innerhalb des Teams. Eine geringe Konsistenz oder eine schlechte Abdeckung durch automatisierte Tests ist noch für alle einsehbar, aber die x-fach abgeleiteten Klassen, die mangelnde Modularisierung und der inflationäre Einsatz von Bibliotheken Dritter, wovon jeweils nur eine einzige Methode benötigt wird, stehen häufig nicht auf der Liste der zu überarbeitenden Dinge.
Generell haben technische Schulden einen negativen Einfluss auf die Softwarequalität und halten häufig böse Überraschungen für die Zukunft parat. Zudem steigt der Aufwand bei der Wartung und Weiterentwicklung der Software im erheblichen Maße, was später wiederum zu höheren Kosten führt. Die Notwendigkeit der Beseitigung von technischen Schulden ist den eigentlichen Projektverantwortlichen häufig nur schwer vermittelbar. Denn den dabei entstehenden Kosten steht kein direkt messbarer Mehrwert gegenüber. Die Kostenersparnis ergibt sich erst später und auch diese ist nur bedingt ermittelbar.

Nicht passende Organisationsstruktur

Viele Unternehmen wollen eine moderne Softwareentwicklung betreiben, effizient und kostensparend sein, eben so wie mein Eingangs erwähnter Gesprächspartner es sich wünscht. Was ich aber immer wieder beobachte, ist der Umstand, dass diese Unternehmen nicht bereit sind ihre Organisationsstrukturen anzupassen. Man muss es einfach so hart sagen, wenn an alten Strukturen, an gewachsenen Hierarchien bedingungslos festgehalten wird, dann wird es meistens sehr schwer mit der Einführung von flexiblen Entwicklungsprozessen und kleiner, hocheffizienter Entwicklerteams. Da hilft es auch nur bedingt die Entwickler in Scrum oder ähnlichem zu schulen und mehr Meetings zwischen den Entwicklern und den Fachbereichen anzusetzen. Ganz im Gegenteil, es kann sogar eher schaden, wenn die alten Prozesse im Großen und Ganzen beibehalten werden, aber aus Gründen scheinbarer Agilität diese in wichtigen Teilen beschnitten werden, z.B. im Bereich der Dokumentation.

Architekturverwässerung und Dokumentationsphobie

Architektur und Dokumentation sind für sich genommen schon bücherfüllende Themen, wodurch sich deren Bedeutung schon zeigt. Und doch erlebe ich immer wieder Projekte, wo diese beiden Themen nur sehr stiefmütterlich behandelt werden. Beim Start auf der grünen Wiese wird noch Softwarearchitektur betrieben und vielleicht auch noch ausreichend dokumentiert, aber in der Phase der Implementierung bleibt dann beides auf der Strecke. Eigentlich der helle Wahnsinn, ist doch dieses Zweiergespann Gold Wert während der Entwicklung, aber vor allem auch bei der Weiterentwicklung und Wartung. Gerade die letzten beiden Punkte sind von zentraler Bedeutung für ein langlebiges Softwaresystem. Entscheidet dies doch darüber, wie schnell neue Anforderungen später umgesetzt werden können, wie schnell der neue Teamkollege eingearbeitet werden kann, um sich im System zurechtzufinden und wie die Qualität des Systems ist und gehalten werden kann.
Bei allen dokumentationswürdigen Dingen eines Systems ist eine Dokumentation von zentraler Bedeutung: Die Übersichtsdokumentation - das BIG PICTURE des Softwaresystems. Wenn die Zusammenhänge im Großen nicht verstanden werden, dann führt dies leider fast immer zu Qualitätsverlust in verschiedenster Form. Beispielsweise werden Refactorings oder Verbesserungen durch die Implementierung neu eingeführter Konzepte oder Lösungen durchgeführt, die aber nur durch lokale Betrachtungen zustande gekommen sind ohne Berücksichtigung von Wechselwirkungen mit anderen Systemteilen, eben weil diese gar nicht bekannt sind aus Ermangelung einer Übersichtsdokumentation. Das System fängt unkontrolliert zu wuchern an durch Implementierungen, die im schlimmsten Fall gar nicht mehr zur Architektur passen.


Diese Liste erhebt natürlich nicht den Anspruch auf Vollständigkeit, aber sie zeigt sehr häufig wiederkehrende Probleme, die es auch in einem agilen Umfeld zu meistern gilt. Dies gilt insbesondere bei der Einführung agiler Prozesse in Unternehmen mit bestehenden Strukturen. Ich selber präferiere die sanfte Strukturänderung bei gleichzeitiger Einführung moderner Prozesse. Wie das aussehen kann, ist sehr vom Unternehmenskontext abhängig. Und manchmal ist es auch besser, sich zunächst nur die bestehenden Prozesse anzuschauen und zu optimieren oder zu ergänzen, anstatt von Anfang an auf die große Änderung zu setzen, was zu Frustrationen in den Teams führen kann oder sogar die bisherigen Prozesse beeinträchtigt. Gerade die Teams müssen bei einer solchen Veränderung mitgenommen werden, bedeutet Agilität zwar mehr Freiheit, aber damit einhergehend auch eine größere Verantwortung für die Entwickler.
Tags: Agilität, Anforderungen, Technische Schulden, Organisationsstrukturen, Dokumentation
Guido Oelmann     Samstag, 4. Februar 2017 0    598
@
(Email Adresse wird nicht veröffentlicht)
(kein HTML erlaubt)
Bitte beantworten Sie die einfache mathematische Frage.
  


Keine Kommentare vorhanden.