Ist die Entscheidung über das Veröffentlichungsdatum vor dem Sammeln aller Anforderungen nicht flexibel?

Ich habe gerade angefangen, das Buch Applying UML and Patterns von Craig Larman zu lesen. Ich finde es sehr interessant, weil es viele meiner Herausforderungen bei der Arbeit in Frage stellt. Ich habe gelesen, dass Anforderungen nicht auf einmal in Agile vollständig erfasst werden und es viele Iterationen erfordert, um die Anforderungserfassung abzuschließen. Wenn dies der Fall ist, ist es dann sehr unagil, eine festgelegte Frist festzulegen, zu der ich bei der Arbeit gezwungen bin, wenn man bedenkt, dass es morgen eine neue bahnbrechende Anforderung geben könnte (oder eine Änderungsanforderung, die sich als Anforderung tarnt)?

Es gibt absolut kein "agiles" Problem mit einem festen Veröffentlichungsdatum, wenn Sie bereit sind, eine der beiden anderen Kanten des "Eisendreiecks" zu verschieben: die Anforderungen an das, was in dieser Version enthalten sein muss, oder die verfügbaren Ressourcen . Sie können nicht alle drei Probleme beheben - und in der Praxis ist die "Ressourcen" -Seite des Dreiecks sehr oft entweder nicht sehr flexibel oder ineffizient zu ändern.

Wenn es morgen eine wichtige neue Anforderung gibt, ist dies in Ordnung, solange das Unternehmen bereit ist, diese Anforderung zu akzeptieren und möglicherweise nicht das Veröffentlichungsdatum erreicht - dh es wird auf die nächste Version verschoben.

Ich denke, das Problem in vielen agilen Lagern liegt in der Wortfrist. Das Risiko einer Frist besteht darin, dass Sie davon ausgehen, dass Sie wissen, was zu tun ist. Wie Sie betonen, können Sie keine Frist für ein Unbekanntes haben.

Was in Philipps Antwort beschrieben wird, ist weit weniger eine Frist als eine Einschränkung. Wir könnten sagen, dass wir bis März Finanzmittel haben und daher das bestmögliche Produkt in dieser Zeit herstellen müssen.

Um eine Analogie zu geben, nehmen wir an, ich bitte Sie, zur Lebensmittelgeschichte zu gehen und alle Lebensmittel für die Woche zu kaufen. Bevor Sie sich die Preise ansehen, möchte ich, dass Sie mir genau sagen, was Sie ausgeben werden. Außerdem werden Sie bestraft, wenn Sie sich irren. Sie werden genau das tun, was die Leute mit Projektfristen tun - Sie werden eine Zahl am oberen Ende des Bereichs auswählen, von dem Sie glauben, dass er liegt, weil er die geringste Wahrscheinlichkeit hat, dass Sie bestraft werden. Nehmen wir jetzt an, ich sage Ihnen, dass dies inakzeptabel ist und Sie müssen die gleichen Dinge kaufen, die Sie geplant haben, aber Sie müssen es für 50 Dollar billiger machen, oder sonst. Was können Sie jetzt tun? Sie können ablehnen, Sie können das Argument einfach verschieben, bis Sie einkaufen, oder Sie können einen Weg finden, die Situation zu betrügen. Dies geschieht in vielen Organisationen mit Fristen für Unbekannte.

Nun, da Agile sieht, wie ungesund diese ganze Situation ist, sagt er nur: "Wenn Sie ein Budget haben, kann ich Ihnen versprechen, darunter zu kommen, und werde Ihnen in dieser Einschränkung die bestmöglichen Mahlzeiten für diese Woche geben." Welches ist ein weitaus gesünderes Gespräch zu führen.

Agilität ist eine Technik, kein Ergebnis. Im Vergleich zum Rasenmähen entspricht eine Iteration einer Graslinie, die Sie gemäht haben. Wenn jemand sagt "Mähen Sie Ihren gesamten Rasen in 15 Minuten" und Sie agil verwenden, werden Sie am Ende vielleicht 30% fertigstellen. Dann werden Sie später noch etwas wiederholen und es beenden.

Sie können problemlos einen geplanten Veröffentlichungstermin festlegen. Stellen Sie einfach sicher, dass Sie zu diesem bestimmten Zeitpunkt keine Verluste haben. Sie sollten ein Produkt haben, das am Ende jedes Sprints versendet werden kann, aber normalerweise wird kein Schaden angerichtet, wenn Sie dies nicht tun. Es ist eher ein Ziel, das die Arbeit fokussiert, als eine Anforderung. Wenn Sie ein geplantes Veröffentlichungsdatum haben, müssen Sie zu diesem Datum ein freigebbares Produkt haben.

Normalerweise streben Sie ein ungetestetes, aber hoffentlich freisetzbares Produkt einige Zeit vor dem geplanten Veröffentlichungsdatum an. Anschließend wird das Produkt getestet und Fehler behoben, bis die Qualitätsstandards erfüllt sind. Anschließend wird es ohne Panik veröffentlicht. Die Veröffentlichung enthält alles, was zu diesem Zeitpunkt fertig war.

Jetzt ist es für Ihren Chef möglicherweise nicht offensichtlich, dass Sie auch einen zweiten Veröffentlichungstermin planen sollten, wobei tatsächlich mehr Funktionen implementiert sind.