Wie ziehen Sie die Grenze zwischen "Agile Development" und "Scope Creep"?

Wie zieht man in einer iterativen Entwicklungsumgebung, wie z. B. einer agilen, die Grenze zwischen einer regulären Iteration und den Anfängen des Bereichskriechens? An welchem Punkt sagen Sie dem Kunden: "Nein, wir können diese Änderung nicht tun, wegen ?"

Antwort auf "Wie ziehen Sie die Grenze zwischen "Agile Development" und "Scope Creep"? " 9 von antworten

Dies ist ganz einfach in einem Scrum-Ansatz. In Scrum legen Sie Ihre Sprintzeit, z.B. 2 Wochen, fest und passen dann Elemente in diese ein. Wenn ein Client etwas hinzugefügt möchte, wird er in den Rückstand gesteckt und in einer zukünftigen Iteration ausgeführt. Wenn sie es jetzt wollen, müssen Sie ihnen erklären, dass etwas fallen gelassen wird, damit das in die Iteration passt.

Die wichtigste Schwäche von Agile ist, dass die meisten Menschen, die "agile" machen, wirklich am Hosensitz vorbeifliegen. Die Dinge sollten sich nicht innerhalb einer einzelnen Iteration ändern, aber Sie sollten Änderungen außerhalb dieser Iteration zulassen.

für mich bereichskriechen geschieht, wenn neue Funktion hinzugefügt wird, ohne dass der Zeitplan explizit angepasst wird.

Mit agilen Methoden ist der Anwender tief in die Entscheidung einbezogen, welche Storys Priorität für die Implementierung haben. Daher sind die Trades-off von einem Stück Funktion gegen andere viel klarer.

Ich würde es nicht als Spielraum kriechen für die Benutzer nennen, um die Funktion zu erhalten, die sie in der Reihenfolge wählen, die sie beeinflussen.

agile Iterationen haben einen festen Gültigkeitsbereich; Der Kunde erklärt sich damit einverstanden, den Umfang während der Iteration nicht zu ändern (obwohl er die aktuelle Iteration abbrechen und von vorne starten kann). Zwischen den Iterationen kann sich der Umfang ändern - dramatisch.

kann in einem agilen Projekt nicht vorkommen, wenn der Bereich definitionsgemäß nicht auftreten kann. Der Begriff des Scope Creep ist ein vermächtnisliegendes Wasserfallkonzept, das davon ausgeht, dass der gesamte Umfang im Voraus bekannt ist und sich für die Dauer des Projekts nicht ändern wird. Dieses Konzept gilt nicht auf agile Methoden solange jede Iteration ein festes Ziel hat.

Wenn der Kunde bereit ist zu zahlen, warum sollten Sie dann nein sagen? Wenn nur ein Kunde für alles bezahlt, dann ist er ziemlich in der vollen Macht dessen, was sich entwickelt ("wenn du es nicht machst, nehme ich mein Geld und sage jemand anderem, es zu tun"). Aber natürlich, wenn das Produkt ein großes Publikum hat, dann müssen Sie einen genau definierten Fokus auf das, was das Produkt tun sollte, da das Hinzufügen unnötiger Funktionen kann seine Benutzerfreundlichkeit zu senken.

Einige Situationen kommen mir in den Sinn, wenn das Entwicklungsteam dem Client empfehlen könnte, einige Funktionen nicht zu implementieren. Danach liegt es in der Verantwortung des Kunden, ob er es trotzdem umsetzen will. Wenn das Feature mit einigen anderen, wichtigeren Features in Konflikt steht, wäre es ratsam, es nicht hinzuzufügen. Wenn die Funktion dem Kunden im Vergleich zu den Kosten für die Implementierung nicht viel Wert gibt, ist es möglicherweise nicht klug, viel Geld darauf zu verbrennen. Auch in einigen Fällen könnte es sinnvoller sein, einige Funktionen als separates Programm zu implementieren, wenn ihr Zweck sehr viel vom ursprünglichen Programm unterscheidet - es ist besser, viele kleine Anwendungen zu haben, die jeweils eine Sache tun und es gut machen, als eine humongous Anwendung, die alles tut, aber auf nichts spezialisiert ist.

Warum solltest du Nein sagen? Ich weiß nicht, welchen Geschmack von agiler Entwicklung Sie verwenden. Scrum ist die normativste / hat bestimmte Regeln, um diesem Szenario gerecht zu werden.

  1. Die Bestellung (Produktbesitzer) verwaltet den (Dinge, die Sie auflisten müssen) Backlog. Er entscheidet, welche Gegenstände in den Rückstand gehen und welche Priorität sie haben. Es steht der Bestellung frei, jederzeit weitere Elemente zum Rückstand hinzuzufügen. Er ist jedoch nicht frei, den Sprint-Rückstand zu ändern (d.h. die Dinge, an denen das Team für die nächsten Wochen gearbeitet hat)
  2. Im Notfall (einige neue Erkenntnisse) kann die PO den Sprint aufgeben und einen neuen mit verschiedenen Rückstandselementen starten.

Scope Creep sollte nicht mehr passieren - es sei denn, Man beugt die Regeln. Sie haben einen LKW, der 500 Boxen (Freigabeplan) tragen wird, Um 100 Boxen (neue Funktionen) zum Plan hinzuzufügen, müsste die PO zuerst 100 am wenigsten gewünschte Boxen aus seinem ursprünglichen Set entfernen.

Ich denke, es gibt zwei Arten von Bereichskriechen:

1.) Die Erweiterung des Projektumfangs ohne Erhöhung der Zahlung/Budget/Zeit, die den Entwicklern zur Verfügung steht. Dies kann in einem agilen Prozess nur bei jedem anderen Prozess passieren, wenn der pm/scrum Master oder was auch immer nicht an den Zahlen klebt und ein anderes Feature in das Projekt/Iteration/Sprint drückt.

2.) die Erweiterung des Anwendungsbereichs einer Software, die über das hinausgeht, was sie nützt. Ich denke, agile Prozesse könnten tatsächlich helfen, gegen diese Art von Problem, weil die Kosten einer Funktion sehr direkt an den Projektbesitzer kommuniziert wird, so dass die Kosten, sollte sehr transparent sein. Aber das Hauptwerkzeug gegen diese Art von Umfang Kriechen ist das gleiche überall: Mit jedem Feature müssen Sie überprüfen: Brauchen wir es wirklich? Brauchen wir es in dieser Software? Oder gehört es woanders hin? Oder im Management sprechen: Was kostet der Bau, was kostet es zu warten (oft vergessen), wie viel erhöht es den Umsatz.

Die Antwort auf An welchem Punkt sagen Sie dem Kunden: 'Nein, das können wir nicht ändern, wegen ?' hängt vom Wert von ab? .

Es gibt in der Regel keinen guten Grund zu sagen: "Wir können diese Änderung nicht tun." Einige Dinge, die Sie sagen könnten:

  1. Wir können dies tun, aber es bedeutet, x, Y und Z werden vom Sprintziel fallen gelassen.
  2. Wir können dies tun, aber es bedeutet, den Veröffentlichungszeitplan zu verrutschen.
  3. Wir können dies tun, aber es wird zusätzliche Tests benötigen.
  4. Wir können dies tun, aber zuerst brauchen wir X Stunden der Umgestaltung.
  5. Wir können dies tun, aber zuerst müssen wir das laufende Feature X stabilisieren oder wiederherstellen.
  6. Wir können dies tun, aber wir könnten X viel schneller machen und trotzdem den größten Teil des gleichen Wertes liefern.
  7. Wir könnten dies vielleicht tun, aber wir müssen es ausarbeiten, bevor wir es schätzen können.
  8. Wir könnten dies tun, aber wir müssen X Tage damit verbringen, eine Spitze zu machen, bevor wir es sicher wissen.

(1)-(5) läuft einfach auf "Schreiben von Code braucht Zeit" -- mit unterschiedlichen Detaillierungsgraden. Die (2)/(3) Combo ist der traditionellen Idee des "Scope Creep" wahrscheinlich am nächsten. (Theoretisch ist Software, die von einem agilen Team entwickelt wurde, immer in einem absetzbaren Zustand, aber nur wenige Teams sind so gut.) Aber Das Kriechen von Reichweiten ist nur dann ein Problem, wenn es bedeutet, dass die Produktbesitzer unrealistische Anforderungen an das Entwicklungsteam stellen. Solange das Entwicklungsteam realistische Schätzungen liefert und die Produktbesitzer sie akzeptieren, sollte es entwicklern egal sein, wie weit der Umfang zu kriechen verleicht.

Wenn das Entwicklungsteam eine ungesunde Beziehung zum Produktbesitzer hat, und was Sie wirklich meinen, ist "Boy howdy is that dumb and I do not to work on it", ist die übliche Antwort, die Funktion wirklich, wirklich teuer aussehen zu lassen.

Angesichts der Tatsache, dass einer der Hauptvorteile von agilen ist der Austausch von realistischen Schätzungen für realistische Liefertermine, aber das ist kein guter Ort zu sein.

Hier ist eine einfache Heuristik, unabhängig davon, ob Sie an einer einmonatigen Iteration, 1-2 Wochen oder sogar einer Kanban-ähnlichen Umgebung arbeiten, in der Features in einem kontinuierlichen Stream hinzugefügt werden:

  1. Wenn Ihr PO (oder Kunde) Features hinzufügt, aber erwartet, dass die Frist gleich bleibt - es ist ein Merkmalskriechen: Wenn er den Umfang und seine Erwartungen entsprechend ändert, ist es vielleicht nicht "Scrum", sondern "Scrum".
  2. Wenn Ihre BESTELLUNG Funktionen hinzufügt, die dem Kunden keinen Wert bringen, dann ist es scope-creep der schlimmsten Art - Abfall! Wenn die Features Einen Wert bringen, ist es agil.