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

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?

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!

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.

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.

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.)

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.