Wie können wir Fristen * setzen *, damit wir effektiv und agil daran arbeiten können?[geschlossen]

Question

Geschlossen. Diese Frage ist off-Thema.Es akzeptiert derzeit keine Antworten.

---

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage also ist es zum Thema für Stapelüberlauf.

Geschlossen vor 2 Jahren.

Ich arbeite in einem Team, das konsequent und ziemlich erfolgreich in einem agilen Ansatz gearbeitet hat, und das hat für das aktuelle Projekt bis jetzt großartig funktioniert, für unsere anfängliche Arbeit, während wir das Produkt schrittweise aufbauen.

Wir gehen jetzt jedoch in die nächste Phase, und das Management ist daran interessiert, dass wir uns selbst bestimmte Fristen setzen, bis wann wir in der Lage sein werden, dies in der Größenordnung von Monaten zu demonstrieren und an echte Kunden zu verkaufen.

Wir haben einen ziemlich gut organisierten großen Rückstand für jedes der Funktionselemente, die wir einbeziehen möchten, und ein gutes Gespür für die Priorisierung dieser einzelnen Funktionsbits.

Die naive Lösung besteht darin, die Mindestliste von Geschichten zu erhalten, die ein Demo-fähiges Produkt liefern, alle einzeln zu schätzen, sie zu addieren und mit unserer Geschwindigkeit zu kombinieren, um ein Datum zu erhalten, und anzukündigen, dass wir ab dann demonstrieren werden.Das lässt jedoch keinen Spielraum und scheint wahrscheinlich zu einem verrückten Knirschen zu führen, wenn wir die Frist einhalten, was ich unbedingt vermeiden möchte.

Als Verbesserung möchte ich ein Verhältnis von optionaleren Geschichten hinzufügen, die je nach Fortschritt entweder als Kontingenz- oder Bonusverbesserungen fungieren, aber wir haben keine Ahnung, welches Verhältnis sinnvoll wäre oder ob dies der Standardansatz ist.

Ich bin auch besorgt darüber, dass wir unseren gesamten Auftragsbestand im Voraus auf einmal schätzen müssen, da dies sehr zeitaufwändig erscheint und es wahrscheinlich ist, dass wir in den Monaten vor dieser Geschichte weitere Informationen entdecken werden, die sich auf unsere Schätzungen auswirken werden.

Gibt es empfohlene Ansätze für den Umgang mit der Festlegung von Fristen, um einen agilen Entwicklungsprozess zu ermöglichen?Die meisten Informationen, die ich gesehen habe, scheinen sich darauf zu beziehen, mit der Situation umzugehen, sobald Sie stattdessen eine feste Frist einhalten müssen.Ich würde mich auch für relevante Literatur oder interessante Blogposts interessieren, die sich mit diesem Thema befassen.

Answer 1

In Bezug auf Literatur:das beste Buch, das ich über die Schätzung in Software kenne, ist "Software Estimation:Entmystifizierung der schwarzen Kunst" von Steve McConnel.Es deckt Ihren Fall ab.Außerdem beschreibt es den Unterschied zwischen Schätzung und Engagement (mit anderen Worten,Frist setzen) und erklärt, wie man die zweite zuverlässig aus der ersten ableitet.

Answer 2

Die naive Lösung besteht darin, die Mindestliste von Geschichten zu erhalten, die dies tun würden stellen Sie ein Demo-fähiges Produkt bereit, schätzen Sie alle einzeln ab und addieren Sie sie und kombinieren Sie sie mit unserer Geschwindigkeit, um ein Datum zu erhalten, und ankündigen wir werden ab dann vorführen.Das lässt jedoch keinen Spielraum und scheint wahrscheinlich zu einem verrückten Knirschen führen, wenn wir die Frist einhalten, was Ich möchte unbedingt vermeiden.

Dies ist die Lösung, die ich in der Vergangenheit verwendet habe.Ihre anfängliche Schätzung wird etwas abweichen, fügen Sie also über ein paar zusätzliche Sprints etwas Spielraum hinzu, bevor Sie Ihr Veröffentlichungsdatum festlegen.Wenn Sie zurückkommen, können Sie es im Durchhang wettmachen.Wenn nicht, bietet Ihnen Ihr Product Backlog zusätzliche Funktionen, die Sie auf Wunsch in das Release aufnehmen können.Dies hängt jedoch von Ihrer Geschwindigkeitsmetrik für das Team ab.Passen Sie Ihre Pufferzeit basierend darauf an, wie genau diese Kennzahl Ihrer Meinung nach für das aktuelle Team ist.Sobald Sie eine Zielversion haben, können Sie einen Kreis zurücklaufen, um festzustellen, ob bekannte Ressourcenbeschränkungen vorliegen, die sich auf diese Version auswirken könnten.

Answer 3

Der von Ihnen beschriebene Ansatz ist wahrscheinlich richtig.Möglicherweise möchten Sie alle wünschenswerten Funktionen abschätzen und UI-Elemente priorisieren (da Investoren und Kunden im Grunde nur die glänzende Benutzeroberfläche sehen), und dann ist Ihre Frist das geschätzte Datum für die Fertigstellung;fügen Sie dann etwas Spielraum in Form der Skalierung Ihrer Schätzungen hinzu.Verwenden Sie das Verhältnis zwischen der aktuellen Produktivität und Ihrer schlechtesten Periode, um eine pessimistische Schätzung zu erstellen.Sie können dasselbe Verhältnis verwenden, um kürzere Schätzungen zu skalieren (z.für Ihre Schätzung auf den minimalen Funktionsumfang).