Berücksichtigung des Scope-Wachstums in der agilen Entwicklung

Messen Sie die Arbeit. Wie Sie sagen, arbeiten Sie an vielen verschiedenen Projekten. Wenn Sie bedenken, dass Sie relevante Daten zu vergangenen Projekten sammeln, sollten Sie in der Lage sein, einige Muster zu erkennen, z. B. scheinen die meisten Projekte auf diese Weise zu funktionieren, aber es gibt nicht standardmäßige Fälle, die von der einen oder anderen Sache angetrieben wurden.

Es ist schwer zu beantworten, was zu Schwankungen in Ihrer Arbeit führt, aber Sie werden wahrscheinlich in der Lage sein, die Grundursachen leicht zu finden.

Eine andere Idee, die Ihnen gefallen könnte, ist die Dimensionierung nicht in Bezug auf die Schätzung, wie viel Zeit Sie benötigen, um ein Projekt zu erstellen, sondern wie viele Funktionen / Geschichten / was Sie brauchen, um das Ding zu bauen . In der Lage zu sein, zu schätzen, dass ein neues Projekt ungefähr 40 Features umfasst, kann Ihnen sehr viel sagen, solange Sie wissen, wie lange es dauert, ein durchschnittliches Feature (End-to-End) zu erstellen, und wie viele Features Sie gleichzeitig in Arbeit haben. Ein Beispiel für einen solchen Ansatz finden Sie hier .

Auch hier läuft es darauf hinaus, Ihre Arbeit zu messen. Ein weiterer wichtiger Aspekt hier ist das Verständnis der Variabilität. Ich meine, wenn die Zeit, die zum Erstellen eines Arbeitselements benötigt wird, sehr unterschiedlich ist, z. B. zwischen 2 und 50 Tagen, sagt Ihnen der Durchschnitt oder Median nicht viel, es sei denn, Sie haben eine wirklich große Stichprobe vergangener Datensätze .

Und schließlich, wenn Sie in der Lage sind, mit Ihren Kunden auf Zeit- und Materialbasis zusammenzuarbeiten , bekommen Sie das Problem einfach vom Tisch. In einer solchen Situation kaufen sie nur Ihre Zeit (zusammen mit Ihren Fähigkeiten) und es ist nicht direkt Ihr Risiko, wenn etwas Neues auftaucht.

Lesen Sie mehr über Cone of Uncertainty – je länger Sie mit dem Projekt arbeiten, desto genauer und präziser ist Ihre Schätzung seiner Dauer und Größe (Bild von der Website Construx.com ):

PMBOK schlägt vor, das Projekt jedes Mal neu zu bewerten, wenn Sie mehr Informationen über seinen Umfang haben. Sie beginnen ein Projekt mit einer ROM-Schätzung ( grobe Größenordnung ) und verfeinern es bei jedem Meilenstein. Ich würde auch vorschlagen, Steve McConnels "Software Estimation: Demistifying the Black Art" zu lesen - es gibt eine gute Zusammenfassung bestehender Schätztechniken.

Pawel spricht über das Messen Ihrer Arbeit. Das ist entscheidend und entscheidend. Ein Grund dafür ist, dass der Rückblick Ihnen helfen kann, nach vorne zu schauen.

Es gibt einen Begriff, der oft in agilen Prozessen verwendet wird und „Wetter von gestern“ heißt. Das Konzept ist, dass das Wetter heute wahrscheinlich dem Wetter von gestern sehr ähnlich war und dem Wetter von morgen sehr ähnlich sein wird (wenn Sie jemals nach Los Angeles, Kalifornien, USA, gereist sind, ist dies beängstigend wahr). Normalerweise wird diese Maxime verwendet, wenn die potenzielle Geschwindigkeit eines agilen Teams bestimmt wird. Wenn Sie bei der letzten Iteration 30 Punkte gemacht haben, dann werden Sie wahrscheinlich ungefähr 30 Punkte in dieser Iteration machen, also überbuchen Sie nicht.

Das Konzept kann darüber hinausgehen. Wenn Sie Ihre Projekte verfolgen, können Sie im Laufe mehrerer Projekte sehen, was für Sie die Norm ist. Sie sehen, keine Formeln werden das Problem lösen. Menschen sind keine mathematischen Formeln. Wir können also nicht einfach in universelle Formeln gesteckt werden. Was wir jedoch tun können, ist unsere eigene Geschichte zu betrachten. Nachdem Sie mehrere Projekte durchgeführt haben, werden Sie wahrscheinlich feststellen, dass es einige Normen gibt, die Sie sich ansehen können, um festzustellen, wie viele Änderungen Sie vom Projektbeginn bis zum Start haben.

Verwenden Sie Ihre eigenen Metriken, um Ihr eigenes Potenzial zu ermitteln.

Agile vermeidet im Allgemeinen die Schwierigkeiten zu wissen, wann ein großer Teil der Arbeit erledigt sein wird, indem man sich nicht dazu verpflichtet, sie zu erledigen.

Wenn Sie ein sechsmonatiges Stück Arbeit haben (basierend auf einer Schätzung des Fingers in der Luft), wählen Sie einen kleinen Teil aus, der Ihnen einen Mehrwert bringt, indem Sie ihn zuerst erledigen. Es ist im Allgemeinen einfacher, die Zeit für eine kleine Sache in den Griff zu bekommen als für eine große Sache, und eine frühe Veröffentlichung ermöglicht es Ihnen, schnell Feedback von Kunden zu erhalten.

Die Chancen stehen gut, dass Sie, sobald Sie ein oder zwei dieser kleinen Teile erstellt haben, ein gutes Feedback erhalten, das den Rest der Arbeit leiten wird. Liefern Sie nicht hartnäckig das ab, was Sie zu Beginn für Ihren Umfang hielten, sondern priorisieren Sie das Feedback ständig neu gegenüber dem Rest Ihres potenziellen Umfangs.

Wir ändern irgendwie die übliche Frage "Wann werden wir in der Lage sein, bis fertig zu werden?" mit "Was ist das Kleinste, was wir tun können, um einen Mehrwert zu schaffen?".

Vorausgesetzt, Sie wägen immer den Wert aller möglichen Arbeiten, die Sie beginnen könnten, gegeneinander ab und stellen sicher, dass Sie keine zu großen Dinge beginnen, ist es eigentlich nicht so wichtig, eine längerfristige Schätzung „richtig“ zu machen, das ist es normalerweise ohnehin eine Illusion.

Einige weitere Gedanken auf einem ähnlichen Weg finden Sie hier: http://decision-coach.com/lean-and-real-options/

Wenn Sie die tatsächlichen Kosten der Projekte (in Zeit) gegenüber der anfänglichen Schätzung (in Zeit oder in Punkten) bis zur Fertigstellung/Freigabe (~= 1 / durchschnittliche Geschwindigkeit des Produktrückstands) über einige Projekte desselben Teams messen, sollten Sie feststellen, dass dies der Fall ist 't variieren viel zwischen Projekt und Projekt. Anhand dieses Faktors können Sie eine grobe Schätzung der tatsächlichen Zeit im Vergleich zur anfänglich geschätzten Zeit für zukünftige Projekte mit demselben Team erhalten.

Die tatsächliche Zeit umfasst hinzugefügte, gelöschte und geänderte User Storys.

Da das Team die Schätzungen gibt und die Arbeit erledigt, ist es wichtig, die Geschwindigkeiten nicht zwischen den Teams zu mischen. Wenn Sie die Änderungsanfrage von Kunden erhalten, versuchen Sie, mit Projekten desselben Kunden zu vergleichen, da die Wahl des Kunden die Messungen beeinflusst (Sie können sich vorstellen, dass der Kunde Teil des erweiterten Teams ist).
Wenn Sie im Laufe der Zeit zwischen Projekten eine Verbesserung sehen (z. B. weil sich das Team daran gewöhnt hat, effizienter zusammenzuarbeiten (oder zusammen mit dem Kunden), dann geben Sie den neueren Projekten mehr Gewicht.

Nehmen Sie für eine sicherere Schätzung die minimalen und maximalen Faktoren (aus früheren Projekten) und verwenden Sie sie, um einen Unsicherheitskegel zu zeichnen.