© best_vector/Shutterstock.com
Windows Developer
Welche Projektmethode passt zu Ihrem Team?

Kleine Projekte mit großer Wirkung

Agile Projektmethoden fordern eine interdisziplinäre und iterative Arbeit in kleinen Zyklen. Vielen Projektteams fällt es schwer, sich auf diese Herangehensweise umzustellen. Der „Big-Design-Up-Front“-Gedanke sitzt tief in den Projektgenen. Wie gelingt es aber, kleine, unabhängige Projekte aus einem großen Ansatz herauszudenken? Wie können Teams auf pragmatische Weise die Forderung nach Iteration und Lernen erfüllen und sich zugleich von impliziten Vorstellungen in Bezug auf gute, vollständige Projekte lösen? Dieser Artikel gibt praktische Tipps für die Veränderung der Teamprozesse und des Projekt-Set-ups.

Judith Andresen


Wir neigen zu großen IT-Projekten. Je länger die Beteiligten über das anstehende Projekt nachdenken, desto größer werden die notwendigen Anforderungen. Die Featureliste nimmt kontinuierlich an Länge zu – und damit wird das Projekt auch immer größer. Wir möchten ein gutes, vollständiges Produkt abliefern. „Wenn wir das so machen, müssen wir aber etwas für den Fall XYZ vorsehen“ – getrieben von diesem Gedanken planen wir ein immer größeres Stück Software. Durch vorherige Projekte haben die Beteiligten nämlich einiges gelernt, dass sie nun umsetzen:

Wenn die Projektbeteiligten ihre Features nicht jetzt „durchgedrückt“ bekommen, bekommen sie diese nie.Die versprochenen Nachfolgeprojekte zum Nachbessern werden immer wieder verschoben. Daher ist es wichtig, dass die eigenen Anforderungen im initialen Projekt enthalten sind.Das vorherige Projekt geriet unter Zeit- und Qualitätsdruck. Wurde das ursprüngliche Feature zu klein angesetzt, drohte es, während des Projekts auf die Streichliste zu kommen.

Mit jeder Anforderung steigt die Komplexität und damit der Umfang der Aufgabe stark an. Für die meisten sind Projekte nur dann perfekt, wenn sie vollumfänglich alle möglichen Features enthalten. Gleichzeitig steigt das Risiko des Scheiterns so signifikant [1], wie das Diagramm in Abbildung 1 zeigt, in der die Projektgröße (in Euro) gegen den Projekterfolg aufgetragen ist.

Abb. 1: Je kleiner die Projektgröße ist, desto eher wird das Projekt gelingen

Ein überschaubarer Projektumfang und ein klarer Projektauftrag wären wünschenswert. Dennoch trauen sich viele Teams diesen (als radikal empfundenen) Schnitt nicht.

Damit Teams künftig seriell in kleinen, erfolgsversprechenden Schritten arbeiten, sind zwei Schritte zu gehen: Auf Organisationsebene sollte der Fokus auf einen kleinen Projektumfang gesetzt werden. Auf Teamebene ist es notwendig, angepasste Teamroutinen umzusetzen.

Kleine Projektumfänge zunächst Herausforderung

Der Projektumfang kann dabei sowohl aus fachlicher als auch aus technischer Sicht überdimensioniert sein. Insbesondere vor „Rewrites“ von Systemen kann es leicht passieren, dass Teams in die „Größenfalle“ tappen.

Die Beteiligten haben gerade erfahren, dass für das System ein derart hoher technischer Schuldenberg aufgehäuft wurde, dass ein Rewrite notwendig wurde. Daher muss das neue System aus technischer Sicht besonders solide und auf dem neuesten Stand entwickelt werden. Gleichzeitig haben die Beteiligten festgestellt, dass in letzter Zeit aufgrund des Bearbei...

Windows Developer
Welche Projektmethode passt zu Ihrem Team?

Kleine Projekte mit großer Wirkung

Agile Projektmethoden fordern eine interdisziplinäre und iterative Arbeit in kleinen Zyklen. Vielen Projektteams fällt es schwer, sich auf diese Herangehensweise umzustellen. Der „Big-Design-Up-Front“-Gedanke sitzt tief in den Projektgenen. Wie gelingt es aber, kleine, unabhängige Projekte aus einem großen Ansatz herauszudenken? Wie können Teams auf pragmatische Weise die Forderung nach Iteration und Lernen erfüllen und sich zugleich von impliziten Vorstellungen in Bezug auf gute, vollständige Projekte lösen? Dieser Artikel gibt praktische Tipps für die Veränderung der Teamprozesse und des Projekt-Set-ups.

Judith Andresen


Wir neigen zu großen IT-Projekten. Je länger die Beteiligten über das anstehende Projekt nachdenken, desto größer werden die notwendigen Anforderungen. Die Featureliste nimmt kontinuierlich an Länge zu – und damit wird das Projekt auch immer größer. Wir möchten ein gutes, vollständiges Produkt abliefern. „Wenn wir das so machen, müssen wir aber etwas für den Fall XYZ vorsehen“ – getrieben von diesem Gedanken planen wir ein immer größeres Stück Software. Durch vorherige Projekte haben die Beteiligten nämlich einiges gelernt, dass sie nun umsetzen:

Wenn die Projektbeteiligten ihre Features nicht jetzt „durchgedrückt“ bekommen, bekommen sie diese nie.Die versprochenen Nachfolgeprojekte zum Nachbessern werden immer wieder verschoben. Daher ist es wichtig, dass die eigenen Anforderungen im initialen Projekt enthalten sind.Das vorherige Projekt geriet unter Zeit- und Qualitätsdruck. Wurde das ursprüngliche Feature zu klein angesetzt, drohte es, während des Projekts auf die Streichliste zu kommen.

Mit jeder Anforderung steigt die Komplexität und damit der Umfang der Aufgabe stark an. Für die meisten sind Projekte nur dann perfekt, wenn sie vollumfänglich alle möglichen Features enthalten. Gleichzeitig steigt das Risiko des Scheiterns so signifikant [1], wie das Diagramm in Abbildung 1 zeigt, in der die Projektgröße (in Euro) gegen den Projekterfolg aufgetragen ist.

Abb. 1: Je kleiner die Projektgröße ist, desto eher wird das Projekt gelingen

Ein überschaubarer Projektumfang und ein klarer Projektauftrag wären wünschenswert. Dennoch trauen sich viele Teams diesen (als radikal empfundenen) Schnitt nicht.

Damit Teams künftig seriell in kleinen, erfolgsversprechenden Schritten arbeiten, sind zwei Schritte zu gehen: Auf Organisationsebene sollte der Fokus auf einen kleinen Projektumfang gesetzt werden. Auf Teamebene ist es notwendig, angepasste Teamroutinen umzusetzen.

Kleine Projektumfänge zunächst Herausforderung

Der Projektumfang kann dabei sowohl aus fachlicher als auch aus technischer Sicht überdimensioniert sein. Insbesondere vor „Rewrites“ von Systemen kann es leicht passieren, dass Teams in die „Größenfalle“ tappen.

Die Beteiligten haben gerade erfahren, dass für das System ein derart hoher technischer Schuldenberg aufgehäuft wurde, dass ein Rewrite notwendig wurde. Daher muss das neue System aus technischer Sicht besonders solide und auf dem neuesten Stand entwickelt werden. Gleichzeitig haben die Beteiligten festgestellt, dass in letzter Zeit aufgrund des Bearbei...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang