Welchen Rahmen oder welche Methodik würden Sie einem Data Science-Team empfehlen?
Ich bin ein Scrum Master für ein Team von hauptsächlich Data Scientists und einigen Software Engineers und einem Product Owner.
Unsere Organisation hat entschieden, dass alle Teams in zweiwöchigen Sprints mit Scrum arbeiten. Ich persönlich glaube nicht, dass es funktioniert. Das Scrum-Framework funktioniert aus folgenden Gründen nicht wirklich für uns:
- Es ist sehr schwer abzuschätzen, da die Zahl der Unbekannten sehr groß ist. Zum Beispiel hätten Sie ein Backlog-Element, um ein Experiment durchzuführen. Die Ausgabe könnte und ist normalerweise so unterschiedlich. Die Ergebnisse des Experiments bestimmen buchstäblich Ihre Arbeit für die kommenden Tage.
- Selbst wenn Sie es schaffen, das Team dazu zu bringen, in Geschichten zu zerlegen, gibt es eine große Anzahl von Abhängigkeiten zwischen Geschichten. Es ist eher ein Flussdiagramm oder ein Entscheidungsbaum als eine Story Map.
- PO und SM sind keine Datenwissenschaftler, es ist unmöglich, wirklich mit dem Inhalt der Geschichten zu helfen.
- Das Sprint-Engagement wird aus den oben genannten Gründen fast nie beendet.
- Das Team kommuniziert nicht wie Ingenieure. Sie brauchen viel Zeit, um zu diskutieren und Hypothesen aufzustellen (dh es ist nicht das, wofür Scrum gedacht war), zumindest ist dies meine Erfahrung.
- Planungsbesprechungen werden aufgrund der unbekannten Art der Arbeit unhandlich.
Welchen Rahmen oder welche Methodik würden Sie einem Data Science-Team empfehlen?
Antworten
Es lohnt sich zu unterscheiden, was Scrum ist (wie im Scrum-Handbuch definiert ) und was im Volksmund mit Scrum assoziiert wird.
Zum Beispiel sind Story Points, Storys, Schätzungen, Geschwindigkeit usw. nicht Teil des Scrum Guide.
Das Team kommuniziert nicht wie Ingenieure. Sie brauchen viel Zeit, um zu diskutieren und Hypothesen aufzustellen (dh es ist nicht das, wofür Scrum gedacht war), zumindest ist dies meine Erfahrung.
Auch hier gibt es im Scrum Guide nichts, was besagt, dass Sie nicht viel Zeit damit verbringen, zu diskutieren und Hypothesen aufzustellen. Sie sprechen eher von Scrum-Konventionen als von dem, was das Framework tatsächlich sagt.
Ich habe mit Data Science-Teams zusammengearbeitet, die das Scrum-Framework verwendet haben, und sie haben viel Zeit damit verbracht, ihre Arbeit zu diskutieren.
Planungsbesprechungen werden aufgrund der unbekannten Art der Arbeit unhandlich.
Dann würde ich vorschlagen, dass Sie mehr Zeit für die Synchronisierung und weniger Zeit für die Planung aufwenden. Der Wert eines Frameworks wie Scrum besteht darin, einem Team zu helfen, kollaborativer zusammenzuarbeiten und sich bei Bedarf gegenseitig zu unterstützen.
Um Ihre Frage zu beantworten, können sowohl Scrum als auch Kanban dazu gebracht werden, mit Data Science-Teams zusammenzuarbeiten. Die Wahl des Frameworks hängt normalerweise von den Persönlichkeitstypen der Teammitglieder, der Art der Organisation und der Art der Domäne ab, in der Sie arbeiten.
Ich spekuliere, aber ich vermute, dass das Problem hier darin besteht, dass dem Team ein Ansatz auferlegt wird, anstatt die Kontrolle über ihre Arbeitsweise zu haben. Der Rückblick- und Inspektions- und Anpassungszyklus in Scrum soll es dem Team ermöglichen, die Arbeitsweise so lange zu optimieren, bis ein geeigneter Ansatz gefunden ist.
Kanban, dh verwalteter Flow anstelle von Sprints mit Zeitbox, ist aus genau den von Ihnen genannten Gründen für Forschungs- und Entdeckungsarbeiten sehr sinnvoll. Vielleicht könnten Sie noch die Metriken und Statusberichte erstellen, um Ihr Team gegenüber dem Management zur Rechenschaft zu ziehen, aber die Idee ist, sich auf Priorisierung und nachhaltige Bereitstellung zu konzentrieren, anstatt auf Schätzung und Iteration. Es sollte möglich sein, dafür ein gutes Argument zu liefern, wenn Sie die Art der von Ihnen erwähnten Probleme nachweisen können.
Stellen Sie außerdem sicher, dass Sie über eine effiziente Pipeline für die kontinuierliche Integration verfügen. Vorausgesetzt, Sie können so oft wie nötig veröffentlichen, gewinnt jeder, wenn er nicht alle seine Erwartungen in Schritten von ein oder zwei Wochen festlegen muss.
Wenn es viele „Hypothesen“ und Treffen ohne festen Zeitrahmen gibt, geht es eher darum, dass der Umfang der Arbeiten noch nicht klar geklärt ist. Wenn der Umfang zementiert und der Zeitplan vorbereitet ist, aber neue Anforderungen kommen oder sich ändern oder Besprechungen verzögert werden, arbeiten wir nur an dem bereits vereinbarten Umfang weiter und heben die Verzögerungen für den Kunden mit Optionen für einen Kompromiss hervor, wenn er Prioritäten setzen möchte ein Merkmal zugunsten eines anderen.
Sie können das SAFe-Framework ausprobieren (https://www.scaledagileframework.com/# und https://www.guru99.com/scaled-agile-framework.html) - Ich kann es zusätzlich zu den zuvor erwähnten anderen Antwortenden hervorheben. Von vielen Rednern auf Fachkonferenzen in Russland wurde dieser Rahmen mehrfach als „Labor“ hervorgehoben (dieser Begriff wird verwendet, um ein mittelgroßes oder großes Team zu benennen, das sich auf die Produktentwicklung in noch nicht bekannten Bereichen konzentriert als wir). Episch -> Feature -> User Story Flow. Wie Sie bereits erwähnt haben, ist "Ihre Bestellung kein Experte auf diesem Gebiet" und es gibt "eine große Anzahl von Abhängigkeiten zwischen den Geschichten". Es ist eher ein Flussdiagramm oder ein Entscheidungsbaum, dann eine Story Map. Ich fand, dass SAFe möglicherweise für die Verwendung geeignet ist, da es Features und Feature-Eigentümer hat, die persönlich für den E2E-Wert verantwortlich sind, auf den sich die Leute verlassen, die Experten sind Bereich und kann Geschäftswert + Code liefern.
Die Zerlegung in SAFe lautet: Episch -> Architektonisches Sub-Epos (dann Aufteilung in ein oder mehrere Features, die in Stories aufgeteilt sind, die wiederum in Aufgaben unterteilt sind) plus Business-Sub-Epic (dann Aufschlüsselung in ein Feature ( s), die in Geschichten aufgeteilt sind, die wiederum in Aufgaben aufgeteilt sind).
Meine persönliche Erfahrung (Business Analyst bei einem großen Unternehmensprojekt, bei dem wir in einer der Phasen einen SAFe-ähnlichen funktionsbasierten Ansatz verwendet haben, um uns auf die Bereitstellung von Geschäftswert für einige wenige, aber szenariengeladene Themen zu konzentrieren). Feature gehört dem Geschäftsanalysten, dessen Produktkomponente am stärksten betroffen ist (auch bekannt als "Geschäftsinhaber" - verantwortlich für E2E und speziell für den Geschäftswert), und der Entwicklungsleiter (auch bekannt als "technischer Eigentümer" - koordiniert die Entwicklung aller Storys, dh E2E innerhalb des Features). Während "Geschäftsinhaber" von den Implementierungsergebnissen des "technischen Eigentümers" abhängig ist, ist "Geschäft" ohnehin das wichtigste.wie er es dem Kunden schließlich demonstriert (extern oder intern insgesamt Product Owner - wie in Ihrem Fall) und das Feedback sammelt.Business Stories unter dem Feature , jeder gehört dem Business Analyst (verantwortlich für ein bestimmtes Szenario, dh Funktionalität gemäß Feature-Zerlegung). Sobald Geschäftsgeschichten beschrieben sind und ein sichtbares E2E oder ein fester Teil davon vorhanden ist, wird der Auftakt für den Eigentümer / das Team der technischen Geschichte arrangiert. Technische Geschichten unter dem FeatureJeder von ihnen gehört dem Entwickler (verantwortlich für ein bestimmtes Szenario, dh die Funktionalität gemäß der Feature-Zerlegung). Um die Berichterstellung zu vereinfachen, spiegelte das DEV-Team Technical Feature-> Technical Stories und behielt die Links zur ID von Business Story bei (über die gesprochen wird) JIRA). Sobald technische Storys implementiert sind und ein E2E oder ein fester Teil davon sichtbar ist, wird DEMO for Business Story Owner / Team arrangiert. Ich habe Epics nicht hervorgehoben, da in diesem Ansatz das 'Feature' ein relevanterer Begriff war. Kurzum: PROS: persönliches Engagement und persönliche Verantwortung. Nachteile: Aufwand für die Überwachung technischer Aufgaben für einen nichttechnischen „Geschäftsinhaber“.