Wie Sie einen iterativen Sprint in Ihrer Zeitplanliste darstellen

In einem agilen Ansatz können wir Tools wie Kanban verwenden, um Sprints zu planen, zu messen und zu überwachen. Aber wenn wir Zeitplansysteme wie MS Project oder ein anderes Online-Collaboration-Tool verwenden müssen, das wie MS Project funktioniert, um unseren Kunden Berichte oder Gantt-Diagramme zu zeigen (weil einige von ihnen bereits so funktionieren), wie stellt man dann einen rekursiven agilen Sprint dar Ausführung innerhalb Ihres klassischen Fahrplansystems?

In traditioneller PN:

  1. Sie erstellen Ihren PSP.
  2. Sie gelangen auf die Arbeitspaketebene.
  3. Sie definieren Ihre Aufgaben für dieses Arbeitspaket in Ihrem Zeitplansystem.
  4. Sie legen eine Grundlinie fest.
  5. Sie aktualisieren den Fortschritt.

Stellen Sie sich vor, Sie wechseln immer noch von klassisch zu agil und müssen ein klassisches Zeitplanmanagement aufbauen. Normalerweise können Sie keine Aktivitäten hinzufügen, die nicht auf Ihr Arbeitspaket ausgerichtet sind und Ihre dreifache Einschränkung überschreiten.

Fügen Sie normalerweise Aufgabenblöcke mit Feature 1 Version 1 und später Feature 1 Version 2 innerhalb derselben Leistung hinzu und so weiter? Wie können Sie wissen, wie viele Iterationen im Voraus für dieselbe Funktion ausgeführt werden können?

Sie sollten dies wahrscheinlich aufteilen, insbesondere die zweite Frage (die Sie hervorgehoben haben) unterscheidet sich stark von den beiden anderen, da sie stärker auf das Tool ausgerichtet ist.
Das ist auf vielen Ebenen falsch :-( Der Grund, warum Menschen Agilität annehmen, ist, dass sie Änderungen (Iteration) akzeptiert, Wasserfall nicht.

Antworten (1)

Wenn ich ein Projektmanagementsystem wie MS Project verwenden müsste, um ein agiles Projekt zu verwalten, dann würde ich einfach jede Iteration als Arbeitspaket darstellen und bei Bedarf jeder Iteration die Analyse-, Design-, Entwicklungs-, Test- und Freigabeaufgaben hinzufügen.

Aber ich würde all dies mit zusammengebissenen Zähnen und geballten Fäusten tun, weil die Verwendung eines traditionellen Planungstools zur Verwaltung eines agilen Projekts das falsche Tool für den falschen Job ist.

Ich hätte Bedenken, dass derjenige, der nach einem klassischen Zeitplan fragt, die agile Schätzung und Planung nicht versteht.