it-swarm.com.de

Sind die Fristen agil?

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 erfüllt sein muss.

Von Wikipedia

Während meiner gesamten Karriere als Softwareentwickler habe ich "Agile" gemacht, was überall zu bedeuten schien, dass zumindest die folgenden Praktiken eingehalten wurden:

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

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

Ich bin der Meinung, dass dies nicht der Fall ist, da ich sehe, dass Fristen zu mangelnder Flexibilität und Qualität führen. Stattdessen bietet es meiner Meinung nach mehr Wert, sich auf Sprints und frühe Lieferungen zu konzentrieren. Es scheint jedoch, dass dies in jedem Kreis, in dem ich war, nicht der Fall ist, und die Fristen werden als mit der agilen Entwicklung einhergehend angesehen.

103
stevebot

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

Die Arbeit wird erweitert, um die für ihre Fertigstellung verfügbare Zeit zu füllen.

Mit anderen Worten, wenn Ihr Projekt für immer weitergehen kann , wird es dies tun.

In Bezug auf die Fristen versucht Agile einige Dinge zu tun:

  • Stellen Sie sicher, dass jeder immer 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 verwendbar sind, dass sie nicht von Funktionen abhängen, die noch nicht abgeschlossen wurden
  • Stellen Sie sicher, dass die Entwicklung in einem nachhaltigen Tempo fortgesetzt wird

Auf diese Weise haben Sie am unvermeidlichen Tag keinen nutzlosen Stapel Code, sondern ein funktionierendes, getestetes Produkt, das hoffentlich nur das unwichtigste Material enthält, das noch nicht fertig ist. Und niemand ist vom fertigen Produkt überrascht.

Also ja. "Agile" und "Deadlines" können perfekt kompatibel sein.

150
Eric King

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

Wir brauchen die Software von Comdex

oder

Die Spiele müssen bis zum Black Friday in den Regalen sein

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

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

Die Frist ist ein fester Termin, der fest festgelegt ist. 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. Für Projektmanager ist es wichtig, diese Probleme früher als später zu erkennen, damit entweder mehr Ressourcen hinzugefügt, der Umfang geändert, die Frist angepasst werden können (in Situationen, in denen es sich eher um eine feste als eine solide Frist handelt) oder das Projekt abgebrochen.

Die Transparenz, die Agile anstrebt, besteht darin, die Probleme und Fortschritte früher 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 und erfahren, dass Sie alles falsch machen und Monate verschwendet haben (und jetzt die Frist vollständig überschritten haben). . Der andere klassische Wasserfallfehler 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 bereitstellbar ist, auch wenn nur ein Teil der vereinbarten Funktionen vollständig ist (aus welchem ​​Grund auch immer).

Ok, wir haben alles verpasst, was wir für die Bereitstellung der Steuersoftware am 15. April wollen, aber wir haben 75% und was wir haben, funktioniert und funktioniert seit unserem Start im letzten November. Wir wissen, dass wir seit Mitte Dezember nicht mehr alle Funktionen bereitstellen können, und haben unsere Bemühungen auf 80% des Kundenstamms konzentriert.

26
user40980

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 in das gleiche Diagramm wie die Fertigung in ihrer 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 es wichtiger ist, die Frist zu verpassen oder die Entwicklung fortzusetzen.

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

Wenn Sie ständig die bestmögliche Software mit den Anforderungen entwickeln, die Sie derzeit in jeder Phase haben, sollte eine Frist 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 erscheinen. Die wichtigsten Fristen, die mir jemals gegeben wurden, wurden mir lange zuvor mitgeteilt. Es war die Erwartung der Qualität und der Merkmale, die das Problem waren. Alle Fristen, an die ich denken kann, sind aus dem Nichts gekommen, wegen Lügen. Entweder teilte der Vertrieb einem Kunden mit, dass die Funktion vorhanden sei, oder sie könnte ohne Rücksprache und manchmal ohne Information des Technikers hinzugefügt werden, oder jemand teilte seinem Chef mit, dass dies bereits geschehen sei.

19
Encaitar

Willkürliche Fristen, die keine Konsequenzen haben, wenn sie versäumt werden, sind nicht sehr agil, aber es gibt Situationen, in denen aus Gründen, die außerhalb der Kontrollfristen des Entwicklungsteams liegen, Fristen festgelegt und eingehalten werden müssen. Glücklicherweise gibt es, wenn die Fristen angemessen sind, viele Möglichkeiten, die Gleichung umzukehren und die Fristen agil zu behandeln.

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

"Nur die Sith handeln absolut"

Es ist fair zu sagen, dass Fristen in den meisten Fällen albern, unnötig und sicherlich nicht agil sind, aber es wäre ein Dummkopf 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 praktisch, 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 agil. Wie können Sie uns also wirklich vorenthalten, wenn wir sie nicht einhalten? '

Es ist nicht sehr agil, Ihren Kunden zu sagen, dass sie es schieben sollen, weil sie etwas Zeitkritisches wollen, und am Ende des Tages wird es jemand haben diese Dinge zu bauen. Wie können wir also die Kunden 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 nur variabel sein, um diese Unsicherheit zu bewältigen ...

Wenn der Liefertermin konstant gehalten wird, wird ein anderer Aspekt zu einer Variablen. Wie wir alle wissen, kann es bei Softwareprojekten zu einer großen Unsicherheit kommen. Als Reaktion auf diese Unsicherheit muss etwas geändert werden, wenn Sie Erfolg in Ihrem Projekt haben möchten, und normalerweise ist dies der Liefertermin. Es scheint sowieso natürlich genug. Dies ist jedoch nicht Ihre einzige Option. Wenn Sie sich nicht an eine harte Frist halten, müssen Sie Ihre gelieferten Funktionen variabel gestalten. Priorisieren Sie eine Liste von Funktionen, und teilen Sie klar mit, dass die Anzahl der Funktionen, die bis zu diesem Datum bereitgestellt werden können, ungewiss ist. Arbeiten Sie mit dem Kunden zusammen, um diese Funktionen zu priorisieren, damit die wichtigsten mit höherer Wahrscheinlichkeit ausgeliefert werden. Dann läuft alles wie gewohnt, nur wenn die Frist um Sie herum läuft, versenden Sie alles, was versandbereit ist. Bei diesem Modell entspricht der Versand von mehr Funktionen dem Versand zu einem früheren Zeitpunkt, und der Versand von weniger Funktionen entspricht dem Versand zu einem späteren Zeitpunkt.

13
Dogs

Wenn jemand eine Frist festlegen möchte, ist dies in Ordnung und die Frist kann festgelegt werden. Was er jedoch verstehen muss, ist, dass der Umfang flexibel bleiben muss, wenn die Frist festgelegt ist.

tl; dr

In einer idealen Welt hätten wir keine Fristen und liefern Dinge nur, 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 schnell und Sie landen mit einer verrückten Crunch-Zeit am Ende des Projekts wieder in der alten Wasserfallwelt. Eine Erhöhung des Budgets ist normalerweise nicht die Antwort, da das Hinzufügen weiterer Entwickler und Tester ein Problem nicht schneller löst. Es ist eine bekannte Ansicht (und ich stimme dem aus Erfahrung zu), dass je mehr Leute Sie hinzufügen (jede mit ihren eigenen Schwächen), desto mehr Zeit dauert es.

Normalerweise (es sei denn, sie verstehen die agilen Methoden wirklich) wird die Person, die für die Software bezahlt, nicht gerne informiert. Wir können Ihre Frist einhalten, aber wir können nicht alles tun, was Sie wollen. Dies kann durch Priorisierung der Funktionen der Software verwaltet werden. Ihre Priorisierungsdiskussion könnte folgendermaßen aussehen:

Entwicklerteam (D): "Können Sie bitte die Funktionen priorisieren, die Sie bereitstellen möchten, wobei die wichtigsten zuerst angezeigt werden?"

Kunde (C): "Alles hat Priorität 1 - Ich möchte, dass sie alle bis Ende nächsten Monats fertig sind."

[~ # ~] d [~ # ~] : "Das ist möglicherweise möglich, aber möglicherweise nicht, wenn sich die Anforderungen ändern oder wir Probleme entdecken, die wir haben habe nicht erwartet, während ich durch die Entwicklung ging. "

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

D: " seufz ... selbst mit mehr Ressourcen werden sie einen Monat brauchen, um wirklich loszulegen; Wenn Sie sich nicht sicher sind, wie Sie die Funktionen priorisieren sollen, teilen Sie uns einfach mit, welche zuerst ausgeführt werden sollen. "

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

Jetzt können Sie die Funktionen in Prioritätsreihenfolge durcharbeiten. Es ist hilfreich, mit Ihrem Team auch vorausschauend auf die Elemente zu schauen, die in der Prioritätsreihenfolge niedriger sind, und frühzeitig Schätzungen vorzunehmen, da Sie wissen, dass Sie diese ändern können, wenn Sie zur Entwicklung kommen, wenn Sie weitere Informationen haben. Dies kann verwendet werden, um Ihre Roadmap neu zu definieren oder zu erstellen, falls Sie noch keine haben. Dies bildet dann die Grundlage Ihres Release-Plans. Die Roadmap kann mit dem Kunden besprochen werden, der anerkennt, dass sich der Umfang ändern kann, Sie jedoch eine Reihenfolge der zu liefernden Dinge haben.

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

Manchmal mag es der Kunde nicht, dass er bis zu einem bestimmten Datum nicht das bekommt, was er will, aber er wird verstehen, warum und was er bekommt, wird von guter Qualität sein. Und 6 Monate nach der Auslieferung der Funktionen ist es dem Kunden egal, ob Sie bis zu einem bestimmten Datum ausgeliefert wurden. Er wird sich an die Qualität des Produkts erinnern, das er noch verwendet.

11
br3w5

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

Kundenzusammenarbeit über Vertragsverhandlungen

Auf Umstellung reagieren 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.

Fristen sind nicht agil, aber Agile kann uns Feedback zu Fristen geben. Agile lässt uns wissen, ob wir aufgrund unserer Geschwindigkeit keine Frist einhalten können, ohne dass ein Feature gekürzt wird. Es lässt uns auch wissen, ob wir einstellen müssen, um eine Frist zu setzen. In einigen Fällen lassen Sie uns wissen, dass eine Frist unmöglich ist, wenn keine Features mehr zu kürzen sind.

Das Beste, was ein agiles Team tun kann, ist, dass seine Geschwindigkeit und sein priorisierter Rückstand die Fristen bestimmen. Dies gibt die voraussichtlichen Liefertermine an. Wenn diese außerhalb der Frist liegen, ist es Zeit für ein ernstes Gespräch mit dem Kunden und um festzustellen, ob die Frist überhaupt machbar ist.

10
stevebot

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

Einige Leute scheinen Agilität für "wilden Westen" zu verwechseln. Agil bedeutet nicht, dass etwas geht. Agil bedeutet, dass wir aufhören, uns selbst zu belügen, wie gut eine vernünftige Person einschätzen kann. Grundsätzlich können wir die Softwareentwicklung auf 2 - 4 Wochen in der Zukunft schätzen. Darüber hinaus gibt es verschiedene Grade von Swags und Vermutungen. Schlimmer noch, die Kosten für die Bereitstellung von Schätzungen für Dinge, die immer weiter in die Zukunft hinausreichen, nähern sich den Kosten für die bloße Ausführung der Arbeit an. Aus irgendeinem Grund waren Projektmanager in der Vergangenheit nicht bereit, Kunden diese absoluten Wahrheiten zuzugeben. Agile passt dieses Denken einfach an, indem es behauptet, dass es eine Grenze dafür gibt, wie gut wir die Zukunft im Software-Engineering vorhersagen können, und wechselt subtil zu "evidenzbasierter Schätzung" für langfristige Prognosen. Indem wir bestimmte Lieferungen in kleinen Stücken tot liefern und evidenzbasierte Lieferungen für langfristige Dinge liefern, erhalten wir etwas, das dem Besten beider Welten nahe kommt - wir können ehrlich sein, was wir tatsächlich sind in der Lage zu schätzen, und wir können ziemlich vernünftige Schätzungen der langfristigen zukünftigen Lieferung basierend auf dem liefern, was wir bisher geliefert haben.

6
Calphool

TL; DR

Sind Fristen [a] gile? ... [D] eadlines gehen mit [a] gile-Entwicklung einher.

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 Freigabezyklen, die Just-in-Time-Planung beinhalten, aber nicht das "große" -frontplanung ", die im Allgemeinen mit traditionellen 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 zur Erreichung eines Ziels erforderlichen Iterationen und nicht auf von Fiat festgelegten Managementzielen. Das heißt nicht, dass Versanddaten nicht festgelegt werden können oder dass Ziele nicht erreicht werden können, sondern auf die Art und Weise , wie sie definiert sind und met ist ganz anders als bei herkömmlichen Projektmanagementmethoden.

Denken Sie an Zeitrahmen, nicht an Fristen

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

Dies ist ein häufiges Missverständnis der agilen Prinzipien. Agile Frameworks wie Scrum und Kanban konzentrieren sich nicht auf Fristen, sondern auf Zeitboxen und eine nachhaltige Kadenz der Bereitstellung.

In Scrum zum Beispiel ist der Sprint keine "Frist". Es handelt sich um eine Zeitbox, die mit dem Arbeitsaufwand gefüllt ist, den das Team schätzt, um in die Zeitbox zu passen, ohne sie zu überlaufen. Sie wird dann entweder "erledigt" oder "nicht erledigt", wenn die Zeitbox abläuft. Einmal weg, ist die Zeitbox für immer weg; Nicht geleistete Arbeiten müssen innerhalb eines neuen, ebenso kurzlebigen Zeitrahmens neu geplant und geschätzt werden, der auf den aktuellen (und nicht den historischen) Anforderungen des Projekts basiert.

Die Bedeutung des Zeitrahmens besteht darin, dass er sowohl eine vorhersehbare Trittfrequenz für die Stakeholder zur Überprüfung des Fortschritts schafft als auch ein nachhaltiges Tempo für das Team, in dem potenziell versandfähige Wertzuwächse erzielt werden können . Die Arbeit ist inkrementell und folgt der Trittfrequenz; Das Konzept einer großen Frist im Voraus entspricht daher nicht den agilen Grundsätzen.

Release-Planung basierend auf Zeitrahmen

Vielleicht ist der einzige Bereich, in dem Menschen die größten Schwierigkeiten haben, agile Prozesse auf traditionelle Frameworks abzubilden, die Release-Planung. Die Release-Planung umfasst häufig Lieferungen mit festem Umfang oder festem Datum. In agilen Frameworks erfolgt die Release-Planung normalerweise über einen Schätzprozess, bei dem scope explizit als veränderbare Variable definiert wird, während Release-Daten in Iterationen geschätzt werden.

Beispielsweise kann ein Projekt verpflichtet sein, die Version 1.0 eines Projekts am Ende von 20 Iterationen freizugeben. Der Umfang der Veröffentlichung kann sich während der Laufzeit des Projekts ändern (da sich Umfang, Funktionen und Prioritäten zu Beginn jedes Sprints ändern können). Die Zieldaten für jede Veröffentlichung sind jedoch im Projektplan festgelegt. Das Team ist bestrebt, bei jedem Sprint ein potenziell versandfähiges Inkrement bereitzustellen. Die Definition von Done enthält Qualitätsprüfungen wie die kontinuierliche Integration, um sicherzustellen, dass sich das Projekt am Ende jedes Sprints in einem freigebbaren Zustand befindet.

Gelegentlich werden agile Projekte angezeigt, bei denen der Bereich festgelegt ist. Da der Bereich 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, ändert oder anpasst . Ich empfehle den Ansatz mit festem Umfang sicherlich nicht für agile Teams, insbesondere für unerfahrene Teams, aber es gibt Zeiten, in denen dies der richtige Ansatz ist.

Siehe auch

5
CodeGnome

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

Was Agilität bringt, ist was dazwischen passiert. Anstatt über ein striktes Dokument mit den Softwareanforderungsspezifikationen zu verfügen, in dem festgelegt ist, dass Sie Merkmal A, das aus den Untermerkmalen B, C, D und E besteht, für ein bestimmtes Datum bereitstellen sollen, verpflichten Sie sich, das Merkmal A für ein bestimmtes Datum bereitzustellen, vorausgesetzt, dass am In einem frühen Stadium wissen weder Sie noch Ihr Kunde, wie die Funktion aussehen wird, oder hätte sie Unterfunktionen B, C, D und E oder vielleicht B und C oder ein Dutzend anderer Unterfunktionen.

Stellen Sie sich ein Unternehmen vor, das zuvor nur kleine Unternehmen beliefert 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 verarbeitet. Sie werden gebeten, ein Plugin zu erstellen, das dies tut, da Ihr Unternehmen vertraglich für den 15. April bereit sein sollteth.

Die Agilität würde bedeuten, dass Zwischenschritte schrittweise durchgeführt werden und auf regelmäßigem Feedback basieren. Grundsätzlich zeigen Sie den Buchhaltern Ihre Fortschritte und sie sagen Ihnen, was sie darüber denken, was die möglichen Probleme sind usw. Dies bedeutet auch, dass die Buchhalter ursprünglich vielleicht eine großartige Idee hatten, die sich ihrer Meinung nach verbessern könnte im Wesentlichen die Benutzererfahrung. Drei Wochen später schien es nicht nur nicht so viel zu verbessern, sondern es wird auch zu einem Monat zusätzlicher Entwicklung führen. Dank Agile können Sie 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 die Olympischen Spiele nicht bereitstellen nach dem Ende der Olympischen Spiele. 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 Perfektionist 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 Termine dafür nicht besonders, zumal Terminverschiebungen sehr leicht passieren, 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 nur die Sprints betrachtet: Eine versäumte Frist kann in diesem Zusammenhang eine klare Erinnerung daran sein, dass etwas außer Kontrolle gerät und jetzt behandelt werden sollte.

4

eXtreme Programming gibt Informationen zur Release-Planung an:

Die Grundphilosophie der Release-Planung besteht darin, dass ein Projekt durch 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, ändern Sie versehentlich einen anderen als Antwort. Beachten Sie, dass eine Verringerung der Qualität auf weniger als ausgezeichnet unvorhergesehene Auswirkungen auf die anderen 3 Variablen hat

Und wie bereits von br3w5 erwähnt, 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. Sie können die Teamgröße jedoch nicht einfach schnell und unbegrenzt erhöhen, zumindest nicht ohne eine Teamreorganisation, die viele Male in Anspruch nimmt.

Mit irreduzibler Qualität und festen Ressourcen: Eine Frist ist eine zeitliche Beschränkung. Dies bedeutet, dass Sie den Umfang anpassen müssen. Durch die Verwendung von Agilität haben Sie die Möglichkeit, die Frist so produktiv wie möglich einzuhalten. In der Regel können Sie jedoch garantieren, dass ein Teil des Umfangs rechtzeitig erledigt wird. Dies ist der Teil, den Sie vertrauensvoll abschätzen können, um die Zeit unterhalb der Frist zu begrenzen. In der Regel etwas, das dem, was Sie mehrmals getan haben, sehr nahe kommt und wenig Unbekanntes aufweist.

1
Juh_

Der Zweck von Softwareentwicklungsmethoden besteht, wenn sie richtig verstanden werden, darin, uns durch Fokussierung unserer Gedanken produktiver zu machen und eine gemeinsame Sprache für typische Situationen bereitzustellen. Es geht um Inspiration und Ermöglichung, nicht um Gedankenkontrolle und Schuld.

Das Befolgen einer Softwareentwicklungsmethode im wahrsten Sinne des Wortes ohne Kompromisse entspricht dem, was in anderen Kontexten als Radikalismus oder Fundamentalismus bezeichnet wird. Die reine Form dieser Aberration wird in der Praxis selten gesehen, da sie typischerweise zu einem raschen Versagen des Marktes führt. Aber natürlich ist es ein natürliches Ereignis, wenn Entwickler bei der schwierigen Aufgabe, eine bestimmte Methode zu implementieren, im Wettbewerb stehen.

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

0
user144228