Ich arbeite in einem kleinen (4-6) Team an einem Projekt, bei dem es darum geht, ein maschinelles Lernmodell zu erstellen, um den Ausgang von Sportspielen in Echtzeit vorherzusagen. Dazu gehört auch das Scraping der Daten und das Speichern in einer Datenbank, damit wir Vorhersagen in Echtzeit treffen können. Wir werden auch eine einfache Website erstellen, um diese Daten anzuzeigen. Der Kunde hat derzeit seinen eigenen populären Sportblog, also plant er, dass die Website, die wir erstellen, entweder eine Ergänzung (wahrscheinlich nur ein weiterer Tab) zu seiner Website oder eine komplett separate Website sein soll - der Kunde hat nicht angegeben, was, da es wahrscheinlich ist hängt von der Qualität unserer Vorhersagen ab.
Wenn man den benutzerorientierten Aspekt der Website für den Moment außer Acht lässt (da die Website definitiv agil gemacht werden kann), könnte der technische Aspekt allein Monate dauern. Ist es angesichts einer hochgradig technischen Aufgabe wie dieser möglich, agil zu arbeiten? Es scheint nicht so, als wäre es für den Stakeholder oder die Benutzer nützlich, die technische Arbeit zu demonstrieren, die in jedem Sprint geleistet wird, und ich weiß nicht, was/ob sich die Anforderungen ändern könnten. Ist diese Aufgabe besser für Wasserfall geeignet oder gibt es eine Möglichkeit, agil zu sein?
Alles in Ihrer Frage deutet darauf hin, dass Sie ein neues Problem untersuchen und nicht einfach etwas erstellen, von dem Sie bereits genau wissen, wie es erstellt wird. Da Wasserfall Sie auffordert, Ihr Design vollständig zu erstellen, bevor Sie mit dem Bau beginnen, wäre die Verwendung von Wasserfall von Natur aus problematisch.
In Agile und insbesondere Scrum besteht das Ziel, ein Produktinkrement zu erstellen und es den Benutzern vorzulegen, darin, zu lernen, ob Sie das Richtige tun. Es ist ein Framework, das für komplexe adaptive Probleme entwickelt wurde und perfekt zu Ihrer Situation passt.
Ich weiß nicht viel über Ihr Projekt, aber es hört sich so an, als ob der primäre Erfolgsmaßstab die Qualität der Vorhersagen sein wird. Also würde ich für Sie fragen, wer das beurteilen wird und wer daran interessiert ist und diese Person ist der wichtigste Beteiligte an Ihrer Bewertung (oder Personen). Ich würde erwarten, dass Ihre Sprintziele und Ihre Backlog-Elemente geringer sind
Als [Benutzer] möchte ich in der Lage sein, auf X zu klicken und Y zu sehen
und mehr
Als [Benutzer] möchte ich, dass der Algorithmus die bisherigen Empfangsstatistiken des Spielers nach Quartal berücksichtigt, damit er die Ermüdung im späten Spiel in der Vorhersage berücksichtigt
In jedem Sprint möchten Sie sich ansehen, wie Sie die Qualität der Vorhersagen verbessert haben und was die richtige nächste Arbeit ist, um sie zu verbessern. Über die Benutzeroberfläche würde ich mir nicht allzu viele Gedanken machen. Mein persönlicher Ansatz wäre es, gleich im ersten Sprint eine einfache Schnittstelle aus dem Weg zu räumen, die mit einem dummen Algorithmus unterstützt wird (es kann zunächst ein Münzwurf sein, um alles, was darauf ankommt), und dann produziert diese Schnittstelle einfach immer besser Informationen, während Sie gehen. Allerdings könnte man argumentieren, dass die Schnittstelle so unwichtig ist, dass Ihr Benutzer sich nicht darum kümmert und Sie sich auf absehbare Zeit nicht einmal darum kümmern. Meine Vermutung ist, dass, wenn Sie Vorhersagen mit einem hohen Maß an Genauigkeit treffen können, es für alle Ihre Benutzersorgen in eine Textdatei ausgegeben werden kann.
Agile Ansätze beinhalten validiertes Lernen . Wikipedia definiert die Schritte des validierten Lernens wie folgt:
Dies passt tatsächlich sehr gut zu einem iterativen Entwicklungsmodell wie Scrum und ist in die Standardereignisse des Frameworks wie Sprint-Planung und Sprint-Review integriert.
Es ist wahrscheinlich, dass Sie Probleme haben, weil Ihr Team nicht alle der folgenden Punkte erfüllt:
Der Scrum-Leitfaden legt einen soliden Rahmen dafür fest, und moderne Praktiken zur Backlog-Verfeinerung werden in Büchern wie Angewandte Benutzergeschichten behandelt , und die Verwendung eines Minimum Viable Product (MVP) wird in Büchern wie The Lean Startup behandelt .
Kein einzelnes Buch wird Ihnen alle Antworten geben, die Sie benötigen, und diese Website ist kein Buchempfehlungsdienst. Trotzdem sollte dies Sie in die richtige Richtung weisen.
Wenn Sie in der Zwischenzeit konkrete Fragen dazu haben, wie Sie eine bestimmte User Story aufteilen oder zerlegen können, können Sie diese gerne als separate (und detaillierte!) Frage stellen, wenn Sie eine pragmatischere Antwort auf einen bestimmten Aspekt Ihrer benötigen Herausforderung des Teams.
Ich fand den Kanban-Ansatz wesentlich einfacher zu verwenden als Scrum in einem F&E-Projekt (habe Scrum zuvor 5 Jahre lang erfolgreich in anderen Projekten eingesetzt). Und es funktioniert, wenn wir auch kein einzelnes Stück UI haben. Sie können demonstrieren, was Sie können, wie Sie können (Sie können den BDD-Testbericht oder andere Berichte verwenden), wann immer Sie ein Produktinkrement (Meilenstein) haben. Wenn der größte Teil Ihrer Arbeit Tech-Spikes sind (zumindest am Anfang wird dies in einem ML-Projekt der Fall sein), konzentrieren Sie sich auf Ziele, begrenzen Sie die laufenden Arbeiten und terminieren Sie die Spikes (z. B. überprüfen Sie den Ansatz nach 2 Tagen Analyse und Initialisierung Mühe, nicht in ein Kaninchenloch zu tauchen)
Nathan Cooper
Erik