« Un Manifeste pour une Data Science Agile » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Ligne 17 : Ligne 17 :
À 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.<br/>
À 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.<br/>
<br/>
<br/>
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.<br/>
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.<br/>
<br/>
<br/>
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.<br/>
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.<br/>
Ligne 29 : Ligne 29 :
[[Fichier:Ads-Iterate fr.png|border|600px]]<br/>
[[Fichier:Ads-Iterate fr.png|border|600px]]<br/>
<br/>
<br/>
===Déployer les résultats intermédiaires===
===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 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.<br/>
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.<br/>
<br/>
<br/>
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.<br/>
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.<br/>
Ligne 72 : Ligne 72 :
<br/>
<br/>
===Passer en méta===
===Passer en méta===
Si nous ne pouvons pas facilement déployer de bons produits selon un calendrier comparable à celui du développement d'une application normale, que ferons-nous ? Si nous ne déployons 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 déployer un contenu intermédiaire tout en grimpant itérativement dans la pyramide données-valeurs 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.<br/>
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 données-valeurs 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.<br/>
<br/>
<br/>
[[Fichier:Ads-Meta fr.png|600px]]<br/>
[[Fichier:Ads-Meta fr.png|600px]]<br/>