Softwareentwicklung im Team – Teil 10 – Abschlussbemerkungen

Zum Abschluß noch ein paar weitere Probleme, die ich stichwortartig in meinem Pamphlet angesprochen habe.

x. Weitere Probleme
Sicherlich gibt es noch weitere Möglichkeiten, den Entwicklungsprozess zu verbessern. Regelmäßige Code-Reviews, Refactoring, Lasttests sind dabei nur einige wenige. Allerdings würde eine Etablierung der genannten Vorschläge bereits entschieden zur Verbesserung des Entwicklungsprozesses beitragen.
Darüber hinaus bin ich nur auf die Probleme eingegangen, die von allen Entwicklern gleichermaßen umgesetzt werden können. Nicht eingeplante Testphasen, o.ä. fanden daher keine Berücksichtigung.
Daher sollte noch einmal gesondert folgende Punkte besprochen werden: Lasten-/Pflichtenheft, Analyse-/Testphasen, Dokumentation (Architektur, Deployment, etc.)

Rückblickend gesehen
Von den genannten Schlagwörtern wurde nichts mehr diskutiert, geschweige denn umgesetzt. Sicherlich, vereinzelt wurde hier oder da mal ein Refactoring durchgeführt oder man saß zusammen vor einem Rechner um ein Stück Code zu begutachten, aber nichts, was sich fest in unseren Entwicklungsprozess etabliert hatte. Daher gibt’s hier auch keinen weiteren Rückblick.

Zusammenfassung
Wer sämtliche Artikel dieser Serie gelesen hat, wird ggf. den Schmerz zwischen den Zeilen gespürt haben, den man als Entwickler durchgemacht hat. Die Ideen, die umgesetzt wurden, haben einen Großteil dieses Schmerzes nehmen können, aber von einem Idealzustand waren wir weit entfernt.
Auch wenn es logisch erscheint (und mit etwas gesundem Menschverstand auch leicht zu erfassen sein sollte): DIE Silver Bullet gibt es nicht. Dennoch wurde ich mal gefragt, ob ich nicht ein Tool kennen würde, womit wir unsere Entwicklungsprozesse verbessern und beschleunigen könnten. “Was ist denn mit UML. Da gibt’s doch so was von Rationale”, war doch tatsächlich mal eine Aussage. Ähm… ja! Man erwartete irgendwo das Wundertool, welches mit einem Knopfdruck all unsere Probleme lösen würde. Zumindest habe ich es damals teilweise so wahrgenommen. Dass die Tools aber eine untergeordnete Rolle spielen und das die Prozesse und deren Ideen dahinter, bei den Leuten erst einmal in die Köpfe müssen, wurde nicht verstanden. Oder man wollte keine Zeit dafür aufbringen. Ich weiß es nicht.
Rückblickend gesehen muss ich sagen, dass ich mit reichlich viel Naivität an die Sache gegangen bin. Ich dachte damals, man zeigt die Vorteile auf, wiegt sie gegen die Nachteile ab und schon wird ein revolutionäres Umdenken statt finden. Dass ich bei den nicht-Programmieren ggf. ein wenig Probleme bekommen könnte, hatte ich erwartet. Bei einigen Entwicklern aber eine gewisse Beratungs- ja Lernresistenz vorzufinden, hat mich hingegen doch desillusioniert. Dabei war es nicht so, dass diese Entwickler die Vorteile nicht erkannt hätten. Sie stimmten ihnen sogar zu und fanden die Ideen dahinter durchaus ansprechend. Nur getreu dem Motto “Das haben wir schon immer so gemacht”, sah man anscheinend nicht die Notwendigkeit, eigenes Verhalten zu hinterfragen oder gar zu ändern.

Hiermit schließe ich meine kleine Artikelserie “Softwareentwicklung im Team”. Wie immer: Feedback ist durchaus erwünscht ;-)