L'agilité dans un projet Data Science

Les “méthodes” Agiles sont plébiscitées dans les projets de développement logiciel. Scrum est le cadre Agile le plus utilisé, dans près de 60% des cas, et ses avantages sont nombreux :

• Livraisons fréquentes et régulières de fonctionnalités utilisables
• Une mise sur le marché plus rapide, itérative et donc des retours clients réguliers.
• En conséquence, un produit répondant aux besoins du client ; et la liste est loin d’être exhaustive !

Pour rappel, un projet Scrum se décompose en itérations – appelées Sprints – d’une durée de 4 semaines ou moins. L’équipe Scrum est composée de 3 rôles qui interviennent de façon permanente et collaborent ensemble :

• Le Product Owner est la voix du client/utilisateur et va traduire le besoin client de façon à ce qu’il soit compris par l’équipe de développement, au travers de Users Stories.
• L’équipe de développement est composée de 3 à 9 personnes dont l’ensemble des compétences permettent de transformer les User stories en résultat potentiellement livrable au client.
• Le Scrum Master maitrise le cadre Scrum et s’assure que l’équipe Scrum comprend, connaît et applique le cadre. Il est tour à tour formateur, coach et bien plus encore !

Les étapes d’un projet Data Science

Un projet Data Science ne se gère pas de la même façon qu’un projet logiciel, le premier étant de nature très exploratoire, et ses étapes sont bien spécifiques :

Etape 1: Définition de la problématique Business

Comme dans tout projet, il s’agit de répondre aux questions suivantes: Quels sont les besoins du client? Quelles problématiques souhaite-t-il résoudre ? Quelles sont les priorités ? Peuvent-elles être résolues grâce à la data ? L’enjeu de cette phase, quelle que soit la méthode, est de s’assurer que le métier exprime clairement son besoin et que celui-ci est compris par les équipes Data. 

Etape 2: La collecte de données

Cette étape est à la fois critique et déterminante pour la suite du projet. Certains projets peuvent s’arrêter là si l’on constate que la data dont nous disposons ne nous permet pas de répondre à la problématique, voire si la Data dont nous avons besoin est inexistante. Se posent aussi les questions d’accessibilité de la data et de respect du RGPD car une data existante ne signifie pas toujours qu’elle sera exploitable.

Etape 3: Le nettoyage de la donnée

Il s’agit là de l’étape la plus chronophage du projet ! Elle va nécessiter de nombreux allers-retours entre l’équipe Data et le métier afin de comprendre la donnée. La méthode Agile est donc totalement adaptée ici. En effet, une compréhension mauvaise ou partielle résulterait en une analyse biaisée. Aussi, à l’ère de la Big Data, nous devons faire face à une volumétrie de données toujours plus conséquente. Les données sont souvent incomplètes ; non normées (une donnée identique sous différents formats, par exemple: France, FR) ; obsolètes; en doublons. Il convient donc d’être attentif et rigoureux si l’on veut obtenir une donnée “propre” et exploitable.

Etape 4: Exploration

En possession d’un jeu de données harmonisé et correctement mis en forme, le Data Scientist va pouvoir débuter l’analyse. Là encore, il est difficile de prédire quel sera le résultat, ni même si le résultat sera satisfaisant. Mais on obtient à ce stade un premier aperçu.

Etape 5: Création de la solution Data Science

La création de la solution peut commencer si l’exploration a donné des résultats suffisamment concluants. Il est primordial que le Data Scientist ait toujours en tête la problématique métier de départ afin de créer l’algorithme qui y répondra au mieux et maximisera le retour sur investissement.

Etape 6: Déploiement

La phase de déploiement ou mise en production est le moment où les clients prennent possession de l’outil qui a été développé afin qu’il soit utilisé.

Quel est l’intérêt de mener un projet de Data Science selon la méthodologie Scrum ?

Les limites des méthodologies “classiques”

Dans un projet géré en “cascade” ou en “cycle en V”, chacune des étapes ne démarre que lorsque la précédente est aboutie. Il peut arriver alors que le temps imparti ou le budget du projet soit consommé en quasi-totalité avant les dernières étapes, obligeant soit de précipiter ces dernières soit d’augmenter le budget initial du projet. 

Avant de procéder au déploiement, c’est-à-dire à la livraison aux utilisateurs, l’équipe projet a effectué des tests techniques et un échantillon d’utilisateurs a fait des tests fonctionnels. Si les résultats sont satisfaisants, le produit peut être déployé auprès de l’ensemble des utilisateurs. 

Après le déploiement, dans le cadre de projets gérés en cascade, on observe très souvent que :

• Les utilisateurs ne sont pas formés à l’utilisation du produit
• Parmi celles qui ont été développées, seules un faible nombre de fonctionnalités vont être utilisées, alors que d’autres fonctionnalités manquantes étaient attendues.

Pourquoi un tel résultat ? Dans un projet en cascade, l’étape de récolte du besoin a lieu une seule fois. Elle se doit donc d’être exhaustive et peut donc durer quelques semaines ou plusieurs mois. Le client est donc fortement impliqué à ce moment-là, puis quelques mois après, au moment des tests fonctionnels…une fois le produit développé dans son intégralité ! Il n’y a donc quasiment aucune marge de manœuvre dans le cas où le produit n’est pas satisfaisant !

L’intérêt de l’approche Agile

C’est pour pallier à cela que les “fondateurs” des méthodes Agiles ont souhaité remettre le client au centre du projet afin d’en assurer la satisfaction. Les 4 valeurs du Manifeste Agile le démontrent:

• Les individus et leurs interactions plus que les outils et les processus.
• Des produits opérationnels plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation contractuelle.
• L’adaptation au changement plus que le suivi d’un plan.

Aussi, l’approche Scrum permet de « paralléliser » plusieurs des 5 étapes vues ci-dessus lors d’un seul Sprint. Ce ne sont donc plus des mois qui séparent la phase de récolte des besoins de la phase de déploiement. Tout au plus 4 semaines s’écoulent entre le Sprint Planning durant lequel les besoins des clients sont abordés et la Sprint Review durant laquelle ce qui a été produit est inspecté, par ces mêmes clients.

C’est l’ensemble de l’équipe de développement qui échange avec le Product Owner lors du Sprint Planning et c’est l’ensemble de l’équipe de développement qui reçoit du feedback de la part des clients/utilisateurs lors des Sprint Reviews ! Et ce, à chaque itération !

Avec Scrum, les investigations vont démarrer dès lors que l’on aura identifié un besoin même de façon sommaire. Le Product Owner commence à récolter les premières informations concernant le besoin client. Il  l’exprime aux Data Scientists au travers de “Users Stories” et d’échanges quotidiens. En parallèle les Data Scientists commencent à “préparer le terrain”: identification des outils où la donnée est stockée, demande d’accès aux différents outils et bases de données, collecte et exploration de la donnée afin de pouvoir commencer à identifier la façon dont il va l’utiliser pour arriver au résultat attendu.

Aussi, si une des demandes est impossible à satisfaire, on va s’en apercevoir très rapidement. Le projet peut alors être réorienté dès le début du sprint suivant. Le rôle du Product Owner est de récolter et prioriser les demandes des utilisateurs pendant que l’équipe de développement s’affaire à répondre aux premiers besoins. L’approche itérative de Scrum, permet de commencer à aller plus loin que la seule récolte du besoin client, afin de découvrir rapidement et régulièrement si le projet est sur la bonne voie.

Dans le cas où les données (ou un échantillon) sont disponibles et exploitables en l’état, la phase d’exploration peut démarrer dès le premier Sprint! Avec l’approche Scrum, nous pouvons obtenir des premiers résultats dès les premiers Sprints. Ceux-ci ne sont pas définitifs mais ils permettent de valider la piste suivie afin de continuer ou de l’invalider afin de changer de stratégie. 

Bien sûr, selon la complexité du modèle à produire, celui-ci pourra être livré à l’issu d’un ou de plusieurs sprints. Cependant l’idée est de rapidement fournir un premier résultat qui pourra être utilisé par le client; ce premier résultat est appelé un MVP  (Minimum Valuable Product). Le client peut alors en retirer les premiers bénéfices et apporter des feedbacks qui permettent à l’équipe d’améliorer/compléter le modèle lors des sprints suivants. 

Chaque itération est donc l’occasion pour le client d’affiner, de préciser son besoin, de le prioriser en fonction de ce qui lui apporte le plus de valeur ajoutée. Pour l’équipe Scrum, chaque itération est l’occasion d’améliorer sa compréhension du besoin client afin de lui apporter la meilleure solution possible.

Si à l’issu d’un sprint, ce qui a été produit ne donne pas satisfaction, la Sprint review permet de le détecter…au bout de 4 semaines maximum! Il est alors tout à fait possible de réorienter le sprint suivant, forts de nouveaux feedbacks récoltés.

Conclusion

Dans un projet Scrum, si les résultats ne sont pas satisfaisants, c’est tout au plus au bout de 4 semaines que l’on s’en aperçoit et l’on peut réorienter le projet dès le sprint suivant. Si le résultat du sprint est satisfaisant, les utilisateurs peuvent en bénéficier. Le projet n’est pas terminé, des demandes d’améliorations et de nouvelles fonctionnalités sont faites au fil de l’eau…, alors que le développement de fonctionnalités supplémentaires se trouve dans les différentes phases précédentes. 

Vous l’aurez compris, chacune des 6 phases vues précédemment seront abordées et répétées dans chacun des sprints afin de produire un résultat partiel mais potentiellement utilisable ! Mais il est probable que les premiers sprints ne puissent donner de résultats, le temps que la donnée soit mise à disposition.

Du point de vue du client/utilisateur, Scrum lui permet de s’assurer de façon régulière que son besoin a été compris, au travers de démonstrations et de livraisons régulières. Ces livraisons régulières lui permettent de bénéficier des résultats du projet dès les premières itérations, dès lors que les premières fonctionnalités sont mises en service. Le projet dans sa globalité ne lui coûte pas moins cher, mais à budget équivalent, le produit répond beaucoup plus à ses attentes. Aussi, les utilisateurs bénéficient d’une prise en main du produit régulière.

Du point de vue du Data Scientist, l’avantage est qu’il va pouvoir explorer, tester plusieurs approches, outils… Chaque projet est donc l’occasion pour lui de découvrir un nouvel outil et d’acquérir de nouvelles connaissances et compétences, et donc de proposer des solutions toujours plus innovantes. De plus, le fonctionnement par Sprint permet d’avoir une meilleure visibilité et un meilleur cadrage des actions à effectuer.

Enfin, il serait utopique de penser que le cadre Scrum offre une formule magique pour réussir tout projet! Le projet ne peut réussir que si l’ensemble du cadre Scrum est respecté et si les principes et valeurs de l’Agilité sont comprises et incarnées par les acteurs du projet. Le Scrum Master est là pour accompagner l’équipe dans cette direction, chaque Sprint étant l’occasion de s’améliorer !

So let’s be Agile !