Un Manifeste pour une Data Science Agile
Auteur : Russell Jurney
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.
Découvrez Agile Data Science 2.0 pour explorer en profondeur la théorie et la pratique de la data science Agile.
À 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 déployé. 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 de la 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 de la 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 fonctionnalités 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.
Déployer les productions 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 déployions 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.
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.
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 fonctionnalité, le propriétaire du produit 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.
Respecter la pyramide des données-valeurs
La pyramide des données-valeurs (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 données-valeurs (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 fonctionnalités, 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.
La pyramide données-valeur. Figure reproduite avec l'aimable autorisation de Russell Jurney.
