Sind Fristen flexibel?


100

Aus Gründen der Klarheit ist eine Frist:

Ein Zeitlimit oder eine Frist ist ein enges Zeitfeld oder ein bestimmter Zeitpunkt, bis zu dem ein Ziel oder eine Aufgabe erreicht werden muss.

Aus Wikipedia

Während meiner gesamten Softwareentwicklungskarriere habe ich "Agile" gemacht, was anscheinend überall bedeutet, dass mindestens die folgenden Praktiken eingehalten wurden:

  • Wöchentliche oder zweiwöchentliche Sprints
  • Rückblicke Sprint-Planung
  • Ein Produktbesitzer
  • Gedränge
  • Benutzergeschichten

Jedes Projekt, an dem ich jemals teilgenommen habe, bestand jedoch darauf, eine Frist zu setzen. Angesichts der Tatsache, dass Agile versucht, sich auf adaptive Planung, Flexibilität und Veränderung zu konzentrieren; sind Fristen agil?

Ich bin der Meinung, dass dies nicht der Fall ist, da meiner Ansicht nach Fristen zu einem Mangel an Flexibilität und Qualität führen. Stattdessen halte ich es für sinnvoller, sich auf Sprints und frühzeitige Lieferungen zu konzentrieren. Es scheint jedoch, dass dies in allen Kreisen, in denen ich tätig war, nicht der Fall ist und dass die Fristen mit der agilen Entwicklung Hand in Hand gehen.


36
Ist das nicht ein Termin für den Sprint?
JeffO,

12
@JeffO a Sprint ist eine Verpflichtung, die sich je nach Geschwindigkeit Ihres Teams ändert. Fristen sind IMO, Verpflichtungen ohne Ehrlichkeit oder Transparenz gegenüber dem Kunden. Sie berücksichtigen weder die Geschwindigkeit noch die Vielzahl anderer Risiken, die bei der Erstellung von Softwareprojekten auftreten.
Stevebot

8
Ich würde sagen, dass jeder Sprint nicht verhandelbar ist. Sie bewerten die Arbeit, legen Kartengrößen darauf und laden genug, um Ihr Team bis zum Ende des Sprints zu beschäftigen (und der Sprint sollte klein sein - zwischen einer Woche und einem Monat). "Lieferfristen" sollten auf dem historischen Trend der abgeschlossenen Arbeiten gegen die erwarteten Arbeiten basieren. Agile fügt der alten Einschränkungsidee "Kosten / Zeit / Umfang" nichts hinzu bzw. entfernt sie nicht. Es verwendet lediglich den Umfang als bevorzugte Methode zum Verwalten des Schlupfes, da eine bessere Priorisierung gegenüber dem Umfang im Allgemeinen einem höheren Geld- oder Zeitaufwand vorzuziehen ist.
Calphool

8
Hier ist Ron Jeffries (einer der Originalautoren des Agile Manifests), der die Deadlines festlegt
Jules

4
Einige meiner Fristen haben sich als ziemlich wendig erwiesen.
PSR

Antworten:


147

Fristen sind Realität. Meistens muss man etwas bis zu einem bestimmten Datum haben. Das ist unvermeidlich. Ohne Fristen können auch agile Projekte dem Parkinson-Gesetz unterliegen :

Die Arbeiten werden erweitert, um die für ihre Fertigstellung zur Verfügung stehende Zeit auszufüllen.

Mit anderen Worten, wenn Ihr Projekt kann ewig so weitergehen, wird es.

In Bezug auf Fristen versucht Agile einige Dinge zu tun:

  • Stellen Sie sicher, dass jeder jederzeit sehen kann, wie viel Arbeit bis zum Stichtag erledigt wird
  • Stellen Sie sicher, dass die wichtigsten Funktionen zuerst ausgeführt werden
  • Stellen Sie sicher, dass die abgeschlossenen Funktionen in dem Sinne verwendet werden können, dass sie nicht von Funktionen abhängen, die noch nicht abgeschlossen wurden
  • Sicherstellen, dass die Entwicklung in einem nachhaltigen Tempo fortgesetzt wird

Auf diese Weise haben Sie, wenn der unvermeidliche Tag kommt, keinen nutzlosen Haufen Code, sondern ein funktionierendes, getestetes Produkt, das hoffentlich nur die unwichtigsten Dinge enthält, die noch nicht fertig sind. Und niemand ist vom fertigen Produkt überrascht.

Also ja. "Agile" und "Deadlines" können perfekt zusammenpassen.


10
@ stevebot Genau diese Situation führt zum Parkinson-Gesetz. Ich habe noch nie einen Kunden getroffen, dem es nicht möglich ist, weitere Funktionen hinzuzufügen. Ohne Fristen ist die Featureliste und damit das Projekt unendlich.
Eric King

12
@ Stevebot Ich denke, wir verstehen uns, aber haben unterschiedliche Bedeutungen des Wortes "Frist". Für mich ist eine "Frist" ein bestimmtes Datum. Für Sie ist eine "Frist" eine bestimmte Reihe von Funktionen, die an einem bestimmten Datum zugesagt werden. Ich glaube, meine Definition ist die gebräuchlichste und meine Antwort basiert auf dieser Definition. Nach den anderen Antworten zu urteilen, die Sie erhalten haben, stimmen andere mir zu. Nimm es für das, was du willst, ich werde nicht beleidigt sein. :-) Aber meine Antwort steht noch.
Eric King

5
"Es wird immer Erwartungen geben und es ist immer möglich, dass die Geschwindigkeit Ihres Teams dazu führt, dass Sie die grundlegendsten Funktionen verpassen." Wenn Sie Agile richtig implementieren, ist diese Aussage eine Absurdität. Ihr Rückstand MUSS nach dem maximalen Kundennutzen priorisiert werden. Wenn nicht, aus welchem ​​Grund auch immer , dann üben Sie nicht agil. Sie üben etwas anderes.
Calphool

7
"Wir müssen bis zum 28. Juli etwas zum Versenden haben." Die Frist in diesem Satz ist der 28. Juli. Sie können festlegen, dass das "Etwas" eine vorgegebene Menge von Anforderungen ist, oder es kann alles sein, was bereit ist. Das "Etwas" ist nicht die Frist. Das Datum ist die Frist.
Eric King

5
@ stevebot "(Die Antwort) führt den Leser in die Irre, zu glauben, dass Agile + Deadlines = vollkommen in Ordnung sind." Das ist jedoch der Punkt. Agile ist mit Fristen völlig in Ordnung. Oder ohne. Treffen Sie Ihre Wahl. Anders zu sagen heißt im Grunde: "Nun, da wir eine Frist haben, können wir dieses Projekt nicht so agil machen!" Das ist Quatsch. Ich habe an vielen Projekten gearbeitet, die beide Fristen hatten und "agil" waren. Sind die Fristen flexibel? Nun, sie sind nicht agil.
Eric King

24

Fristen sind eine Tatsache des Lebens. Es gibt Dinge, die ein sehr genaues Datum haben.

Wir brauchen die Software von Comdex

oder

Die Spiele müssen bis zum Black Friday im Handel erhältlich sein

und dergleichen. Man kann Comdex oder Black Friday nicht verschieben - der Rest der Welt funktioniert nicht so.

Das Ziel von Agile besteht darin, dass Dinge, die die Frist nicht einhalten, schneller scheitern (und das ist auch gut so), oder dass der Umfang früher überprüft werden kann, damit die Ressourcen auf den richtigen ROI in a fokussiert werden können pünktlicher Weise.

Die Frist ist ein fester Termin. Agile ist ein Tool, mit dem man früher im Zyklus erkennen kann, dass die Entwicklung der Software doppelt so lange dauern wird, wie ursprünglich erhofft. Es ist wichtig, dass Projektmanager diese Probleme früher als später erkennen können, damit entweder mehr Ressourcen hinzugefügt, der Umfang geändert, die Frist angepasst werden kann (in Situationen, in denen es sich eher um eine feste als eine grundsolide Frist handelt) oder das Projekt abgesagt.

Die Transparenz, die Agile anstrebt, besteht darin, die Probleme und Fortschritte zu einem früheren Zeitpunkt im Zyklus aufzuzeigen. Der klassische Fehler bei der Lieferung von Wasserfällen ist einer, bei dem Sie Monate hinter verschlossenen Türen verbracht und das Produkt eine Woche vor Ablauf der Frist geliefert haben. Es wird Ihnen mitgeteilt, dass Sie alles falsch gemacht haben und Sie Monate verschwendet haben (und nun die Frist vollständig überschritten haben). . Das andere klassische Versagen eines Wasserfalls besteht darin, eine Woche vor Ablauf der Frist herauszufinden, dass Sie noch Monate Zeit haben. Agile versucht, diese Probleme frühzeitig bekannt zu machen.

Der andere Teil, den Agile im Rahmen einer Frist anstrebt, ist, dass die aktuelle Version der Software nützlich und einsatzfähig ist, auch wenn nur ein Teil der vereinbarten Funktionen (aus welchen Gründen auch immer) vollständig ist.

Ok, wir hatten nicht alles, was wir uns für die Bereitstellung der Steuersoftware am 15. April wünschen, aber wir haben 75% und was wir haben, funktioniert und funktioniert seit wir im letzten November angefangen haben. Wir wissen, dass wir ab Mitte Dezember nicht mehr alle Funktionen bereitstellen können, und haben uns erneut auf 80% des Kundenstamms konzentriert.


2
Ich stimme Ihnen zu, obwohl ich die Bedeutung Ihrer beiden Behauptungen auf den Kopf stellen würde. # 1. Agile konzentriert sich in erster Linie darauf, sicherzustellen, dass die aktuelle Version der Software nützlich und einsetzbar ist. # 2. Zweitens hilft es uns zu erkennen, wann Umfang früher völlig unvernünftig ist, damit Produktbesitzer das Ziel von Nr. 1 neu priorisieren und aufrechterhalten können.
Calphool

2
@ user40980 Das ist schrecklich. Ja, es gibt Dinge, die ein festes Datum haben. Sie können jedoch nicht unendlich viel Arbeit in endlicher Zeit produzieren. Termine können nicht flexibel sein, es sei denn, sie werden erst nach Schätzung erstellt. Das ist eine äußerst wichtige Einschränkung. Aus diesem Grund planen Sie einen Sprint, um genau zu bestimmen, welche Arbeiten ausgeführt werden können. Eine harte, feste Frist, bis zu der trotz aller Anstrengungen alles vollständig sein muss, kann NIEMALS agil sein.
EKW

18

Einige Fristen müssen eingehalten werden. Vertragliche Verpflichtungen, Konventionen, behördliche Anforderungen. Einige werden von Managern auferlegt, die in der Lage sein möchten, die Softwareentwicklung im gleichen Diagramm wie die Fertigung in ihre Tabelle aufzunehmen. Was auch immer der Grund sein mag, die meisten Menschen kommen nicht von ihnen weg.

Wenn Sie in einem funktionierenden Team arbeiten, bedeutet die Kommunikation zwischen den Entwicklern und dem Management / den Stakeholdern, dass die Personen, die eine Entscheidung treffen müssen, gut informiert sind, um zu entscheiden, ob die Frist versäumt oder die Entwicklung fortgesetzt werden soll.

Selbst wenn Sie einmal in der Woche oder zweimal im Monat fertige User Stories liefern, haben Sie wahrscheinlich noch Termine. Stellen Sie sicher, dass Ihre Stakeholder wissen, was Ihrer Meinung nach zum Stichtag passt, und legen Sie die Erwartungen fest.

Wenn Sie ständig die bestmögliche Software mit den aktuellen Anforderungen entwickeln, sollte eine Deadline am Ende eines Sprints theoretisch kein Problem sein. Praktisch ist dies normalerweise nicht der Fall, aber es gibt auch keine Fristen, die aus dem Nichts heraus erscheinen. Die wichtigsten Fristen, die ich je erhalten habe, wurden mir lange vorher mitgeteilt, es war die Erwartung an die Qualität und die Eigenschaften, die das Problem waren.


13

Willkürliche Fristen, die keine Konsequenzen haben, wenn sie nicht eingehalten werden, sind nicht sehr flexibel. Es gibt jedoch Situationen, in denen Fristen festgelegt und eingehalten werden müssen, die außerhalb der Kontrollfristen des Entwicklungsteams liegen. Glücklicherweise gibt es bei angemessenen Fristen viele Möglichkeiten, die Gleichung umzukehren und Fristen agil zu handhaben.

Termine sind nicht immer falsch. Wie wir alle von Obi-Wan gelernt haben:

"Nur die Sith handeln absolut"

Es ist fair zu sagen, dass in den meisten Fällen Fristen albern, unnötig und sicherlich nicht agil sind, aber es wäre ein Narr zu sagen, dass dies immer der Fall ist. Der Architypal-Fall ist eine Software, die für eine zeitkritische Verwendung benötigt wird, z. B. eine Wahlverfolgungssoftware. Wenn die Software nicht rechtzeitig zur Wahl bereit ist, wäre es weder sinnvoll noch praktikabel, die Wahl zu verschieben, und es scheint nicht sehr kundenorientiert zu sein, nur zu sagen: „Entschuldigung, es sieht so aus, als hätten wir zu lange gebraucht. Ich weiß, dass diese Software, für die Sie uns bezahlen, völlig wertlos ist, aber die Fristen sind nicht flexibel. Wie können Sie sie uns wirklich vorenthalten, wenn Sie sie nicht einhalten? '

Es ist nicht sehr wendig, Ihren Kunden zu sagen, dass sie es schieben sollen, weil sie etwas wollen, das zeitkritisch ist, und am Ende des Tages muss jemand diese Dinge bauen. Wie können wir also die Kunden immer noch glücklich machen und scheinbar vernünftige Lösungen für zeitkritische Dinge liefern? Nun, wenn die Entwicklung von Software eine ungewisse Zeit in Anspruch nimmt und die Frist nicht variabel ist, muss etwas anderes einfach variabel sein, um mit dieser Unsicherheit umzugehen ...

Wenn der Liefertermin konstant gehalten wird, wird ein anderer Aspekt zu einer Variablen.Wie wir alle wissen, kann es bei Softwareprojekten eine große Unsicherheit geben. Als Reaktion auf diese Unsicherheit muss etwas verändert werden, wenn Sie Erfolg in Ihrem Projekt haben möchten. In der Regel ist dies der Liefertermin. Es scheint sowieso natürlich zu sein. Aber das ist nicht Ihre einzige Option. Wenn Sie sich nicht an einen festen Termin halten, müssen Sie Ihre bereitgestellten Funktionen variabel gestalten. Priorisieren Sie eine Liste von Features, und teilen Sie klar mit, dass die Anzahl der Features, die bis zu diesem Datum geliefert werden können, ungewiss ist. Arbeiten Sie mit dem Kunden zusammen, um diesen Funktionen Priorität einzuräumen, sodass die Versandwahrscheinlichkeit für die wichtigsten Funktionen höher ist. Dann funktioniert es wie gewohnt, nur wenn die Frist um Sie herum rollt und alles versendet wird, was versandbereit ist. In diesem Modell


11

Wenn jemand eine Frist festlegen möchte, ist dies in Ordnung und die Frist kann festgelegt werden. Sie müssen jedoch verstehen, dass der Geltungsbereich flexibel bleiben muss, wenn die Frist festgelegt ist.

tl; dr

In einer idealen Welt hätten wir keine Fristen und liefern Dinge, wenn sie fertig sind. Die Realität ist jedoch, dass Leute, die für Dinge bezahlen, normalerweise wissen wollen, wann sie fertig sind. Agile Methoden erkennen dies, erkennen aber auch, dass nicht alles gebunden werden kann.

Dies stellt sicher, dass Sie die Lieferqualität auf dem für das Produkt richtigen Niveau halten können. Wenn Sie eine Frist und einen Umfang (und ein Budget) festlegen, werden die Dinge schneller und Sie landen am Ende des Projekts in der alten Wasserfallwelt mit einer verrückten Crunch-Zeit. Eine Erhöhung des Budgets ist normalerweise nicht die Lösung, da das Hinzufügen von mehr Entwicklern und Testern ein Problem nicht schneller löst. Es ist eine bekannte Ansicht (und ich stimme aus Erfahrung zu), dass je mehr Leute man hinzufügt (jeder mit seinen eigenen Schwächen), desto länger dauert es.

Normalerweise (es sei denn, sie verstehen die agilen Methoden wirklich) wird der Person, die für die Software bezahlt, nicht gerne gesagt, dass wir Ihre Frist einhalten können, aber wir können nicht alles tun, was Sie wollen. Dies kann durch Priorisieren der Funktionen, aus denen die Software besteht, verwaltet werden. Ihre Priorisierungsdiskussion könnte so aussehen:

Entwicklerteam (D): "Können Sie die Funktionen, die bereitgestellt werden sollen, mit den wichtigsten zuerst priorisieren?"

Kunde (C): "Alles hat Priorität 1 - ich möchte, dass alles bis Ende nächsten Monats erledigt ist."

D : "Das ist möglich, aber nicht möglich, wenn sich die Anforderungen ändern oder wir Probleme entdecken, die wir bei der Entwicklung nicht erwartet haben."

C: "Was ist, wenn ich dir mehr Geld gebe?"

D: " Seufz ... selbst mit mehr Ressourcen wird es einen Monat dauern, bis sie wirklich loslegen. Wenn Sie sich nicht sicher sind, wie Sie die Funktionen priorisieren sollen, teilen Sie uns einfach mit, welche Sie zuerst ausführen möchten."

C: "Ok, ich möchte den großen Knopf, aber mach ihn wirklich groß und dann ... usw."

Jetzt können Sie die Funktionen in der Prioritätsreihenfolge durcharbeiten. Es ist hilfreich, gemeinsam mit Ihrem Team einen Blick auf die Elemente zu werfen, die in der Prioritätsreihenfolge niedriger sind, und frühzeitig Schätzungen vorzunehmen, da Sie wissen, dass Sie diese möglicherweise ändern können, wenn Sie in der Entwicklung sind, wenn Sie weitere Informationen haben. Dies kann verwendet werden, um Ihre Roadmap neu zu definieren oder zu erstellen, wenn Sie noch keine haben. Dies bildet dann die Grundlage für Ihren Release-Plan. Die Roadmap kann mit dem Kunden besprochen werden, wobei dieser anerkennt, dass sich der Umfang ändern kann, Sie jedoch eine Bestellung für die zu liefernden Dinge haben.

Einer der großen Vorteile von Agile ist, dass es anerkennt, dass sich die Dinge während der Entwicklung ändern und Sie sich anpassen, während sie es tun. Im Gegensatz zu herkömmlichen Ansätzen bedeutet dieses Prinzip in Verbindung mit den regelmäßigen Sprint-Ergebnissen und der laufenden Kommunikation mit dem Kunden, dass Sie natürlich gezwungen sind, transparenter über den Fortschritt zu sein, was eine gute Sache ist.

Manchmal gefällt es dem Kunden nicht, dass er zu einem bestimmten Zeitpunkt nicht das bekommt, was er will, aber er versteht, warum und was er bekommt, ist von guter Qualität. Und 6 Monate nach Auslieferung der Funktionen ist es dem Kunden egal oder er merkt sich, dass Sie zu einem bestimmten Zeitpunkt geliefert wurden. Er merkt sich auch die Qualität des Produkts, das er noch verwendet.


7
"Wenn also jemand eine Frist festlegen möchte, ist dies in Ordnung und die Frist kann festgelegt werden. Sie müssen jedoch verstehen, dass der Geltungsbereich flexibel bleiben muss, wenn die Frist festgelegt ist." Absolut.
Eric King

Dies ist wahrscheinlich die agilste Antwort hier. Die Tatsache, dass es nicht viele Stimmen hat, ist ein Beweis dafür, wie weit die Agilität missverstanden wird.
PostCodeism 18.11.18

10

Die Fristen richten sich traditionell nach dem Geschäftslebenszyklus. Steuersoftware muss bis zum 15. April verfügbar sein. Die Berichterstattung für das nächste Geschäftsjahr muss möglicherweise bis Juli erfolgen.

Das Agile-Manifest besagt:

Individuen und Interaktionen über Prozesse und Werkzeuge

Arbeitssoftware über Umfassende Dokumentation

Kundenkooperation über Vertragsverhandlungen

Reagieren auf einen Wechsel Nach einem Plan

Fristen sind ein Vertrag. Sie sind ein Plan. Sie reagieren nicht auf die Geschwindigkeit Ihres Teams. Sie ändern sich nicht, wenn Sie Ihre drei besten Entwickler verlieren.

Deadlines sind nicht agil, aber agil kann uns Feedback zu Deadlines geben. Mit Agile können wir wissen, ob wir mit unserer Geschwindigkeit keinen Termin festlegen können, ohne dass ein Feature abgeschnitten wird. Lassen Sie uns auch wissen, ob wir einen Mitarbeiter einstellen müssen, um eine Frist zu setzen. In einigen Fällen lassen Sie uns wissen, dass eine Frist nicht eingehalten werden kann, wenn keine Features mehr verfügbar sind.

Das Beste, was ein agiles Team tun kann, ist, seine Geschwindigkeit und sein priorisierter Rückstand die Fristen vorantreiben zu lassen. Dies wird voraussichtliche Liefertermine geben. Wenn diese außerhalb der Frist liegen, ist es Zeit für ein ernsthaftes Gespräch mit dem Kunden, um festzustellen, ob die Frist überhaupt eingehalten werden kann.


1
Manchmal muss der Versand bis zu einem bestimmten, nicht verhandelbaren Datum (einer Frist) erfolgen. In diesem Fall ist es das Beste, was ein Agile-Team tun kann, wenn der Abgabetermin ausläuft und der geschätzte Funktionsumfang zum Abgabetermin angegeben wird. Wenn dieses geschätzte Feature-Set die Anforderungen des Kunden nicht erfüllt, ist es Zeit für ein ernsthaftes Gespräch mit dem Kunden, um festzustellen, ob das Projekt überhaupt durchführbar ist.
Eric King

@EricKing Ja, Sie haben Recht, Agile kann mit Deadlines arbeiten. Ich glaube, ich habe Ihre Aussagen als "Deadlines are Agile" gelesen, anstatt als "Agile works with Deadlines".
Stevebot

Vielen Dank für Ihren Kommentar. Ich denke, wir haben beide eine Weile aneinander vorbei geredet, und vielleicht braucht es nur eine bestimmte Formulierung, um die Dinge zum Klicken zu bringen. Ich wollte nicht sagen, "Dealines sind agil", aber ich kann sehen, wie es auf diese Weise kommen würde. Das tut mir leid.
Eric King,

6

Ich würde sagen, dass jeder Sprint nicht verhandelbar ist. Sie bewerten die Arbeit, legen Kartengrößen darauf und laden genug, um Ihr Team bis zum Ende des Sprints zu beschäftigen (und der Sprint sollte klein sein - zwischen einer Woche und einem Monat). "Lieferfristen" sollten auf dem historischen Trend der abgeschlossenen Arbeiten gegen die erwarteten Arbeiten basieren. Agile fügt der alten Einschränkungsidee "Kosten / Zeit / Umfang" nichts hinzu bzw. entfernt sie nicht. Es verwendet lediglich den Umfang als bevorzugte Methode zum Verwalten des Schlupfes, da eine bessere Priorisierung gegenüber dem Umfang im Allgemeinen einem höheren Geld- oder Zeitaufwand vorzuziehen ist.

Manche Leute scheinen agil für "wilder Westen" zu verwechseln. Agil bedeutet nicht, dass irgendetwas geht. Agil bedeutet, dass wir aufhören, uns selbst darüber zu belügen, wie gut eine vernünftige Person einschätzen kann. Grundsätzlich können wir die Softwareentwicklung auf etwa 2 - 4 Wochen in der Zukunft schätzen. Darüber hinaus ist alles in unterschiedlichem Maße vermeintlich. Schlimmer noch, die Kosten für die Bereitstellung von Schätzungen für Dinge, die immer weiter in die Zukunft ragen, nähern sich den Kosten für die bloße Ausführung der Arbeit an. Aus irgendeinem Grund waren Projektmanager in der Vergangenheit nicht gewillt, Kunden diese absoluten Wahrheiten zuzugeben. Agile passt dieses Denken einfach an, indem es behauptet, dass die Vorhersage der Zukunft im Software-Engineering begrenzt ist, und wechselt für Langzeitprognosen subtil zu "evidenzbasierter Schätzung".sind in der Lage zu schätzen, und wir können ziemlich vernünftige Schätzungen der langfristigen zukünftigen Lieferung auf der Grundlage dessen liefern, was wir bisher geliefert haben.


Übrigens, Cal, ich bin ziemlich einverstanden mit allem, was Sie hier sagen. und ich glaube nicht, dass es dem widerspricht, was ich geschrieben habe.
Robert Bristow-Johnson

5

TL; DR

Sind Fristen [a] gile? ... [D] eadlines werden als Hand in Hand mit der [a] gile-Entwicklung gesehen.

Viele Antworten hier konzentrieren sich wahrscheinlich auf die technischen Aspekte der Frage. Stattdessen werde ich dies aus Sicht des Projektmanagements ansprechen.

Eine Frist setzt viel Vorausplanung voraus, die nicht den agilen Grundsätzen entspricht. Stattdessen basieren iterative Entwicklungsmodelle auf Zeitrahmen, Trittfrequenz und Veröffentlichungszyklen, die eine Just-in-Time-Planung umfassen, jedoch nicht auf der "großen Vorausplanung", die im Allgemeinen mit herkömmlichen Projektmanagementfristen verbunden ist.

Es ist weiterhin möglich, Release-Planungen mit agilen Methoden durchzuführen. Die Pläne basieren jedoch im Allgemeinen auf einer Schätzung der Anzahl der Iterationen, die erforderlich sind, um ein Ziel zu erreichen, und nicht auf den von Fiat festgelegten Managementzielen. Das heißt nicht, dass Versandtermine nicht festgelegt werden können oder dass Ziele nicht erreicht werden können, aber die Art und Weise , wie sie definiert und erreicht werden, unterscheidet sich erheblich von den herkömmlichen Projektmanagementmethoden.

Denken Sie an Zeitfenster, nicht an Fristen

Jedes Projekt, an dem ich jemals teilgenommen habe, bestand jedoch darauf, eine Frist zu setzen. Angesichts der Tatsache, dass Agile versucht, sich auf adaptive Planung, Flexibilität und Veränderung zu konzentrieren; sind Fristen agil?

Dies ist ein weit verbreitetes Missverständnis der agilen Prinzipien. Agile Frameworks wie Scrum und Kanban konzentrieren sich nicht auf Deadlines, sondern auf Time-Boxing und eine nachhaltige Lieferfrequenz.

In Scrum beispielsweise ist der Sprint keine "Frist". Es ist eine Zeitbox, die mit der Menge an Arbeit gefüllt ist, die das Team schätzt, um sie in die Zeitbox einzufügen, ohne sie zu überschreiten, und die dann entweder "erledigt" oder "nicht erledigt" ist, wenn die Zeitbox abgelaufen ist. Einmal weg, ist die Zeitbox für immer weg; Nicht erledigte Arbeiten müssen innerhalb eines neuen, ebenfalls kurzlebigen Zeitrahmens neu geplant und geschätzt werden, basierend auf den aktuellen (und nicht historischen) Anforderungen des Projekts.

Die Bedeutung des Zeitrahmens besteht darin, dass er sowohl eine vorhersehbare Kadenz für die Überprüfung der Fortschritte durch die Interessengruppen als auch ein nachhaltiges Tempo für das Team schafft, in dem potenziell lieferbare Wertzuwächse erzielt werden können . Die Arbeit ist inkrementell und folgt der Trittfrequenz; Das Konzept einer großen Vorlaufzeit entspricht daher nicht den Grundsätzen der Agilität.

Releaseplanung auf Basis von Time-Boxes

Möglicherweise ist der Bereich, in dem Menschen die größten Schwierigkeiten haben, agile Prozesse auf traditionelle Frameworks abzubilden, die Release-Planung. Die Release-Planung umfasst häufig entweder festgelegte oder terminierte Ergebnisse. In agilen Frameworks erfolgt die Release-Planung normalerweise über einen Schätzprozess, bei dem der Gültigkeitsbereich explizit als veränderbare Variable definiert wird, während die Release-Daten in Iterationen geschätzt werden.

Zum Beispiel kann ein Projekt verpflichtet werden, die Version 1.0 eines Projekts nach Ablauf von 20 Iterationen freizugeben. Der Umfang der Veröffentlichung kann sich im Laufe der Projektlaufzeit ändern (Umfang, Funktionen und Prioritäten können sich zu Beginn jedes Sprints ändern). Die Zieldaten für jede Veröffentlichung sind jedoch im Projektplan festgelegt. Das Team ist bestrebt, bei jedem Sprint ein potenziell versendbares Inkrement zu liefern. Die Definition von Done umfasst Qualitätsprüfungen wie die kontinuierliche Integration, um sicherzustellen, dass sich das Projekt am Ende jedes Sprints in einem freigebbaren Zustand befindet.

Gelegentlich werden Sie agile Projekte sehen, bei denen der Umfang festgelegt ist. Da der Umfang jedoch die veränderbare Variable in agilen Projekten ist, kann sich das Veröffentlichungsdatum im Laufe der Zeit ändern, wenn sich der Umfang jeder Iteration an die sich ändernden Anforderungen des Projekts anpasst . Ich empfehle den Ansatz mit festem Umfang nicht für agile Teams, insbesondere für unerfahrene Teams, aber es gibt Zeiten, in denen dies der richtige Ansatz ist.

Siehe auch


... irgendwie ... aber im Laufe der Zeit sollte sich das Team besser darauf konzentrieren, die Arbeit so zu gestalten, dass sie gut zu diesen "Zeitboxen" passt. Wenn Sie nur akzeptieren, dass Ihre Zeitfenster und Ihre abgeschlossene Arbeit nichts miteinander zu tun haben, dann programmieren Sie Cowboys und das ist völlig unvorhersehbar. Ich würde sagen, dass es vielleicht als "Zeitfenster" beginnt und im Laufe der Zeit zu einer nicht verhandelbaren Frist wird, da das Team besser vorhersagen kann, wie viel Arbeit es in einem Sprint bewältigen kann. Es geht darum, dass ein Team sich selbst trainiert, um bei der kurzfristigen Schätzung eine hervorragende Leistung zu erbringen.
Calphool

4

Stellen Sie sich Termine als Verpflichtung vor. Die Tatsache, dass das Projekt flexibel ist, bedeutet nicht, dass Sie sich nicht dazu verpflichten sollten, bestimmte Funktionen für ein bestimmtes Datum bereitzustellen.

Was Beweglichkeit bringt, ist das, was dazwischen passiert. Anstatt ein striktes Dokument mit den Softwareanforderungen zu haben, in dem festgelegt ist, dass Sie das Merkmal A aus den Untermerkmalen B, C, D und E für ein bestimmtes Datum ausliefern sollen, verpflichten Sie sich, das Merkmal A für ein bestimmtes Datum auszuliefern In einem frühen Stadium wissen weder Sie noch Ihr Kunde, wie das Merkmal aussehen wird, oder es hätte Untermerkmale B, C, D und E oder vielleicht B und C oder ein Dutzend anderer Untermerkmale.

Stellen Sie sich ein Unternehmen vor, das zuvor nur an kleine Unternehmen geliefert und gerade einen Vertrag mit einem großen Unternehmen unterzeichnet hat. Dieses große Unternehmen verwendet EDIFACT, und es scheint, dass die derzeit von Ihrem Unternehmen verwendete Buchhaltungssoftware EDIFACT nicht unterstützt. Sie werden gebeten, ein Plugin zu erstellen, mit dem Ihr Unternehmen vertraglich für den 15. April gerüstet ist .

Die Agilität würde bedeuten, dass Zwischenschritte schrittweise durchgeführt werden und auf regelmäßigem Feedback basieren. Grundsätzlich werden Sie den Buchhaltern Ihre Fortschritte zeigen und sie werden Ihnen sagen, was sie darüber denken, was mögliche Probleme sind usw. Dies bedeutet auch, dass die Buchhalter ursprünglich vielleicht eine großartige Idee hatten, die sie verbessern könnten im Wesentlichen die Benutzererfahrung. Drei Wochen später stellte sich heraus, dass es nicht nur nicht so viel verbessert, sondern auch zu einer zusätzlichen Entwicklung von einem Monat führen wird. Dank Agile können Sie dann Ihre Bemühungen von dieser Funktion auf etwas anderes umleiten und sicherstellen, dass Sie pünktlich liefern.

Sie sollten auch den Standpunkt des Kunden verstehen:

  • Oft benötigen Unternehmen einen bestimmten Liefertermin. Zum Beispiel können Sie den Online-Streaming-Service für Olympische Spiele nach dem Ende der Olympischen Spiele nicht mehr anbieten . In geschäftlicher Hinsicht ist dies einfach ein Misserfolg mit enormen negativen Konsequenzen.

  • Ohne Verpflichtung ist es für einen Entwickler oder Subunternehmer verlockend, entweder perfektionistisch zu sein oder dem Projekt eine niedrige Priorität einzuräumen. Die Regelmäßigkeit der Sprints hilft zwar, verhindert dieses Risiko jedoch nicht vollständig.

    Ich mag Fristen dafür nicht, zumal Terminverschiebungen sehr leicht vorkommen, aber ich verstehe immer noch, warum viele Unternehmen das tun. Es ist nicht immer leicht zu erkennen, dass das Projekt hinter dem Zeitplan zurückliegt, wenn man sich nur die Sprints ansieht: Ein versäumter Termin kann in diesem Zusammenhang ein deutliches Indiz dafür sein, dass etwas außer Kontrolle gerät und sofort erledigt werden sollte.


Danke, aber warum verhindert die Regelmäßigkeit der Sprints dieses Risiko nicht vollständig? Ich mag auch Ihr Beispiel für die Olympischen Spiele, aber ich denke, dass Umfang und Kosten unabdingbar sind. Wenn ich einen Entwickler für dieses Projekt einsetzen würde und alle Funktionen bereitstellen müsste, würde die Frist nicht wirklich helfen und uns höchstwahrscheinlich dazu bringen, ein Produkt von sehr geringer Qualität bereitzustellen.
Stevebot

Die Regelmäßigkeit von Sprints verhindert nicht das Risiko, da es für einen Manager relativ einfach ist, die Stakeholder zu täuschen, dass das Projekt gut läuft. Dinge wie "Wir haben diese Sache nicht implementiert, weil Sie bei unserem letzten Treffen einen Akzent auf diese beiden Dinge gelegt haben." Oder "Zwei unserer Entwickler sind im Urlaub, also haben wir während dieses Sprints nur die Hälfte der Arbeit geleistet." Für die Stakeholder ist es schwierig, darüber zu streiten, und bei jedem Sprint können sie das Gesamtbild des Projekts verlieren.
Arseni Mourzenko

Dann haben Sie ein Problem mit der Transparenz, und es hilft nicht, eine Frist an die Spitze zu setzen. Diese Ausreden werden ebenso leicht auf die Frist geworfen, und das ist fast immer das, was ich im wirklichen Leben sehe.
Stevebot

1

In eXtreme Programming heißt es zur Release-Planung:

Die Grundphilosophie der Release-Planung ist, dass ein Projekt anhand von vier Variablen quantifiziert werden kann: Umfang, Ressourcen, Zeit und Qualität.

Welches scheint fair. Es heißt auch, dass

Niemand kann alle 4 Variablen steuern. Wenn Sie einen ändern, veranlassen Sie versehentlich einen anderen, sich als Reaktion zu ändern. Beachten Sie, dass das Verringern der Qualität auf weniger als ausgezeichnet unvorhergesehene Auswirkungen auf die anderen 3 Variablen hat

Und wie bereits von br3w5 festgestellt , ist die Erhöhung der Ressourcen eine begrenzte Lösung. Sie können wahrscheinlich ein paar Leute hinzufügen, die bereits Teil des Teams waren, wenn sie auf etwas anderes geschickt wurden. Aber Sie können die Teamgröße nicht einfach schnell und auf unbestimmte Zeit erhöhen, zumindest nicht ohne eine Umstrukturierung des Teams, die viele Male dauert.

Bei nicht reduzierbarer Qualität und festen Ressourcen bedeutet eine Frist als zeitliche Beschränkung, dass Sie den Umfang anpassen müssen. Und mit Agilität haben Sie die Möglichkeit, den Termin mit dem höchstmöglichen Produktivitätsumfang einzuhalten. Sie können jedoch in der Regel garantieren, dass ein Teil des Umfangs rechtzeitig erledigt wird. Dies ist der Teil, den Sie vertrauensvoll einschätzen können, wenn die Frist unterschritten wird. Typischerweise etwas, das dem, was Sie mehrmals gemacht haben, sehr nahe kommt und wenig Unbekanntes hat.


0

Wenn Softwareentwicklungsmethoden richtig verstanden werden, sollen sie uns produktiver machen, indem sie unsere Gedanken fokussieren und eine gemeinsame Sprache für typische Situationen liefern. Es geht um Inspiration und Ermöglichung, nicht um Gedankenkontrolle und Schuld.

Eine Softwareentwicklungsmethode wörtlich ohne Kompromisse zu befolgen, entspricht in anderen Zusammenhängen dem, was man Radikalismus oder Fundamentalismus nennt. Die reine Form dieser Aberration wird in der Praxis selten gesehen, da sie typischerweise zu einem raschen Versagen auf dem Markt führt. Aber natürlich ist ein Überschreiten der Marke ein natürliches Ereignis, wenn Entwickler in der schwierigen Aufgabe konkurrieren, eine bestimmte Methode zu implementieren.

Das Problem wird durch die Tatsache verschärft, dass Missionare und Evangelisten in erster Linie diejenigen ansprechen, die noch überzeugt werden müssen, die Methode überhaupt anzuwenden. und selbst wenn sie Mäßigung predigen, sorgt die menschliche Natur dafür, dass sie weniger Beachtung findet.


-1

Fristen sind nicht wendig, sie sind:

1) Wasserfall und 2) Falsch.

Software und Fristen passen nicht gut zusammen und haben es nie getan. In vielerlei Hinsicht sind die Agile-Methoden eine Reaktion auf das massive Problem versäumter Fristen oder Software, das aufgegeben wurde, als sich herausstellte, dass die Frist nicht eingehalten werden konnte (und auch in Bezug auf das Budget).

Agile Versuche, die Realität in die Situation einzubringen, indem sie sagen: "Sie wissen, dass die Frist abläuft oder sich die Merkmale ändern werden, wir wissen es, also lasst uns auf den rechten Fuß steigen und nicht einmal so tun, als ob".

Der Schlüssel ist, dass die Frist lediglich ein Veröffentlichungsdatum für die erste Version der Software wird. Das könnte immer noch in Stein gemeißelt sein - sagen wir, die Software ist für akademische Zwecke gedacht und MUSS zu Beginn des Semesters einsatzbereit sein - aber was Sie liefern, ist nicht. Sie haben ein Produkt, von dem jeder sicher ist, dass es bis dahin geliefert werden kann, und Sie haben eine Menge "Hätten gerne". Anstatt dass jeder seine Hände in die Luft wirft, wenn sich herausstellt, dass nicht die gesamte Liste zum "Stichtag" geliefert wird, stellen Sie sicher, dass Sie den MVP aus der Tür bekommen und so viele der "hätten gerne" wie möglich und bewerten Sie dann die Kosten / Nutzen des Rests zu diesem Zeitpunkt.

Wer schon längere Zeit Computerspiele gespielt hat, weiß genau, wie das geht! Wenn die erste Veröffentlichung den Beta-Standards entspricht, sind viele Gamer glücklich, und die Erwartungen an das, was "feste, echte Deadlines" im echten Leben bedeuten, sind so gering.

Aus diesem Grund sind die Fristen nicht flexibel. Sie sind ein Überbleibsel aus der Zeit, als die Leute dachten, dass Software wie Hardware und Stahlbau behandelt werden könnte. Wir haben gelernt, dass dies weder möglich noch wünschenswert ist, da es den größten Vorteil der Software gegenüber der Hardware bietet: Es ist weich.

Agile versucht, diese Weichheit auszunutzen, indem es zulässt, dass sich Ziele im Verlauf des Projekts auf eine Weise entwickeln und ändern, die ein Brückendesign niemals könnte.


3
Ich habe keine Ahnung, warum die Leute dich herabgestimmt haben. Ich mache seit über 10 Jahren agile / xp-App-Entwicklung in einem Fortune-100-Unternehmen - habe es hier tatsächlich vorgestellt, und ich sehe absolut nichts Falsches an dem, was Sie gesagt haben. Ich habe dich auf Null hochgestuft, weil jeder, der dich runtergestuft hat, ein agiler Neuling sein muss, der immer noch an seiner alten Realität festhält, denn Gott weiß aus welchem ​​Grund. Die Leute sind zu simpel. Sie denken, dass "Software und Fristen nicht gut zusammenarbeiten" ein absolutes Muss ist. Sie wollen JEDEN Sprinttermin einhalten. Sie lügen einfach nicht über Ihre Fähigkeit, auf lange Sicht geschätzte Daten zu treffen. So einfach ist das.
Calphool

7
@ Calphool Ich habe ein Problem damit zu sagen, dass Fristen ein Wasserfall sind (sie existieren unabhängig von der verwendeten Methodik - sie existieren sogar für Cowboy-Codierer) und falsch (sie existieren aufgrund äußerer Zeitbeschränkungen - nicht mehr falsch als "das müssen wir haben Code läuft auf dieser Hardware mit minimaler Leistung "). Es ist eine zeitliche Einschränkung, was eine akzeptable Lösung ist. Die Steuererklärung muss bis zum 15. April eingereicht werden. Die Software muss bis zum 1. November beim Distributor sein, damit sie bis zum 27. November in den Regalen sein kann. Beides ist nicht falsch.

4
@MichaelT: Wenn Sie es noch nicht getan haben, empfehlen wir Ihnen, das Buch von Tom & Mary Poppendiecks "Leading Lean Software Development: Ergebnisse sind nicht entscheidend" zu lesen. Er vermittelt einfach ein ziemlich beliebtes Mem in schlanken / agilen Kreisen. Wenn Sie und Ihr Team sich mehr auf Termine als auf kontinuierliche Verbesserungen konzentrieren, leben Sie nicht wirklich agil. Du machst vielleicht Scrum, lebst aber nicht agil. Gibt es langfristige Fristen? Offensichtlich. Sind sie das, worauf sich agile Teams konzentrieren sollten? Absolut nicht. Fristen sind nebensächlich zu agilen Denken.
Calphool

4
@MichaelT Das OP bezog sich auf die Projektfristen und das ist es, worauf ich reagiere - langfristige Fristen, die von einem Premierminister zu Beginn eines Projekts festgelegt wurden, anstatt eines Sprints. Zwar gibt es in Agile Termine, aber sie unterscheiden sich stark von dem, was die Leute unter Projektterminen verstehen, aber vielleicht ist es nur die Semantik, die hier das Problem darstellt.
Nagora,

3
@Ellesedil: Geben Sie mir Ihr wichtigstes Feature oder Ihren kleinstmöglichen Funktionsumfang an. Geben Sie mir ein paar Wochen bis ein paar Monate Zeit, um eine Erfolgsbilanz mit Ihrem gewünschten Funktionsumfang zu erstellen. man braucht mehr Zeit, um vorherzusagen, wie lange es dauern wird, bis man zum Mond kommt (gegen Pittsburgh). Dann sage ich es Ihnen, und da meine Schätzung auf tatsächlichen Lieferungen nützlicher Software basiert, können wir uns auf die Schätzung verlassen, im Gegensatz zu dem Märchen, das Sie mir von Anfang an aufzwingen.
Calphool

-1

Antwort "wahrscheinlich nein"

Das Project_management_triangle gibt an, dass Kosten, Zeit und Umfang (und auch Qualität) voneinander abhängen. ("wähle zwei und erhalte den 3.")

Ein Scrum-Sprint wählt eine feste Zeit (dh 7 Tage = Länge des Sprints) und Kosten (dh Budget für 7 Teammitglieder) und schätzt den Umfang (die Anzahl der im Sprint durchzuführenden Storys).

Wenn das Management oder die Verkaufsabteilung versucht, alle drei zu definieren (Kosten, Zeit und Umfang), ist dies im Sinne von Scrum nicht agil, da das Team nicht versprechen kann, das Ziel zu erreichen (ohne die Qualität zu verletzen = Definition-of-done).

Professionelles Management versucht, Kosten und Zeit zu definieren und den Umfang bei Bedarf zu reduzieren, wenn ein fester Termin eingehalten werden muss.


-1

Kann dies nicht einfach und direkt beantwortet werden?

Keine Termine sind nicht wendig.

Der springende Punkt ist, das, was Sie können, iterativ zu lernen und anzupassen, während Sie gehen.

Eine Frist ist "Sie müssen x mal y liefern", was in beiden Fällen scheitert, da Sie ein festes Ergebnis innerhalb eines festgelegten Zeitrahmens versprechen (wenn Agile angibt, dass wir nicht sicher sind, was wir zu liefern versuchen, und Das Lernen von Agile lehrt uns, dass es sehr schwierig ist, Gewissheit über Zeitskalen zu haben, selbst wenn wir es wissen - oder es ist ein gelöstes Problem, und wir sollten es sowieso nicht tun.

Nachdem wir festgestellt haben, dass die Antwort auf die Frage "Nein, Fristen sind nicht wendig" lautet, können wir ein interessantes Gespräch führen, das sich mit der Frage befasst: "Wie werden Fristen in einem wendigen Kontext behandelt?" Und es gibt eine Menge Gutes darüber nachzudenken in den anderen Antworten.

Meines Erachtens ist eine vernünftige Antwort darauf, dass wir Wertzuwächse früh und häufig liefern und wir werden sehen, wo wir zu gegebener Zeit sind - aber es gibt keine Einheitsgröße.


-2

Der Grad an Beweglichkeit, der für die eigene Arbeit erforderlich ist, ist umgekehrt proportional zu der Position, die sie im Organigramm einnehmen.

"Agile" ist gut für das, was es ist. "Agile" Sorta bedeutet "aufgeschlossen gepaart mit ausreichender Kompetenz". Es sind die Grunzgeräusche am unteren Ende, die am beweglichsten sein müssen.

Wenn der spitze Chef auf Managementebene so agil war, dass er verstanden hat, dass eine Fristverlängerung um eine Woche zu einem besseren Produkt oder zu einem saubereren, fehlerfreieren und besser nutzbaren Code führt, sodass das Unternehmen ( oder die Division) spart in Zukunft zwei Wochen, das ist eine agile Frist.

Aber wie aufgeklärtes Eigeninteresse existiert es nicht wirklich.


5
Ein Termin, der verschoben werden kann, ist kein Termin. Das nennt man ein Kalenderdatum. Deadlines sind Dinge wie Black Friday - entweder im Laden oder nicht. Trotzdem bedeutet Agile, dass ich bis zu diesem Termin das Beste habe, was ich haben kann.
MSalters

Wenn diese Frist nicht eingehalten wird, der Hersteller aber in der folgenden Woche im Geschäft ist, stirbt er dann immer? Wenn diese Frist nicht eingehalten wird, entstehen Kosten. Aber was ist, wenn diese Kosten durch ein besseres Produkt mehr als wettgemacht werden, das die Kunden mit ihrem ersten Eindruck mehr beeindruckt ( "Sie bekommen nie die zweite Chance, einen ersten Eindruck zu hinterlassen" ) und andere Vorteile hat, die diese Kosten übersteigen? Wenn das Management klug genug ist, eine taktische Entscheidung zu treffen, um die Veröffentlichung zu verschieben (es wird die Frist überschreiten und nicht fallen lassen), zum Nutzen von Kunden und Herstellern, ist das nicht "agil"?
Robert Bristow-Johnson

Hattest du jemals einen Black Friday-Termin bei Walmart? Ich hatte das Gefühl, dass du im nächsten Jahr keine zweite Chance bekommst, wenn du dieses Jahr Mist gebaut hast. Das ist wörtlich "keine zweite Chance".
MSalters

3
Hören Sie i-Code im Bereich Audio- und Musikinstrumente. sicherlich muss das produkt aus der tür raus, um damit geld zu verdienen. Aber Fristen haben buchstäblich dazu geführt, dass ein schlecht entwickelter Mist aus der Tür ging, mit dem Kunden, Unternehmen und zukünftige Entwickler jahrelang leben mussten.
Robert Bristow-Johnson

5
Die Sache mit Black Friday-Verkäufen ist, dass es ein Marketingversuch ist, eine falsche Knappheit von Zeit und Produkt zu schaffen, um die Leute dazu zu bringen, sich irrational zu verhalten und Dinge zu kaufen, die sie sonst nicht kaufen würden. Dieses Beispiel eines induzierten irrationalen Verhaltens scheint sich nicht allzu sehr von einigen Ansätzen zum Management von Softwareprojekten zu unterscheiden. In der Argumentation, dass es keine gute Idee ist, mit Software falsche Zeitmängel zu schaffen, sage ich nicht, dass echte Zeitmängel unmöglich sind, weil sie offensichtlich in bestimmten Kontexten stehen (und dabei von entscheidender Bedeutung sind).
Shuttle87
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.