Scrum in einem Fixkostenprojekt

Question

Ich habe das agile Manifest gelesen und verbringe einen schönen Tag im Internet surfen auf der Suche nach dieser schwer fassbaren Antwort. Aber leider bekam ich keine Antwort, die alle Grundlagen abdecken würde.

Wenn Sie alle Blogposts und Nachrichtensendungen von Agile Preachers sehen, hören Sie nur von offenen Bereichen oder offenen "Zeit" -Projekten. Wie wenden Sie dies auf ein Fixkostenprojekt an?

Von dem, was ich herausgefunden habe, ist das größte Problem Scope-Management. Wie bestimmen Sie, ob sich etwas außerhalb des projizierten Bereichs befindet und wie formulieren Sie Argumente für Ihre Entscheidung? Wegen der agilen Art und Weise, wie Sie Ihre Software implementieren, gibt es kein detailliertes Design, um darüber zu streiten. In den meisten Fällen haben Sie nur eine vage Wunschliste, die der Kunde Ihnen übergibt. Und ist so allgemein, dass Sie jedes Feature darin interpretieren können.

Und mit dem steigenden Anteil von Fixed-Cost-Projekten scheint mir das ein echtes Problem zu sein.

So würden die Fragen sein:

• Wie Sie Rahmen in einem fix Kosten Projekt verwalten?
• Wie bestimmen Sie, ob die gewünschten Features außerhalb des ursprünglichen Umfangs liegen?

Answer 1

Scrum ersetzt nicht die richtigen Anforderungen oder gelegentlich größere Releases oder Meilensteine. Es gibt Ihnen vielmehr die Möglichkeit, Ihr Team produktiv und fokussiert zu halten, und vermeidet die zeitverschwendenden Nebenwirkungen eines Wasserfallprozesses.

Einer der größten Vorteile eines agilen Prozesses wie Scrum ist, dass Sie in problematischen Bereichen Ihres Projekts "schnell und laut" ausfallen. Wenn Ihr Team nach einigen Sprints immer noch nicht in der Lage ist, die für die Implementierung eines bestimmten Features benötigte Zeit und Ressourcen effektiv zu schätzen, kann es sinnvoll sein, die Anforderungen in diesem Bereich zu revidieren. oder ganz verschrottet. In einem traditionellen Wasserfallprozess können diese "Problemmerkmale" jedoch oft auf die letzte mögliche Minute zurückgeschoben werden, was zu der üblichen Todesmarsch und Unterlieferung führt, in die die meisten Projekte münden.

Allerdings ist die Rolle des Product Owners in Teams, die Scrum verwenden, die eine große Anzahl von Anforderungen haben, noch kritischer. Wenn sie sich selbst überlassen, konzentrieren sich die meisten Entwicklerteams zuerst auf die interessantesten/amüsantesten/amüsantesten Funktionen (Dienst-APIs, Caching, Suche) und verlassen die "unordentlichen" Dinge wie Zahlungsprozess, UX-Design und i18n bis zur letzten Minute . Eine starke Benutzerstimme ist unerlässlich, um sicherzustellen, dass die für den Endbenutzer wichtigen Funktionen einen angemessenen Anteil an Aufmerksamkeit erhalten.

Answer 2

Ich antwortete kürzlich auf eine similar question on SO. Sie können diese Antwort nützlich finden.

Answer 3

Okay, dies wird nicht die ideale Antwort sein, die Sie suchen, aber kann nicht helfen, dennoch.

Für Ihren ersten Punkt: mit Iteration Muster

mit agilen und Scrum insbesondere ist der Stil in Richtung ändernden Spezifikationen und nicht fixierten Fristen geeignet. Dies in einem festen Umfang zu bewältigen, wird ein Albtraum sein. In der Regel wird ein Budget für den angegebenen Bereich festgelegt, und jedes Addendum würde über das Budget hinaus abrechenbare Stunden generieren. Dies wäre in Scrum sinnlos, da der Produktstau von den Stakeholdern kontinuierlich gefüllt wird. Wenn es keine "Bestrafung" für Umfangänderungen in einem festen Budget gibt, gibt es nichts, was die Leute davon abhält, sich einfach auf dich zu laden.

Die Alternative ist hier Umfang Sprint Abfolgen behoben haben, so zum Beispiel:

5x Sprints = x Cost with minimal scope change.

Für Ihren zweiten Punkt:

Die Verwendung von Analyse und Design ist ein unschätzbares Werkzeug. Unter Verwendung von Anwendungsfällen, Ereignistabellen, Sequenzdiagrammen, Zustandsautomaten und dergleichen; Sie werden auf lange Sicht Tränen auf der Erde retten. Grundsätzlich, wenn die Planung abgeschlossen ist, verwenden alle Ergänzungen zu diesem, die zusätzliche (bitte beachten Sie zusätzliche, nicht Dinge, die übersehen wurden) Anwendungsfälle und große Code-Änderungen werden außerhalb des Geltungsbereichs sein. In der Tat ist alles, was bei der Planung nicht übersehen wurde und nicht in Ihrer Spezifikation enthalten ist, außerhalb des Geltungsbereichs.

Abschließend müssen Sie sehr gut geplante Dokumentation sowie sehr solide Vereinbarungen mit Ihren Kunden haben, um dies zu 100% abziehen zu können.

Ich hoffe, das hilft.

Answer 4

Ich arbeitete in einer Umgebung, in der wir Fixkosten und Fixed-Time-Projekte hatten. Wir sind auf eine Scrum-ähnliche Methodologie aus einer Wasserfall/VModel-Methodologie umgestiegen. Scrum kann sehr gut in Fixed-Cost/Time-Projekten arbeiten, da das Konzept ist, dass der Kunde die Kontrolle hat, aber damit dies funktioniert, müssen Sie in der Lage sein, etwas zu bestimmen, was Arbeit kostet und was es kostet (Zeit, Geld) , Ressource). Und das ist eine Situation, in der Scrum ein idealer Kandidat ist.

Sie brechen die wishy washy Wunschliste/Anforderungen/Screenshots in Tagable Ergebnisse. Z.B. Ein Kunde könnte sagen "Ich möchte E-Commerce, mit Paypal", müssen Sie dies in tatsächliche Ergebnisse, z. "1. Kundenregistrierung und Login, 2. Produktkatalog, 3. Einkaufstasche, 4. Zahlung, 5. Auftragsbestätigung". In diesem Stadium ist es immer noch unmöglich zu bestimmen, wie lange es dauern wird, und wir müssen alle oben genannten liefern, um das Projekt abzuschließen (d. H. Sie können keinen E-Commerce ohne Zahlung haben). Also brich sie wieder auf, und wieder, bis du körnige Ergebnisse hast, die innerhalb von Stunden, vielleicht Tagen, aber sicherlich nicht Wochen, z.

1 Catalogue 
1a View all Items 
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row 
1aii View 10 items per page with paging 
1aiii View a user slected number of items per page, with paging 
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row 

1b View by Category 
... 
1c Search 
... 
1d Attribute Filter 
... 

Und so weiter, kann es sehr schnell durchgeführt werden, und Sie können jetzt wahrscheinlich guesstimate, wie lange es dauern würde, todo x (OFC, könnte ich die oben noch weiter nach unten, fügen Sie mehr beschreibenden Text brechen die beschreiben Arbeit benötigt, wie z. B. welche persistenten Datenstrukturen Ill benötigen, die Daten in diesen Strukturen, wie Daten hinzugefügt werden, weiter gehend könnten Sie sogar die erforderlichen Start- und Beendigungszustände beschreiben.

Sobald Sie dies gehen, werden Sie feststellen, dass einige Funktionen und Abhängigkeiten von anderen, zB. Sie können nicht Paging-Funktion in einem Katalog haben, wenn Sie einen Katalog zu starten witj, und der Catagloge wird Erfordert das CMS screesn zum Hinzufügen und Bearbeiten von Objekten usw. Markieren Sie diese "kann nicht ohne Feature leben" in welchem ​​Werkzeug Sie verwenden und dies bildet das Kernprojekt, und innerhalb von ein oder zwei Tagen haben Sie eine Reihe von Funktionen, die entwickelt werden können etwas eigenständig, mit Kosten, die, wenn sie zusammengerechnet werden, die Kosten des Projekts ausmachen. Und jetzt ist der Kunde verantwortlich, sie entscheiden, dass sie ein Feature hinzufügen und die Kosten erhöhen wollen, cool, es ist ihnen allen überlassen.

All dies ist offensichtlich nur ein kleiner Teil dessen, was Scrum oder irgendein agiler Prozess ist.

Answer 5

Ich glaube nicht, dass ein Festpreis-Vertrag mit Scope-Creep und einem Scrum-Prozess inkompatibel sind. Sie müssen nur vorab mit Ihrem Kunden vereinbaren, wie es funktioniert.Wenn Sie Ihren anfänglichen Rückstau bei Ihrem Kunden erstellen, indem Sie die Schätzung vornehmen, können Sie dies als Grundlage für die Festpreiskosten und -zeitpläne verwenden. Sie können sogar eine Rate von "X" Story Punkten gleich "Y" Kosten und "Z" Zeitplan am Anfang zustimmen.

Sie dann die normale gedränge Sache zu tun, der Kunde Geschichten der aktuellen Iteration zuteilen mit etc.

Da der Kunde im Rahmen Kriechen eingreift, arbeiten Sie mit ihnen die „kriechen“ als User Stories hinzufügen der Rückstand. Jedes Mal, wenn Sie eine neue Geschichte hinzufügen, weisen Sie darauf hin, dass sie für jede zum Rückstand hinzugefügte X-Punkte die Kosten um Y erhöhen und um Z planen müssen, oder sie müssen Story-Punkte gleichen Werts abgeben. Da sie auswählen, was Sie in jeder Iteration arbeiten, sind die Punkte, die sie aufgeben (wenn das die Wahl ist), die am wenigsten wertvollen Funktionen. Wenn Ihr Zeitplan abgelaufen ist, werden Sie mit einem Rückstand der am wenigsten wichtigen Funktionen, die sie löschen können, oder geben Sie einen neuen Vertrag zu beenden.

Der Trick ist natürlich Kosten und Zeitplan für jede Geschichte/Aufgabe gut sein ;-)

Answer 6

Das Projekt in kleinere Teile an Schätzen abgebaut und feste Preise an diejenigen angebracht werden könnte werden könnten. Die anderen Phasen des Projekts könnten dann angepasst werden.

Sie müssen in der Lage sein, den agilen Prozess gegen Ihre Konkurrenten zu verkaufen. Wenn ein Kunde über feste Projekte mit festem Gebot verfügt, die pünktlich, mit Spezifikationen und Kosten geliefert wurden, warum sollten sie dann ihre Zeit damit verschwenden, Angebote anderer Entwickler einzuholen?

Answer 7

Für mich ist die kurze Antwort über Agile und Festpreis, dass Sie es nicht tun können, zumindest nicht mit einem festen Umfang.

Ich weiß, einige Leute werden sagen "das ist nicht wahr, wir tun es", aber mit allem Respekt, ich glaube nicht, dass sie wirklich Agile tun und ich werde erklären, warum. Tatsächlich ist die Erklärung ziemlich einfach: Festpreis impliziert festen Umfang und basiert auf Vorhersagbarkeit, wobei es bei Agile um variablen Bereich, Umfangmanagement und Adaptivität geht. Festpreis mit festem Umfang ist also im Grunde das Gegenteil von Agile.

Mit einem Agilen Ansatz gibt Ihnen der Festpreis eine Reihe von Iterationen für eine gegebene Teamgröße. Während dieser Iterationen kann der Kunde das Team zuerst die wertvollsten Funktionen erstellen lassen und so den generierten Geschäftswert maximieren. Die ganze Idee besteht dann darin, die Iteration zu stoppen, wenn die Kosten einer Iteration größer als der generierte Wert sind. So funktioniert Agile.

Also, wenn Leute sagen, dass sie Festpreis mit festen Umfang in einer agilen Art und Weise tun, führen sie tatsächlich einige Einschränkungen ein, die nicht wirklich kompatibel mit der Agile-Theorie sind - wie eine Vorabschätzung einer bestimmten Reihe von Features und Einfrieren zu tun Diese Funktionen und Schätzungen - und sie verlieren wichtige Vorteile von Agile (es sei denn, sie haben ein perfektes Wissen über die Technologien und die Geschäftsdomäne und meistern sie genug, um alles vorherzusagen, aber ich kenne nur wenige Projekte, die so sind).

Hier ist auf jeden Fall eine gute Zusammenstellung von verschiedenen Agile-Verträge: 10 Contracts for your next Agile Software Project das könnte hilfreich sein. Aber ich denke, sie alle erfordern eine gewisse Ausbildung der Kunden, vor allem derjenigen, die mit festem Umfang (und verspäteten Lieferungen) zu Festpreisen verwendet werden.

Answer 8

Fixed Cost bedeutet nicht Einzelsprint. Der Umfang wird in das Produkt-Backlog übertragen, und der Fortschritt der Sprints wird angepasst, ausgehandelt und ausgeliefert. Scrum ermöglicht eine schnelle Wertschöpfung und bietet eine schnelle Validierung sowie die Möglichkeit, potenzielle Goldplattierungen zu erkennen.

Die Bereichsänderung kann zum Hinzufügen von Rückständen und zum Löschen anderer führen.Es ist ein Gleichgewicht zwischen ROI und festem Budget.

Wenn der Bereich erhöht (und Wert hinzufügen), und die Kosten festgelegt sind, muss die dreifache Einschränkung (Kosten, Zeit und Umfang) entsprechend verwaltet werden.

Denken Sie daran, dass Fixkosten keine feste Länge bedeuten.