Quel cadre ou quelle méthodologie recommanderiez-vous pour une équipe de science des données?
Je suis Scrum Master pour une équipe composée principalement de Data Scientists et de quelques Software Engineers et d'un Product Owner.
Notre organisation a décidé que toutes les équipes travaillent en sprints de 2 semaines en utilisant Scrum. Personnellement, je ne pense pas que cela fonctionne. Le framework Scrum ne fonctionne pas vraiment pour nous pour les raisons suivantes:
- C'est très difficile à estimer car le niveau d'inconnues est énorme. Par exemple, vous auriez un élément de backlog pour exécuter une expérience, la sortie pourrait et est généralement si variée. Le résultat de l'expérience guide littéralement votre travail pour les jours à venir.
- Même si vous parvenez à amener l'équipe à se décomposer en histoires, il existe un grand nombre de dépendances entre les histoires. Cela ressemble plus à un organigramme ou à un arbre de décision, puis à une Story Map.
- Le PO et le SM ne sont pas des data scientists, il est impossible de vraiment aider avec le contenu des histoires.
- L'engagement de sprint n'est presque jamais terminé pour les raisons ci-dessus.
- L'équipe ne communique pas de la même manière que les ingénieurs. Ils ont besoin de beaucoup de temps pour discuter et émettre des hypothèses (c'est-à-dire que ce n'est pas ce à quoi Scrum était destiné), du moins c'est mon expérience.
- Les réunions de planification deviennent lourdes en raison de la nature inconnue du travail.
Quel cadre ou quelle méthodologie recommanderiez-vous pour une équipe de science des données?
Réponses
Il vaut la peine de faire la différence entre ce qu'est Scrum (tel que défini par le Guide Scrum ) et ce qui est populairement associé à Scrum.
Par exemple, les points d'histoire, les histoires, l'estimation, la vélocité, etc. ne font pas partie du Guide Scrum.
L'équipe ne communique pas de la même manière que les ingénieurs. Ils ont besoin de beaucoup de temps pour discuter et émettre des hypothèses (c'est-à-dire que ce n'est pas ce à quoi Scrum était destiné), du moins c'est mon expérience.
Encore une fois, il n'y a rien dans le Guide Scrum qui indique que vous ne passez pas beaucoup de temps à discuter et à émettre des hypothèses. Vous parlez des conventions Scrum plutôt que de ce que dit réellement le cadre.
J'ai travaillé avec des équipes de science des données qui utilisaient le framework Scrum et elles ont passé énormément de temps à discuter de leur travail.
Les réunions de planification deviennent lourdes en raison de la nature inconnue du travail.
Ensuite, je vous suggère de passer plus de temps à synchroniser et moins de temps à planifier. La valeur d'un framework comme Scrum est d'aider une équipe à travailler ensemble de manière plus collaborative, en se soutenant mutuellement si nécessaire.
Pour répondre à votre question, Scrum et Kanban peuvent être conçus pour fonctionner avec des équipes de science des données. Le choix du cadre se résume généralement aux types de personnalité des membres de l'équipe, à la nature de l'organisation et au type de domaine dans lequel vous travaillez.
Je spécule, mais je soupçonne que le problème ici est que l'équipe se voit imposer une approche plutôt que de contrôler la façon dont elle travaille. Les rétrospectives et le cycle d'inspection et d'adaptation dans Scrum sont destinés à permettre à l'équipe d'ajuster leur façon de travailler jusqu'à ce qu'ils trouvent une approche appropriée.
Kanban, c'est-à-dire un flux géré plutôt que des sprints temporisés, a beaucoup de sens pour les travaux de recherche et de découverte pour exactement les raisons que vous avez mentionnées. Vous pourriez peut-être encore produire les métriques et les rapports d'état pour que votre équipe soit responsable devant la direction, mais l'idée est de se concentrer sur la priorisation et la livraison durable plutôt que sur l'estimation et l'itération. Il devrait être possible de faire une bonne cause pour cela si vous pouvez mettre en évidence le type de problèmes que vous mentionnez.
Assurez-vous également de disposer d'un pipeline d'intégration continue efficace. À condition que vous puissiez publier aussi souvent que nécessaire, tout le monde y gagne s'il n'a pas à définir toutes ses attentes sur une ou deux semaines.
S'il y a beaucoup d '«hypothèses» et de réunions sans délais fixes, c'est plutôt que la portée des travaux n'est pas encore clairement clarifiée. Lorsque la portée est cimentée et que le calendrier est préparé, mais que de nouvelles exigences arrivent ou changent ou que les réunions sont retardées - nous ne travaillons que sur la portée déjà convenue, en soulignant les retards pour le client avec des options de compromis, s'il veut déprioriser une caractéristique en faveur d'une autre.
Vous pouvez essayer le framework SAFe (https://www.scaledagileframework.com/# et https://www.guru99.com/scaled-agile-framework.html) - Je peux le souligner en plus de ce que d'autres intervenants ont mentionné auparavant. De nombreux orateurs lors de conférences professionnelles organisées en Russie, ce cadre a été souligné à plusieurs reprises comme utilisé en `` laboratoire '' (ce terme est utilisé pour désigner une équipe de taille moyenne ou grande, axée sur le développement de produits dans un domaine encore inconnu. comme nous). Epic -> Fonctionnalité -> Flux de récit utilisateur. Comme vous l'avez mentionné, «votre PO n'est pas un expert dans le domaine» et qu'il existe «un grand nombre de dépendances entre les histoires. Cela ressemble plus à un organigramme ou à un arbre de décision, puis à une Story Map '', j'ai trouvé que SAFe pouvait être utilisé car il a des fonctionnalités et des propriétaires de fonctionnalités, qui deviennent personnellement responsables de la valeur E2E, dont les gars sur lesquels ils comptent sont des experts en la matière. zone et peut fournir une valeur commerciale + code.
La décomposition dans SAFe est la suivante: Epic -> Sous-épopée architecturale (puis ventilation en une ou plusieurs fonctionnalités, qui sont divisées en histoires, qui sont divisées en tâches à leur tour) plus sous-épopée commerciale (puis ventilation en une fonctionnalité ( s), qui sont divisés en histoires, qui sont à leur tour divisées en tâches).
Mon expérience personnelle (analyste commercial sur un grand projet d'entreprise, où, pour l'une de ses phases, nous avons utilisé une approche basée sur les fonctionnalités de type SAFe afin de nous concentrer sur la fourniture de valeur commerciale pour quelques sujets, mais chargés de scénarios). Feature , appartient à l'analyste commercial dont le composant du produit est le plus impacté (alias `` propriétaire de l'entreprise '' - responsable d'E2E et de la valeur commerciale en particulier) plus le responsable du développement (alias `` propriétaire technique '' - orchestre le développement de toutes les histoires, c'est-à-dire E2E dans la fonction). Pendant ce temps, le `` propriétaire de l'entreprise '' dépend des résultats de la mise en œuvre appartenant au `` propriétaire technique '', `` entreprise '' est de toute façon le principal,comme il le démontre enfin au client (en externe ou en interne, comme dans votre cas) et recueille les commentaires.Business Stories sous la fonctionnalité , chacun est la propriété de l'analyste commercial (responsable d'un scénario particulier, c'est-à-dire des fonctionnalités en fonction de la décomposition des fonctionnalités). Une fois que les histoires commerciales sont décrites et qu'il y a un E2E visible ou une partie solide de celui-ci, le coup d'envoi pour le propriétaire / l'équipe de l'histoire technique est organisé. Histoires techniques sous la fonction, chacun est détenu par le responsable du développement (responsable du scénario particulier, c'est-à-dire des fonctionnalités en fonction de la décomposition des fonctionnalités) - afin de simplifier le reporting, l'équipe DEV a mis en miroir la fonctionnalité technique-> Technical Stories, en conservant les liens vers l'ID de Business Story (en parlant de JIRA). Une fois que les histoires techniques sont implémentées et qu'il y a un E2E visible ou une partie solide de celui-ci - DEMO for Business Story Owner / team est organisé. Je n'ai pas mis en évidence Epics car dans cette approche, le terme `` fonctionnalité '' était un terme plus pertinent. En bref: AVANTAGES: implication personnelle et responsabilité personnelle. INCONVÉNIENTS: frais généraux pour garder un œil sur les tâches techniques d'un «propriétaire d'entreprise» non technique.