Wie bestimmt man das Fertigstellungsdatum des Projekts?

Als Projektleiter habe ich schon einige Tech-Projekte mit immer wieder neu zusammengestellten Teams bearbeitet. Das Team besteht normalerweise aus 2-3 Teammitgliedern, die die eigentliche Arbeit erledigen. Es ist schwierig, die Geschwindigkeit zu bestimmen. Wir sind nicht wirklich agil und sprinten auch nicht.

In der Regel beenden wir die Arbeiten vorzeitig oder am Ende des Quartals. Diese Ressourcen werden für die Arbeit eingesetzt, aber während der Woche wahrscheinlich zu 70-80 % ausgelastet. Der Rest der Zeit dient der Unterstützung geschäftlicher Anforderungen.

Ich habe wieder eine andere Gruppe von Projekten mit anderen Mitgliedern im Team. Wie kann ich ungefähr bestimmen, wann das Projekt abgeschlossen sein wird? Meine 2 Entwickler haben ihre Schätzungen für alle ihre Tickets niedergelegt.

Wenn Sie „nicht wirklich agil sind“ und kein Scrum verwenden, was tun Sie dann? Die Methoden, mit denen Sie den Abschluss einer Arbeit schätzen können, hängen davon ab, wie Sie diese Arbeit planen und ausführen.
Danke, ich wollte wissen, ob es bessere Ansätze gibt, um aus diesem Muster herauszukommen, mit dem meine Teams konfrontiert sind. Mgmt könnte es vorschlagen, hat sich aber zurückgehalten, da sie die Gewinne so schnell wie möglich steigern wollen. Die Mentalität des Teams hat es geschafft, Dinge zu erledigen. Ich denke, es ist schwierig, ein ungefähres Fertigstellungsdatum zu bestimmen, da wir nicht häufig veröffentlichen. Eher projektbezogen und das passiert alle 2-3 Monate.
Bei Agile legen wir oft den Zeitplan fest und variieren den Umfang. Wenn die anfängliche Arbeit einen Mehrwert hat, wird die Folgearbeit besprochen. Es ist eine andere Sichtweise auf die Situation. Manchmal gibt es Widerstand gegen die Variation des Umfangs durch einen Stakeholder, obwohl der Umfang immer variiert, da ohnehin mehr über das Projekt bekannt ist. Genauso wie es manchmal Widerstand gibt, Prioritäten zu setzen, obwohl das nur bedeutet, dass der Entwickler die Prioritäten setzt.

Antworten (3)

Wie oft wirst du Releases machen? Eine Sache, die Sie versuchen könnten, ist, Tickets in vorläufige Veröffentlichungen (oder Iterationen) zu gruppieren, Ihre Schätzungen in Punkte umzuwandeln und dann eine Veröffentlichungsgeschwindigkeit / Iterationsgeschwindigkeit zu schätzen.

Priorisierung und Minimierung von Abhängigkeiten sind ebenfalls wichtig, insbesondere wenn Ihr Team nicht Vollzeit arbeitet. Sie haben Ihre Frage als Scrum markiert. Wenn Sie sich in Richtung Scrum bewegen möchten, beginnen Sie mit den Product Ownern, teilen Sie ein Backlog mit ihnen und definieren Sie einige Prioritäten. Es ist ein Fehler, sich auf das „Projektabschlussdatum“ zu konzentrieren, da alle wichtigen Dinge im Allgemeinen früh im Arbeitsprogramm passieren sollten, niemals am Ende.

Wir veröffentlichen etwa alle 2 bis 3 Monate. Ja, viele Leute sind auf ein Projektabschlussdatum fixiert. Sie haben mir gesagt, ich solle vom Team einen Kostenvoranschlag einholen und das ungefähre Datum bestimmen. Ist das überhaupt möglich? Mein Team (Größe 2) glaubt, dass die Fertigstellung 20 Tage dauert. Wenn man alle Aufgaben zusammenzählt, kommt man auf 30 Tage. Der Ort hier hat den Stil verfolgt, Dinge zu erledigen. Ich hätte gerne Agile/Scrum, aber es wird eine Weile dauern, bis ich dort ankomme.
@ user2763930 , 30 Tage bis zur "Fertigstellung", aber dann müssen Sie möglicherweise bis zu zwei Monate warten, bevor Sie es veröffentlichen? Das klingt nicht sehr realistisch, aber wenn Sie recht haben, dann wird Ihnen die Einschätzung sehr leicht gemacht. Ihre Schätzung muss nur auf die nächsten 2 oder 3 Monate genau sein, denn dann wird sie veröffentlicht. 20 - 30 Tage scheinen also als Schätzung nahe genug zu sein.
Ja, das Team gibt mir überraschenderweise eine ziemlich genaue/genaue Zahl, wann die Arbeit abgeschlossen ist. Ich würde jedoch gerne häufiger veröffentlichen oder pushen, um zu prodieren. Mgmt hätte lieber weniger Veröffentlichungen mit mehr Dingen zusammen. Ich habe befürwortet, dass dieser Prozess weniger Wert liefert und alle Funktionen einen Stau aufbauen, um wartenden Kunden zu liefern. Haben Sie jemals mit dieser Art von Schätzungs-/Prognosestil an Projekten gearbeitet? -In der Vergangenheit habe ich mit Teams gearbeitet, die agil sind und konstant alle 2 Wochen liefern. Jetzt bin ich mit dieser unterschiedlichen Teamkultur konfrontiert. Gedanke/Ansicht?

Es hängt wirklich von der Art des Rückstands/der verbleibenden Arbeit und der von Ihnen verwendeten Methodik ab, die bei Ihrer Frage nicht klar ist.

Wenn Sie SCRUM verwenden, müssen Sie 2 Dinge wissen.

  1. Geschätzter Story Point (Story Point /= Story Point Schätzung) gesamter Rückstand
  2. Teamgeschwindigkeit gegebenes Team ist performant und die Teamzusammensetzung ändert sich nicht.

(Geschätzter Rückstand / Teamgeschwindigkeit) * Dauer der Sprints + Puffer – Geplante Ereignisse/Blätter sollten Ihnen eine ungefähre Zahl geben. Denken Sie daran, dass Zeitpläne in Agile fundierte Vermutungen und keine tatsächlichen Werte sind.

Wenn es ein Wasserfall ist, müssen Sie wieder 2 Dinge haben.

  1. Geschätzte verbleibende Arbeit
  2. Ressourcenzuweisungen.

Basierend auf Ressourcenzuweisungen und deren Kapazität müssen Sie die Fristen berechnen, die in den meisten Fällen fest sind.

Wenn die Methodik so etwas wie XP ist, müssen Sie Release-Planungen und die Anzahl der Iterationen in die Berechnung einbeziehen.

Danke. Mein Team (Größe 2) glaubt, dass die Fertigstellung 20 Tage dauert. Wenn man alle Aufgaben zusammenzählt, kommt man auf 30 Tage. Zuerst dachte ich, dass die Erstellung eines 2-3-wöchigen Sprints meinen 2 Ressourcen helfen würde. Wir geben die Produktion nicht frei, nachdem ein Sprint abgeschlossen ist. Wir veröffentlichen, wenn das gesamte Projekt abgeschlossen ist, was normalerweise innerhalb von 2-3 Monaten geschieht. Das Team hat erst vor kurzem angefangen, wird aber auch für Verschiedenes hinzugezogen. arbeiten. Bisher habe ich die verbleibende Gesamtzahl der Tage überwacht, um an allen Aufgaben zu arbeiten, das Fertigstellungsdatum zu bestimmen und 2-3 Wochen Pufferzeit hinzuzufügen.

Dies ist schwer zu empfehlen, ohne mehr über das grundlegende Lebenszyklusmodell, das Entwicklungsparadigma und die Methoden rund um die Schätzung zu wissen. Aber Sie sagen "wir sind nicht wirklich agil", daher sollte so etwas wie ein CBS/WBS das Rückgrat der Planung sein.

  • Erstellen Sie eine Liste der Produktelemente / Module.
  • Schätzen Sie den Aufwand, um jeden in einen freigabefähigen Zustand zu bringen. Geben Sie vorzugsweise 3-Punkt-Schätzungen ein (siehe auch) und berechnen Sie die Summen entsprechend.
  • Vergleichen Sie diese Schätzungen mit dem, was Ihre Ressourcen Ihrer Meinung nach leisten können.
  • Berücksichtigen Sie eine Zugabe für Systemkleber. Wenn Sie möchten, stellen Sie dies als zusätzliches Modul dar.