Projekt-Makro-Management, Teil 1 Datenbasierte Kontrolle und präzise Prognosen mit wenig Aufwand

Anbieter zum Thema

TASKING GERMANY GmbH

MicroConsult Academy GmbH

Parasoft® Deutschland GmbH

Softwareprojekte lassen sich auch ohne Mikromanagement steuern, wenn man konsequent die richtigen Tools einsetzt. Teil 1 dieses zweiteiligen Beitrags zeigt, wie sich aus Tickets, Verfügbarkeiten und groben Meilenstein-Zuordnungen ein täglich aktualisierter Forecast ableiten lässt, der Risiken früh sichtbar macht, ohne Teams mit Detailplanung zu belasten.

Bei der Organisation mehrerer Softwareprojekte ist es weder praktikabel noch wünschenswert, ständig zu verfolgen, wer genau gerade an welcher Aufgabe arbeitet, oder genaue Schätzungen für jede einzelne Aktivität zu erwarten. Diese Detailgenauigkeit ist sowohl zeitaufwendig als auch ineffektiv; sie liefert kaum verwertbare Erkenntnisse darüber, ob ein Projekt planmäßig verläuft oder ob ein Eingreifen erforderlich ist. Darüber hinaus untergräbt ein solches Mikromanagement oft die Moral des Teams. In der Realität arbeiten Teams in der Regel mit einem kurzfristigen Planungshorizont von wenigen Wochen. Sie arbeiten am besten, wenn sie sich auf die Aufgaben mit der höchsten Priorität konzentrieren – idealerweise jene auf dem kritischen Projektpfad – und dann ihre Pläne aktualisieren, sobald neue Informationen vorliegen.

Tatsächlich ist man nicht an diesen Details interessiert, sondern möchte wissen: Wann ist die Fertigstellung des Projekts konkret zu erwarten, basierend auf der Unterteilung der Aufgaben in grob geschätzte Meilensteine und der Zuweisung der verfügbaren Mitarbeiter auf diese Meilensteine? Noch wichtiger ist es, so früh wie möglich zu sehen, wenn sich die voraussichtliche Fertigstellung verschiebt – beispielsweise durch ungeplante Aufgaben, ungenaue Schätzungen oder unvorhergesehene Abwesenheiten. Denn nur so können rechtzeitig Korrekturmaßnahmen ergriffen werden, sobald Deadlines erkennbar unrealistisch werden.

Herkömmliche Methoden wie Sprint-Reviews oder Ampel-Dashboards (grün/gelb/rot) geben keine verlässliche Vorhersage. Sprint-Reviews konzentrieren sich eher auf die jüngsten Fortschritte als auf die Prognose der endgültigen Fertigstellung, und Ampeln, die nicht mit den richtigen Daten verknüpft sind, bleiben in der Regel bis kurz vor Ablauf der Frist auf Grün – nur um dann plötzlich auf Rot zu springen, wenn es bereits zu spät ist, um eine Kurskorrektur vorzunehmen.

In diesem Artikel wird gezeigt, wie man bereits vorhandene Daten – wie Tickets z. B. aus JIRA und die Verfügbarkeiten aus Urlaubskalendern – zusammen mit einfachen durchschnittlichen Arbeitszuweisungen (z. B. „John wird von Januar bis März 20 Stunden pro Woche am Beta-Meilenstein von Projekt X arbeiten“) nutzt, um ein automatisiertes, täglich aktualisiertes Dashboard zu erstellen, das Folgendes bereitstellt:

• Tägliche Prognosen zu Projekt-Deadlines auf Grundlage der bisherigen Arbeit, der geplanten Arbeit und der Qualität der Schätzungen;

• Auswirkungen der Genauigkeit der Gesamtschätzungen auf den Fertigstellungstermin;

• Frühwarnungen bei gefährdeten Deadlines (Ampel, aber basierend auf realen Daten und Projektionen); und

• Eindeutige Zuordnung von Verzögerungen zu ihren Ursachen (z. B. unterschätzte Aufgaben, erweiterter Umfang, unzureichende Kapazitäten).

Dieser Ansatz berücksichtigt die praktischen Realitäten: Schätzungen werden niemals perfekt sein, und Entwickler benötigen Flexibilität bei der Einteilung ihrer Zeit. So entscheiden beispielsweise John und sein Projektmanager gemeinsam, wann er seine 20 Wochenstunden leistet – er kann in einer Woche doppelt so viel arbeiten und in der nächsten Woche eine Pause einlegen. Solange sein durchschnittlicher Beitrag zur Planung passt und die Schätzungen im Durchschnitt innerhalb des geplanten Puffers liegen, bleibt das Projekt im Plan.

Die Methode funktioniert, ohne zusätzlich große Mengen an Daten über die täglichen Aktivitäten aller Beteiligten verwalten zu müssen, welche häufig auch zu ungenau sind. Die verwendeten Mittelwerte lassen sich mit wenig Aufwand verwalten, erlauben aber trotzdem präzise Prognosen.

Vorteile auch bei agilem Arbeiten?

Viele Softwareunternehmen nutzen heute eine Form der agilen Methodik, um ihre Arbeit zu planen und auszuführen, sei es Scrum, SAFe oder eine selbst entwickelte Variante. Auch wenn sich der Zeitrahmen unterscheiden kann (SAFe blickt in der Regel weiter in die Zukunft als Scrum), beschränkt sich der Fokus agiler Methoden oft auf nur wenige Wochen. Der Rest des Projekts ist top-down geplant und die Informationen aus den schon abgeschlossenen Sprints fließen erfahrungsgemäß selten in strukturierter Form in den Restplan ein.

Erfahrungsgemäß veröffentlichen die meisten Softwareunternehmen wichtige Produktaktualisierungen nur ein- oder zweimal pro Jahr, manchmal sogar noch seltener. Der Feedback-Zyklus ist fast immer viel länger als der Release-Zyklus. In der Praxis heißt das, dass die Planung für ein bevorstehendes Release eher auf Erkenntnissen aus älteren Releases (und Bug-Reports) basierte als auf denen aus dem letzten Release oder Sprint.

Außer bei der Entwicklung von risikoarmen Internet-, Mobil- oder Cloud-Anwendungen, bei denen A/B-Tests und schnelles Anwender-Feedback die Entwicklung vorantreiben können, haben die meisten Produkte längere Lebenszyklen. Businesskunden sind in der Regel nicht daran interessiert, als permanente A/B-Tester zu fungieren, und sie sind nur bereit, wenige wesentliche Releases pro Jahr zu akzeptieren, insbesondere wenn es sich um ein reglementiertes Produkt (Safety) handelt.

Das Ergebnis? Selbst in Unternehmen, die „agil arbeiten“, erfolgen die Veröffentlichungen oft in Form von monolithischen Releases, bei denen das minimal funktionsfähige Produkt (MUST-have-Funktionen plus einige COULD-have-Funktionen) feststeht und die Fristen weit über ein paar Sprints hinausgehen – manchmal sechs Monate, manchmal Jahre.

Reichen da nicht die Sprints in JIRA und die Projektmanagement-Tabellen oder -Tools, die wir schon haben?

In der Praxis scheitern viele Projekte. Manche waren von Anfang an unrealistisch, häufiger wurden sie jedoch im Laufe der Zeit aufgrund unvorhergesehener Probleme unrealistisch: ungenaue Schätzungen, ungeplante Änderungen des Projektumfangs, unerwartete Ausfälle oder sogar politischer Druck, den Arbeitsaufwand zu unterschätzen.

In den meisten Unternehmen wird Projektmanagement in diversen Formen betrieben, um diese Probleme zu beherrschen: Es werden Projektstrukturpläne erstellt, Schätzungen vorgenommen, Mitarbeiter zugewiesen und Aufgaben in Sprints verfolgt. Häufig jedoch wird der „Gesamtplan“ zu Beginn manuell erstellt und später nur selten aktualisiert. Danach konzentriert man sich hauptsächlich auf die Erfassung kleinerer Schritte: den nächsten Sprint oder die nächsten beiden Sprints (oder Kanban oder andere Methoden zur Verfolgung kleinerer Arbeitsschritte).

Sprints bieten nur einen engen Planungshorizont: In der Regel blicken die Teams ein bis drei Sprints in die Zukunft und beurteilen den letzten Sprint. Das ermöglicht nur begrenzte Einblicke in langfristige Trends. Auch schaffen es die Teams oft nicht, alle innerhalb eines Sprints geplanten Aufgaben bis zum Ende des Sprints vollständig abzuarbeiten (alle Tickets geschlossen). So kommt es zu Diskussionen darüber, warum wirklich jedes Ticket geschlossen sein muss, wenn am Ende des Sprints kein Release folgt, sondern nur der nächste Sprint. Die Aufgabenzuteilung für zukünftige Sprints ändert sich ständig. Das Sprint-Review zeigt, was in den vergangenen Wochen passiert ist, bietet aber fast keinen Ausblick darauf, ob das gesamte Projekt auf Kurs ist.

Es ist auch nicht sinnvoll, von Teams (Projektmanager gibt es in Scrum ja nicht) zu erwarten, dass sie mehr als zwei bis drei Sprints in die Zukunft denken. Alles an Feinplanung, was darüber hinausgeht, wird sich mit hoher Wahrscheinlichkeit noch ändern. Stattdessen sollte sich das Team auf die Herausforderungen des aktuellen Sprints konzentrieren.

Um trotzdem einen Ausblick zu bekommen, wo das Projekt steht, setzen viele Unternehmen auf Sprint-Reviews, Feature-Demos und Projektmanagement-Meetings, bei denen ein Ampelstatus gezeigt wird – grün, gelb oder rot –, begleitet von einer kurzen, manuell verfassten Zusammenfassung der Highlights, Lowlights und Risiken. Allzu oft basiert dieser Ampelfarbenstatus eher auf Bauchgefühl als auf harten Daten. Die Risiken sind in der Regel sehr allgemein gehalten („Menschen könnten krank werden“) und die Ampeln bleiben bis wenige Wochen vor der Veröffentlichung auf Grün. Dann springen sie plötzlich auf Rot und niemand weiß, was schiefgelaufen ist.

Da der praktische Planungshorizont der Teams üblicherweise auf zwei bis drei Sprints begrenzt ist, bekommt man damit nur eine Momentaufnahme. Es sei denn, es werden systematisch mehr Daten herangezogen.

Das Risiko irreführender Kennzahlen

Statt eine bessere Datenbasis zu verwenden, wird häufig versucht, mit SMART-Goals den Entwicklern Regeln mitzugeben, wie sie sich zu verhalten haben, damit das Projekt am Ende rechtzeitig fertig wird.

So ist es z. B. möglich, Visualisierungen zu erstellen, die die am meisten über- oder unterschätzten Tickets hervorheben und identifizieren, wer sie umgesetzt hat. Allerdings sind solche Daten sehr anfällig für Fehlinterpretationen. Wenn man daraus vorschnell Schlussfolgerungen zieht, kann das unerwünschte Verhaltensweisen fördern und das Projekt zusätzlich verzögern.

Beispielsweise ist die Person, die ein Ticket bearbeitet, möglicherweise nicht dieselbe, die es abgeschätzt hat, oder sie trägt aus anderen Gründen keine persönliche Verantwortung für etwaige Abweichungen zwischen der Schätzung und der tatsächlich aufgewendeten Zeit. Nehmen wir ein Szenario, in dem der erfahrenste Entwickler besonders anspruchsvolle Tickets übernimmt, die von Natur aus schwer genau zu schätzen sind. Aufgrund der zahlreichen Unbekannten kann die tatsächlich aufgewendete Zeit erheblich von der Schätzung abweichen. Hier ist es fraglich, ob man den Entwickler deshalb unter Druck setzen sollte:

Schätzungen sind von Natur aus schwierig, und bei einzelnen Tickets können die Abweichungen auch mit ausgefeilten Schätzmethoden erheblich sein. Einige Studien zeigen, dass auch die Größe des relativen Fehlers häufig trotz Expertenwissen groß ist (iaeng.org).

Der starke Druck, genaue Schätzungen (oder ähnliche Kennzahlen) einzuhalten, kann nach hinten losgehen. Entwickler könnten schwierige Aufgaben vermeiden, Schätzungen konservativ auslegen oder sogar absichtlich langsamer arbeiten, wenn sie „zu früh“ fertig sind, um die Schätzung einzuhalten. Das Ergebnis untergräbt die Produktivität und fördert ein Verhalten, das Kennzahlen schützt, statt einen Mehrwert zu schaffen und dem Projekt zu helfen.

Statt jedes Ticket und jeden Entwickler einzeln zu betrachten, kann man (wie im zweiten Teil des Artikels gezeigt) sich die mittlere Abweichung der Abschätzungen aller Tickets in einem Meilenstein ansehen. So muss man nur dann eingreifen, wenn der Abschätzfehler im Mittel zu groß wird.

Stärken und Schwächen klassischer Projekt-Tools

Grundlegendes JIRA

Verwendet man z. B. JIRA (ohne Plug-ins), ist die relevanteste integrierte Funktion, um einen Release-Termin vorherzusagen, der Versionsbericht, der einen zeitlichen Überblick über die folgenden Größen bietet (Bild 1):

• Geplante geschätzte Arbeit (grau).

• Erledigte Arbeit (blau).

• Anzahl nicht geschätzter Posten (rot).

• Ein voraussichtlicher Fertigstellungstermin, basierend auf der bisherigen durchschnittlichen Fertigstellungsrate, mit einer Unsicherheitsspanne (blaue Gerade).

So funktioniert es: JIRA nimmt den bisher erledigten Arbeitsaufwand (der blaue Bereich) und extrapoliert ihn linear, bis er den geplanten Gesamtarbeitsaufwand (der graue Bereich, der von der blauen Linie geschnitten wird) erreicht. Auf dieser Grundlage wird anhand des verbleibenden Arbeitsaufwands und der durchschnittlichen Geschwindigkeit seit Projektbeginn ein Fertigstellungstermin prognostiziert.

Das ist ein großer Fortschritt gegenüber einer Folie mit Projektampel, die auf Bauchgefühl basiert. Man könnte sogar einen Ampelstatus daraus ableiten:

• Grün: Das berechnete Datum liegt deutlich vor dem Zieltermin (mit einer Sicherheitsmarge).

• Gelb: Das berechnete Datum liegt innerhalb der Marge.

• Rot: Das berechnete Datum liegt nach dem geplanten Veröffentlichungsdatum.

Bei der praktischen Anwendung dieses Diagramms treten jedoch immer wieder dieselben Probleme auf:

Das Diagramm ist zu konservativ:

• Die frühen Projektphasen verlaufen langsam. Die Einarbeitung des Teams, die Klärung der Anforderungen und erste grobe Schätzungen führen dazu, dass die anfängliche Geschwindigkeit niedrig erscheint.

• Nur abgeschlossene Aufgaben zählen als „erledigt“. Große, fast abgeschlossene Aufgaben erscheinen erst, wenn das Ticket geschlossen wird, was sich oft aus formalen Gründen nach hinten schiebt, obwohl die eigentliche Arbeit größtenteils fertig ist.

Das Diagramm ist zu optimistisch:

• Nicht abgeschätzte Tätigkeiten (rot) haben keinen Einfluss auf die Prognose.

• Geplante Abwesenheiten/Urlaube werden ignoriert (aber hoffentlich wenigstens in die Durchschnittsgeschwindigkeit einbezogen).

Das Diagramm basiert auf unrealistischen und unklaren Annahmen:

• Die Qualität der Schätzungen wird ignoriert (entsprach die für erledigte Aufgaben aufgewendete Zeit in etwa den ursprünglichen Schätzungen?).

• Die Puffer sind unklar: pauschaler Prozentsatz? Separate Pufferaufgaben? In den Schätzungen der Aufgaben enthalten? Keine?

• Es wird ein konstant verfügbares, stabiles Team über die ganze Dauer angenommen. Das kommt in der Realität selten vor, da Spezialisten ihre Zeit oft auf mehrere Projekte aufteilen.

Es ist klar, dass JIRA in erster Linie für Scrum-/Agile-Workflows konzipiert ist und nicht für die Umsetzung eines Projekts mit festem Umfang und fester Frist. Daher sollten seine Schwächen in diesem Bereich nicht überraschen. Trotzdem wird es von vielen Firmen so auch für längere Projekte eingesetzt.

Moderne Projektmanagement-Software

Es gibt viele Tools für die detaillierte Projektplanung: BigPicture, Advanced Roadmaps (ehemals Portfolio for Jira) und verschiedene eigenständige Suiten wie MS Project. Mit ihnen lassen sich alle Aufgaben einer bestimmten Person zuweisen, mit bestimmten Terminen und einer bestimmten Zeitspanne.

Der Haken dabei ist, dass die einzugebenden und zu pflegenden Daten schnell anwachsen und ihre Aktualität verlieren. Am Ende müssen Teams, Kalender, Feiertage, Abhängigkeiten und genaue Zeitfenster modelliert werden: Wer arbeitet wann und wie lange an was? Mit diesem Detailgrad (Bild 2) können Feiertage einbezogen, Zeitpläne optimiert, Fertigstellungstermine prognostiziert und Überlastungen in Projekten erkannt werden.

Die Realität folgt leider selten unseren Plänen. Schätzungen sind ungenau. Wenn jemand früher oder später fertig wird, muss der gesamte Zeitplan neu angepasst werden, es sei denn, man akzeptiert Leerlaufzeiten. Schnell wird klar, dass ein Mikroplan wie „Tom beginnt am Dienstag um 14 Uhr mit Aufgabe X und beendet sie am Donnerstag um 12 Uhr“ fast nie korrekt ist und in der Praxis nicht durchgesetzt werden kann. Alle Entwickler „lieben“ es, darüber zu diskutieren, warum die Aufgabe jetzt doch schneller fertig war oder länger gebraucht hat – und eine ständige Pflege erfordert.

Verloren in den Details

Solche Pläne sind häufig überpräzise (wehe, wenn Tom einen halben Tag länger benötigt), aber zu ungenau, um daraus gute Projektionen zu erhalten. Die Verwaltungskosten können den Nutzen deutlich überwiegen. Außerdem setzen sie ein Maß an Kontrolle voraus, über das man oft nicht verfügt. Es gibt Bereiche, in denen sich diese Detailgenauigkeit auszahlt, insbesondere bei physischen Projekten mit strengen Abfolge- und Standortvorgaben (man kann keine Fliesen verlegen, bevor der Unterboden verlegt und ausgehärtet ist, und der Fliesenleger hat während der Wartezeit möglicherweise keine andere Aufgabe, die er schnell übernehmen kann). Bei Software sind die Abhängigkeiten oft weniger streng und die Arbeiten besser austauschbar.

Bei den meisten Softwareprojekten ist es weniger wichtig, wer eine bestimmte Aufgabe an einem bestimmten Tag erledigt, sondern vielmehr, dass jemand mit den richtigen Fähigkeiten vor Ablauf der Frist und innerhalb der möglichen Puffer verfügbar ist. Die wenigen harten Abhängigkeiten auf dem entscheidenden Pfad sollten zwar überwacht werden, aber in den meisten Fällen können die Mitarbeiter zu anderen nützlichen Aufgaben wechseln, wenn eine Aufgabe blockiert ist. In der Regel reicht es aus, eng miteinander verbundene Aufgaben nicht im selben Sprint zu platzieren, um Wartezeiten zu vermeiden. Wichtiger als das Mikromanagement der Aufgabenreihenfolge innerhalb eines Sprints oder Meilensteins ist es, frühzeitig integrationsfähige Artefakte zu liefern – mit einem Puffer vor der endgültigen Integration.

Wenn das Team so hoch spezialisiert ist, dass die einzelnen Mitglieder nur eine Art von Aufgabe pro Sprint bewältigen können, sollten die Engpässe bei den Kapazitäten durch Cross-Training, Pairing oder Personalaufstockung behoben werden, anstatt durch Mikromanagement und unrealistisch überpräzise Pläne.

Die richtige Balance finden

Ideal wäre ein Mittelweg zwischen dem Jira-Versionsbericht und umfangreichen Projektmanagement-Suiten. Im zweiten Teil des Artikels werden wir zeigen, dass durch Hinzufügen einer kleinen Menge strukturierter Daten zu z. B. Jira (wer arbeitet im Mittel wie viele Stunden pro Woche an welchem Meilenstein mit) eine ausreichend gute Vorhersagegenauigkeit erzielt werden kann, ohne jede Aufgabe einer bestimmten Person und einem bestimmten Zeitfenster zuordnen zu müssen. Um diesen Ansatz zu validieren, gilt es zunächst zu klären, welche Fragen mit diesen Daten konkret beantwortet werden sollen.

Requirements

Änderungsbasiertes Anforderungsmanagement

Agile Entwicklung

Scrum für Embedded Systeme

Wann ist ein Projekt im Zeitplan?

Aus Sicht der Entwicklung und des Projektmanagements konzentrieren wir uns auf folgende Schlüsselfragen:

• 1. Wer sollte an welchem Meilenstein arbeiten und mit welchem Anteil seiner Zeit, damit das Release-Datum eingehalten werden kann? Dies wird sich im Laufe der Zeit ändern, verschiedene Meilensteine erfordern möglicherweise unterschiedliche Personen, und Feiertage oder andere Abwesenheiten müssen berücksichtigt werden.

• 2. Sind die Fehler der Schätzungen von Aufgaben im Rahmen der gegebenen Zeitpuffer? Mit anderen Worten: Sind die Schätzungen zumindest im Durchschnitt ausreichend genau?

• 3. Arbeiten die Mitarbeiter tatsächlich wie geplant an den zugewiesenen Projekten? Oder sind sie noch mit der Fertigstellung eines anderen Projekts beschäftigt, stecken in einer alten Aufgabe fest oder werden an anderer Stelle zur Hilfe herangezogen?

• 4. Ist die Gesamtzuteilung der Mitarbeiter realistisch? Wenn Tom beispielsweise 70 % seiner Zeit für Projekt A und 70 % für Projekt B eingeplant ist und beide Projekte parallel laufen, dann wird mindestens eines der Projekte nicht rechtzeitig fertig werden.

• 5. Wie viel Arbeit bleibt insgesamt noch zu erledigen? Und wie passt das zur verbleibenden Zeit bis zum Release? Dazu gehört zumindest eine grobe Berücksichtigung für nicht abgeschätzte Aufgaben. Basierend auf den aktuellen Daten: Wann ist der voraussichtliche Veröffentlichungstermin? Ist der Status grün, gelb oder rot? Idealerweise sollte es Prognosen unter verschiedenen Annahmen geben (mehr dazu später).

Der abschließende Teil 2 dieses Artikels zeigt, wie diese Informationen auf dem neuesten Stand gehalten und für kontinuierliche Prognosen und Monitoring genutzt werden können. Mit sehr geringem Aufwand kann das gesamte Projekt im Ticketsystem modelliert und alle nötigen Berichte daraus generiert werden.  (sg)

* Dr. Alexander Herz ist Senior Engineering Manager bei TASKING.

(ID:50822924)