Macht Scrum Sinn, wenn ein neues Compiler-Backend implementiert wird?

15

Ich habe eine vorhandene Sprache, die ich auf eine neue Plattform portieren muss. Ich werde es wahrscheinlich versuchen, indem ich das Backend des vorhandenen Compilers ändere.

Es ist ein erheblicher Arbeitsaufwand, das Backend neu zu schreiben. Ich kann keinen Weg finden, dies in sinnvolle Geschichten zu zerlegen, ohne die INVEST-Kriterien zu verletzen.

Ich kann nicht erkennen, wie jede Story verhandelbar sein kann - sie werden alle für einen funktionierenden Compiler benötigt. Die Geschichten haben alle die gleiche Priorität und es ist egal, in welcher Reihenfolge ich sie liefere. Ich muss sie alle machen.

Einige Teile der Software, die ich implementiere, haben eine niedrigere Priorität als andere, und ich kann sehen, dass wir diese schrittweise bereitstellen können. Es gibt jedoch einen wichtigen Kern, den man haben muss .

Ich habe vor, Scrum zu folgen, aber gehe ich nur die Bewegungen durch?

Gibt es empfohlene Vorgehensweisen für diese Art von Projekt?

Dave Hillier
quelle
1
@Sklivvz aktualisiert sinnvoller?
Dave Hillier
1
Werfen Sie als Alternative zu Scrum einen Blick auf Kanban. Sie sind beide agil, aber AFAIK-Kanban ist besser für die Art der Arbeit, die Sie tun, während Scrum besser für die Arbeit ist, die in verschiedene Prioritäten unterteilt werden kann.
Izkata
@Izkata Kanban erwartet weiterhin eine priorisierte Eingabewarteschlange, entweder nach Wert oder nach Ankunftszeit. Das Alles-oder-Nichts-Wertversprechen ist der fundamentale Blocker bei der Betrachtung von iterativen Entwicklungsmodellen.
CodeGnome
@CodeGnome Hm .. Ich gebe zu, dass ich kein Kanban gemacht habe, aber ich habe verstanden, dass es gut ist, viele übergeordnete Dinge zu haben, wie in dieser Frage beschrieben: Wenn Sie für jede Karte in einem eigenen Zweig arbeiten, dann führen Sie sie zum Trunk zusammen, wenn es ist komplett, das ist eine "Iteration" / Veröffentlichung. Sie würden sich nur überlappen, im Gegensatz zu Sprints im Gedränge.
Izkata
2
Die Anforderungen ändern sich nicht. Das kann man einfach nicht mehr glauben.
JeffO

Antworten:

22

Denken Sie daran, dass der Hauptgrund, warum agile Prozesse geschaffen wurden, darin bestand, wechselnden Anforderungen gerecht zu werden. Wenn Anforderungen in Stein gemeißelt sind (wirklich feste Anforderungen sind selten, aber ich werde Sie hier beim Wort nehmen!), Werden einige der Best Practices für den Umgang mit sich ändernden Anforderungen - z. B. verhandelbare Geschichten - etwas irrelevant. Die Verfolgung eines Scrum-Workflows birgt jedoch noch viel Potenzial für die Planung und Bereitstellung von Ergebnissen. Auch wenn Ihre Ergebnisse für eine Weile kein vollverwendbares Produkt darstellen, gibt es immer noch etwas zu sagen, um Ihren Kunden (und dem Team!) Den Fortschritt zu demonstrieren.

Bedenken Sie, dass all diese "must have" -Geschichten ein einziges Epos umfassen: "Auf Plattform X kompilieren können". In diesem Fall muss das gesamte Epos fertiggestellt werden, bevor ein Wert an den Benutzer übergeben wird. Dies ist jedoch häufig zu Beginn großer Projekte der Fall. Beginnen Sie mit einer Story, um das einfachste Programm zu kompilieren, und erstellen Sie dann weitere Storys, um immer mehr Sprachfunktionen zu unterstützen.

Lassen Sie sich vor allem nicht zu sehr auf den Versuch ein, jede Situation dazu zu zwingen, in einen stark verallgemeinerten Ansatz zu passen. Agile soll für Sie arbeiten, nicht umgekehrt!

vaughandroid
quelle
1
Anforderungen ändern sich immer und zu glauben, dass sie sich erst ändern, wenn der Code geschrieben und genehmigt wurde (vorausgesetzt, die Verantwortlichen halten sich an die Regeln), ist einfach in Ablehnung.
JeffO
@JeffO Ich stimme zu: Wechselnde Anforderungen sind ein begehrtes Feature von Agile, zum Beispiel haben wir deshalb Demos.
Sklivvz
1
@JeffO Wenn Sie nicht picken möchten, ändern sich die Anforderungen nicht immer , fast immer . Ich werde meine Formulierung trotzdem ändern.
Vaughandroid
1
Ich finde diese Antwort unangenehm. "Beginnen Sie mit einer Story, um das einfachste Programm zu kompilieren, und erstellen Sie dann weitere Storys, um immer mehr Sprachfunktionen zu unterstützen." Aber es wird wahrscheinlich 6 Monate Arbeit erfordern, um ein Framework zu erstellen, bevor auch nur das kleinste Programm erstellt werden kann! Dies ist keine realistische Antwort, die die Verwendung eines agilen Ansatzes für ein Backend-System beschreibt.
Dan Nissenbaum
10

Natürlich ist Scrum nützlich. Es ist eine Methode, die zwei Dinge für Sie erledigt:

  1. Es ermöglicht Ihrem Projekt, sich an Veränderungen anzupassen und
  2. Sie können den Fortschritt verfolgen und sich einen Eindruck verschaffen, wann dieser abgeschlossen sein wird

Es hat also einen gewissen Wert, es zu benutzen.

Ich denke, einige deiner Voraussetzungen sind nicht korrekt und das ist der Punkt, an dem du dich verirrst.

Ich kann nicht erkennen, wie jede Story verhandelbar sein kann - sie werden alle für einen funktionierenden Compiler benötigt

Das ist nicht wahr. Sie können eine Teilmenge der Sprache unterstützen und haben dennoch einen Compiler, der unter bestimmten Bedingungen funktioniert. Sicher weniger wert als ein vollständiger Compiler, aber dennoch wertvoll.

Außerdem verstehen Sie falsch, was "verhandelbar" bedeutet: Es bedeutet nicht notwendigerweise "optional", und es gibt keine Anforderung, dass Storys in INVEST optional sind. Eine Geschichte ist ein wertvolles Ziel, und bei der Verhandlung geht es darum, wie dieses Ziel erreicht werden kann. Mit Sicherheit wird es mehr als nur Möglichkeiten geben, das Backend der einzelnen Sprachfunktionen zu implementieren. Dort müssen Sie verhandeln.

Die Geschichten haben alle die gleiche Priorität und es ist egal, in welcher Reihenfolge ich sie liefere.

Dies ist nicht richtig, da Sie unten sagen, dass einige Geschichten nicht "müssen", also sicherlich einige weniger wertvoll sind. Aber auch in der Kategorie "Muss": Einige Sprachmerkmale sind wesentlich grundlegender als andere, und das messbar.

Eine Möglichkeit, dies zu messen, besteht darin, "wie viel mehr Codezeilen auf einer vorhandenen Codebasis kompiliert werden können" oder "wie viele Tests bestehen", wenn Sie über eine vordefinierte Testsuite verfügen.

Es gibt auch andere Möglichkeiten. Wenn Sie eine C-ähnliche Sprache kompiliert haben, benötigen Sie streng genommen nur ein ifund eine gotoSchleife, um eine (kaum) funktionierende Sprache zu haben, die Sie implementieren können while, forund repeatals Makros. Vorausgesetzt, es ist einfach genug, einen Precompiler zu schreiben, können Sie eine billige Notlösung haben (Hey, verhandeln wir ?:-)

In Bezug auf Anpassungsfähigkeit ist die Unterstützung einer Sprache ein ziemlich statischer Satz von Anforderungen, aber Sprachen ändern sich auch, und auch Ihre Kenntnisse über Ihre Bedürfnisse ändern sich. Müssen Sie alles implementieren? Gibt es Dinge, die Sie nicht speziell für Ihre Ziele benötigen? Einer der Grundpfeiler von Agile ist das Wissen, unvollständiges Wissen zu haben. Können Sie es nutzen?

Um Ihre Frage noch direkter zu beantworten: Benötigen Sie agile Prozesse, wenn sich Ihre Anforderungen nicht ändern lassen? Definitiv nicht! Sind sie verwendbar? Wahrscheinlich ja! Sind sie deine Zeit wert? Wahrscheinlich nicht - aber sind Ihre Anforderungen unveränderlich? In meiner Vergangenheit waren "unveränderbare Anforderungen" => "fauler Produktbesitzer" - keine Regel, aber es lohnt sich, daran zu denken.

Sklivvz
quelle
3
+1 für " Dies ist nicht wahr. Sie können eine Teilmenge der Sprache unterstützen und haben dennoch einen Compiler, der unter bestimmten Bedingungen funktioniert. Sicher weniger wertvoll als ein vollständiger Compiler, aber dennoch wertvoll. " das Ende der Entwicklung.
Ross Patterson
2
Und "Eine Möglichkeit, dies zu messen, besteht darin," wie viel mehr Codezeilen auf einer vorhandenen Codebasis kompiliert werden können "oder" wie viele Tests bestehen ", wenn Sie über eine vordefinierte Testsuite verfügen." - Ich halte es für wichtig, Fortschritte vorweisen zu können.
Dave Hillier
+1, obwohl ein Punkt, den ich hier vermisse, ist, dass Anforderungen für einen Compiler auch "horizontal" geschnitten werden können, anstatt durch "Sprachfunktion X unterstützt". Der Compiler muss möglicherweise die Dinge optimieren (eigene Anforderung), gibt möglicherweise Debugging-Informationen aus (eigene Anforderung), erfüllt möglicherweise einige Leistungsanforderungen und so weiter.
Doc Brown
@DocBrown-Anforderungen können durchaus horizontal sein, aber Storys müssen vertikal sein.
Sklivvz
"Als Benutzer des Compilers möchte ich eingeben DavesCompiler -O9 program.c, und die Ausgabe sollte eine hochoptimierte Version von program.c sein (eine formalere Definition dessen, was hochoptimiert bedeutet, folgt)" - klingt für mich nach einer vernünftigen User Story.
Doc Brown
4

TL; DR

Alle Projektmanagement-Steuerelemente verursachen zusätzlichen Aufwand. Fügen Sie keine zusätzlichen Kosten hinzu, die Sie nicht benötigen.

Scrum ist der falsche Hammer hier (sei kein Nagel)

Scrum ist eher ein Projektmanagement-Framework als eine Reihe von Entwicklungsmethoden, die für einen einzelnen Entwickler geeignet sind. Wenn Sie kein Projektmanagement durchführen, ist Scrum wahrscheinlich die falsche Wahl.

Außerdem, wenn Sie sagen:

Die Geschichten haben alle die gleiche Priorität und es ist egal, in welcher Reihenfolge ich sie liefere. Ich muss sie alle machen.

Sie implizieren ein paar Dinge:

  1. Das Projekt hat den Wert Null, es sei denn, alle Geschichten sind zu 100% abgeschlossen.
  2. Die Geschichten sind nicht voneinander abhängig.

Wenn beide Aussagen zutreffen, macht es keinen Sinn, ein Framework oder eine Vorgehensweise zu verwenden, um die Arbeit nach Wert oder Abhängigkeitsreihenfolge zu priorisieren.

Vorgeschlagene Alternativen

Jedes Entwicklungsprojekt könnte möglicherweise von einigen agilen Praktiken profitieren. Insbesondere in Ihrem speziellen Fall würde ich empfehlen:

  1. Stellen Sie sicher, dass alle Ihre Geschichten eine "Definition von erledigt" haben, die Unit- und Akzeptanztests umfasst.
  2. Oft integrieren und umgestalten; Überlassen Sie sich am Ende des Projekts nicht einer riesigen Integrationsaufgabe.

Selbst wenn Ihr Produkt wirklich den Wert Null hat, wenn nicht alle Storys fertig sind, würde ich einige Zeit damit verbringen, die Storys in Themen zu gruppieren, die Sie als abgeschlossene Meilensteine ​​behandeln können. Die Aussage "Ich habe die Foo-Funktion abgeschlossen" ist oft nützlicher als die Aussage "Ich habe 23/117 zufällige Geschichten fertig". YMMV.

CodeGnome
quelle
1
Ich habe nicht behauptet, ein einzelner Entwickler zu sein.
Dave Hillier
@ DaveHillier "Ich habe eine vorhandene Sprache ... Ich werde dies wahrscheinlich versuchen, indem ... Ich plane, Scrum zu folgen." Nichts davon sagt etwas über Teams, andere Leute oder die Notwendigkeit eines formellen Projektmanagements aus. Selbst wenn 347 von Ihnen an dem Projekt arbeiten, ist die Antwort immer noch gültig, wenn Ihre Prämisse gültig ist. Wenn nicht, aktualisieren Sie Ihre Frage und ich werde mein Bestes tun, um die Antwort entsprechend zu aktualisieren.
CodeGnome
1
Niemand sonst hat eine solche Annahme gemacht. Ich stimme einigen Ihrer Ausführungen zu.
Dave Hillier
4
@ DaveHillier Ich habe Ihre Frage genauso gelesen wie CodeGnome, dass Sie ein Solo-Entwickler für dieses Projekt wären. Die Übernutzung von Istatt Weist wahrscheinlich der Grund.
Izkata
Falsches Werkzeug, kein falscher Hammer. Ein Hammer ist ein Hammer, nicht alle Probleme sind Nägel :-)
Sklivvz
2

Ich verstehe Ihre Bedenken, aber ich glaube, dass die Verwendung von Scrum für Sie immer noch von Nutzen ist.

Zugegeben, die User Stories sind viel fester als in einer Anwendung für Endverbraucher. Dieser Aspekt von Scrum bietet also weniger Wert.

Ich denke, Sie werden von den iterativen und häufigen Veröffentlichungen profitieren . Wenn Sie am Ende jedes Sprints ein potenziell abrufbares Produkt haben, müssen Sie die Codequalität hoch und die technische Verschuldung niedrig halten. Es ist auch eine gute Möglichkeit, Fehler frühzeitig zu finden.

Ich denke, Sie würden auch davon profitieren, wenn Sie Ihre Geschwindigkeit kennen . Nach mehreren Sprints können Sie sehen, wie viele Leistungspunkte Ihr Team bei jedem Sprint erzielt. Auf diese Weise erhalten Sie eine objektive Metrik zur Bestimmung Ihres Versanddatums.

Denken Sie vor allem daran, dass Agilität ein Adjektiv ist . Am Ende jedes Sprints sollten Sie eine Retrospektive abhalten und dann Ihren Prozess an Ihre Bedürfnisse anpassen. Wenn sich ein Teil des Scrum-Prozesses nicht auf die Compiler-Entwicklung bezieht, entfernen Sie ihn. Wenn Sie von einem anderen Prozesselement profitieren, fügen Sie es hinzu. Der wichtigste Teil von Agile ist meiner Meinung nach, sich Ihres Prozesses bewusst zu sein und sich für Ihre spezifische Situation ständig zu verbessern.

(Bitte beachten Sie, dass ich bei einem Compiler-Projekt noch nie Gedränge gemacht habe. Nehmen Sie meinen Rat mit einem Körnchen Salz.)

Epotter
quelle
0

Ja, solange Sie sich daran erinnern, dass Scrum keine strengen Regeln enthält, die befolgt werden müssen. Sie können es an Ihr Projekt anpassen. Sprints, Stand-ups und wöchentliche Scrums sind weiterhin nützlich, um eine bessere Kommunikation zwischen den Teammitgliedern zu fördern und sicherzustellen, dass das Projekt in der beabsichtigten Richtung fortgesetzt wird.

Alle Geschichten scheinen die gleiche Priorität zu haben, aber Sie müssen die relativen Schwierigkeiten bei der Implementierung berücksichtigen. Sie möchten Ihre schwierigsten Aufgaben erst am Ende des Projekts aufbewahren. Sie werden so schnell wie möglich mit der Arbeit beginnen wollen.

Mchl
quelle
Scrum is not a set of strict rules to follow- Ich dachte, es ist genau umgekehrt. Ist es nicht so, als hätte es nur ein paar Regeln, aber Sie müssen sich daran halten (z. B. Tägliche Aufstände, Definition des Geschehens, Story Points)?
Uooo
Befürworten Sie ScrumBut ?
Dave Hillier
@Uooo nur der erste der drei, die Sie erwähnen, ist Scrum, der Rest sind nur gute Praktiken, aber nicht unbedingt grundlegend.
Sklivvz
@Sklivvz Denken viele Projektmanager deshalb, "wir machen tägliche Stand-ups, also machen wir Scrum" ? Scrum ist mehr als nur tägliche Stand-ups.
Uooo
1
@Sklivvz okay, jetzt verstehe ich was du damit meinst :-) ich dachte du meintest nur standups zu machen ist schon scrum.
Uooo