Theorie und Praxis
27.11.2006 Permalink Jetzt sitze ich nach dem Vortrag über Methoden des Requirements-Engineering im Zug und denke an den Satz eines Zuhörers, den er mir im unmittelbaren Anschluss sagte: das alles müsste man mal wirklich machen, warum nur kommt das in Projekten so selten zum Fliegen.Warum diese Praktiken zur Erhebung, Spezifikation, Modellierung, Validierung -- obwohl alle praxiserprobt -- selten Anwendung finden, kann ich mir schon denken. Eine Frage interessiert mich aber mehr: Es gibt einen ganzen Haufen von Prinzipien und Praktiken. Eine überwiegende Zahl, obwohl sicher sinnvoll, hat es nicht in die Projektrealität geschafft, wie ich sie kenne. Trotzdem kommt Software heraus. Ist das also alles nur Theorie, die in der Praxis zu vernachlässigen ist? Und gibt es eine Grenze, d.h. gibt es eine Menge von Praktiken, ohne die Softwareentwicklung richtig schmerzhaft wird, wogegen man beim Weglassen aller anderen Praktiken zwar Nachteile in Kauf nimmt, die aber -- verglichen mit den möglichen Schmerzen -- Peanuts sind? Und wenn ja, wie sieht diese Menge aus?
Ich glaube, sie ist überschaubar:
In kleinen Releases denken.
Durch zuviel Umfang in frühen Projektphasen tappt man mit beiden Füßen in die
Wasserfall-Falle. Man riskiert enorme Kosten ohne eingespielte Prozesse und
Fähigkeiten zur Vorhersage.
Aufschreiben, was man jeweils bauen möchte.
Wer einfach programmiert, ohne festzuhalten, was eigentlich gehen soll, nimmt
sich jede Möglichkeit eines systematischen Tests. Denn allein am (halbwegs)
laufenden System kann man keine Testfälle ableiten.
Organisatorische und technische Abhängigkeiten vermeiden.
Abhängig sein heißt: ich kann nicht ohne x,y und z. Und das ist immer ein
Risiko, denn wer garantiert uns x, y und z? Und wer mal
Wahrscheinlichkeitsrechnung hatte, weiß, dass die Wahrscheinlichkeit, dass x, y
und z alle in Ordnung sind, p(x)*p(y)*p(z) ist, und dass diese Zahl recht
schnell nahe bei Null liegt.
Früh und häufig das System bauen.
Integration ist immer schmerzhaft. Und je länger Code nicht integriert und
zusammen zum Laufen gebracht wird, desto größer wird das Leid.
Versionskontrollsystem einsetzen.
Mit mehreren Personen an einer Codebasis ohne Versionskontrolle zu arbeiten,
garantiert den frühen Wahnsinn.
Ist- und Restaufwände auf Basis eines Plans erfassen.
Bessere Vorhersagen kann ich nur machen, indem ich lerne, was mich ein Release
kostet. Das Ziel in einem Release ansteuern zu können geht nur, wenn ich sehe,
wie weit ich davon weg bin.
Tests spezifizieren und durchführen.
Ohne Tests vor der Auslieferung werden die Anwender zu Testern. Dadurch kann ich
komplette Geschäftsbereiche lahmlegen.
Change-Management-Prozess verwenden.
Ohne einen geordneten Weg, Änderungen der Anforderungen in ein laufendes Release
einzusteuern, werden sich die Anforderungen eine ungeordneten Weg schaffen.
Alternativ wird die Anwendung unbrauchbar ausgeliefert.
Wöchentliche Projektsteuerungssitzung abhalten.
Ohne, dass man sich wöchentlich (oder von mir aus auch täglich) in die Augen
sieht, und feststellt, wo man steht und was zu tun ist, ist in ein Projekt kein
Zug reinzukriegen.
(Apropos Zug, jetzt bin ich schon in Köln. Gleich ist Feierabend.)
Tatsächlich kann man viel mehr einsetzen und ich würde das auch wärmstens empfehlen. Wer aber an den oben genannten Punkten noch blank ist, sollte dort schnell Abhilfe schaffen, denn diese Mängel vermiesen einem echt den Spaß.