Accompagnant plusieurs projets de data science, je crée ce sujet pour partager les connaissances et expériences.
Les projets que je suis combinent le développement, en front end, d’une web app et, en back end, en plus des composants de la web app, d’un modèle data science d’aide à la décision dont les résultats s’intègrent dans la web app.
Les équipes sont réparties sur plusieurs sites. En pratique on a donc pour ces projets deux sous-équipes de développement: celle de la web app et celle du modèle data science. Pour garder l’esprit agile d’une seule scrum team, on a mis en place une organisation spécifique; n’hésitez pas à me contacter pour en savoir plus.
Avez-vous de l’expérience dans ce genre de projets? Quels outils collaboratifs en ligne employez-vous? Si vous utilisez Jira, savez-vous comment gérer l’évolution des story points de chacube des deux sous-équipes qui sont sur le même Jira?
En parallèle à ces projets je suis en train de monter un groupe d’entreprises pour échanger les bonnes pratiques sur la gestion agile des projets data science. Si cela vous intéresse, j’ai hâte d’être en contact avec vous!
Au plaisir d’avoir vos retours inspirants,
Vincent.
PS: c’est mon premier message sur la plateforme donc merci d’avance pour votre bienveillance dans le cas où je suis maladroit dans la gestion de ce sujet au sein de la communauté!
Tout d’abord, bienvenue.
Ensuite, je serais intéressé d’en parler, l’organisation de la data est tellement intéressante !
Il existe pas mal de modèles, j’aime bien par exemple la data mesh architecture, et d’avoir une équipe stream-aligned façon Team Topologies en mode Data as a Product, avec un produit en self service pour le reste des équipes.
Mon point de vue :
Ne pas utiliser les story points pour la data. C’est déjà pas une idée incroyable avec le développement (il y a de biens meilleures manières de rendre prédictible le delivery… Lead time par exemple), mais alors pour une équipe data ça va être terrible.
Le delivery c’est de la R&D, mais la data, c’est de la recherche pure (je suis algorithmicien de formation, et mon opinion c’est qu’estimer de la recherche est une aberration)
Je mettrais rapidement en place un VSM, Value Stream Mapping, pour voir le flux de valeur entre les deux sous équipes (si on parle de sous équipes, c’est qu’il y a deux équipes de toute façon ) et permettre aux personnes de s’organiser entre eux.
Je nuancerais juste un peu le propos : au sujet de la R&D, l’articulation est souvent passé sous silence dans Scrum en espérant qu’auto-magiquement, ce qu’on va délivrer sera assez pour Driver l’architecture de la solution, de la même manière que beaucoup de pratiquants du TDD pensent qu’une solution incrémentale est suffisante pour créer l’architecture d’un produit complexe voir chaotique. « Careful and deliberate thinking »…
) et permettre aux personnes de s’organiser entre eux.