Crunch oder Planung?
Von Carsten
Mal ehrlich, wir kennen alle diese Zeiten, wenn das Projektende plötzlich und unerwartet vor der Tür steht. Wenn nach 2 oder 3 Monaten Implementierung reihenweise Bugs im Tracker auftauchen. Wenn sich anscheinend niemand mehr an Entscheidungen aus den allerersten Tagen erinnern kann. Und dann beginnt der Crunch und die Tage im Büro werden unabhänging von der Jahreszeit immer länger…
Aber wieso ist das so? Muss die Entwicklung vielleicht so laufen und gibt es gar keine Möglichkeit, so einen Ablauf zu verhindern? Oder ist man vielleicht einfach so daran gewöhnt, dass es gar keinem mehr als Missstand auffällt?
Gründe gibt es viele. Aber für mich sind 2 Gründe gravierend und gleichzeitig vermeidbar:
- Kundenfeedback wurde viel zu spät eingeholt
- Prioritäten sind zu unscharf definiert und angewendet
Der erste Punkt kann nur durch eine Aktion gelöst werden: Früher Kundenfeedback einholen. Das bedeutet gleichzeitig, so früh wie möglich Versionen ausliefern. Und das bedeutet, man muss wirklich iterative Prozesse anwenden, von der Entwicklung, zum Test, bis zum Deployment. Ich würde gern in einem Projekt mit SCRUM arbeiten, aber das steht im Moment in weiter Ferne. Aber allein die Theorie und die Prozessbeschreibung von SCRUM klingt nach einem Prozess, wie ich ihn mir für meine nächsten Projekte erträume…
Der zweite Punkt kann nur durch die Organisation und die strikte Befolgung von Prozessen (sprich: definierten Abläufen) erreicht werden. Und wenn jemand mit dem Satz”Wir müssen flexibel sein” eigentlich”Wir machen einfach alles, was von uns verlangt wird” meint, dann entspricht das nicht ganz meiner Einstellung und erst recht nicht einem agilen Entwicklungsprinzip.
Passend zu meiner Einstellung zu Entwicklungsprozessen lese ich gerade folgendes Buch:
Continuous Delivery von Jez Humble und David Farley.