Sind Fristen flexibel?

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.

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.

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.

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.

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

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.

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.

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.

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

• So führen Sie eine agile Release-Planung durch

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.

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.

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.

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.

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.

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.

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.