Un Manifeste pour une Data Science Agile

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Russell Jurney @rjurney Data Syndrome
Source : A manifesto for Agile data science
Date : 23/10/2017


Traducteur : Fabrice Aimetti
Date : 10/04/2020


Traduction :

Appliquer des méthodes de développement Agile de logiciels à des projets de data science (science des données).

Fractal-1832620 1920 crop.jpg
Spirale fractale (source: Pixabay)

Découvrez Agile Data Science 2.0 pour explorer en profondeur la théorie et la pratique de la data science Agile.

Agile-data-science-20-book.jpeg

À titre personnel, je pratique la data science Agile, le développement itératif et évolutif d'applications analytiques, depuis une dizaine d'années, bien avant que je ne sache comment l'appeler. En tant que développeur solitaire, il était naturel de faire évoluer de manière itérative le logiciel d'analyse que j'avais construit. Lorsque j'ai rejoint une équipe, je m'attendais à ce que les choses fonctionnent de cette manière. Ce n'était pas le cas.

J'avais été exposé aux méthodes Agiles en tant que développeur web, j'ai donc été surpris, lorsque j'ai commencé mon premier emploi de data scientist, de constater que la data science n'était pas Agile. Dans les semaines qui ont suivi mon arrivée, j'ai dû spécifier un système prédictif complexe que j'ai ensuite confié à quelqu'un d'autre qui a eu besoin de six mois pour le construire avant qu'il ne soit livré. Cela contrevenait à tout ce que je savais sur la façon de construire un logiciel, mais la dimension du système et la qualité des outils de big data rendaient cela nécessaire. Le projet a failli échouer et a été sauvé à la dernière minute. J'ai perdu beaucoup d'heures de sommeil et j'en ai retiré d'importantes leçons.

Je n'ai jamais voulu revivre cela. J'ai donc essayé d'imposer l'Agile à la data science, avec plus ou moins de succès. Lorsque j'ai commencé à appliquer des méthodes de développement Agile de logiciels à la data science, j'ai vu un modèle émerger. La difficulté ne résidait pas dans les détails de la mise en oeuvre, mais dans la manière de penser aux possibilités offertes par l'Agile lorsque l'on travaille avec des données en plus du logiciel.

Alors que mes expériences au sein de plusieurs entreprises commençaient à échafauder ma pensée, j'ai élaboré le Manifeste pour une Data Science Agile. Ce manifeste se concentre sur la façon de penser, plutôt que sur ce qu'il faut faire. Les spécificités du Kanban ou du Scrum fonctionnent pour la data science, tant que l'équipe pense de manière dynamique en réponse aux opportunités qui émergent de l'exploration des données. John Akred a fait un travail intéressant sur les spécificités de la mise en oeuvre de la data science Agile, mais je n'ai pas d'opinion sur la façon dont vous suivez l'état d'avancement du travail. L'essentiel est d'aborder la data science de manière active et dynamique.

Le Manifeste pour une Data Science Agile

Itérer, itérer, itérer

La prise de conscience provient de la 25e requête d'une chaîne de requêtes, et non de la première. Les tableaux de données doivent être analysés, formatés, triés, agrégés et résumés avant de pouvoir être compris. Les tableaux pertinents proviennent généralement de la troisième ou quatrième tentative, et non de la première. La construction de modèles prédictifs précis peut nécessiter de nombreuses itérations d'ingénierie des caractéristiques et de réglage des hyperparamètres. En data science, l'itération est l'élément essentiel de l'extraction, de la visualisation et de la production de la connaissance. Lorsque nous construisons, nous itérons.

Ads-Iterate fr.png

Livrer des résultats intermédiaires

L'itération est l'acte essentiel dans la création d'applications analytiques, ce qui signifie que nous nous retrouvons souvent à la fin d'un sprint avec des choses qui ne sont pas complètes. Si nous ne livrions pas de résultats incomplets ou intermédiaires à la fin d'un sprint, nous finirions souvent par ne rien envoyer du tout. Et ce n'est pas ça l'Agile ; je l'appelle la "boucle de la mort", où un temps infini peut être perdu à perfectionner des choses dont personne ne veut.

Les bons systèmes s'auto-documentent, et dans la data science Agile, nous documentons et partageons les ressources incomplètes que nous créons au fur et à mesure que nous travaillons. Nous consacrons tout le travail au contrôle des sources. Nous partageons ce travail avec nos coéquipiers et, dès que possible, avec les utilisateurs finaux. Ce principe n'est pas évident pour tout le monde. De nombreux data scientists viennent de milieux universitaires, où des années d'efforts de recherche intenses ont abouti à un seul grand document appelé thèse qui a abouti à un diplôme de haut niveau.

Ads-Under construction fr.png

Réaliser des expériences, pas des tâches

Dans le domaine du génie logiciel, un chef produit attribue à un développeur un graphique à mettre en oeuvre lors d'un sprint. Le développeur traduit ce graphique en une requête SQL GROUP BY et crée une page web pour celui-ci. Mission accomplie ? Faux. Les graphiques qui sont spécifiées de cette manière ont peu de chances d'avoir de la valeur. La data science diffère du génie logiciel en ce qu'elle est à la fois une science et une ingénierie.

Ads-Experiment fr.png

Pour toute tâche donnée, nous devons itérer pour obtenir quelque chose de pertinent, et ces itérations peuvent être qualifiées au mieux d'expériences. Gérer une équipe data science signifie superviser de multiples expériences simultanées plus que distribuer des tâches. Les bonnes ressources (tableaux, graphiques, rapports, prévisions) apparaissent comme des artefacts de l'analyse exploratoire des données, nous devons donc penser davantage en termes d'expériences que de tâches.

Ecouter les données

Ce qui est possible est aussi important que ce qui est prévu. Ce qui est facile et ce qui est difficile sont aussi importants à connaître que ce qui est désiré. Dans le développement d'applications logicielles, il y a trois perspectives à prendre en compte : celles des clients, des développeurs et de l'entreprise. Dans le développement d'applications analytiques, il y a une autre perspective : celle des données. Sans comprendre ce que les données "ont à dire" sur une caractéristique, le product owner ne peut pas faire un bon travail. L'opinion des données doit toujours être incluse dans les discussions sur le produit, ce qui signifie qu'elles doivent être fondées sur la visualisation par le biais d'une analyse exploratoire des données dans le cadre de l'application interne qui devient le centre de nos efforts.

Ads-Listen fr.png

Respecter la pyramide de la valeur des données

La pyramide de la valeur des données (figure ci-dessous) est une pyramide à cinq niveaux calquée sur la hiérarchie des besoins de Maslow. Elle exprime la quantité croissante de valeur créée lors de l'affinage des données brutes sous forme de tableaux et de graphiques, suivis de rapports, puis de prévisions, le tout destiné à permettre de nouvelles actions ou à améliorer les actions existantes :

  • Le premier niveau de la pyramide de la valeur des données (les enregistrements) concerne la tuyauterie ; il s'agit de faire circuler un ensemble de données depuis l'endroit où elles sont recueillies jusqu'à celui où elles apparaissent dans une application.
  • La couche des graphiques et des tableaux est le niveau où commencent l'affinage et l'analyse.
  • La couche des rapports permet une exploration immersive des données, où l'on peut vraiment en discuter et apprendre à les connaître.
  • La couche des prédictions est le niveau où l'on crée le plus de valeur, mais pour créer de bonnes prédictions, il faut faire de l'ingénierie des caractéristiques, ce que les niveaux inférieurs englobent et facilitent.
  • Le dernier niveau, celui des actions, est celui où l'engouement pour l'intelligence artificielle (IA) se manifeste. Si votre intuition ne permet pas d'entreprendre une nouvelle action ou d'améliorer une action existante, elle n'a pas beaucoup de valeur.


Ads-pyramid fr.png
La pyramide de la valeur des données. Figure reproduite avec l'aimable autorisation de Russell Jurney.

La pyramide de la valeur des données donne une structure à notre travail. La pyramide est un élément à garder à l'esprit, et non une règle à suivre. Parfois on saute des étapes, parfois on travaille en marche arrière. Si vous introduisez un nouvel ensemble de données directement dans un modèle prédictif en tant que caractéristique, vous contractez une dette technique si vous ne rendez pas cet ensemble de données transparent et accessible en l'ajoutant à votre modèle de données d'application dans les niveaux inférieurs. Vous devez garder cela à l'esprit et rembourser la dette dès que vous en êtes capable.

Trouver le chemin critique

Pour maximiser nos chances de succès, nous devrions consacrer la majeure partie de notre temps à l'aspect de notre application qui est le plus essentiel à sa réussite. Mais de quel aspect s'agit-il ? Il faut le découvrir par l'expérimentation. Le développement de produits analytiques correspond à la recherche et à la poursuite d'un objectif mouvant.

Ads-Critical path fr.png

Une fois qu'un objectif est déterminé, par exemple une prédiction à faire, nous devons trouver le chemin critique pour sa mise en œuvre et, s'il s'avère utile, pour son amélioration. Les données sont affinées étape par étape au fur et à mesure qu'elles passent d'une tâche à l'autre. Les produits analytiques nécessitent souvent plusieurs étapes d'affinage, l'utilisation de processus d'extraction, de transformation et de chargement (ETL), de techniques statistiques, d'accès à l'information, de machine learning, d'intelligence artificielle et d'analyse de graphiques.

L'interaction de ces étapes peut former des réseaux complexes de dépendances. Le team leader a ce maillage dans la tête. C'est à lui de s'assurer que l'équipe découvre le chemin critique, puis d'organiser l'équipe pour le compléter. Un chef produit ne peut pas gérer ce processus du haut vers le bas ; c'est plutôt un scientifique du produit qui doit le découvrir du bas vers le haut.

Passer en méta

Si nous ne pouvons pas facilement livrer de bons produits selon un calendrier comparable à celui du développement d'une application normale, que ferons-nous ? Si nous ne livrons pas, nous ne sommes pas Agile. Pour résoudre ce problème, dans la data science Agile, nous "passons en méta". L'accent est mis sur la documentation du processus analytique par opposition à l'état final ou au produit que nous recherchons. Cela nous permet d'être Agile et de livrer un contenu intermédiaire tout en grimpant itérativement dans la pyramide de la valeur des données pour trouver le chemin critique vers un produit génial. Alors, d'où vient le produit ? De la palette que nous créons et élargissons en documentant notre analyse exploratoire des données.

Ads-Meta fr.png

Conclusion

Ces sept principes fonctionnent ensemble pour alimenter la méthode de la data science Agile. Ils servent à structurer et à documenter le processus d'analyse exploratoire des données et à le transformer en applications analytiques.

Agile-Data-Science fr.png

Découvrez Agile Data Science 2.0 pour explorer en profondeur la théorie et la pratique de la data science Agile.

Agile-data-science-20-book.jpeg