Ist Scrum eigentlich für alle Arten von Projekten geeignet?

Das Projekt, an dem ich arbeite, ist rein nicht funktionaler und zutiefst technischer Natur und konzentriert sich auf die Verbesserung der Leistung des Produkts als Ganzes. Ich habe Schwierigkeiten zu erkennen, inwiefern Scrum eine geeignete Methodik für diese Art von Projekt ist:

  • Die Geschäftsperson, auch bekannt als PO, hat keine Ahnung, wovon wir während unserer Planungen sprechen, da die gesamte Arbeit zutiefst technisch ist und keine Konsequenzen für den Benutzer hat.
  • Aufgrund des Vorhergehenden kann er das Backlog nicht verwalten und wir müssen alle User Stories erstellen und verwalten.
  • Auch das Konzept einer User Story scheint keinen Sinn zu machen. In unserem Projekt gibt es keinen Benutzer. Alle Interaktionen finden zwischen verschiedenen Systemkomponenten statt.
  • Schätzungen sind ziemlich schwierig, da fast die gesamte Arbeit darin besteht, Dinge zu tun, die wir vorher nicht getan haben, sodass das Zuweisen von Punkten zu Geschichten fast eine nutzlose Übung zu sein scheint.
  • Die Lieferzeiten für funktionierende Software betragen für die meisten Dinge, die wir erledigen müssen, normalerweise Monate und nicht Wochen, da sie viele Nachforschungen erfordern, bevor sie überhaupt mit der Arbeit beginnen. Daher bedeuten Sprints normalerweise nicht so viel für uns.
  • Es gibt keinen Kunden, mit dem wir den Fortschritt überprüfen, Feedback zu unserer Arbeit geben und entsprechend anpassen können, da es rein leistungsabhängig ist, und dafür führen wir unsere Leistungstests durch, um den Fortschritt zu sehen.

Nach all diesen Punkten vermisse ich also entweder einen Teil von Scrum oder ist es wahr, dass es für diese Art von Projekt nicht geeignet ist? Und im Allgemeinen, wenn das stimmt, welche Art von Projekten sind nicht für Scrum geeignet?

Hallo Dragosb, toll, dass du anfängst, hier etwas beizutragen. Ofc Scrum ist nicht für alle Zwecke geeignet. Im Allgemeinen möchten wir Scrum nicht verwenden, wenn die Unsicherheit gering ist (wobei wir nicht sagen, dass dies Ihr Fall ist).
Können Sie näher darauf eingehen, was Sie mit "rein nicht funktional" meinen? Viele typische nicht-funktionale Anforderungen können tatsächlich in funktionale B-Anforderungen umgewandelt werden. Beispielsweise kann „hohe Leistung“ in „durchschnittliche Antwortzeit für eine Anfrage mit 1 Million derzeit aktiven Benutzern beträgt x Millisekunden“ umgewandelt werden. Dies geht bis zu dem Punkt, an dem ich einige Leute argumentieren gesehen habe, dass es keine funktionalen Anforderungen für Behälter gibt
"Der PO hat keine Ahnung, worüber wir während unserer Planungen sprechen, da die gesamte Arbeit zutiefst technisch ist und keine Konsequenzen für den Benutzer hat." Dann sprechen Sie in Ihrem Planungsmeeting über das Falsche. Sie sollen die Aufgabe nicht im Meeting lösen. Sie sollten angeben, was getan werden muss und warum es gut für das Unternehmen ist, wenn es getan wird. Wenn Sie das nicht können, sollten Sie die Aufgabe nicht ausführen. (Die Reduzierung der technischen Schulden ist eine gute Sache für das Geschäft.)
@LightnessRaceswithMonica „Dann redest du in deinem Planungsmeeting über das Falsche. Du sollst die Aufgabe nicht im Meeting lösen.“ Wir lösen nichts in der Besprechung. Wir geben an, was getan werden muss, aber was getan werden muss, ist wie erwähnt zutiefst technisch. Und warum ist es gut für das Geschäft? Denn was getan werden muss, unterstützt das Endziel des Projekts, aber das ist selbstverständlich.
Das ist mein Punkt - wenn "was getan werden muss" "zutiefst technisch" ist, dann abstrahieren Sie es für Planungszwecke nicht genug und gehen in einem Planungsmeeting auf Implementierungsdetails ein. Auch „weil das, was getan werden muss, das Endziel des Projekts unterstützt“ ist wirklich kein Business Case; das ist nur "weil es so ist". Sie sollten eine stärkere Begründung haben. Und ich bin mir sicher, dass Sie das tun: Sie müssen nur einen Weg finden, es zu vokalisieren.
@LightnessRaceswithMonica Das gesamte Projekt wurde von der Geschäftsseite aus gestartet, um die allgemeine Leistung der Plattform zu verbessern, und dann wurde uns überlassen, das Projekt im Grunde zu leiten, aber immer noch ist eine Geschäftsperson die PO, weil die Dinge laut Unternehmen in Scrum so funktionieren . Es ist schwierig, ins Detail zu gehen, aber was Sie sagen, macht für unseren Fall nicht viel Sinn. Was ist auch der Vorteil, so viel Zeit damit zu verbringen, diese Abstraktionen zu erreichen, damit die PO verstehen kann, was wir tun, anstatt unsere Arbeit tatsächlich zu erledigen?
@dragosb Entschuldigung, nichts, was Sie gerade gesagt haben, ändert die Funktionsweise von Scrum oder behebt die Tatsache, dass Sie in Ihren Planungssitzungen auf so viele technische Details auf niedriger Ebene eingehen, dass Ihr Product Owner buchstäblich nicht versteht, wovon Sie sprechen . Egal, was Ihr Fall ist oder wer den Prozess eingerichtet hat: Es funktioniert nicht. Und deshalb sind Sie hierher gekommen: um von uns zu erfahren, warum das so ist.
Was das Erreichen von Abstraktionen betrifft, ehm, ich verstehe nicht, das dauert buchstäblich überhaupt keine Zeit. Es ist eine Art zu sprechen. Wenn überhaupt, sollte es Ihr Gespräch bei der Planung viel viel kürzer machen. Anstelle von "we need to flob the bar and make xarg a char*" , sagen Sie "wir müssen dies umgestalten, weil es zu dupliziert ist und es Zeit verschwendet, es zu pflegen" . Bonus: Das ist auch der Business Case.
@LightnessRaceswithMonica Ich schätze Ihre Erkenntnisse, aber wenn ich mir Ihre Antworten ansehe, denke ich, dass Sie eine bestimmte Denkweise haben, die wahrscheinlich durch die Projekte bestimmt wird, an denen Sie gearbeitet haben, und was Sie sagen, macht wahrscheinlich sehr viel Sinn für diese. Ich bin auch nicht hierher gekommen, um herauszufinden, warum es nicht funktioniert, bitte überprüfen Sie meine Frage.
Es ist keine bestimmte Denkweise, es ist buchstäblich, wie Scrum funktioniert, und nicht nur das, sondern Projekt- und Personalmanagement im Allgemeinen, aber okay, machen Sie weiter und viel Glück :) (Ich habe Ihre Frage überprüft und „[vermisse ich] einen Teil von Scrum “ scheint hier gut zu passen.)
"Ein Kaufmann ist der PO, weil die Dinge in Scrum laut Unternehmen so funktionieren." Wer ist in diesem Fall „das Unternehmen“? Führung? Dein Boss? Der Rest Ihres Teams?
>>>Das gesamte Projekt wurde von der Geschäftsseite aus gestartet, um die allgemeine Leistung der Plattform zu verbessern<<< Leistung an sich ist kein Geschäftswert. Es beginnt, ein Geschäftswert zu werden, sobald Sie wissen, was Sie mit der besseren Leistung anfangen. Beispiele sind eine verbesserte Benutzererfahrung durch kürzere Reaktionszeiten, eine vereinfachte Architektur, da eine bessere Leistung Lastausgleiche überflüssig macht, Kosteneinsparungen, da die 5 Server die Arbeit erledigen, die zuvor von 10 Servern erledigt wurde, usw. Das sollte der nicht technische Product Owner entscheiden

Antworten (5)

Zu Ihrer Gesamtfrage: Obwohl Scrum in den meisten Projekten angewendet werden kann, ist es für einige Projekte nicht unbedingt der beste Ansatz. Allerdings eignet es sich gut für komplexe Probleme, die das Finden der Lösung und die Anpassung an neue Informationen erfordern. Ihr Projekt klingt genau nach der Art von Projekt, für das Scrum entwickelt wurde. Sie sprechen jedoch einige wichtige Punkte an, und ich werde versuchen, sie anzusprechen:

1) Ein Product Owner muss die Domäne, in der er arbeitet, auf einer Ebene verstehen, die es ihm ermöglicht, die wichtigsten Probleme, die gelöst werden müssen, um Werte zu schaffen, intelligent zu identifizieren und zu diskutieren. Zum Beispiel kennt die PO für den Large Hadron Collider ihre Quantenphysik besser. Es ist durchaus möglich, dass Sie die falsche Bestellung für Ihre Arbeit haben. Es ist jedoch erwähnenswert, dass sie nicht verstehen müssen, wie das Problem zu lösen ist, um effektiv zu sein – das ist die Aufgabe des Teams. Tatsächlich ist es manchmal besser, wenn sie es nicht tun, damit sie dem Team aus dem Weg gehen können.

2) Während Product Backlog Items von jedem stammen können, muss der PO sie genug verstehen, um ihren Wert auszudrücken und Prioritäten setzen zu können. Sind Ihre Backlog Items Ausdruck zu lösender Probleme oder Aufgaben in der Lösung. Wenn ersteres, dann sollten Sie sich vielleicht wieder eine andere Bestellung ansehen. Wenn letzteres der Fall ist, haben Sie möglicherweise die falschen Elemente in Ihrem Backlog.

3) Erstens müssen Sie keine User Stories verwenden. Sie haben jedoch einige Personen oder Personengruppen, die von Ihrer Arbeit profitieren. Ihre Backlog-Elemente sollten ihnen jeweils einen Mehrwert bieten. Wenn ein Produkt für niemanden einen Mehrwert bietet, sollten Sie es stornieren. (Ich bin natürlich übertrieben. Ich bin noch nie auf ein Projekt gestoßen, das für niemanden einen Wert hatte.)

4) Die relative Schätzung ist so konzipiert, dass sie mit Unsicherheiten oder Unbekannten umgehen kann und in den meisten Projekten hilfreich ist. Einige Projekte weisen jedoch so viele Unsicherheiten auf, dass Schätzungen unbrauchbar werden. Glücklicherweise erfordert Scrum sie nicht. Eine Empfehlung, die ich aussprechen würde, ist, dass Sie Zeitboxen verwenden, wenn Sie keine Schätzungen verwenden. Eine Zeitbox legt die Zeit fest, die man an etwas arbeiten muss, bevor man in die Gruppe zurückkehrt, um zu sehen, ob es sich lohnt, weiter Zeit zu investieren, oder ob etwas anderes wichtiger ist.

5) Dies ist eine gemeinsame Herausforderung. Die Lösung ist einfach, erfordert aber Übung, um gut darin zu werden. Die Lösung besteht darin, entweder a) das Problem in kleinere Probleme zu zerlegen oder b) ein Experiment durchzuführen, um validiertes Lernen zu erhalten, anstatt lange forschende Lernprozesse. Die erste wird in Fällen verwendet, in denen der Untersuchungszyklus lang ist, weil einfach versucht wird, viele Dinge zu untersuchen. Die zweite wird verwendet, wenn der Untersuchungszyklus lang ist, da bei komplexen Problemen viele erschwerende Faktoren berücksichtigt werden müssen. Natürlich ist es viel einfacher, diesen Absatz zu tippen, als ihn zu tun, also fühlen Sie sich nicht schlecht, wenn Sie auf Probleme stoßen, von denen Sie nicht wissen, wie Sie sie in einem Sprint angehen sollen.

6) Wer will mehr Leistung, wie viel will er und wie wirkt sich das auf ihn aus? Das haben Sie in Ihrer Bewertung. Ihr Problemraum klingt sehr eng, daher wäre ich nicht überrascht, wenn ich herausfinden würde, dass Ihre Bewertungen sehr direkt sind.

für Nr. 4 und Nr. 5. In Fällen, in denen umfangreiche Untersuchungen/Recherchen erforderlich sind und die Gesamtaufgaben derzeit zu groß und unbekannt sind, um sie zuverlässig abzuschätzen, ist die Aufteilung in kleinere Teile definitiv die Antwort. Sowohl dem Timebox-Vorschlag zu folgen als auch die Sprints sinnvoll zu halten ... Sie können die Recherche in eine Timebox-Aufgabe aufteilen und die Ergebnisse der Untersuchung für diese Aufgabe in einem Sprint liefern. Sie können dann das Gelernte verwenden, um die Implementierung in einem zukünftigen Sprint genauer aufzuteilen/zu schätzen.
@Mr.Mindor ist es wirklich den ganzen Aufwand wert, tonnenweise Zeit damit zu verbringen, Aufgaben (vielleicht sogar künstlich) in kleinere Aufgaben zu zerlegen, die in einen 2-Wochen-Sprint passen? Es ist mit viel Aufwand und Zeit verbunden, die letztendlich für die eigentliche Erledigung der Arbeit hätten aufgewendet werden können. Was ist der Hauptvorteil, der es wert macht?
@dragosb Die Frage "Lohnt es sich wirklich?" wird von Fall zu Fall unterschiedlich beantwortet. Für jede Aufgabe gibt es einen Punkt, an dem die Kosten dafür den Nutzen übersteigen, wobei dieser Punkt davon abhängt, wie gut die Aufgabe verstanden wird und wie groß sie ist. Es lohnt sich wahrscheinlich nie, eine Aufgabe künstlich aufzubrechen . Eine große, aber sehr gut verstandene Aufgabe ist es vielleicht nicht wert, sie aufzuteilen. Meiner Erfahrung nach hängt die Leichtigkeit, eine Aufgabe aufzuteilen, jedoch direkt davon ab, wie gut sie verstanden wird. (Fortsetzung)
(...fortsetzung) In meiner jahrelangen Erfahrung kann ich mir keine gut verständliche Aufgabe von mehr als 2 Wochen vorstellen, die künstliche Mittel erfordert hätte, um sie in überschaubarere Stücke zu zerlegen. Ich sage nicht, dass wir diese Aufgaben immer weiter aufgeteilt haben.
@JimmyBreck-McKye, das ist eine "Aufgabe", die mehrere Personen mehrere Monate in Anspruch nehmen kann. Ich wäre zutiefst besorgt, wenn es nicht in Unteraufgaben aufgeteilt werden könnte. Natürlich werden sich spätere Aufgaben wahrscheinlich weiterentwickeln, wenn frühere bearbeitet werden, aber das ist wahrscheinlich in Ordnung. Lassen Sie Aufgaben aus der fernen Zukunft vage und verfeinern Sie sie, wenn sich ihre Voraussetzungen dem Abschluss nähern.
@dragosb In Bezug auf "die Arbeit tatsächlich erledigen". Herauszufinden, wie man etwas implementiert, IST die eigentliche Arbeit. Um effizient zu arbeiten, muss dieser Teil immer erledigt werden. Sie können es herausfinden, bevor die Implementierung beginnt, schrittweise/iterativ, während Sie Code in Ihre IDE eingeben, oder Sie können dies erst 3 Monate später im Nachhinein tun. Sie müssen nicht alle Details haben, bevor Sie beginnen, aber wenn Sie ein Problem nicht gut genug verstehen, dass Sie es nicht in sprintgroße Teile aufteilen können, springen Sie in die „Arbeit erledigen“. ohne Strategie kostet am Ende fast immer mehr.
@JimmyBreck-McKye Das klingt wie ein Ziel, das möglicherweise nicht einmal möglich ist, also kann es ohne weitere Nachforschungen nicht explizit aufgelöst werden. Aber 7 (Bonus) 6 Gesamtaufgaben: 1: Analysieren/Testen der thermischen Eigenschaften des aktuellen Designs und Identifizieren von "Hot Spots". 2: Delta zwischen aktuellem Profil und Ziel bestimmen. 3: X Kandidatenänderungen vorschlagen. 4: Simulieren Sie die Wirkung jedes Xj auf das Profil. 5: Erfolgreiche Kandidaten auswählen/einbeziehen und in das Design einbeziehen. 6. Kombinierte Wirkung ausgewählter Änderungen simulieren/validieren. 7. Prototypen von Verbesserungen herstellen und testen.
@dragosb, um die letzte Frage aus Ihrem Kommentar ausdrücklich zu beantworten: Die Hauptvorteile, die es wert sind, sind die gleichen wie die Hauptvorteile, Scrum überhaupt zu folgen! (in keiner bestimmten Reihenfolge) Sichtbarkeit/Transparenz (Erwartungen sind für Stakeholder klar und können überprüft werden); erhöhte Qualität (weniger Bugs für unvorhergesehene Situationen); Flexibilität (informierte Entscheidungen treffen, den Kurs aufzugeben/zu ändern); verringertes Risiko (siehe Qualität und Sichtbarkeit). verbesserte Produktivität (weniger Zeitverschwendung in Sackgassen, Nacharbeitsfehlern).
Wenn ich die Kommentare durchgehe, erinnere ich mich an den geläufigen Satz in der Softwareentwicklung … „Wochenlanges Programmieren kann Stunden der Analyse ersparen“.

Ist Scrum eigentlich für alle Arten von Projekten geeignet?

Wie bei vielen Dingen in der Softwarebranche ist Scrum keine Wunderwaffe. Es funktioniert gut für einige Arten von Projekten und weniger für andere. Ich habe oft das erwähnte Cynefin-Framework gesehen, wenn ich versuchte, Projekttypen zu identifizieren, in denen Scrum verwendet werden könnte, also werfen Sie vielleicht einen Blick darauf und sehen Sie, unter welche Kategorie Ihr Projekt fallen könnte.

Eine andere Sache, die ich oft gesehen habe, ist, dass Scrum Teams aufgezwungen wird, ohne die Art der auszuführenden Arbeit zu berücksichtigen. Aus Ihrer Frage geht hervor, dass dies der Fall sein könnte. Wer hat Scrum für Sie und Ihr Team ausgewählt? Warum? Haben Sie nach anderen Möglichkeiten gesucht, Ihre Arbeit zu organisieren? Würde Kanban vielversprechender aussehen?

Das Problem bei der Formulierung der Frage ist, dass sie Dinge gegen die Einführung von Scrum erwähnt, aber nichts über den Rest aussagt. Sind diese Dinge wichtige „No Gos“ oder nur etwas, das Sie identifiziert haben? Was ich sagen will ist, dass jedes Projekt seine Herausforderungen hat. Betrachten Sie dies also als Herausforderung, analysieren Sie es und suchen Sie nach Lösungen, sei es Scrum, Kanban oder etwas anderes.

Dann, wenn Scrum die Arbeit angehen kann, verwenden Sie es. Aber wenn Sie etwas Besseres finden, ist es am besten, Ihre Arbeit nicht zu "biegen", um sie an Scrum anzupassen, sondern verwenden Sie einfach das Bessere, das Sie gefunden haben. Wenn Sie andererseits keine Aussage darüber haben, wie Sie arbeiten, und Sie Scrum verwenden müssen, weil eine höhere Instanz es so sagt, dann haben Sie größere Probleme, als dass Scrum nicht das Beste für Ihre Arbeit ist.

"Sind diese Dinge wichtige "No Go"s oder nur etwas, das Sie identifiziert haben?" Die Punkte, die ich aufgelistet habe, sind Dinge, die ich in dem gesamten Prozess, den wir befolgen müssen, als Dinge identifiziert habe, die für mich keinen Sinn ergeben und die mich zu der Annahme veranlasst haben, dass unser Projekt möglicherweise nicht so gut für Scrum geeignet ist. Aus Daniels Antwort erkenne ich, dass einige der Punkte nicht wirklich Teil von Scrum sind, sondern einige "Scrum-Verbesserungen", die leider obligatorisch sind.
Wenn ein Prozess "obligatorisch" ist, führen Sie überhaupt kein Scrum durch und müssen möglicherweise Ihre Frage ändern. Ein Prinzip von Scrum ist, dass das Team die Macht hat, jeden Prozess oder jede Zeremonie zu ändern. Agiles Prinzip 12: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten dann entsprechend an.“ Manifestwert 1: „Wir haben gelernt, Individuen und Interaktionen über Prozesse und Tools zu stellen“ agilemanifesto.org
@dcorking Während Scrum ein ausgezeichneter Container ist, können Sie nicht tun, was Sie wollen, und es Scrum nennen. Scrum hat unveränderliche Aspekte . - Verwechseln Sie Inspizieren und Anpassen nicht mit „Cowboy-Agility“. Alle agilen Frameworks und Methoden erfordern die Einhaltung einiger grundlegender Regeln des Engagements. Der Unterschied zwischen Inspizieren und Anpassen und Cowboy-Agilität ist subtil, aber sehr real.

Fügen Sie Daniels ausgezeichneter Antwort ein wenig hinzu.

Du sagst:

Die gesamte Arbeit ist zutiefst technisch und hat keine Konsequenzen für den Benutzer

Du sagst aber auch:

konzentriert sich auf die Verbesserung der Leistung des Produkts als Ganzes

Ich kann mir zwei Gründe vorstellen, warum Sie die Leistung des Produkts verbessern könnten:

  1. Zur Verbesserung des Nutzererlebnisses (schnellere Reaktionszeiten etc.)
  2. Um die Menge an Hardware zu reduzieren, müssen Sie das gleiche Leistungsniveau erreichen

Wenn es Grund 1 ist, dann haben Sie Konsequenzen für den Benutzer, und diese werden Ihre Geschichten definieren. Zum Beispiel so etwas wie:

Als Benutzer möchte ich, dass das Produkt schneller reagiert, damit ich mehr erledigen kann

Wenn es Grund 2 ist, dann ist der Kunde wahrscheinlich ein interner Kunde und jemand, der Geld sparen möchte. Zum Beispiel so etwas wie:

Als CIO möchte ich mein wiederkehrendes Hardwarebudget reduzieren, um die Rentabilität zu steigern

Beachten Sie, dass diese Geschichten von jemandem, der nicht technisch versiert ist, wie z. B. einer Geschäftsperson oder einem Product Owner, perfekt verständlich sind. Sie beschreiben die Sache, die gewünscht wird, und nicht, wie diese Sache geliefert wird.

Danke für die Eingabe. Das Problem, das ich bei der Art von Geschichten finde, die Sie erwähnen, ist, dass sie sehr allgemein gehalten sind. "Als Benutzer möchte ich, dass das Produkt schneller reagiert, also X" ... das wäre buchstäblich eine gültige Aussage für all die Arbeit, die wir in den letzten Jahren geleistet haben, und ich sehe nicht, wie wir einen solchen Rückstand haben können Geschichten. Das klingt für mich eher nach dem generellen Ziel des Projekts als nach einer User Story,
Die Beispiele, die ich gegeben habe, sind allgemein, weil ich wenig Ahnung von den Details Ihrer Situation habe. Sie können viel spezifischer sein: "Als Benutzer möchte ich, dass die Seitenladezeiten auch in Spitzenlastzeiten unter 10 Sekunden liegen, damit ich mein Surferlebnis genießen kann". Wie spezifisch diese Geschichten sind, spiegelt tatsächlich wider, wie gut durchdacht die nicht funktionalen Anforderungen sind. Es kann verlockend sein, den „Warum“-Aspekt bei nicht funktionalen Anforderungen zu ignorieren, aber er ist genauso wichtig wie bei funktionalen Anforderungen.
@dragosb Warum musst du überhaupt die Leistung verbessern? Schreiben Sie beispielsweise fünf spezifische Situationen auf, in denen schlechte Leistung Probleme verursacht (und welche Probleme genau) – wenn Sie dies nicht können, dann liegt es vielleicht nicht an der Leistung, sondern an etwas anderem, das verbessert werden könnte? (Ich habe im Zusammenhang mit dieser Antwort kommentiert, weil Barnaby Golden im Prinzip denselben Ansatz vorschlägt.)
@Arvo Ich brauche es nicht, das Geschäft braucht es und dieses ganze Projekt wurde zu diesem Zweck gestartet, das effektiv eine alte Ausführungs- / Berechnungsmaschine durch eine neue ersetzt.
@BarnabyGolden, selbst das "spezifische" Beispiel, das Sie geben, klingt für mich immer noch sehr allgemein. Unser Ziel ist es, eine allgemein bessere Reaktionszeit zu haben, und wir erreichen dies, indem wir die zugrunde liegende Ausführungs-Engine ersetzen. Ich verstehe wirklich nicht, wie ein Benutzer in die Lage kommt, diesen Job zu machen, da Änderungen für ihn völlig transparent sind und der Geschäftswert selbst allgemein ist ... bessere Leistung, die zu billigerer Hardware und zufriedeneren Kunden führt, das ist das Ziel des Projekts keine User Story.
erstellen Sie die neue Ausführungs-Engine oder konfigurieren Sie eine vorhandene Engine, die von einem anderen Team erstellt wurde?

TL;DR

Das Scrum-Framework kann normalerweise an jedes Produkt oder jede Dienstleistung angepasst werden, die von zeitgesteuertem Aufwand und inkrementeller Lieferung profitieren können. Das bedeutet nicht, dass es für jedes Projekt am besten geeignet ist, aber die ursprüngliche Frage beschreibt nichts, was nicht in eine Scrum-Implementierung passen kann.

Fragenanalyse

Die Frage, wie sie derzeit formuliert ist, beschrieb eine Reihe von Framework- Implementierungsgerüchen , die zusammengenommen zu weit gefasst sind, um sie in einer einzigen Frage und Antwort zu behandeln. Wie beschrieben, scheint dieses Projekt keinen messbaren Geschäftsbedarf klar zu artikulieren, der zum empirischen Prozesssteuerungsmodell vieler agiler Frameworks passt. Das ist kein Versagen von Scrum oder Agile, sondern eher ein Fehler in einem oder mehreren der folgenden Punkte:

  • Projektinitiierung
  • Konzeptualisierung oder Auswahl von Projektsteuerungen
  • Organisations- oder Projektkommunikation

Die Frage, wie sie derzeit geschrieben wird, wird auch eher als Bestätigungsverzerrungs-Unterstützungsanfrage dargestellt als als ein konkretes Problem, das gelöst werden muss. Daher liegt dieser Aspekt der Frage außerhalb des Anwendungsbereichs und wird in dieser Antwort nicht behandelt.

Wofür Scrum entwickelt wurde

Das Scrum-Framework hat nur drei klar definierte Rollen und vier vorgeschriebene Ereignisse . Abgesehen von den obligatorischen Framework-Elementen, die im Framework genannt werden, steht es Organisationen frei, es an ihre spezifischen Bedürfnisse anzupassen.

Scrum ist in erster Linie als Rahmen für die Produktlieferung gedacht. Der Leitfaden selbst nennt eine Reihe konkreter Anwendungen:

  1. Recherchieren und identifizieren Sie realisierbare Märkte, Technologien und Produktfähigkeiten;
  2. Produkte und Erweiterungen entwickeln;
  3. Veröffentlichen Sie Produkte und Verbesserungen so oft wie oft am Tag;
  4. Cloud (online, sicher, On-Demand) und andere Betriebsumgebungen für die Produktnutzung entwickeln und unterhalten; Und,
  5. Produkte erhalten und erneuern.

Solange ein Projekt in iterative oder inkrementelle Einheiten zerlegt werden kann, die zeitlich begrenzt werden können, kann Scrum an den Anwendungsfall angepasst werden. Die ursprüngliche Frage deutet stark darauf hin, dass die wahrgenommenen Fehler des Scrum-Modells für den aktuellen Anwendungsfall mehr mit Schwierigkeiten zu tun haben, das Projekt als eine Reihe zeitlich begrenzter Inkremente zu konzipieren, die jeweils einen zentralen Zusammenhalt enthalten. Dies ist höchstwahrscheinlich eher eine Implementierungs- oder Erfahrungslücke als ein negativer Anwendungsfall für die Anwendbarkeit von Scrum auf einen bestimmten Problembereich.

Wann Sie Scrum nicht verwenden sollten

Es gibt sicherlich Alternativen zur Verwendung von formalem Scrum , wenn die Problemdomäne nicht der Theorie oder den Werten des Frameworks entspricht. Eine solche Liste kann niemals vollständig sein. Es gibt jedoch sicherlich häufige negative Anwendungsfälle, darunter:

  1. Unbefristete Support- oder Servicebereitstellungsprozesse.
  2. On-Demand-Prozesse (Helpdesk oder Callcenter sind zwei häufige Beispiele).
  3. Wenn eine Just-in-Time-Planung von Inkrementen nicht machbar oder wünschenswert ist.
  4. Extrem kurze Projekte.
  5. Projekte mit individuellen Mitwirkenden.
  6. Sehr kleine oder sehr große Teams.
  7. Leistungen, denen es an zentralem Zusammenhalt mangelt.
  8. Leistungen, denen eine messbare Definition of Done fehlt.
  9. Projekte ohne aktive Zusammenarbeit der Interessengruppen.

Wenn Ihre Problemdomäne grundsätzlich nicht zum Scrum-Modell passt, sind andere Frameworks oder Methoden möglicherweise besser geeignet. Welches Framework das „beste“ ist, ist subjektiv, aber jedes etablierte Framework sollte klar definierte Designziele haben, die Sie als Leitfaden für Ihren Auswahlprozess verwenden können.

"Die Frage (...) ist (...) eine bestätigungsverzerrte Support-Anfrage als ein konkretes zu lösendes Problem." Das. Es wird keine Antworten geben, die die Meinung ändern, wenn das OP nicht bereit ist, sich zu ändern.

Scrum ist ein Schlagwort unter Managern, insbesondere unter denjenigen, die nie wirklich programmieren/analysieren/testen. Es passt zu einigen spezifischen Projekten, aber nicht zu allen. Für viele ist es nicht geeignet, diese Auseinandersetzung mit hochtechnischen Themen gehört dazu. Scrum ist eigentlich dafür bekannt, technische Schulden anzuhäufen (es ist einfach, diese „nicht netten“ Aufgaben irgendwo unten im Backlog zu mischen). Ich denke, der beste Weg für jedes Projekt besteht darin, ein einfaches Kanban zu verwenden und es dann an die Anforderungen des Entwicklers und des Projekts anzupassen, um entweder mehr in den agilen Weg zu gehen oder starrer zu werden (was an sich nicht schlecht ist, insbesondere für risikoreiche Projekte). Wohlgemerkt, Wasserfall ist kein schmutziges Wort, wie uns all diese Scrum-Coaches, -Meister und -Gurus glauben machen wollen.

Diese enthält falsche Aussagen zu Agile und Scrum. Versuchen Sie, den Scrum Guide zu lesen, Sie werden angenehm überrascht sein, dass er nichts davon befürwortet. Auch der Name Waterfall war das Wort, das von agilen Praktikern als Strohmann geschaffen wurde – also ja, genau das bedeutet es.
@DaveHillier Ihre Zuschreibung von "Wasserfall" als agiles Pejorativ ist falsch. Es gibt ein tatsächliches Modell namens Wasserfallmodell , das seine Wurzeln im Jahr 1956 hatte. Selbst die erste formelle Verwendung des Begriffs ging lange vor der agilen Bewegung zurück, obwohl Sie Recht haben, dass er sogar in seiner ursprünglichen Form ein Modell beschreiben sollte mit bekannten Mängeln.
Abgesehen von meinem Kommentar an @DaveHillier hat er Recht, dass diese "Antwort" größtenteils eine unbegründete Meinungsäußerung ist. Während „Schlagwort agil“ sicherlich ein Problem sein kann, ist Scrum nicht von Natur aus ein reines Schlagwort-Framework. Die meisten Scrum-Fehler sind eher Implementierungs- oder Anwendungsfehler als Framework-Mängel. Daher beantwortet diese Antwort derzeit nicht die ursprünglich gestellte Frage.
@ToddA.Jacobs Wikipedia macht die folgende Behauptung: „Die erste formale Beschreibung des Wasserfallmodells wird oft als Artikel von Winston W. Royce aus dem Jahr 1970 zitiert,[3][4] obwohl Royce den Begriff Wasserfall in diesem Artikel nicht verwendet hat. Royce präsentierte dieses Modell als Beispiel für ein fehlerhaftes, nicht funktionierendes Modell; so wird der Begriff im Allgemeinen in Schriftstücken über Softwareentwicklung verwendet – um eine kritische Sicht auf eine häufig verwendete Softwareentwicklungspraxis zu beschreiben.[5] "Das würde ich vielleicht tun hätte besser gesagt, es wird als Strohmann verwendet.
Ist Scrum eigentlich für alle Arten von Projekten geeignet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v