Agile Entwicklung

Ich habe neulich ein relativ übersichtliches Swing/JPA Projekt gebaut und hatte dabei den Luxus zeitlich recht frei zu sein.

Bei GUI-lastigen Programmen für Kunden ist es besonders wichtig, schnell einen Prototypen zu haben, den der Kunde ausprobieren kann. Die meisten Kunden kommen nicht aus der IT-Branche und sind es oft nicht gewohnt, alltägliche Abläufe zu abstrahieren. Es ist also ziemlich belanglos, wie gut die Vorgespräche waren, es muss schnell etwas Konkretes zum ausprobieren her, damit erfahren werden kann, was vorher besprochen wurde. Damit hat man dann eine großartige Grundlage für die ganz sicher nötigen Anpassungen, bis Kunden- und Enwicklervorstellung sich decken.

Provisorien halten ewig

Der Code von dem funktionsfähigen Prototypen sah schrecklich aus und auch nur wenigen Tage Pause hätten vermutlich dafür gesorgt, dass nichtmal ich weiß, was ich da geschrieben habe. Alle GUI Konstrukte für den Hauptdialog in einer Klasse, keine Zeile Dokumentation (abgesehen von den „FixMe“ und „ToDo“ Kommentaren) und redundanter Code.

Zwar hat das Programm die funktionalen Anforderungen erfüllt, war aber nicht mehr wirklich wartbar. Das ist allerdings für einen nicht Techniker nicht sichtbar. Der Kunde sieht die GUI, sieht, dass was passiert, wenn er irgendwo draufdrückt und ist ersteinmal zufrieden. Es wird jetzt sehr schwierig zu erklären, dass das Programm zwar funktioniert aber noch nicht „fertig“ ist. Für den Kunden ist das Projekt jetzt beendet.

Dass das auch auf InHouse Projekte von Firmen mit eigener IT-Abteilung zutrifft, sehe ich täglich bei meinen Beratungskunden. Da Erklären mir regelmäßig Administratoren den Unterschied zwischen „bösen“ und „guten“ Exceptions: Gute Exceptions werden kontinuierlich ins Log geschrieben und werden zu bösen Exceptions, wenn die Applikation den Server lahmlegt. Dass es sich meist um exakt die gleichen Exceptions handelt die nur zu unterschiedlichen Zeitpunkten (einmal kurz nach dem Start des Servers – einmal kurz vor dem Absturz) betrachtet werden, ist dabei uninteressant.

Refactoring gehört zum Projekt

Nun, mein GUI Projekt sieht inzwischen gut aus. Ich habe den redundanten Code zusammengefasst, das Eventsystem überarbeitet und den Hauptdialog in mehrere Klassen aufgeteilt.

Gerade bei den etwas altbackenen, geschwätzigen Sprachen wie Java ist dabei eine gute IDE ausgesprochen hilfreich. Was dafür jedoch noch wichtiger ist, sind gute Tests, damit man sicherstellen kann, dass man beim Aufräumen nicht die funktionalen Anforderungen zerschießt.

Ich kann jetzt auch nach längerer Pause auf den Code gucken und weiß, wozu er gut ist – ja ich weiß sogar, wo ich eventuelle Erweiterungen einbauen kann. Und die Erweiterungen kommen. Ein gutes Programm ist ab einem bestimmten Komplexitätsgrad niemals fertig. Es gibt immer eine Zusatzfunktion, die das Leben für den Benutzer angenehmer macht oder eben Aufgrund von Veränderungen im Benutzungsumfeld nötig wird. Bedürfnisse erzeugen Bedürfnisse.

Die erste Entwicklung hat jetzt mit dem Refactoring ca. 20% länger gedauert als die Erstellung des first Shot und wird bei der Erweiterung die Zeit sicherlich auf wenigstens die Hälfte reduzieren. Der zusätzliche Aufwand wird sich so mittelfristig rechnen. Auch nur mittelfristiges Denken ist aber leider in der Branche nicht mehr sehr üblich. Der Prototyp wird zum finalen Produkt, jede Erweiterung wird ein Abreißen und Neubauen mit gleichzeitigem schimpfen auf die Unfähigkeit des ursprünglichen Entwicklers, der das Projekt mit Erstellung des funktionalen Prototypen aus den Händen gerissen bekommt. Teuer und nicht sehr lehrreich ist dieses Vorgehen.

Für eine kontinuierliche Produktentwicklung gehört deswegen Refactoring zwingend zur Projektzeit und sollte von vorne herein mit eingeplant werden.

Die Kristallkugel

Agile Entwicklung basiert auf Kommunikation und ständiger Veränderung. Die gleichen Grundprinzipien, die Gesellschaft am Leben erhält. Könnte man mit dem klassischen Design First Ansatz ein System bauen, dass allen Marktanforderungen entspricht?

Dazu müsste man in die Zukunft blicken können. Müsste Anforderungen kennen, bevor sich diese im Markt etabliert haben. Man müsste die Folgebedürfnisse bereits vorwegnehmen können. Das führt üblicherweise nur zu einer Menge an Funktionen, die später keinen Interessieren und ein Fehlen von Funktionen, die mittelfristig wichtig sind. Egal wie gut man sein Produkt plant, es bleibt bei dem Grundsatz, dass Bedürfnisse Bedürfnisse erzeugen. Das ist der Motor der Welt. Somit ist es ziemlich beliebig, was ich für eine Funktionalität plane, es wird immer eine geben, die darauf aufbaut. Im Zweifelsfall finanziert man also mit dem Blick in die Kristallkugel einen Holzweg aus Mahagoni.

Es ist meist eine gute Idee, sich bei neuen Produkten ersteinmal auf das Problem zu beschränken, dass sie vornehmlich lösen sollen. Neue Anforderungen kommen im Betrieb von ganz allein.

Ein Gedanke zu „Agile Entwicklung

  1. Frank Pfabigan

    Tja, reichen wir uns die Hände 😉
    Entwicklungen für Kunden laufen meistens nach diesem Schema ab, ob gewollt oder nicht. Daß man unter Umständen erst einmal die Basis, z.B. eine aufwändige Datenbank und die Scripte, die für den Transport der Daten sorgen, schreiben muß, interessiert nicht.
    Der Kunde will zuerst die GUI, alles andere interessiert ihn nicht. Er verdreht dabei den Entwicklungsweg und macht dem Entwickler das Leben (unnötig) schwer.
    Besonders schlimm bei Webprojekten, die direkt im Browser laufen: sowas wird als „einfach“ angesehen, das kann ja wohl nicht so schwer sein, mal eben die Designfarben umzustellen… seufz.
    Ich kann den Kunden verstehen, aber andererseits fühle ich mich auch ein wenig „gekränkt“ (nicht das richtige Wort, ist zu früh, hab bis 03:00 Uhr an was gesessen):
    Kunde beauftragt „Fachkraft“ und schreibt diesem die Arbeitsweise vor. Das gibt es wohl nur bei Software und besonders auch bei Web/Print.
    Kein Kunde würde doch auf die Idee kommen, beim Zahnarzt einen Holzzahn zu verlangen… Warum dann bei Entwicklern?
    Wenn man viele Projekte parallel bearbeitet, wird das zusätzliche „betütern“ zu einem echten Zeitfaktor und bringt die ganze Planung durcheinander. Nicht ganz zufriedenstellend für mich. Aber ändern/erziehen kann man den Kunden nicht. Schlußendlich zahlt der Kunde (hoffentlich) dafür. Also muß man einen gangbaren Weg finden. Ich bin lange weg von „Projektmanagement-Methoden“, bringt nix. Jeder Auftrag ist „Einzelverhandlungssache und -gebastel“.
    Glückauf 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


+ drei = 7