it-swarm.com.de

Erzeugt Scrum zusätzlichen Overhead für Projekte, bei denen sich die Anforderungen nicht ändern?

Ich lese das Scrum - A Pocket Guide von Gunther Verheyen und es heißt:

Der Chaos-Bericht 2011 der Standish Group markiert einen Wendepunkt. Es wurden umfangreiche Untersuchungen durchgeführt, um traditionelle Projekte mit Projekten zu vergleichen, die agile Methoden verwendeten. Der Bericht zeigt, dass ein agiler Ansatz für die Softwareentwicklung zu einer viel höheren Ausbeute führt, selbst gegen die alten Erwartungen, dass Software pünktlich, im Rahmen des Budgets und mit dem versprochenen Umfang geliefert werden muss. Der Bericht zeigt, dass die Agile-Projekte dreimal so erfolgreich waren und es im Vergleich zu herkömmlichen Projekten dreimal weniger fehlgeschlagene Agile-Projekte gab.

Ich habe also einen Streit mit einem meiner Kollegen, der sagt, dass für einige Projekte (wie Medizin/Militär, bei denen sich die Anforderungen nicht ändern) Agile (und insbesondere Scrum) mit allen Meetings usw. überfordert ist und es logischer ist zum Beispiel Wasserfall zu benutzen.

Mein Standpunkt ist, dass Scrum in solchen Projekten eingesetzt werden sollte, da dies den Prozess transparenter macht und die Produktivität eines Teams erhöht. Ich denke auch, dass Scrum-Events nicht viel Zeit in Anspruch nehmen, wenn sie nicht benötigt werden, da wir nicht die gesamten 8 Stunden in Sprint Planning für einen 1-monatigen Sprint sitzen müssen. Wir können 5 Minuten Zeit sparen, um sicherzugehen, dass wir alle auf derselben Seite sind und mit der Arbeit beginnen.

Wird Scrum zusätzlichen Aufwand für ein Projekt schaffen, bei dem sich die Anforderungen nicht ändern?

29
Artem Malchenko

Ich glaube, es ist eine falsche Annahme zu sagen, dass es Projekte gibt, bei denen sich die Anforderungen nicht ändern. Nachdem ich sowohl in der Verteidigungsindustrie als auch in der Pharmaindustrie gearbeitet habe und Software hergestellt habe, kann ich Ihnen sagen, dass es Feedback gibt, sobald Software in die Hände von Fachexperten (entweder intern oder extern) gelangt. Manchmal bezieht sich dieses Feedback auf die Art und Weise, wie die Anforderung erfüllt wurde, und in anderen Fällen darauf, dass die Anforderungen selbst falsch oder unvollständig sind.

Bei Agilität geht es darum, diesen Feedback-Zyklus zu verkürzen und funktionierende Software schneller in die Hände von jemandem zu bekommen, dieses Feedback zu erhalten und zu entscheiden, was der nächste Schritt sein soll, um sicherzustellen, dass das Gelieferte einen Mehrwert bietet, wenn der Kunde beschließt, die Software zu akzeptieren. Selbst in Bereichen wie eingebetteten Systemen mit benutzerdefinierter Hardware (wie Sie sie möglicherweise in Bereichen wie Luft- und Raumfahrt, Automobilindustrie oder medizinischen Geräten finden) kann die schnelle Bereitstellung dünner Funktionsbereiche zur Integration und zum Prototyping sicherstellen, dass das Software- und Hardwaresystem funktioniert Arbeiten Sie wie beabsichtigt und auf eine Weise, die dem Endbenutzer hilft.

Die Verkürzung des Feedback-Zyklus ist ein wichtiger Faktor für die Risikominderung. Wenn Sie aus Sicht des Projektmanagements ein Projekt für 2 bis 4 Wochen finanzieren und regelmäßig einen Überblick über den Fortschritt erhalten, können Sie sicher sein, dass Sie auf dem richtigen Weg sind. Indem Sie in der Lage sind, dünne Funktionsbereiche bereitzustellen, arbeiten Sie schrittweise auf den Zielstatus hin und können mit der Vorhersage beginnen, wann Sie dort ankommen. Wenn die Zeit zu einer Einschränkung wird, können Sie die Funktionen mit niedrigerem Wert herabsetzen, da die zuerst ausgeführte Arbeit entweder eine Funktion mit hohem Wert oder ein Enabler für eine Funktion mit hohem Wert sein sollte. Sie können jederzeit entscheiden, ob es sich lohnt, den Aufwand weiter zu finanzieren oder in eine andere Richtung zu gehen und ein Projekt zu stoppen, bevor es zu spät ist.

69
Thomas Owens

Die sehr kurze Antwort lautet: Ja, Scrum ist von Natur aus ein teurerer Ansatz, aber wenn Sie es als Projekt bezeichnen, spielt es mit ziemlicher Sicherheit keine Rolle und führt am Ende mit ziemlicher Sicherheit immer zu einem besseren ROI.

Die vollständigere Antwort lautet:

Generell gibt es drei Formen der Prozesssteuerung: Definierte Prozesssteuerung, Statistische Prozesssteuerung und Emperische Prozesssteuerung. Definierte Prozesssteuerung ist bei weitem die billigste. Dies ist möglich, wenn häufig wiederholbare Arbeiten im Laufe der Zeit verfeinert wurden, um den "besten" Weg zu finden, die Arbeit zu erledigen. CI/CD in der Softwareentwicklung fällt in diese Kategorie. Sie möchten keine Variation in Ihrem Erstellungsprozess, also standardisieren Sie den Prozess, passen ihn an, bis Sie damit zufrieden sind, und automatisieren ihn dann. Dieser automatisierte Prozess ist offensichtlich weitaus kostengünstiger als das manuelle Durchkämpfen einer Bereitstellung.

Die statistische Prozesskontrolle ist die nächstbilligste, berücksichtigt jedoch Abweichungen in einem bekannten Prozess. Medizinische Verfahren, die nach Plan verlaufen, fallen in diese Kategorie. Ich möchte nicht jedes Mal eine Bypass-Operation neu erfinden. Ich folge dem grundlegenden Prozess und passe mich an die Variation an. Dies hat eine relativ geringe kognitive Belastung und eine ziemlich hohe Erfolgsrate.

Als nächstes folgt die empirische Prozesssteuerung, die bei weitem am teuersten ist, da Sie den Prozess unterwegs entdecken müssen. Das Lernen ist unglaublich hoch, aber zum Preis von Produktivität und Effizienz. Fast alle Projektarbeiten erfordern dies jedoch, da bisher nur wenige Projekte durchgeführt wurden. Es gibt natürlich Ausnahmen. Das Einrichten einer großen Active Directory-Umgebung ist statistischer, da Sie anhand einiger bewährter Anweisungen arbeiten, von denen Sie je nach den Umständen geringfügig abweichen. Aber wenn Ihr Projekt nicht genau die Arbeit erledigt, die zuvor erledigt wurde, erfordert es mit ziemlicher Sicherheit eine Emperical Process Control.

Um es wieder zu Scrum zu bringen, wurde Scrum entwickelt, um Probleme mit der Emperical Process-Steuerung zu lösen. Daher hat es mehr Overhead als andere Ansätze. Da die meisten Projekte diesen Ansatz erfordern, ist dies ein strittiges Argument.

Für den Kontrapunkt über Medizin und militärische Projekte klingt es nach fehlerhafter Logik. Wenn Sie eine Bestellung für 500 Flugzeuge ausführen, dann erstellen Sie genau etwas neu und Scrum ist wahrscheinlich nicht vorteilhaft. Wenn Sie ein neues Flugzeug bauen und sich Ihre Anforderungen nie ändern, würde ich dieses Flugzeug nicht fliegen.

13
Daniel

Sicher, wenn Sie ein Projekt haben, bei dem Sie kristallklare Anforderungen haben, können Sie diese einfach vor den Entwicklern ablegen und zwei Jahre später wiederkommen, um die Software Ihrer Träume zu erfüllen.

Aber die überwiegende Mehrheit der Softwareprojekte ist nicht so.

Normalerweise weiß der Kunde nicht, was er braucht. Sie können keine vollständigen und spezifischen Anforderungen erfüllen. Hier helfen iterative Ansätze: Bauen Sie eine kleine Sache auf und bitten Sie den Kunden um Feedback. Ja, dies "verschwendet" Zeit mit Demos und der Planung der nächsten Iteration. Es ist jedoch viel besser, für einen Sprint das Falsche zu bauen und dann die Anforderungen schnell zu korrigieren, als für das gesamte Projekt das Falsche zu bauen. Das heißt, Während die Anforderungen im Vorfeld eine effizientere Entwicklung ermöglichen können, sind iterative Ansätze effektiver.

Entwickler müssen die Anforderungen richtig verstehen, wenn sie nützliche Software erstellen möchten. Was ist ein guter Weg, um Missverständnisse zu entdecken, bevor es zu spät ist? Auch hier können iterative Ansätze helfen. Es ist jedoch auch wichtig, dass Entwickler selbst mit dem Kunden zusammenarbeiten, anstatt nur gefilterte Informationen über einen Autor des Anforderungsdokuments zu erhalten.

Schließlich steht die Welt während des Projekts nicht still. Externe Systeme ändern sich, Prioritäten ändern sich, Menschen ändern sich. Es ist eine schlechte Idee, so zu tun, als würden sich die Anforderungen eines Softwareprojekts nicht ändern, außer bei kurzen Projekten.

Alle diese Vorteile auf Prozessebene verpassen den großen täglichen Vorteil agiler Ansätze: Wenn sie richtig gemacht werden, macht Agilität alle glücklicher. Die größte davon ist, dass sich agile Techniken darauf konzentrieren, über kurze Zeiträume einen echten Wert zu liefern. Dies bringt Sichtbarkeit in den Entwicklungsprozess, gibt den Stakeholdern ein angemessenes Maß an Kontrolle über das Projekt und ist viel motivierender als auf ein entferntes Ziel hinzuarbeiten. Damit verbunden ist die Idee, dass sich agile Teams weitgehend selbst organisieren. Wenn die Menschen die Kontrolle über ihre tägliche Arbeit haben, fühlen sie sich geschätzt und geben daher eher ihr Bestes.

Ihr Kollege ist nicht falsch, dass Projekte im Wasserfallstil ihren Platz haben können. Und Sie irren sich nicht, dass einige agile Praktiken zeitraubende Rituale sein können. Es ist jedoch völlig dumm, die Vorteile agiler und iterativer Ansätze zu ignorieren, insbesondere ein besseres Risikomanagement und Respekt für den Einzelnen. Dies sind Dinge, die Sie in jedem Projekt wollen. Bei Bedarf kann ein Team versuchen, einen Teil davon intern umzusetzen, aber Prozesse funktionieren besser, wenn alle an Bord sind.

10
amon

Ich denke, das könnte gut umschreiben, was @Cort Ammon sagt, aber hier ist meine Meinung:

Die externen Anforderungen (Beschreibung der "Ergebnisse") sind nicht die einzigen Anforderungen in einem Projekt. Selbst wenn sich die externen Anforderungen nicht ändern, ändern sich die "internen" Anforderungen oder müssen sich während Ihrer Arbeit ändern dürfen. Entwickler werden Hindernisse oder Probleme mit einem Ansatz entdecken, was sich auf die Arbeit der anderen Personen im Team auswirkt. Ein täglicher Stand-up hält alle über diese internen Änderungen auf dem Laufenden.

1
Beejamin

Berücksichtige das:

  • Selbst bei festgelegten funktionalen Anforderungen müssen Sie diese in technische Anforderungen umwandeln. Und dies kann besser durch Iterationen erreicht werden. Möglicherweise finden Sie in der Mitte des Projekts bessere Möglichkeiten, um das Problem zu lösen.

  • Einige Anforderungen sind möglicherweise zu allgemein oder mehrdeutig: "Einfach zu bedienen", "Sicher sein". Es ist schwer zu analysieren, ob die Sicherheit oder Benutzerfreundlichkeit eines Systems noch nicht abgeschlossen ist. Einige können versteckte Implikationen haben oder sind möglicherweise nicht gut verstanden.

  • Einige Anforderungen können verbessert werden. In 200 ms zu antworten mag gut sein, aber 100 kann besser sein. Sie können das bestmögliche Ergebnis erzielen, es jedoch bei Bedarf während des Projekts opfern.

  • Möglicherweise entdecken Sie versteckte Anforderungen, die nicht in den Vertrag aufgenommen werden, aber das Projekt möglicherweise von einem Fehlschlag zu einem Erfolg ändern. Selbst wenn Sie das Projekt liefern, ist der Kunde möglicherweise nicht zufrieden. Möglicherweise müssen sie sogar den Vertrag ändern, um neue Funktionen hinzuzufügen (und in Rechnung zu stellen), die Sie im Projekt möglicherweise in einem frühen Stadium billiger entwerfen.

  • Möglicherweise stellen Sie fest, dass Sie Ihre Anforderungen in der angegebenen Zeit nicht erfüllen können. Ist nicht so, als ob Softwareprojekte nie zu spät gekommen wären. Wenn Sie also den besten Wert erzielen, können Sie die zu löschenden Funktionen neu zuordnen.

  • Eine frühere Bereitstellung hilft bei der Integration und zeigt, dass dieses Projekt Ergebnisse liefern kann.

1
Borjab

Man kann argumentieren, dass es einen Top-Down-Ansatz gibt, der diese Anforderungen so schnell wie möglich erfüllt, wenn alle Anforderungen perfekt ausgelegt sind. Wenn dies jedoch gute Anforderungen sind, sagen sie Ihnen, was Sie machen sollen, nicht wie Sie es machen sollen. Wenn sie Ihnen sagen, wie es gemacht werden soll, würde ich es "Arbeitsanweisungen" anstelle von "Anforderungen" nennen, und wir würden eine andere Art von Problem diskutieren.

Dementsprechend gibt es immer einen Prozess zur Entwicklung des "Wie" innerhalb des Unternehmens oder des Teams, das die Anforderungen umsetzt. Empirisch gesehen stützen wir uns stark auf einen hierarchischen Ansatz, bei dem ein Team von Designern das High-Level-System so gestaltet, dass es diese Anforderungen erfüllt, und dann die Besonderheiten dieses High-Level-Systems verwendet, um kleineren Teams "Anforderungen" zu stellen, die unsere Details präzisieren.

Im Wasserfallprozess ist dies am Einwegpfeil zwischen Design und Implementierung zu erkennen. Diese Anforderungen sind jedoch nicht in Stein gemeißelt, wie es die vom Kunden bereitgestellten waren. Diese sind intern definiert und bieten Platz für den iterativen Prozess. In der Praxis stellen wir fest, dass Designer entweder einen beträchtlichen Spielraum in den Prozess einbringen, um diesen Mangel an Iteration zu berücksichtigen, oder einen iterativen Prozess suchen.

SCRUM und viele andere verwandte agile Methoden bieten lediglich einen strengen Rahmen für diesen iterativen Prozess. Ein Markenzeichen der agilen Ansätze ist, dass sie die Optimierung dieses iterativen Musters als Kern des Prozesses betrachten, anstatt sich auf die äußere Schicht harter Anforderungen zu konzentrieren. Wie andere bereits erwähnt haben, sind tatsächliche feste Anforderungen selten, aber selbst in ihrer Gegenwart verwendet SCRUM den iterativen Ansatz als Methode, um den vertraglichen Ansatz zu steuern, in den es passt.

Ob dies gelingt, ist eine offene Debatte. Andere haben zu diesem Zweck viele Metriken bereitgestellt. Ich werde lediglich bemerken, dass es an der Stärke der Führung liegt, sicherzustellen, dass die Iterationen, die unter ihnen auftreten, korrekt in das obige Vertragssystem passen. Dies gilt für jeden Entwicklungsansatz, ist jedoch bei agilen Ansätzen sichtbarer, da wir davon ausgegangen sind, dass der Top-Down-Ansatz "normal" ist und Führungskräfte als solche geschult werden.

0
Cort Ammon