Cet article présente les avantages de la méthode Agile Scrum dans les projets de développement logiciel et de data science, soulignant des livraisons fréquentes, des retours clients réguliers, une adaptation au changement. Il décrit comment Scrum, avec son approche itérative, favorise l’exploration continue, place le client au centre, offre visibilité et stimule l’innovation.
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 :
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 :
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 :
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.
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.
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.
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.
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.
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é.
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 :
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 !
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:
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.
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 !
