Kontinuierlich vs. iterativ

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Eine kurze Bemerkung meinerseits zu dem Punkt kontinuierlich vs. iterativ.

Der kontinuierliche Ansatz basiert meiner Meinung nach auf zwei Rahmenbedingungen. Kontinuierlicher Verfügbarkeit der relevanten Personen, also deren ausschließliche Fokussierung auf ein "Projekt" und der Annahme, dass zentrale Risiken einigermaßen im Griff sind bzw. stets klarer Prioritäten.

Es gibt Softwareprojekte, für die das gilt, doch gerade, wenn mehrere Fachabteilungen/Stakeholder und/oder räumliche Verteilungen ins Spiel kommen oder für einzelne Personen/Fachwissen keine Redundanz vorhanden ist (z.B. eine QS für 3 Projekte oder technische Fachexperten) sehe ich Vorteile im iterativen Ansatz mit verlässlichen, vorab planbaren Terminen.

Dazu kommt die notwendige Fokussierung auf Rüstzeiten, um die Flexibilität zu erreichen. Das ist für mich ein spannender Punkt, denn von dort ausgehend, kann man zu sehr originellen Lösungen kommen (vgl. Ohno: Toyota-Prozess). In der SW-Entwicklung haben wir es oft mit Rüstzeiten im Kopf einzelner Personen zu tun.

Ich finde es spannend darüber nachzudenken, wie von dort aus kommend, Entwicklungsprozesse aussehen können, die minimale Rüstzeiten erlauben. Wie kann man mit parallelen Tasks angemessen umgehen? Wie nehme ich Zwischenstände aussagekräftig ab? Testgetriebene Ansätze könnten vielleicht dazu interessante Ideen beisteuern oder auch eine ganz andere Form der technischen Bereitstellung von Zwischenständen für die anderen Stakeholder wie Fachbereiche oder QS in einer eher kontinuierliche Form, so dass zu jeder (passenden) Zeit an jedem Arbeitsplatz ein Zwischenergebnis abgenommen werden kann. Im klassischem, prozessorientierten Projektmanagement entspricht diese Idee der Einführung vieler und flexibel handhabbarer "Zwischen"-Gates. Anders als im klassichen Sinne, möchte ich diese allerdings nicht planen ;-) Das betrifft aber nur einen Aspekt und löst nicht die Rückkopplungsproblematik usw.

Uwe Vigenschow