tag:blogger.com,1999:blog-4795558919213122052024-02-22T08:08:00.333-08:00Institut AgileUne informatique plus humaine et plus efficace...Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.comBlogger49125tag:blogger.com,1999:blog-479555891921312205.post-49940542914541063692012-02-14T05:01:00.000-08:002012-02-14T05:02:10.688-08:00Prochain Rendez-Vous de l'Institut: le 22 mars à CaenL'Institut sort de Paris pour son prochain Rendez-Vous:"Vous avez dit Management Agile ?"<br />
<div>
<br /></div>
<div>
Il s'agit d'une journée pleine, proposée par l'Institut Agile, le Chapitre France-Atlantic du PMI et l'Université de Caen, qui se tiendra le 22 mars 2012 à Caen. Vous pouvez <a href="http://www.pmi-fratl.org/images/pmifratl/plaquette/Plaquette_Forum_Mars2012.pdf">télécharger la plaquette</a> ou <a href="http://www.pmi-fratl.org/index.php?option=com_content&view=article&id=77:evenement-2012-22-mars&catid=1:latest-news">vous inscrire</a> sur le site du Chapitre.</div>
<div>
<a name='more'></a></div>
<div>
<div>
Cet événement vous propose de faire le point sur le management Agile de projets et d'équipes, d'en aborder les spécificités, mais également d'échanger et de confronter vos expériences et vos préoccupations avec d'autres responsables de projet, qu'ils soient ou non rompus à l'approche Agile.</div>
<div>
<br /></div>
<div>
C'est pourquoi cette rencontre se décline en deux temps: au cours de la matinée, des intervenants d'horizons divers vous proposeront des lectures diverses des enjeux d'un management Agile: du survol général des pratiques Agiles telles qu'elles se présentent aujourd'hui à des questions plus concrètes comme la constitution et le suivi d'une équipe. Puis, l'après-midi, une session au format "Open Space" ("forum ouvert"), au cours de laquelle tous les participants ont la possibilité de devenir orateurs, vous permettra d'aller au plus près de vos préoccupations.</div>
</div>
<div>
<br /></div>
<div>
Cet événement est le résultat d'une première collaboration avec l'Université de Caen, elle-même issue du lancement en novembre dernier de la communauté thématique "<a href="http://blog.institut-agile.fr/2011/11/naissance-dune-communaute-enseigner.html">Enseigner Agile</a>": celle-ci a par ailleurs produit d'autres résultats, que je détaillerai dans un prochain billet...</div>
<div>
<br /></div>
<div>
Il s'agit aussi, je l'espère, d'une première collaboration avec des organismes tels que le PMI, qui en annonce d'autres. L'Institut Agile reste très vigilant quant aux risques de <a href="http://www.journaldunet.com/developpeur/expert/50201/approches-agiles--entre-essor-et-recuperation.shtml">récupération</a> du mouvement Agile, et ne cache pas sa désapprobation quant aux mécanismes de certification mis en place aux Etats-Unis par le PMI.</div>
<div>
<br /></div>
<div>
Pour autant, il semble naturel de se rapprocher de tous ceux qui s'intéressent à la pratique actuelle et au devenir de la gestion de projet, et nous, Agilistes, n'avons rien à gagner à rester repliés sur nous-mêmes. C'est le sens de cet événement, qui vise avant tout à provoquer, à travers la rencontre, des débats utiles.</div>Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-76647650285130059662011-11-16T06:41:00.001-08:002012-02-14T04:30:29.490-08:00Naissance d'une communauté: Enseigner Agile<br />
Le 9 novembre s'est réuni une <a href="http://groups.google.com/group/enseigner-agile/">nouvelle communauté thématique</a> à l'initiative de l'Institut Agile: elle se composait d'enseignants en activité et d'intervenants issus de l'industrie. (Plusieurs d'entre nous ont d'ailleurs eu des parcours mixtes: ex-enseignants devenus ingénieurs ou chefs de projet, ex-ingénieurs devenus enseignants, par exemple.) Une dizaine de personnes étaient présentes.<br />
<br />
<a name='more'></a><br /><br />
Après un tour de table permettant à chacun de faire connaissance, nous avons planché sur un "énoncé de mission" pour clarifier les activités futures de ce groupe. En fin de journée, nous avons ouvert les débats à la communauté Agile et terminé à plusieurs dizaines autour d'un apéritif.<br />
<br />
<b>Missions du groupe</b><br />
<br />
<ul>
<li><i>Quel est son objectif et qui sont ses "clients"?</i> Notre groupe travaille pour que les étudiants qui suivent des cursus en informatique puissent <b>s'intégrer efficacement dans une équipe agile</b> à leur arrivée sur le marché de l'emploi: nous voulons que leur formation soit une occasion <b>de plaisir, d'apprentissage</b> et qu'elle leur apporte <b>des compétences utiles</b>.</li>
</ul>
<br />
<ul>
<li><i>Comment?</i> Nous pensons que l'essentiel est de <b>transmettre "l'esprit Agile"</b>. A cette fin nous voulons animer <b>un réseau qui recense de bonnes pratiques, de nouvelles techniques d'enseignement et des outils</b> pour former à l'approche Agile les développeurs et les autres intervenants d'un projet.</li>
</ul>
<br />
<ul>
<li><i>Jusqu'où souhaitons-nous aller?</i> Pour une partie du groupe, faire évoluer l'enseignement exige de rendre visible l'importance de cet "esprit Agile", de l'argumenter auprès des instances de décision dans l'enseignement, jusqu'à l'échelon national: en somme de se livrer à du <b>lobbying auprès des pouvoirs publics</b>. </li>
</ul>
<br />
<ul>
<li>Plusieurs pensent également qu'il est important de faire émerger un enseignement spécifiquement Agile, au sein des formations en génie logiciel ou en parallèle à ces dernières; et également de militer pour une <b>mise à jour des programmes d'enseignement</b>, par exemple en favorisant l'intégration de pratiques innovantes venues de l'industrie ou de la recherche.</li>
</ul>
<br />
<br />
<b>Work in progress</b><br />
<br />
Cet énoncé de mission n'est pas définitif, et notamment sur la question "jusqu'où aller" a donné lieu à de longs débats non encore tranchés, certains argumentant en faveur d'un périmètre plus restreint pour ne pas se disperser, d'autres encourageant le groupe à faire preuve d'ambition.<br />
<br />
Le titre du site associé joue quelque peu sur cette ambiguïté: "enseigner Agile" ce peut être deux choses, enseigner le sujet Agile mais aussi enseigner de façon Agile (et pourquoi pas d'autres sujets).<br />
<br />
<b>Activités</b><br />
<br />
Quoi qu'il en soit, il émerge de cette discussion au moins trois idées concrètes d'activités:<br />
<br />
<ul>
<li>une "<a href="https://sites.google.com/site/enseigneragile/la-place-de-marche">place de marché</a>" pour réunir les demandes des enseignants et les propositions des agilistes volontaires pour intervenir en école ou université;</li>
<li>des outils pour favoriser le partage de bonnes pratiques d'enseignement; une <a href="http://groups.google.com/group/enseigner-agile/">liste de diffusion</a> et un <a href="https://sites.google.com/site/enseigneragile/">site collaboratif</a> sont déjà en place</li>
<li>des actions (partant du simple retour d'expérience dans un premier temps, puis peut-être plus ambitieuses) pour "faire du bruit" autour de la question de l'enseignement de l'Agilité, pour gagner en visibilité</li>
</ul>
<br />
<br />
En parallèle, les discussions se poursuivront sur la <a href="http://groups.google.com/group/enseigner-agile/">liste de diffusion</a>: rejoignez-nous si vous êtes concernés par le sujet!<br />
<br />
<b>Sujets futurs</b><br />
<br />
Voici quelques-uns des sujets versés à notre "backlog", dont nous avons plus ou moins brièvement traité compte tenu du temps limité qui nous était imparti, mais qui alimenteront sans doute des discussions plus approfondies:<br />
<br />
<ul>
<li>Communautés locales de praticiens et d'enseignants</li>
</ul>
<br />
Comment rapprocher, dans une même région, les enseignants et leurs étudiants d'une part, et les personnes qui s'identifient à la "communauté agile" d'autre part? Nous avons constaté des situations différentes, à l'occasion de l'événement national Agile Tour: dans de trop nombreux cas ces conférences se tiennent dans une université ou une école... mais aucun enseignant de l'établissement n'assiste à la conférence!<br />
<br />
<ul>
<li>Stages</li>
</ul>
<br />
Pour un étudiant, le stage en entreprise est souvent un coup de poker: il peut s'avérer une excellente occasion de mettre en pratique sur le terrain des notions Agiles abordées dans un cours, interactif ou théorique. Même sans aborder la question du stagiaire considéré seulement comme "main d'oeuvre bon marché", le stage peut aussi être une perte de temps, par exemple si le stagiaire n'a ni l'occasion d'apprendre de ce travail... ni d'être un agent du changement vis-à-vis de son employeur, en lui apportant des idées fraîches.<br />
<br />
<ul>
<li>Techniques de base</li>
</ul>
<br />
Faut-il apprendre comment se servir d'un gestionnaire de sources? Si on ne le fait pas, peut-on prétendre qu'on forme des étudiants à contribuer efficacement à des projets dans l'industrie? Des questions de ce type sont souvent revenues, à propos de la gestion de versions qui cristallise certains débats mais aussi au sujet des "design patterns" (patrons de conception) ou des techniques de déboguage.<br />
<br />
A l'intersection de ces deux sujets, les stages étudiants et les outils qui composent "l'établi" du professionnel du logiciel, se dessine aussi la question de savoir comment sensibiliser les étudiants aux réalités du monde de l'entreprise et des projets: on rejoint fortement l'énoncé de mission du groupe.<br />
<br />
<ul>
<li>Jeux, recherche, autres sujets</li>
</ul>
<br />
La prédilection de la communauté Agile pour les jeux et simulations, qu'il s'agisse de jeux de rôle, "serious games", jeux d'innovation, ateliers expérientiels etc. a bien entendu été soulevée; elle occupera sans doute une part importante des débats, mais n'a pas été traitée en profondeur.<br />
<br />
A plusieurs reprises également a été abordée la question de la recherche: la dualité enseignant-chercheur, un pilier du système français, nous y poussait fortement. Cependant cette question a été délibérément poussée de côté, puisque le thème de la journée était l'enseignement.<br />
<br />
Nous avons aussi abordé, sans les détailler, des questions comme l'enseignement de l'informatique en seconde au collège, le risque posé par le développement offshore, ou le statut à long terme du sujet Agile (peut-on enfin cesser de parler de "mode" ou de "feu de paille").<br />
<br />
Enfin nous avons parlé d'une liaison avec le réseau ALE, qui se fera dans un premier temps via le site <a href="http://aleuniversity.org/">aleuniversity.org</a>.<br />
<br />
<b><br class="Apple-interchange-newline" />Comment nous aider?</b><br />
<b><br /></b><br />
<br />
<ol>
<li>En parlant autour de vous de cette initiative! Sur votre blog, sur Twitter, à vos collègues pendant le déjeûner...</li>
<li>En participant!</li>
</ol>
<br />
<div>
<b><br /></b></div>
<br />Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-15580265840565830982011-10-20T06:59:00.000-07:002012-02-14T04:30:44.898-08:00Enseignement Agile: le 9 novembre à l'EpitechLes inscriptions sont ouvertes pour le prochain Rendez-Vous de l'Institut Agile, consacré <a href="http://blog.institut-agile.fr/2011/09/les-rendez-vous-de-linstitut.html">comme évoqué précédemment</a> à la place et au rôle des pratiques Agiles dans l'enseignement supérieur.<br />
<br />
<br />
<div class="p1">
Peut-on, doit-on enseigner les approches Agiles au sein des universités et écoles d'ingénieur? Si oui, comment?</div>
<div class="p2">
<br /></div>
<div class="p1">
C'est à ces questions que nous vous invitons à répondre lors d'une soirée-débat gratuite, qui fera suite à la rencontre inaugurale d'un nouveau réseau national d'enseignants et intervenants ayant intégré les pratiques Agiles au sein de leurs contenus pédagogiques. Nous serons accueillis par l'Epitech à Paris.</div>
<div class="p2">
<br />
<a name='more'></a><br /></div>
<div class="p1">
Inscriptions:</div>
<div class="p3">
<span class="s1"> <a href="http://pedagogie-agile.eventbrite.com/"><span class="s2">http://pedagogie-agile.eventbrite.com/</span></a></span></div>
<div class="p2">
<br /></div>
<div class="p1">
Nous entendrons notamment les témoignages de:</div>
<div class="p1">
- Claude Aubry</div>
<div class="p1">
- Jean-Luc Lambert</div>
<div class="p1">
- Frédéric Dufau-Joel</div>
<div class="p1">
- Alexandre Boutin</div>
<div class="p2">
<br /></div>
<div class="p1">
Le débat qui suivra portera sur les questions qui <i>vous</i> intéressent! A titre indicatif, la liste non limitative ci-dessous:</div>
<div class="p2">
<br /></div>
<div class="p1">
Quel avenir espérer pour les pratiques Agiles au sein de la formation initiale? Apporteront-elles une refonte significative de ces programmes, ou bien se cantonneront-elles à des aménagements mineurs des cursus d'informatique et génie logiciel?</div>
<div class="p2">
<br /></div>
<div class="p1">
Est-ce à la communauté Agile d'adapter son mode d'enseignement dominant (formations ponctuelles, typiquement de deux jours, avec ou sans "certification" à la clé) à des démarches de formation plus longues et plus construites?</div>
<div class="p2">
<br /></div>
<div class="p1">
A contrario, peut-elle apporter des idées intéressantes - apprentissage par l'expérience et par le jeu, favorisant réactivité au changement plutôt que le suivi d'un plan, c'est à dire d'un cursus prédéfini - à des universités et des écoles dont le mode de fonctionnement semble par ailleurs peu remis en question par les nouvelles technologies?</div>
<div class="p2">
<br /></div>Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-59515817475389453852011-10-10T10:06:00.000-07:002012-02-14T04:30:57.895-08:00Etymologie d'un terme Agile: le backlog<br />
Si vous êtes agiliste, vous connaissez le mot "backlog", mais vous êtes-vous interrogé sur ses origines et ses connotations?<br />
<br />
<a name='more'></a><br /><br />
Le terme "backlog" est <a href="http://www.answers.com/topic/backlog">attesté</a> dans la langue anglaise <b>à partir de 1684</b>: c'est "la bûche du fond", pièce maîtresse d'une flambée bien préparée; le petit bois démarre le feu mais c'est cette bûche plus grosse qui fournit une réserve de chaleur. Les cheminées cédant la place à des chauffages plus modernes, le mot perd vers la fin 19è son sens figuratif pour devenir métaphorique: c'est une réserve, une accumulation.<br />
<br />
Le terme acquiert dans l'industrie manufacturière <b>un sens plus nuancé</b> au 20è; vers 1930-1940 plus précisément, le diagramme fourni par <a href="http://bit.ly/mUC4CM">Google n-grams</a> est éloquent quant à la popularité soudaine de ce mot. Il désigne un "empilement" de choses (souvent des commandes de produits industriels) derrière ce qu'on appelerait maintenant un goulot d'étranglement. Positif lorsqu'il évoque la vigueur de l'économie, il devient plus tard négatif lorsqu'il dénote un retard de traitement.<br />
<br />
C'est bien cette connotation moins franchement positive qui est à mon sens évoquée par le backlog de Scrum, et que ne rendent pas certaines traductions alternatives: "carnet de produit" (par analogie au carnet de commandes) ou même "exigences".<br />
<br />
Dès les premiers articles sur Scrum, vers 1995, ce terme est associé à cette démarche de gestion de projets, <b>en net décalage avec le discours dominant</b> qui parle plus volontiers de "spécifications", "d'exigences" (requirements). Le terme français de "cahier des charges" capture très bien les connotations véhiculées par "requirements document" - on ne conçoit pas l'information entrante, "l'input" d'un projet logiciel <b>autrement que comme un document</b>. Un célèbre <a href="http://dl.acm.org/citation.cfm?id=9800">article</a> de Parnas et Clements, "A rational design process" en fait même <b>un critère de rationalité du processus</b>, excusez du peu: qui ne produit pas de document est donc irrationnel.<br />
<br />
L'usage que font les concepteurs de Scrum du terme "backlog" semble donc <b>idiosyncratique</b>, propre à leur approche individuelle des choses. En examinant les <a href="http://web.archive.org/web/19970517085111/http://www.controlchaos.com/aberdeen.htm">archives du site ControlChaos.com</a> préservées par The Internet Archive, on découvre des traces des origines de Scrum, traces que son créateur n'a hélas pas choisi de préserver (on peut même se demander s'il n'a pas souhaité, délibérément, les effacer). On découvre ainsi que le premier véhicule de Scrum est l'outil MATE (Methods and Tool Expert), un <b>environnement logiciel</b> d'aide au développement vendu par ADM, l'entreprise de Ken Schwaber. La terminologie de Scrum semble être celle utilisée dans le module "gestion de produit" de l'outil MATE. (D'autres termes mentionnés dans ces premiers écrits sur Scrum, comme "packet" qui désigne un composant logiciel, ont depuis disparu.)<br />
<br />
Le sens d'origine, donné dans l'article de 1995, est très éclairant: "une liste de tout <b>ce qui n'est pas adéquat dans la version actuelle</b>".<br />
<br />
En d'autres termes, à l'origine Scrum ne fait pas de distinction entre la création d'un produit nouveau d'une part, et d'autre part la maintenance d'un produit existant, déjà livré entre les mains d'utilisateurs. On considère la création d'un nouveau produit comme un cas particulier de la maintenance! C'est un des aspects les plus importants de la rupture que marque ce qu'on appellera plus tard l'approche Agile.<br />
<br />
En caractérisant le backlog comme une liste de ce qui rend l'actuel inadéquat, Scrum donne une vision nettement moins rationalisante que ce qui s'attache au terme "exigences": on peut envisager que les "exigences" du produit soient un ensemble platoniquement parfait, dont on ne dévierait que par erreur; alors qu'un "backlog" est implicitement le résultat ET le lieu d'une négotiation.<br />
<br />
Le sens actuel donné par le <a href="http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf">Scrum Guide</a> est donc <b>nettement moins intéressant</b>: "la liste de tout ce qui est nécessaire pour réaliser le produit".<br />
<br />
Je regrette que la version actuelle du Scrum Guide tende à effacer ces connotations d'origine et adopte une version plus proche de ce qu'évoque le terme "exigences"; également qu'il se soit gaspillé un temps considérable à traiter de la subtile différence entre "ordonné" et "priorisé", coupage de cheveux en 256èmes alors que le véritable débat est celui qui porte sur ces idées de négotiation, et sur l'incertitude (voire l'irrationalité) inhérente à la définition des exigences.<br />
<br />
La nécessité pour un discours Agile tel que Scrum à soigner son acceptabilité, son aspect "politiquement correct", conduit ses auteurs à <b>tenter d'effacer les traces de sa construction historique</b>. A mon sens, c'est <b>une erreur</b>: l'étymologie des mots, l'origine des idées, sont comme les miettes de pain du Petit Poucet... des repères indispensables mais fragiles. Ces miettes doivent être préservées, sans quoi nous risquons ne plus pouvoir comprendre comment nous en sommes arrivés là où nous sommes, et reproduire des erreurs déjà commises - <b>celles-là mêmes</b> contre lesquelles l'approche Agile s'est mobilisée au départ!Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-71830093852749485352011-09-21T06:35:00.000-07:002012-02-14T04:31:16.820-08:00Agile et en forme!Un des inconvénients de nos métiers est sans doute le temps que nous passons assis: apparemment, ce n'est <a href="http://www.medicalbillingandcoding.org/sitting-kills/">pas très bon pour la santé</a>.<br />
<br />
Heureusement pour les équipes agiles, <a href="http://referentiel.institut-agile.fr/daily.html">on se lève</a> au moins une fois par jour... Ce n'est sans doute pas suffisant. Sans aller jusqu'à remplacer votre bureau par un tapis de marche comme <a href="http://www.agilejourneyman.com/2010/11/agile-workstations.html">certains de nos collègues</a>, vous avez peut-être, pour y remédier, inclus un peu de jogging dans vos activités régulières.<br />
<br />
<a name='more'></a><br /><br />
Pour ma part, quand je <a href="http://runkeeper.com/user/Morendil/profile">m'y suis mis</a>, je n'appréciais pas trop: quand on est un "geek", on a vite fait de trouver que l'activité physique pure est une perte de temps. Je n'aurais sans doute pas tenu, et ça m'amène enfin au sujet de ce billet, si je n'avais pas trouvé des <a href="http://fr.wikipedia.org/wiki/Podcasting">podcasts</a> intéressants.<br />
<br />
Deux sont particulèrement notables: le <a href="http://ut7.fr/podcast/">Podcast à Papotes</a> de mes amis d'UT7 (également partenaires de l'Institut). J'aime particulièrement le ton léger, qui n'empêche pas d'aborder des choses très sérieuses, et l'érudition de Manu et Jonathan (par exemple vous apprendrez ce qu'est une <a href="http://fr.wikipedia.org/wiki/Faluche">faluche</a>).<br />
<br />
Et last but not least, la propre production de l'Institut: <a href="http://instagile.podbean.com/">Conversations avec les Agilistes</a>, qui vise à vous faire découvrir des initiatives intéressantes de la communauté agile francophone. Les deux premiers épisodes disponibles ont quelques mois déjà - mais d'autres suivront prochainement. Les Conversations devraient apparaître prochainement sur iTunes mais vous pouvez d'ores et déjà obtenir ces deux épisodes sur leur hébergement temporaire (Podbean, service gratuit et utile).<br />
<br />
Dans le premier épisode, Jonathan Perret nous parle du "Kata Marrant", une variante un peu particulière des dojos de programmation, qui a connu un franc succès à Agile 2011.<br />
<br />
Le second épisode a été enregistré à l'occasion d'Agile France; Antoine Contal nous présente la "communauté A3" qu'il a constituée avec le <a href="http://www.agilealliance.org/programs/lean-agile-a3-community-program/">soutien de l'Alliance Agile.</a><br />
<br />
De quoi faire quelques kilomètres, en attendant les prochains épisodes de l'un et de l'autre.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-78306384874292010622011-09-09T06:54:00.000-07:002012-02-14T04:31:32.569-08:00Les Rendez-Vous de l'Institut: Enseignement AgileParmi les sujets que l'Institut Agile entend traiter en priorité, on trouve en bonne place la recherche et l'enseignement.<br />
<br />
Que pouvons-nous apprendre, par la méthode expériementale notamment, sur les pratiques Agiles et leur relation à d'autres "bonnes pratiques"dans le domaine du logiciel? Mais également, et les deux sujets sont indissociables, comment favoriser l'acquisition de ces connaissances (et d'autres) par les élèves, les étudiants et les jeunes diplômés d'aujourdhui qui vont (rapidement) devenir les professionnels du logiciel de demain? C'est un enjeu d'avenir mais encore peu abordé par la communauté Agile.<br />
<br />
<a name='more'></a><br /><br />
L'un des prochains Rendez-Vous de l'Institut sera consacré en particuler au volet "enseignement": <a href="http://www.doodle.com/nwh5s6mczi6ht3fe">suivez ce lien</a> pour réserver votre place... Il s'agit dans un premier temps de choisir une date.<br />
<br />
L'Institut accueillera tous ceux, sans critère de statut ou d'appartenance à telle ou telle institution, qui revendiquent une démarche "d'enseignement Agile" à destination de professionnels du logiciel (futurs ou en exercice). Cela peut naturellement désigner un programme d'enseignement (universitaire, scolaire, ou autre) dont le contenu inclut une ou plusieurs <a href="http://referentiel.institut-agile.fr/">pratiques Agiles</a>. Mais aussi l'application de ces mêmes pratiques à la démarche pédagogique elle-même: participative, itérative, pilotée par les tests...<br />
<br />
(Précisons cependant que cette invitation concerne les programmes éducatifs substantiels: sauf exception, les formations ponctuelles de 2 jours destinées aux ingénieurs en exercice ne sont pas concernées. Non parce qu'elles n'ont pas de valeur - mais parce que cette partie de notre écosystème n'a aucun besoin qu'on lui donne plus de visibilité: elle a été le principal vecteur de diffusion des idées Agiles depuis des années, avec les conférences de praticiens.)<br />
<br />
Cette rencontre se fera en deux temps: d'abord un atelier qui permettra aux intervenants de faire connaissance, de partager leurs succès et leurs interrogations et de recenser des priorités communes - de nombreuses initiatives de ce type ont vu le jour dans de nombreux organismes en France et ailleurs et ce sera aussi une occasion d'améliorer le fonctionnement en réseau.<br />
<br />
Puis une soirée ouverte au débat avec les professionnels. Les intervenants y trouveront une occasion de présenter leur travail pédagogique, les autres personnes présentes pourront intervenir pour partager leur propre expérience (en tant qu'étudiants, en tant que membres de projets, en tant que recruteurs par exemple) et proposer des pistes et des idées.<br />
<br />
N'hésitez pas à faire passer le message - à vos collègues, à vos étudiants, à vos profs... à tout ceux que le sujet peut intéresser!Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-30098639760704652812011-04-04T13:55:00.001-07:002012-02-14T04:32:01.593-08:00Premier Rendez-vous de l'Institut Agile: 04/05Le <b>4 mai</b>, l'Institut Agile vous invite au <a href="http://lanyrd.com/2011/instagile-april/">premier de ses Rendez-Vous</a>. (<b>Attention</b>: changement de date par rapport à la première annonce!)<br />
<div>
<br /></div>
<div>
Petit à petit le projet de l'Institut Agile se construit, grâce au soutien de ses <a href="http://institut-agile.fr/membres.php">partenaires</a>. Comme annoncé au fil de ce blog divers livrables importants ont vu le jour: le <a href="http://referentiel.institut-agile.fr/">référentiel des pratiques agiles</a>, les premières sessions "<a href="http://blog.institut-agile.fr/2011/02/session-innovation-games-les-29-et-30.html">Master Class</a>", les premières <a href="http://blog.institut-agile.fr/2011/02/premiere-communaute-thematique-de.html">communautés thématiques</a>. D'autres projets encore en couveuse produiront prochainement leurs résultats.</div>
<div>
<br />
<a name='more'></a><br /></div>
<div>
Pour autant, et cela peut se comprendre, le modèle de fonctionnement de l'Institut étant une première mondiale (cocorico), ces actions sont encore peu connues et demandent souvent à être expliquées. Pour donner plus de visibilité à ces résultats, pour mieux faire connaître le projet de l'Institut et les personnes qui le soutiennent, pour solliciter aussi de nouveaux soutiens toujours nécessaires, l'Institut Agile démarre une série de rencontres avec toutes les personnes qui, au sein de la communauté Agile, se sentent concernés par son projet: développer "l'écosystème" des entreprises qui s'appuient sur les compétences développées par cette communauté. Ce sont les Rendez-Vous de l'Institut.</div>
<div>
<br /></div>
<div>
Ce premier rendez-vous sera donc en premier lieu l'occasion de donner un coup de projecteur sur le Référentiel des Pratiques, les outils qui l'accompagnent, et de présenter en exclusivité pour les personnes présentes sa version "livre électronique" (un eBook qui sera dans un premier temps édité au format PDF, autres formats selon la demande) avec des contenus inédits.</div>
<div>
<br /></div>
<div>
Nous parlerons également, dans un format inspiré de l'Open Space, de l'avenir de cette communauté Agile. Dans un esprit de service, l'Institut a choisi d'apporter son aide à l'initiative de Jurgen Appelo, le réseau <a href="http://www.linkedin.com/groups?home=&gid=3786271&trk=anet_ug_hm">ALE (Agile Lean European Network)</a> - une initiative totalement indépendante et non liée à l'Institut, mais qui tiendra sa <a href="http://www.linkedin.com/groups/ALE-Gathering-XP2011-3786271.S.47736844">première réunion</a> lors de la conférence XP2011 à Madrid. Ayant prévu de m'y déplacer, je me propose donc comme porte-parole des personnes qui seront présentes; mais c'est aussi une excellente occasion de discuter ensemble de la façon dont nous voyons l'avenir de l'Agilité.</div>
<div>
<br /></div>
<div>
Le nombre de place étant limité, merci de bien vouloir vous inscrire. Utilisez <a href="http://lanyrd.com/2011/instagile-april/">ce lien</a> pour vous inscrire sans formalités à l'aide d'un compte Twitter (procédure recommandée) ou bien inscrivez-vous par mail à rdv(arobase)institut-agile.fr.<a href="http://www.blogger.com/"></a><br />
<br />
La réunion aura lieu à Issy-les-Moulineaux. <b>Nous serons accueillis au centre de conférences Microsoft, auditorium Prairie.</b></div>Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-14336426641692824822011-02-10T08:23:00.000-08:002012-02-14T04:32:14.380-08:00Première communauté thématique de l'Institut Agile: Contrats AgilesLa première réunion de groupe de travail "Contrats Agiles" de l'Institut s'est tenue le 17 janvier dernier; ce billet en donne un compte-rendu. (Pour en savoir plus, vous pouvez également participer à la <a href="http://groups.google.com/group/institut-agile-contrats">liste de diffusion</a> "Institut Agile - Contrats")<br />
<br />
<a name='more'></a><br /><br />
<b>Pourquoi ce sujet?</b><br />
<br />
Il semble généralement établi qu'un lien étroit existe entre<br />
<br />
<ul>
<li>d'une part l'approche séquentielle et prédictive des projets de développement de logiciels (souvent désignée, par approximation, par le terme "cycle en V"), considérée comme l'antithèse d'une approche Agile; </li>
<li>d'autre part les pratiques courantes en matière d'appels d'offres et de contrat, dominées par le modèle du contrat "au forfait" et dans lequel les trois grands paramètres d'un projet - coût, délais, périmètres - sont fixés antérieurement au projet et encadrent son déroulement.</li>
</ul>
<br />
Le consensus est moins net sur le sens d'un éventuel lien de cause à effet: est-ce parce que le contrat au forfait reste dominant qu'il est encore difficile de déployer pleinement les approches Agiles? Ou bien est-ce parce que les modes de pensée restent dominés par une vision séquentielle et prédictive que le contrat forfaitaire apparaît comme le plus naturel?<br />
<br />
Bien qu'ils soient des outils imparfaits, les <a href="http://www.versionone.com/state_of_agile_development_survey/10/page3.asp">questionnaires</a> à grande échelle semblent confirmer ce qu'on entend souvent de la part des nouveaux entrants dans la communauté Agile: ces questions de contrat, et au-delà, de la relation client-fournisseur sont perçues par beaucoup comme un frein majeur à la généralisation des approches et des pratiques que nous préconisons.<br />
<br />
Ce sujet reste donc une préoccupation prioritaire, pas seulement en France comme en témoigne un <a href="http://www.infoq.com/articles/agile-contracts">article récent dans InfoQ</a> qui récapitule les principales pistes formulées à ce jour.<br />
<br />
<b>Le rôle de l'Institut Agile</b><br />
<br />
Sur des sujets cruciaux de ce type, l'Institut cherchera en 2011 à réunir (au-delà des sociétés membres) des groupes d'intervenants représentant la diversité des profils concernés: en l'occurrence acheteurs, décideurs, prestataires, etc.<br />
<br />
Il s'agit d'aller au-delà des simples retours d'expérience, qui au demeurant ont parfois le marketing de telle ou telle enseigne pour principale vocation; de faire réellement avancer le sujet, en dressant un tableau réaliste des difficultés rencontrées, et en proposant des solutions.<br />
<br />
<b>Première table ronde (17 janvier 2011)</b><br />
<br />
Une première réunion s'est tenue le 17 janvier, à laquelle étaient conviés des représentants de la plupart des sociétés partenaires (Microsoft, Neoxia, UT7, PIA, Agile2You, Agilidee, Yaal, Exakis et Axones) ainsi que des intervenants extérieurs (Orange, CNRS, Sfeir, Agilessence) intéressés par le sujet.<br />
<br />
Un premier constat est celui de la difficulté à réunir ces interlocuteurs. Bien que plusieurs acteurs commerciaux proposant des offres "Agiles" fassent publiquement état de nombreux retours d'expérience dans la contractualisation de projets Agiles, il s'est trouvé pour cette première réunion assez peu de candidats à venir échanger sur les solutions mises en oeuvre.<br />
<br />
Ces difficultés s'expliquent sans doute en partie par la visibilité encore limitée de l'Institut Agile et de ces actions, mais il faut peut-être aussi y voir des réticences à dialoguer dans un cadre relativement intime et sans retombées commerciales, ou à partager ouvertement ce que certains peuvent voir comme un avantage concurrentiel. L'Institut espère contribuer à lever ces réticences avec le temps.<br />
<br />
La réunion elle-même s'est donc déroulée, cette première fois, de façon assez informelle. Parmi les sujets évoqués:<br />
<br />
<ul>
<li>l'importance d'examiner l'ensemble de la démarche, depuis la phase de l'appel d'offres jusqu'à la période de garantie, la conclusion d'un contrat formel n'étant qu'une étape parmi d'autres</li>
<li>le constat que parmi les appels d'offres (encore rares, mais en augmentation) qui stipulent une approche Agile, la plupart sont assortis de conditions qui ne sont en fait pas compatibles, et révèlent que ce qui est réellement demandé est un contrat tout à fait "classique": les prestataires qui jouent le jeu et proposent une démarche Agile se voient écartés, au profit de réponses qui respectent moins la demande!</li>
<li>l'éloignement entre "ceux qui font le contrat" et "ceux qui font le travail", source d'inévitables décalages entre les attentes et la réalité</li>
<li>des évolutions récentes dans le cadre particuler des Marchés Publics, qui rendent ces questions encore plus urgentes: par exemple l'abaissement récent du seuil permettant une procédure simplifiée, revenant de 20000€ à 4000€</li>
<li>a l'inverse, l'existence de procédures qui permettent sous certaines conditions de revenir à plus de souplesse: référencement, multi-attribution, accords-cadres</li>
</ul>
<br />
<br />
<b>Prochaines étapes (en ligne; en mai 2011)</b><br />
<br />
Avez-vous un retour d'expérience positif à partager, en tant que prestataire ou (mieux encore, car plus rare) en tant que client ou acheteur?<br />
<br />
Etes-vous volontaire, en tant que client ou acheteur, à venir dialoguer avec d'autres intervenants de la communauté Agile pour exposer en toutes franchise les aspects de leur approche qui vous préoccupent, dans une recherche constructive de solutions?<br />
<br />
Etes-vous disposé, en tant que prestataire ou consultant, à inciter vos clients et prospects à venir participer à cette recherche?<br />
<br />
Si vous êtes dans l'un de ces trois cas, vous pourrez contribuer aux travaux de cette communauté thématique, dans un premier temps via la liste de diffusion:<br />
<br />
<a href="http://groups.google.com/group/institut-agile-contrats">http://groups.google.com/group/institut-agile-contrats</a><br />
<br />
Une réunion publique, dans le courant du mois de mai, nous donnera l'occasion de faire un premier point sur les avancées constatées, en restituant les travaux réalisés dans l'intervalle par les participants à cette communauté thématique.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-77861664786658197472011-02-07T07:26:00.000-08:002012-02-14T04:32:36.594-08:00Session "Innovation Games" les 29 et 30 mars 2011, première Master Class<b>Ouverture des inscriptions</b><br />
<br />
Les inscriptions sont ouvertes dès aujourd'hui pour la première Master Class de l'Institut Agile.<br />
<br />
Celle-ci a pour thème les <b>Innovation Games</b> popularisés par Luke Hohmann. Elle se déroulera <b>les 29 et 30 mars</b> à Paris et sera <b>animée en anglais par Maarten Volders</b>, instructeur accrédité par Innovation Games Inc.<br />
<br />
<a name='more'></a><br /><br />
Le <b>tarif public</b> de cette session est de <b>950€ H.T.</b> pour les deux jours, repas du midi compris.<br />
<br />
Les <b>six premières places réservées</b> bénéficieront d'un <b>tarif préférentiel de 850€ H.T.</b>, sous condition impérative de réception de l'intégralité du règlement avant le 28 février 2011. (Six autres places sont réservées aux salariés des sociétés partenaires de l'Institut Agile au tarif préférentiel de 600€ H.T.)<br />
<br />
Les places sont limitées et seront réservées dans l'ordre de réception des pré-inscriptions. Pour réserver votre place, écrivez à: <b>laurent (at) bossavit (dot) com</b>. (N.B. l'adresse précédemment publiée ici est momentanément indisponible.)<br />
<br />
<b>Contenu de la session</b><br />
<br />
Les ateliers "Innovation Games" permettent de structurer les activités - cruciales pour la réussite de tout projet de développement - de réflexion, d'échange et de communication sur le produit à réaliser: qui en sont les destinataires, quelles sont leurs valeurs, leurs priorités, etc. Ces ateliers offrent un cadre convivial et efficace et rencontrent un franc succès auprès de la communauté Agile depuis plusieurs années, mais restent encore peu connus en France.<br />
<br />
Consultez <a href="http://innovationgames.com/university/practitioner-class/">le site d'Innovation Games Inc</a>. pour plus de détails. Cette session abordera:<br />
<br />
<ul>
<li>l'art et la manière de dialoguer avec les clients et utilisateurs du projet</li>
<li>comment planifier, exécuter puis exploiter un des ateliers Innovation Games</li>
<li>le détail de ces différentes étapes à travers des simulations et études de cas</li>
<li>comment adapter les ateliers et techniques de facilitation au contexte des participants</li>
<li>comment développer ses compétences d'animation et de facilitation</li>
<li>comment évangéliser ces ateliers auprès de clients externes ou internes</li>
</ul>
<br />
<br />
<b>A propos des Master Class</b><br />
<b><br />
</b><br />
Ces sessions "Master Class" s'inscrivent dans les missions de l'Institut Agile, parmi lesquelles figure notamment le maintien d'un niveau d'exigence et de qualité élevé au sein des entreprises vendeuses ou acheteuses de prestations en rapport avec les approches Agiles.<br />
<br />
L'Institut n'a pas vocation à proposer des formations visant les praticiens (ingénieurs en développement, responsables de projets ou de produits, cadres). Cependant, et en accord avec les entreprises partenaires, l'Institut propose un cycle de sessions destinées à promouvoir "l'excellence des formateurs" (au sens large: formateurs au sens strict, mais également accompagnants tels que "coachs" agiles ou consultants, internes ou externes).<br />
<br />
Les sujets abordés sont prioritairement des pratiques Agiles qui commencent à se généraliser au sein de la communauté mais qui restent encore mal connues en France. Plutôt que de tabler sur une diffusion progressive de ces compétences, acquises par bribes par la lecture de blogs ou de rares rencontres à l'occasion de conférences, l'Institut a pris contact avec <b>les experts les plus reconnus</b> à l'origine de la formulation ou de la popularisation de ces pratiques, et propose d'accélérer ainsi l'acquisition de ces compétences sur le sol français.<br />
<br />
Parmi les sujets abordés prochainement, et les experts déjà pressentis pour ces prochaines sessions:<br />
<br />
<ul>
<li>behaviour-driven development (avec Liz Keogh)</li>
<li>Story Mapping et techniques avancées de construction du "backlog"(avec Jeff Patton)</li>
<li>Exploratory Testing (avec Michael Bolton)</li>
<li>...et d'autres en fonction des demandes...</li>
</ul>
<div>
Pour signaler votre intérêt pour l'un de ces sujets et accélérer ainsi la planification de la session correspondante, écrivez à: <b>masterclass (at) institut-agile.fr</b></div>Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com2tag:blogger.com,1999:blog-479555891921312205.post-68049412264356434122011-01-28T02:04:00.000-08:002011-01-28T02:04:34.288-08:00On "fact and folklore"Late in 2010 I published on the blog of Institut Agile an essay in French, the latter half of which was a critique of Steve McConnell's 2008 blog entry "Productivity Variations Among Developers and Teams: The Origin of 10x". The context of this critical essay was a series in which I examined some of the issues in arriving at reliable knowledge in the domain of software engineering.<br />
<br />
In January, I posted to my personal GitHub site and to various social networks an English translation of that article, which thanks to the leverage of social networks enjoyed a relatively wide audience. This led to a series of exchanges on the blog of Steve McConnell and others, and some private correspondence. On net, my impression has been that this discussion has left the topic no clearer than it was previously, and I take responsibility for this poor result.<br />
<br />
On reflection I have come to realize that my claims, in both the original and the translated version, that McConnell was "cheating with citations" and "abusing the mechanism of scientific citation" were overblown. As a consequence of this carelessness on my part, the discussions that ensued were less fruitful than they might have been if I had presented my findings in a more neutral way, to be improved upon as necessary in the interests of factual accuracy.<br />
<br />
Even when dealing with charged issues, my normal mode of operation in debate is to avoid framing it as one person against another, but as both working in pursuit of some truth; in this instance, and on several occasions over a period of time, I did less than my best.<br />
<br />
On the bright side, I'm happy with many of the insights I was able to glean from this exchange, frustrating as it may have been to other readers. I am resolved to do a better job, at some future time, of presenting what I found during my investigation of the empirical evidence that McConnell and others have collected regarding programmer productivity. (A draft of this report is available and I will provide it upon request.)Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-37104960760674491592011-01-06T08:08:00.000-08:002011-01-06T08:08:56.724-08:00Traduction de "folklore ou fait scientifique"Hier, j'ai pris le temps, suite à diverses conversations avec des <a href="http://raganwald.posterous.com/i-cannot-rightly-apprehend-the-confusion-of-i">confrères</a> <a href="http://twitter.com/jamesshore/status/22397246167326720">anglophones</a>, de traduire <a href="http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scientifique-comment.html">ce billet</a>, sous le titre "<a href="http://morendil.github.com/folklore.html">Fact and folklore in software engineering</a>".<br />
<br />
Grâce au relais de HackerNews et de Twitter, l'article a été lu 12000 fois entre sa parution hier et le présent billet, soit moins de 24h. (<a href="http://fr.wikipedia.org/wiki/Quart_d%27heure_de_c%C3%A9l%C3%A9brit%C3%A9">Andy Warhol avait raison</a>.)Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-84662283848071691842010-12-22T02:02:00.000-08:002010-12-22T02:02:22.772-08:00Rétrospectives et capitalisationLundi, en visite chez <a href="http://www.piaction.com/">People In Action</a>, un des partenaires de l'Institut, j'ai eu l'occasion d'une conversation très enrichissante avec <a href="http://twitter.com/ludovicPEROT">Ludovic</a> Perot sur les <a href="http://referentiel.institut-agile.fr/heartbeatretro.html">rétrospectives d'itération</a>. Les équipes de PIA utilisent des pratiques Agiles en interne depuis plus de deux ans, et disposent par conséquent d'un stock important de notes prises à l'occasion de ces rétrospectives. Avec un tel stock il est naturel de finir par se poser la question: que peut-on en faire?<br />
<br />
Les informations collectées pendant une rétrospective constituent des données de terrain, des données empiriques dont l'exploitation peut produire de la connaissance. Encore faut-il savoir comment... et pourquoi.<br />
<br />
Quand on parle de "connaissance" dans ce domaine, l'une des questions importantes est de savoir quels enseignements <b>généralisables</b> on peut tirer de notre propre expérience.<br />
<br />
Une ou plusieurs rétrospectives peuvent nous apprendre des choses comme: "quelle que soit l'heure que nous fixons pour la réunion quotidienne Bob a toujours 10 minutes de retard", ou bien "les repas de fin d'itération ne sont pas très motivants parce qu'on ne trouve pas de resto sympa dans le quartier". Ces informations peuvent être utiles localement - elles peuvent susciter des décisions appropriées - mais on aura du mal à les généraliser: à en tirer quelque chose d'utile pour d'autres projets ou pour d'autres entreprises.<br />
<br />
Un enseignement qui se généralise bien pourra souvent s'exprimer sous la forme d'une règle, d'un mécanisme, ou d'un principe: "à chaque fois que A on observe B", ou "dans un contexte caractérisé par X, la pratique Y est plus bénéfique que la pratique Z".<br />
<br />
On pourrait établir une hiérarchie des moyens utilisés pour traiter des données empiriques de terrain, selon l'opportunité qu'elles offrent d'en tirer des conclusions généralisables:<br />
<ul><li>une unique <b>rétrospective d'itération</b> ne permet que de formuler des hypothèses - elle concerne des éléments très ponctuels, qu'il est difficile de généraliser même s'ils sont localement utiles</li>
<li>l'accumulation de plusieurs rétrospectives d'itération, voire une <b>rétrospective de projet</b>, permet de tirer des conclusions plus claires sur le fonctionnement d'une équipe en particulier: on peut espérer qu'elles se généralisent à de futurs projets confiés à cette même équipe</li>
<li>la comparaison entre les expériences de plusieurs équipes au sein d'une même entreprise (souvent formalisée par un <b>retour d'expérience</b>) permet de dégager des conclusions plus robustes: si plusieurs équipes ont des expériences convergentes (par exemple "le binômage est une pratique efficace") on peut penser que ces observations s'expliquent par des raisons qui ne dépendent pas de l'équipe (mais peuvent dépendre de facteurs locaux, comme le management ou la culture de l'entreprise)</li>
<li>la comparaison entre les expériences de nombreuses équipes dans des entreprises ou des contextes différents, par exemple dans le cadre d'une <b>étude statistique</b>, permet de tirer des conclusions plus générales encore.</li>
</ul>(Il existe d'autres moyens de tirer des conclusions généralisables de l'étude de données empiriques, tels que l'<b>expérimentation contrôlée</b>, mais je ne cherche pas à faire une liste exhaustive...)<br />
<br />
Pour l'instant il reste encore difficile de mener des études au-delà de l'échelle d'une seule entreprise (l'<a href="http://blog.institut-agile.fr/2010/12/lancement-de-letude-projets-pratiques.html">étude PPO</a> de l'Institut étant une des rares initiatives dans ce domaine sur le sujet des pratiques Agiles), mais je trouve intéressante l'idée d'agréger les résultats de nombreuses rétrospectives.<br />
<br />
D'une part le <b>retour d'expérience</b> est une forme très intéressante, et à juste titre mise en avant dans de nombreuses conférences: il permet à ceux qui y assistent de juger par eux-mêmes dans quelle mesure les résultats présentés peuvent être liés à des facteurs locaux ou sont potentiellement généralisables à leur propre contexte. De nombreuses pratiques Agiles se sont diffusées précisément de cette façon: parce que ceux qui les avaient expérimentées lors d'un ou plusieurs projets en on fait état lors d'une conférence, propageant l'idée à des personnes dans l'assistance qui, à leur tour, quelques mois ou années plus tard étaient venus présenter des résultats positifs à une prochaine édition.<br />
<br />
Mais le retour d'expérience "véridique" est parfois difficile à distinguer d'un discours plus commercial. Sous couvert de dire "voici ce que nous avons fait et pourquoi, et comment ça s'est passé" j'ai trop souvent assisté à des sessions qui ressemblaient à une brochure publicitaire.<br />
<br />
L'utilisation de rapports authentiques collectés lors des rétrospectives d'itération et de projet me semble être un très bon moyen de <b>vérifier la sincérité d'un retour d'expérience</b>.<br />
<br />
En l'occurrence, chez PIA la démarche adoptée a été de comptabiliser les sujets qui revenaient le plus fréquemment lors des rétrospectives d'itération afin d'établir un "hit parade" des pratiques Agiles les plus discutées. Il en sortira au minimum un billet sur le <a href="http://blog.piaction.com/">blog</a> de PIA, mais j'ai aussi insisté auprès de <a href="http://twitter.com/ludovicPEROT">Ludovic</a> pour qu'il envisage de proposer une session à une prochaine conférence.<br />
<br />
Cette conversation m'a également donné une idée pour une exploitation un peu plus formelle des rétrospectives d'itération que je vous exposerai dans un prochain billet.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-16348889066030120822010-12-17T07:36:00.000-08:002010-12-17T07:39:05.398-08:00Les développeurs sont-ils des Morlocks?Il existe une très grande disproportion entre l'importance croissante des métiers du logiciel dans la société, et l'attention qu'on porte à ces métiers dans le discours public.<br />
<br />
(Les métiers du logiciel, c'est au sens large toutes les activités spécialisées qui tournent autour de la production de logiciel ou de systèmes à base de logiciel: les développeurs évidemment, puisqu'ils sont directement responsables de la création du "matériau" logiciel, mais également les testeurs, les ergonomes, les "exploitants"... Dans ce qui suit j'utiliserai le mot "programmeur" exclusivement mais c'est à tous ces métiers que je pense.)<br />
<br />
Les technologies logicielles sont très récentes, les mots pour les désigner ("software") ne remontent qu'à la fin des années 50 (en France on invente "logiciel" en 70 et il devient officiel dix ans après). Pourtant elles se son répandues jusqu'à l'ubiquité, ou presque. Comptez le nombre d'actes quotidiens que vous effectuez chaque jour qui ne sont possibles que grâce aux créations d'un programmeur: connaissez-vous beaucoup de métiers à ce point indispensables?<br />
<br />
Pourtant les programmeurs sont quasi-invisibles: on n'en parle jamais, ou très rarement, me semble-t-il, dans "les média" - journaux, télévision ou radio - destinés au grand public. (Si vous n'êtes pas d'accord, par pitié, citez vos sources!)<br />
<br />
On penserait presque aux Morlocks, les êtres souterrains que dévoile H.G. Wells dans <i>La machine à remonter le temps</i>. Le narrateur rencontre d'abord les Eloi, des créatures qui ont la beauté et l'innocence des enfants et vivent à l'abri de tout souci matériel; mais cette situation paradisiaque n'est possible que grâce au travail invisible des Morlocks, indispensables mais dont on nie l'existence en raison du terrible prix de leurs services...<br />
<br />
Non, on n'a jamais vu un développeur manger littéralement un utilisateur, mais je crois que nous payons de plus en plus nombreux un lourd tribut à ceux qui crééent les programmes sur lesquels notre quotidien s'appuie: le prix de la non-qualité, des frustrations perpétuelles devant la machine qui vient de "bouffer" un document qu'on a passé des heures à rédiger, des engins qui sont censés "parler" entre eux mais qui ne veulent pas se reconnaître, des téléphones qui "plantent" en milieu de conversation...<br />
<br />
Mais aussi (et là on s'approche peut-être plus du destin des Eloi) des <a href="http://fr.wikipedia.org/wiki/Therac-25">appareils médicaux qui irradient des patients</a>, ou des <a href="http://erichmusick.com/writings/06/las_failure.html">ambulances qui n'arrivent pas à temps</a>. Ces incidents graves font d'ailleurs partie des rares occasions où l'on parle brièvement de ce substrat invisible de la société moderne qu'est le logiciel. <br />
<br />
Est-ce, d'ailleurs, à cause de la quasi-totale invisiblité de nos professions que l'éducation des programmeurs est à ce point déficiente? Ou bien est-ce parce que nous n'arrivons pas, justement, à exister en tant que professionnels qu'on ne parle pas de nous? Où est l'effet, et où est la cause?Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com3tag:blogger.com,1999:blog-479555891921312205.post-56664517350149921132010-12-13T07:21:00.000-08:002010-12-13T07:55:05.673-08:00Lancement de l'étude Projets - Pratiques - Objectifs<b>Version courte:</b> l'Institut Agile lance aujourd'hui son étude "Projets - Pratiques - Objectifs" (PPO), et si vous utilisez des pratiques Agiles sur vos projets, <b>vous pouvez nous aider</b>. Il suffit pour cela de <a href="http://www.surveygizmo.com/s3/428510/4f02d5455835">remplir ce questionnaire préliminaire en ligne</a>, très court, de le faire très largement circuler autour de vous, et d'indiquer si vous êtes volontaire pour participer à l'étude complète.<br />
<ul><li>Le <a href="http://www.surveygizmo.com/s3/428510/4f02d5455835">questionnaire exploratoire</a> sur SurveyGizmo</li>
<li>Le <a href="https://github.com/Morendil/PPO-Study">descriptif</a> de l'étude (en anglais) sur Github</li>
<li>L'article "<a href="http://www.paskaward.org/publications/bossavit100225.html">When Agile Met Data</a>" </li>
</ul>Cette étude est soutenue par un <a href="http://www.agilealliance.org/programs/">programme de l'Alliance Agile</a> ainsi que par les partenaires de l'Institut: Microsoft, Neoxia, Exakis, People In Action, Axones, UT7, Agile To You, Yaal, Agilidée. <br />
<ul></ul><b>Version longue:</b><br />
<br />
Depuis plus de dix ans que l'on parle d'Extreme Programming, de Scrum et plus généralement de pratiques Agiles, se fait entendre une question récurrente tant de la part des adeptes que des simples curieux ou des critiques: "où sont les chiffres prouvant que ça fonctionne ?"<br />
<br />
Pour illustrer ce que fut pendant longtemps la réponse de la communauté à cette question, voici ce qu'on peut lire entre autres dans <a href="http://web.archive.org/web/20030104213730/http://www.agilemodeling.com/essays/proof.htm">la première version, publiée fin 2002, d'un essai de Scott Ambler</a>:<br />
<ul><li> les approches Agiles sont toutes nouvelles, il n'y a donc pas eu le temps de collecter des chiffres</li>
<li>l'exigence en matière de "preuve" est excessive, et sert en fait d'excuse à ne pas s'intéresser au sujet</li>
<li>l'approche Agile s'intéresse précisément à d'autres aspects que ceux mesurés jusqu'à présent, par exemple la réponse au changement plutôt que le respect du plan initial</li>
</ul>Ambler explique par ailleurs que sur certains aspects précis, comme la programmation en binômes ou le développement par les tests, on commence dès cette époque à voir paraître des résultats empiriques. Mais son argument principal reste qu'il <b>n'est pas légitime</b> de demander aux évangélistes de l'approche Agile des preuves quantitatives.<br />
<br />
<b>Dix ans après...</b><br />
<br />
J'ai souvent l'occasion de le répéter ces jours ci, la situation a beaucoup changé au cours des dix dernières années. Suffisamment changé pour que les objections ci-dessus n'aient plus cours, à mon sens:<br />
<ul><li>dans les années 2000-2006, la communauté Agile militait pour obtenir des entreprises où nous travaillions la permission d'utiliser ces approches; aujourd'hui non seulement cette permission est accordée, l'initiative de leur mise en place vient de plus en plus des entreprises elles-mêmes, les projets se réclamant d'une approche "Agile" se multiplient, et par conséquent depuis au moins quelques années <b>la matière existe</b> à établir des résultats quantitatifs;</li>
<li>il n'est pas exact que ce sont les "réfractaires" qui exigent ces preuves; on s'aperçoit à l'usage que dans les entreprises qui souhaitent sincèrement en généraliser l'utilisation, certaines fonctions, par exemple les acheteurs, <b>utiliseraient ces chiffres s'ils étaient disponibles</b> pour orienter leurs choix;</li>
<li>la question "quoi mesurer" n'est sans doute pas la plus importante, en tout cas tant que la communauté Agile continue... à <b>ne pas mesurer grand-chose</b>.</li>
</ul>La <a href="http://www.agilemodeling.com/essays/proof.htm">version la plus récente</a> de l'article d'Ambler cite désormais des résultats chiffrés, en dépit de cette posture qu'on aurait pu interpréter comme défensive; en fait, Ambler a initié depuis quelques années un <a href="http://www.ambysoft.com/surveys/">grand nombre d'enquêtes</a> visant à répondre à ces demandes d'éléments quantitatifs.<br />
<br />
Là où le bât blesse, c'est qu'il s'agit de questionnaires diffusés via le Web. De tels questionnaires peuvent donner un aperçu fort utile de la popularité de divers éléments du <i>discours</i> agile, mais ils ne sont pas adéquats pour tirer des conclusions généralisables quant à la <i>pratique</i>, sur le terrain, de ces approches et quant aux résultats obtenus.<br />
<br />
Il existe par ailleurs un certain nombres d'études académiques sur le mode de l'étude de cas ou de l'expérimentation contrôlée. Il s'agit, respectivement, soit de suivre de près un projet pour mieux mettre en évidence les mécanismes par lesquels une approche Agile apporte (ou non) les bénéfices prétendus; soit de réaliser un protocole expérimental qui permettra d'isoler un facteur particulier en confrontant deux situations entre lesquelles ce facteur est la seule différence. Dans les deux cas, il s'agit de travaux de longue haleine et nécessitant d'importants investissements, en termes de temps et d'argent.<br />
<br />
<b>Les données manquantes</b><br />
<br />
Ce qui n'a pas (ou très peu) été réalisé jusque là, c'est une collecte <i>directe</i> des données de terrain qui se généralisent: celles produites par les projets de plus en plus nombreux qui, dans un nombre également croissant d'entreprises d'horizons très divers, mettent en place des pratiques Agiles pour des raisons purement pragmatiques - ce qui veut dire, dans bien des cas, sans se soucier beaucoup de la "pureté" de leur approche, mais en adoptant au cas par cas les pratiques qui leur semblent judicieuses.<br />
<br />
Les conférences, telles <a href="http://conf.agile-france.org/">Agile France</a> (anciennement XP Day France, issue du cycle européen XP Day), donnent à la communauté une excellente occasion de livrer des informations empiriques, sous la forme de retours d'expérience (REx pour les accros des acronymes). Ils ont été et continuent à être une bonne source d'informations <i>qualitatives</i>.<br />
<br />
Ils ont cependant un talon d'Achille, la fiabilité des informations produites. En effet, lors de la présentation d'un retour d'expérience il est facile d'attribuer ses succès à des pratiques qui n'y ont pas beaucoup contribué; de passer sous silence certaines erreurs ou épisodes embarrassants, et ce d'autant plus qu'on citera le nom de l'entreprise où l'on travaillait. Par ailleurs un retour d'expérience suppose que le projet soit allé au bout, on va donc éliminer d'emblée les projets qui ont échoué très rapidement; de la même manière on occultera souvent ce qui se passait en début de projet au bénéfice des événements les plus récents.<br />
<br />
<b>L'étude PPO</b><br />
<br />
L'objectif de l'étude PPO est de traiter des projets de façon longitudinale, afin d'obtenir des résultats quantitatifs susceptibles d'un traitement statistique. Elle vise à identifier et décrire des projets le plus tôt possible afin d'éviter les biais de sélection, par exemple celui qui ne consisterait à décrire que les projets ayant réussi ou qui se sont terminés à peu près dans les conditions initialement prévues.<br />
<br />
Les questions auxquelles l'étude vise à répondre sont les suivantes:<br />
<ul><li>quelles pratiques sont choisies pour obtenir quels objectifs (délais, qualité, productivité...)?</li>
<li>quelles pratiques s'avèrent faciles ou difficiles à adopter?</li>
<li>quelles pratiques <i>effectivement adoptées</i> contribuent réellement aux objectifs fixés?</li>
</ul>Afin d'obtenir des réponses fiables, l'étude s'appuiera sur le Référentiel des pratiques, et s'appuiera pour la collecte des données sur des entretiens (idéalement en personne, au besoin par téléphone) avec les intervenants et décideurs des projets concernés, par exemple pour évaluer le degré d'utilisation réelle des pratiques Agiles déclarées.<br />
<br />
L'Institut Agile bénéficie d'une position privilégiée pour répondre à ces questions: c'est une entité neutre et indépendante qui peut donner aux entreprises participantes des garanties de confidentialité des données qui lui seront confiées. L'Institut s'emploie à plein temps à ce rôle d'observateur de la mise en place sur le terrain des pratiques Agiles, ce travail ne souffrira donc pas d'interférences comme cela peut être le cas pour une entreprise ayant par ailleurs des activités commerciales qui entâcheraient son objectivité, ou des consultants freelances qui pourraient être accaparés par leur activité.<br />
<br />
Si vous êtes intéressés pour participer à cette étude et aider à mieux mettre en lumière les effets réels des pratiques Agiles, n'hésitez pas à vous manifester en remplissant le <a href="http://www.surveygizmo.com/s3/428510/4f02d5455835">questionnaire</a>!Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-75290874404525326562010-12-09T00:39:00.000-08:002010-12-09T00:39:23.501-08:00Le Principe de GilbAujourd'hui, en préparant une mise à jour majeure du <a href="http://referentiel.institut-agile.fr/">Référentiel</a>, je me suis "reposé" de l'écriture du code d'indexation (en Ruby) en écrivant quelques fiches, dont celle de la pratique "<a href="http://referentiel.institut-agile.fr/nikoniko.html">Niko Niko</a>", un import japonais d'autant plus intéressant qu'il m'a donné l'occasion de rappeler le Principe de Gilb<br />
<blockquote>Si vous avez besoin de quantifier quelque chose, il existe toujours une manière de le faire qui soit préférable à ne pas le quantifier du tout.</blockquote><br />
Le Principe de Gilb est un bon antidote à l'un des travers les plus pernicieux du management des projets de développement logiciel: quand on se pique de gérer ces projets de façon empirique, en se basant sur des éléments objectifs et donc quantifiés, on finit en général par ne mesurer... que ce qui est <i>facile</i> à mesurer, mais rarement ce qui est <i>pertinent</i>.<br />
<br />
Par exemple, la motivation, le bien-être d'une équipe ont généralement un effet déterminant sur les résultats qu'elle obtient. Mais comme aucun élément objectif ne permet de rendre ces paramètres immédiatement visibles, ces préoccupations passent souvent au second plan dès qu'on utilise par ailleurs des chiffres rendant compte de la productivité ou de la qualité.<br />
<br />
Dans une approche Agile on cherche à mesurer en premier lieu ce qui est pertinent, ce qui est déterminant, même quand c'est difficile à mesurer. Et si on ne sait pas mesurer ce qui a de l'importance, ça n'a pas de sens de dépenser énergie et créativité à mesurer ce qui n'en a pas.<br />
<br />
Attention toutefois: le Principe de Gilb ne dit pas que quantifier quelque chose qui ne l'était auparavant pas est systématiquement une bonne chose, et surtout pas que quantifier <i>en vue d'encourager les équipes à atteindre des objectifs chiffrés</i> est une bonne chose. (Lisez en particulier l'excellent <a href="http://www.amazon.fr/dp/0932633366"><i>Measuring and Managing Performance in Organizations</i></a> si jamais la tentation vous vient du "management par les objectifs chiffrés".)Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-36186180471088182392010-12-03T01:17:00.000-08:002010-12-03T01:30:06.455-08:00Devops - premières rencontres et survolCe mercredi 1er décembre j'ai eu le plaisir de participer à la première rencontre <span id="goog_1381284157"></span><a href="http://www.blogger.com/">Devops<span id="goog_1381284158"></span></a> parisienne; en voici un compte-rendu, et bien sûr je vais tenter de répondre à la question que vous vous posez déjà: "Devops, qu'est-ce que c'est encore que ce bidule ?"<br />
<br />
Commençons par les ingrédients: un petit groupe (une douzaine de personnes) qui se réunissait dans une ambiance informelle et très auto-organisée, la plupart ne connaissant pas les autres participants présents, simplement pour discuter d'un sujet qui leur tenait à coeur: recette classique pour passer une soirée passionnante. (Merci au passage à nos hôtes, <a href="http://www.theodo.fr/blog/">Theodo</a>, et aux initiateurs, Philippe, Samuel et Fabrice.)<br />
<br />
Ajoutons des bières et des pizzas; en effet "Devops" est un raccourci pour "developers and operations", c'est à dire des intervenants du développement (appelés diversement programmeurs, développeurs, codeurs, "softeux", etc.) et de l'exploitation ("exploitants", ingénieurs de production, administrateurs systèmes, etc.). Vous aurez compris qu'on est entre techniciens...<br />
<br />
Pourtant il y a là deux cultures très différentes, et on s'en aperçoit vite à mesure que le tour de table pour faire les présentations commence, chacun y allant de son "troll", petite pique pour deviner à la réaction de chacun qui fait partie de quel bord, ça donne à peu près: "je m'appelle X et je préfère vi à emacs, il faut que j'en dise plus?" Le sujet qui nous réunit c'est justement le rapprochement entre deux cultures que l'organisation usuelle des projets de développement a eu tendance à séparer. (Parfois littéralement, au sens "les développeurs dans la grande salle du 3è étage, les exploitants à la cave".) Certains des effets néfastes de cette séparation sont proverbiaux dans la profession: "excuse n°1 du développeur: ça marche sur ma machine!".<br />
<br />
Après le tour de table <a href="http://raphael.pierquin.com/">Raphaël</a> a proposé d'organiser le reste de la réunion en Open Space, ce qui nous a permis d'apprécier l'étendue des sujets qui nous intéressaient. De mémoire et en vrac:<br />
<ul><li>des outils (Chef ou Puppet) pour gérer les configurations système</li>
<li>exploiter la virtualisation du développement à l'exploitation</li>
<li> intégrer la création de packages dans le build automatisé</li>
<li>déploiement maîtrisé des applications Web </li>
<li>...et d'autres que j'oublie...</li>
</ul> Cette liste ne vous apprend sans doute pas grand-chose sur ce que veut dire "Devops"? C'est justement tout l'intérêt de cette communauté naissante.<br />
<br />
Je m'explique: de façon très similaire à l'invention en 2001 du terme "Agile", la communauté Devops est née du sentiment diffus d'un certain nombre de personnes qu'elles avaient, chacune dans leur coin, eu des idées convergentes pour résoudre des difficultés lancinantes dans leur métier. En se rencontrant et en donnant un nom (une <a href="http://blog.institut-agile.fr/2010/09/dans-une-bonne-bouteille-vous-buvez.html">étiquette</a>, certes) à cette convergence elles espèrent donner plus de visibilité à la fois à ces difficultés et aux solutions proposées.<br />
<br />
Il s'agit donc de briser les "silos" qui isolent les développeurs et les exploitants chacun dans leur coin, avec de nombreuses conséquences néfastes: par exemple des projets qui semblent "réussis" techniquement (code propre et bien testé) et fonctionnent très bien... jusqu'au jour de la "mise en prod" où rien ne va plus: quelques connections simultanées et le serveur "tombe", ou encore une base de données ralenties par des accès mal conçus.<br />
<br />
On retrouve dans cette volonté de "déspécialiser" une constante de la culture Agile, au sein de laquelle d'ailleurs les fondateurs de Devops ont fait leurs armes. Le discours Agile a cherché à modifier, voire à effacer les frontières entre développeurs et clients, entre développeurs et testeurs, ou plus récemment entre développeurs et ergonomes; Devops vise à abolir une frontière supplémentaire. Plutôt que développer dans leur coin des applications qu'ils vont ensuite "balancer par-dessus le mur" aux exploitants, les développeurs sont encouragés à travailler dès le début du projet avec eux et à les intégrer à l'équipe.<br />
<br />
De même que le discours Agile s'oppose à des approches "cérémoniales" ou totalisantes du développement, de même Devops se positionne comme une réponse "Agile" aux démarches <a href="http://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library">ITIL</a> ou <a href="http://fr.wikipedia.org/wiki/Cobit">Cobit</a> très prisées dans le domaine de l'exploitation.<br />
<br />
On retrouve donc dans l'approche Devops, d'une part des outils et pratiques "empruntés" à l'approche Agile:<br />
<ul><li>outils de management <a href="http://www.itpi.org/home/visibleops.php">visuel (on parle de "visible ops")</a> pour créer de la transparence</li>
<li>alignement sur un rythme itératif et incrémental (mettre en production au rythme du développement)</li>
<li>automatisation du test</li>
<li>intégration continue</li>
</ul>Mais on va également trouver dans Devops des solutions spécifiques, transposant l'approche Agile au métier de l'exploitation, ou qui visent à établir un nouveau contrat avec les développeurs:<br />
<ul><li>l'automatisation du "build" ne doit pas se cantonner à produire un exécutable mais va jusqu'au bout de la chaîne en produisant un "package" dont l'installation est répétable et même automatisable</li>
<li>considérer la description d'une infrastructure système comme du code, et intégrer ce code à la gestion de version au même titre que le code applicatif; c'est l'intérêt d'outils comme <a href="http://www.opscode.com/chef/">Chef</a> ou <a href="http://reductivelabs.com/products/puppet/">Puppet</a></li>
<li>de même qu'on ne teste pas à la main, on n'installe pas à la main, on ne configure pas à la main, etc. - tout ce qui est manuel <b>et</b> répétitif représente de la connaissance et il faut capturer cette connaissance sous la forme de fichiers texte ou de code</li>
<li>intégrer très tôt dans le cycle de développement les questions de surveillance et de gestion de l'application, de benchmarking des performances, etc. - en d'autres termes adopter une vision d'ensemble</li>
<li>plus généralement considérer qu'on est "tous dans le même bateau" et qu'il n'est pas productif de chercher "à qui reviennent les reproches" lors d'un incident en production: abolir les petits jeux qu'on voit fréquemment pour savoir si c'est un bug ou un défaut de surveillance qui est à l'origine d'une panne par exemple; adopter des outils, des processus et surtout une responsabilité partagées</li>
</ul>Vous pourrez trouver plus d'information ailleurs sur le Web:<br />
<ul><li><a href="http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/">What is this Devops thing, anyway?</a> de Patrick Debois </li>
<li><a href="http://code.google.com/p/devops-toolchain/wiki/BestPractices">Devops Best Practices</a> (concis et précis)</li>
<li><a href="http://devops-br.posterous.com/what-is-devops-the-agile-admin">What is Devops?</a> de Rodrigo Campo</li>
<li><a href="http://dev2ops.org/blog/2010/2/22/what-is-devops.html">What is Devops?</a> de Damon Edwards </li>
</ul>Les parallèles avec la communauté Agile sont intéressants, notamment le fait que la question "qu'est-ce que DevOps" ne donne pas pour l'instant lieu à une réponse brève, précise et circonstanciée, le mouvement se dérobant aux tentatives de définition. On pourrait le réduire à des outils: de fait au cours de la soirée de mercredi nous avons beaucoup parlé d'outils (j'ai découvert l'existence de Chef, Puppet, Vagrant et d'autres outils et je vais m'y intéresser, par curiosité et pour ma culture générale), mais ce serait la même erreur que de réduire l'approche Agile à des outils.<br />
<br />
Dans les deux cas, il ne s'agit ni de définir des méthodologies, d'imposer des processus ou des outils, mais de créer, d'animer et de se réclamer d'une communauté; l'objet de cette communauté étant l'élaboration et la conservation d'un ensemble de pratiques, non pas pour leur valeur en soi (on ne "sacralise" pas les pratiques) mais pour les bénéfices que ces pratiques apportent aux projets.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com3tag:blogger.com,1999:blog-479555891921312205.post-39864343127001476142010-12-01T02:30:00.000-08:002010-12-01T02:30:51.740-08:00De l'éducation des programmeursDimanche dernier je faisais du ménage... sur mon disque dur: je faisais du tri parmi les nombreux articles sur le génie logiciel amassés depuis des années sur mon disque dur, et je suis tombé sur un essai de David Parnas, "Software Engineering: An Unconsummated Marriage". Une citation m'a accroché l'oeil:<br />
<blockquote>We rarely mention the most basic problem: most programmers are not well educated for the job they do. -- David Parnas</blockquote>J'ai trouvé la phrase percutante et je l'ai <a href="http://twitter.com/Morendil/status/8849426902683648">postée</a> sur Twitter. Je vous rappelle que nous sommes un dimanche... Au bout de quelques heures elle avait été "retweetée" par plusieurs dizaines de personnes.<br />
<br />
Un "retweet" sur cet outil social réservé aux personnes ayant la durée d'attention d'un moustique (je plaisante...), c'est une façon de dire "bien vu", "je suis d'accord", ou "c'est intéressant". Evidemment c'est une phrase sortie de son contexte - d'ailleurs dans l'article d'origine Parnas argumente pour une profession d'ingénieur logiciel régie par des codes de bonne conduite, des licenses professionnelles obligatoires, et toutes sortes de choses que la communauté Agile réprouve.<br />
<br />
Mais quand même, je m'interroge sur cette phrase et le fait qu'elle semble toucher à ce point une corde sensible dans mon "réseau social". Il m'arrive d'avoir d'autres idées que je trouve pertinentes, mais aucune n'a jamais été aussi populaire, en tout cas sur Twitter, que ce simple constat: "Les programmeurs sont très mal éduqués".Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com4tag:blogger.com,1999:blog-479555891921312205.post-37881032349478842152010-11-29T02:26:00.000-08:002010-11-29T02:26:31.320-08:00MD Day - agilité, modélisation et modélismeJeudi dernier, le 25 novembre, se tenait le quatrième <a href="http://www.mdday.fr/">MD Day</a>, une journée intéressante à plus d'un titre.<br />
<br />
La conférence était hébergée dans le très beau centre de conférences de Microsoft à Issy, auquel le seul reproche que je puisse faire est une connectivité 3G limitée (et je n'avais pas les infos pour me connecter au réseau WiFi en tant qu'invité). Cela n'a pas empêché de <a href="http://search.twitter.com/search?q=mdday">nombreux commentaires sur Twitter</a>.<br />
<br />
Cette année le thème retenu était "Model-Driven et Agilité", un lien thématique qui se traduisait dans le programme: le mot "agilité" apparaissait dans le titre de quatre des 10 sessions prévues, plus une "table ronde" au sein de laquelle Xavier Warzee et votre serviteur avaient pour mission de représenter le point de vue Agile.<br />
<br />
J'étais un peu anxieux à l'idée d'apporter en quelque sorte une "caution" Agile à un événement organisé autour d'une approche du développement, le fameux "model-driven", à laquelle je n'adhère personnellement pas et qui peut sembler aux antipodes du discours Agile: en caricaturant, elle semble marginaliser le rôle du développeur (remplacé par la génération automatique de code) au profit de celui de l'architecte (traçant des diagrammes de modèles dans le but de les convertir en code automatiquement).<br />
<br />
Lors d'une <a href="http://www.docstoc.com/docs/55810509/Agilit--monter-soi-mme">intervention</a> aux Valtech Days il y a quelque temps, j'avais ainsi opposé "modélisation" et "modélisme":<br />
<blockquote>En fait de modélisation, on pratique trop souvent ce que j'appellerai le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.</blockquote>On peut illustrer le "modélisme" par <a href="http://www.umlgraph.org/doc/er-sqo-oss.png">ce diagramme</a> par exemple, obtenu à l'aide d'un outil UML qui analyse du code existant. Trente classes différentes sur un seul diagramme ce n'est tout simplement pas lisible, pertinent, ou utile: c'est uniquement une perte de temps.<br />
<br />
Il me semblait cependant important d'accepter l'invitation, pour plusieurs raisons. D'une part, je suis favorable aux échanges entre les diverses communautés de professionnels qui se retrouvent autour d'une volonté commune d'améliorer leur pratique d'un métier, en l'occurrence le développement de logiciels. D'autre part, la communauté "model driven" me semble avoir un rapport plus étroit avec le milieu de la recherche, privée ou publique, que la communauté Agile, et l'une des missions de l'Insittut est de resserrer ces liens.<br />
<br />
De ce point de vue, l'important était de participer. Mais je me devais d'apporter un regard plus attentif, et dès le début de la journée je m'étais fixé comme objectif de répondre à la question suivante: la communauté "model driven" ici présente est-elle motivée par un réel intéret pour les <a href="http://blog.institut-agile.fr/2010/10/synthese-referentiel-des-pratiques.html">pratiques</a> agiles, ou s'agit-il (pour l'instant) d'une simple curiosité, piquée par le "buzz" de plus en plus présent autour de l'<a href="http://blog.institut-agile.fr/2010/09/dans-une-bonne-bouteille-vous-buvez.html">étiquette</a> "Agile"?<br />
<br />
Mon canevas d'évaluation était, comme il se doit, le <a href="http://agilemanifesto.org/iso/fr/">Manifeste Agile</a> et la liste des pratiques Agiles: lors des sessions, est-ce que les orateurs évoquaient ce qui, dans leurs solutions proposées, privilégiait les individus et les interactions, la livraison de logiciels opérationnels, la collaboration avec le client, et la réponse au changement? Est-ce que les orateurs mettaient en avant l'inclusion dans une stratégie "model-driven" de telle ou telle pratique appartenant à la "boîte à outils" Agile? J'ai prévenu les orateurs des différentes sessions auxquelles j'assistais, afin de ne pas les prendre en traitre, de mon intention de distribuer en fin de journée un "carnet de notes" avec mention des bons et des mauvais élèves.<br />
<br />
Alors, <b>quel bilan</b> de cette journée?<br />
<br />
Force est de constater qu'il y a encore loin de la coupe au lèvres, et que la communauté "model-driven" n'est pas encore pleinement Agile. Le mot "agile" était plus utilisé pour légitimer un discours déjà établi, que pour y chercher un véritable contenu pouvant constituer un apport.<br />
<br />
La première présentation, celle de Grégory Weinbach et Jérémie Grodziski, se distinguait par un rappel explicite du Manifeste Agile, et un véritable "zoom" sur des pratiques, en l'occurrence le Behaviour-Driven Development (BDD) et le Ubiquitous Language issu de l'approche Domain-Driven Design. D'autres éléments Agiles y étaient présents, portant à... quatre le nombre des pratiques Agiles mentionnées lors de cette intervention. C'est honorable mais sans doute en-deça de ce qu'il serait possible de faire en combinant les deux approches, et je suis resté un peu sur ma faim.<br />
<br />
Malheureusement, le reste de la journée n'allait pas combler mon appétit pour une mise en valeur de pratiques et de réalités de terrain: les autres sessions auxquelles j'ai assisté se résumaient à peu de choses près à des démos d'outils. La session proposée par l'éditeur W4 abordait (en passant) deux pratiques que j'ai pu reconnaitre comme issues du discours Agile, mais il aurait été plus juste de parler de <a href="http://fr.wikipedia.org/wiki/D%C3%A9veloppement_rapide_d%27applications">RAD</a> pour caractériser l'approche présentée. Pour les autres les retours clients étaient (à mon goût) réduits au strict minimum et laissaient la part belle au "pitch" de l'ingénieur commercial montrant (tout seul au clavier) ce qu'on peut faire avec l'outil.<br />
<br />
J'ai été particulièrement frappé par une remarque d'un des orateurs, en fin de journée: "pour la suite je vous demande de m'excuser mais il va falloir que je rentre un peu dans les détails du métier de l'assurance...". Mais non, c'est <b>justement l'attention portée au métier de vos clients</b> qui fait, en tout cas pour moi et en tant "qu'Agiliste", toute la valeur et la saveur de votre retour d'expérience.<br />
<br />
Car encore une fois, <b>qu'est-ce que modéliser</b> sinon <b>poser des questions </b><b>à un client</b> dont, en tout cas en début de projet, <b>on ne connaît pas le métier</b>? Pour être vraiment convaincante, une démonstration de l'approche "model driven" soutenue par un outil devrait se tenir sous la forme suivante: on choisit au hasard dans l'assistance une personne qui propose une situation à traiter, issue d'un domaine d'expertise non technique - ou même de la vie courante, par exemple "gérer la fréquentation d'un musée" ou "réserver une table au <a href="http://wiki.agile-france.org/cgi-bin/wiki.pl?DojoDeveloppement/Mardi24Mai2005">restaurant</a>" - et on construit <b>en direct</b> une solution à base de modèles. C'est à mon avis dans ce genre d'exercice qu'on s'apercevrait le mieux des bienfaits ou des limites de tel outil ou de telle approche.<br />
<br />
Quand on l'aborde sous cet angle, celui où développer des logiciels consiste à encoder et formaliser des connaissances sur un domaine, la distinction entre "code source" et "modèle" commence à mon sens à s'effacer, proposition qui m'a servi de conclusion lors de la table ronde. Toutes les préoccupations que nous avons vis-à-vis du code source sont applicables aux modèles, dès lors que nous sortons du "modélisme" (faire de beaux documents visuels) et que nous cherchons à répondre à la demande d'un client: est-ce que le résultat est <b>correct</b> (ne donne pas des réponses fausses), est-ce qu'il est <b>utilisable </b>(son ergonomie s'adapte à l'utilisateur), est-ce qu'il <b>créée de la valeur</b>?<br />
<br />
Dans une approche qui consiste à créer des modèles pour générer automatiquement du code source, cette seconde étape s'apparente à de la compilation, par conséquent le modèle devient le véritable code source. Mais d'un autre côté on constate que les langages modernes (par exemple Ruby) permettent de plus en plus, par le biais de l'abstraction et de techniques comme les <a href="http://fr.wikipedia.org/wiki/Domain-specific_programming_language">DSL</a>, de séparer les préoccupations purement techniques et algorithmiques de l'expression (dans le même langage) des connaissances sur le domaine fonctionnel et des exigences: le code source devient tout à fait adéquat pour exprimer ce qu'on appele en général le "modèle".Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com11tag:blogger.com,1999:blog-479555891921312205.post-41914547661347009632010-11-19T05:22:00.000-08:002010-11-19T05:22:37.557-08:00Mauvaises conception de la conceptionMon <a href="http://prezi.com/yuirqsqxl7cd/">exposé</a> sur les pratiques Agiles liées à la conception a été très bien accueilli à Reykjavik, dont je suis revenu hier très fatigué mais aussi très content.<br />
<br />
Mon principal objectif était de faire le lien entre les connaissances accumulées depuis quelques décennies sur les biais cognitifs et l'activité de conception ou "design". J'y ai déjà fait allusion dans mes billets précédents évoquant la <a href="http://blog.institut-agile.fr/2010/11/la-danseuse-et-la-dette-technique.html">danseuse</a> et les <a href="http://blog.institut-agile.fr/2010/11/des-bugs-dans-le-cerveau-aux-bugs-dans.html">bugs du cerveau</a>.<br />
<br />
<b>Le point sur la conception</b> <br />
<br />
Cet exposé était aussi l'occasion de faire le point sur ce qu'ont été les apports du mouvement Agile au discours sur la conception.<br />
<br />
Le terme anglais "<a href="http://en.wikipedia.org/wiki/Design">design</a>" est très surchargé, que ce soit dans la vie courante (une brosse à dents ou un siège peuvent "être design", c'est une <a href="http://fr.wikipedia.org/wiki/Design">discipline</a> artistique mais aussi industrielle) ou dans le champ professionnel du logiciel, où il peut suggérer aussi bien l'ergonomie (product design, interaction design), l'esthétique (graphic design), la représentation de l'information (<a href="http://en.wikipedia.org/wiki/Information_design">information design</a>), ou enfin la conception logicielle à proprement parler.<br />
<br />
La terminologie francophone laisse peut-être légèrement moins de place à l'ambiguité, quand on parle de "conception" ce sont le plus souvent les programmeurs qui se sentent concernés.<br />
<br />
<b>Avis de décès?</b><br />
<br />
En 2000 paraissait un article important de Martin Fowler, intitulé "Is Design Dead?". A l'époque on ne connaissait que peu Scrum, le "buzz" se concentrait autour d'Extreme Programming et ni l'un ni l'autre de ces discours n'était encore appelé "Agile" - ce n'est qu'à partir de 2001 que le terme issu de la rencontre de Snowbird sera adopté.<br />
<br />
On sortait d'une période qui avait vu UML triompher après un long et intense débat sur les notations formelles graphiques, bien illustré dans <a href="http://en.wikipedia.org/wiki/File:OO-historie.jpg">ce dessin</a>. Pour une grande partie de la profession, "UML" et "conception logicielle" étaient devenus des synonymes.<br />
<br />
Fowler relevait l'une des principales critiques à l'égard d'Extreme Programming, auquel on reprochait d'être "centré sur le code". Et de constater le rejet par Extreme Programming non seulement d'UML mais de plusieurs dogmes tout aussi fortement associés à l'idée de conception: le principe d'une "phase de conception" venant en amont de la phase de programmation, celui d'organiser le développement autour de "frameworks" ou de "patrons de conception".<br />
<br />
Pour certains, selon Fowler, Extreme Programming semblait vouloir en finir avec la conception. Martin Fowler était en bonne position pour arbitrer ce débat: il était non seulement le co-auteur d'un <a href="http://www.amazon.com/dp/020165783X">bréviaire</a> sur UML qui avait connu des ventes record, mais également d'un livre sur le "refactoring" connu comme l'une des pratiques clés d'Extreme Programming, et considéré commel'une des figures tutélaires de cette mouvance.<br />
<br />
Non, concluait Fowler, Extreme Programming n'appellait pas à la mort de la conception ni n'annonçait son décès; et Fowler d'attester, en analysant de près les recommandations effectivement émises par Extreme Programming, que la conception y restait une préoccupation majeure, et que ses critiques avaient eu une vision caricaturale de la conception.<br />
<br />
<b>Trois mises au point sur la conception</b><br />
<br />
Extreme Programming, et à sa suite le mouvement Agile, ont ainsi permis de rectifier, ou de commencer à rectifier, un certain nombre d'idées fausses sur la conception, et trois exemples me paraissent particulièrement importants.<br />
<br />
<b>La conception n'implique pas nécessairement une notation formelle qui s'exprime visuellement.</b> Cette idée a longtemps été le cheval de bataille des tenants d'UML, et le triomphe d'UML au tournant de l'an 2000 était partiellement le triomphe de cette idée. Par un raccourci de pensée jamais justifié "visuel" était présenté comme synonyme de "supérieur": parce que UML permettait de modéliser visuellement, il était un meilleur véhicule pour parler de conception. Corollairement, le code source lui-même, n'étant que textuel, ne pouvait pas être un support approprié pour exprimer des notions de conception.<br />
<br />
Le succès des approches Agiles a contribué à remettre les pendules à l'heure. Toutes les modalités d'expression - visuelles, textuelles, ou autres - ont leur place pour parler de conception. La question est moins de savoir comment représenter le résultat des activités de conception, mais plutôt de savoir <b>qui</b> doit y participer, et par conséquent <b>où</b> elles doivent se dérouler. L'approche privilégiée par les équipes agiles est celle de la "modélisation agile" ou des "sessions rapides de conception": cela se passe au tableau blanc, on doit impliquer les développeurs chargés de la réalisation, et s'il faut conserver une trace permanente une photo du tableau suffit largement.<br />
<br />
<b>La conception n'est pas nécessairement une activité qui précède la programmation.</b> Avec UML c'est aussi une approche en phases du projet de développement logiciel qui prévaut. L'accent a été mis sur des outils permettant aux architectes de réaliser un document de conception détaillé en amont du développement, et (comme on dit alors) de le "balancer par-dessus le mur" aux programmeurs qui doivent en suivre les recommandations. C'est une vision caricaturale et inefficace des activités de conception qui n'a que peu de rapport avec la réalité du terrain.<br />
<br />
La démonstration en est faite par Fowler lui-même dans son ouvrage sur le <a href="http://referentiel.institut-agile.fr/refactoring.html">Refactoring</a>, dont le sous-titre est "améliorer la conception d'un code existant". C'est un travail rigoureux, argumenté, basé sur un travail de thèse doctorale, celle de Bill Opdyke; il amène Fowler à prédire, et l'avenir lui donnera raison, l'intégration du refactoring automatisé dans les éditions futures des outils de développement.<br />
<br />
<b>La conception est une activité collective, pas exclusivement individuelle.</b> Le discours sur la conception est dominé par la description de principes, d'heuristiques, de règles. Grammaticalement, la forme la plus usitée est celle de l'impératif: "évitez les classes contenant un trop grand nombre de méthodes publiques". On n'y prend presque pas garde mais une hypothèse, implicite et jamais remise en question, sous-tend la quasi totalité de ce discours: il s'adresse à une seule personne (Le Concepteur), travaillant de manière isolée. Elle se confirme facilement en examinant des sites d'entraide du type <a href="http://stackoverflow.com/">StackOverflow</a>: les questions sont systématiquement de la forme "Comment dois-je m'y prendre pour..."<br />
<br />
L'approche Agile suggère une autre démarche, dans laquelle le "nous", le collectif, l'équipe prennent le pas sur l'individu. La question n'est plus "quelle est <b>la</b> bonne conception dans cette situation", mais "sur quelle conception pouvons-<b>nous</b> être d'accord". Non pas "quel principe de conception prévaut", mais "quels critères <b>nous</b> permettent de décider entre deux propositions individuelles (ou mieux encore en faire la synthèse)".<br />
<br />
L'enjeu de la conception n'est pas, d'une façon un peu scolaire, de donner individuellement la réponse correcte; il est pragmatique et économique, et consiste à générer plusieurs propositions et décider, entre ces diverses alternatives, laquelle offre les conséquences les plus désirables pour le projet. Cette décision engage la responsabilité de chacune des personnes qui devront ensuite assurer la maintenance du code, elle est donc une négotiation <b>collective</b>... sans pour autant être nécessairement égalitaire: les compétences en matière de conception ne seront que rarement partagées dans l'équipe de façon homogène.<br />
<br />
<b>Changer de point de vue</b><br />
<br />
Sur ces trois points au moins, le discours Agile a contribué à chasser les images d'Epinal de la conception et rétablir une perception plus juste de cette activité. Reste que ces trois erreurs avaient à mon sens une origine commune, l'erreur de <a href="http://blog.institut-agile.fr/2010/11/la-danseuse-et-la-dette-technique.html">projection</a> que je dénonçais dans un précédent billet: et malheureusement, y compris au sein de la communauté Agile, nous continuons à commettre cette erreur en parlant exclusivement de propriétés du code telles la duplication, la complexité, les heuristiques <a href="http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29">SOLID</a>, les métriques de conception, etc.<br />
<br />
Tout comme la dette technique, la conception, bonne ou mauvaise, <b>n'est pas exclusivement une propriété du code source</b> (ou des documents et autres artefacts qui l'entourent), et se focaliser sur les produits de l'activité de développement, c'est faire l'impasse sur la moitié de la question: le fonctionnement cognitif humain et ses limites.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-88794035235027467252010-11-15T05:22:00.000-08:002010-11-15T05:22:56.528-08:00Des bugs dans le cerveau aux bugs dans le codePourquoi est-il si difficile de créer du logiciel sans bugs? Probablement en grande partie parce que l'outil principal que nous utilisons est lui-même un très mauvais exemple de conception rationnelle, et pour cause, et quand on y regarde de près s'avère bourré de bugs.<br />
<br />
Cet outil, c'est le cerveau; ou si l'on veut, mais en ne le prenant que comme une métaphore, le logiciel, appelé "Intelligence", que nous faisons tourner sur le matériel qu'est le "Cerveau". (Faire le parallèle entre l'esprit-logiciel et le cerveau-matériel, c'est en soi rentrer dans la vaste controverse de l'intelligence artificielle, et ce n'est pas mon propos.)<br />
<br />
<b>La Loi des Bugs</b> <br />
<br />
Je ne suis pas loin de penser que l'énoncé suivant est une loi fondamentale du développement:<br />
<blockquote>Il n'existe de bugs dans nos programmes qu'en raison de bugs dans notre pensée.</blockquote>Le terme "bug" est en soi <a href="http://www.ayeconference.com/entomology/">un choix terminologique malheureux</a>, c'est un excellent exemple de la <a href="http://blog.institut-agile.fr/2010/11/la-danseuse-et-la-dette-technique.html">psychologie de la projection</a> que j'évoquais dans un précédent billet: on visualise une petite bestiole dont l'existence et les décisions sont autonomes et indépendantes de notre volonté. Je lui préfère en général le terme "défaut", qui indique plus clairement ce qui est, selon moi, <b>toujours</b> à l'origine de ce qu'on appele familièrement un bug: une <b>erreur</b> du programmeur, se traduisant par un code source qui spécifie un comportement différent de ce qu'il devrait être.<br />
<br />
Mais c'est au moins un terme familier, et si vous dites à quelqu'un "tu ne t'en aperçois pas mais ton cerveau est plein de bugs", vous êtes au moins sûr de faire une forte impression.<br />
<br />
<b>Biais cognitifs</b><br />
<br />
L'étude des bugs du cerveau relève de la psychologie, et le terme plus communément accepté est celui de "<a href="http://fr.wikipedia.org/wiki/Biais_cognitif">biais cognitif</a>". Contrairement à la situation qui prévaut dans le domaine du logiciel, les sciences cognitives ont produit, s'agissant des biais cognitifs, des <a href="http://blog.institut-agile.fr/2010/10/de-lopinion-au-savoir.html">connaissances scientifiques</a> démontrées de façon robuste, répétable, qui ne sont plus affaire d'opinion. Indépendamment de ce que je voudrais croire ou de mes bonnes intentions, je suis bien contraint de reconnaitre que mon cerveau, à peu de choses près dans la même mesure que celui de mes congénères, est sujet à un certain nombre de biais cognitifs.<br />
<br />
Intéressons-nous par exemple au <a href="http://fr.wikipedia.org/wiki/Biais_de_confirmation_d%27hypoth%C3%A8se">biais de confirmation</a>. Nous allons voir que ce phénomène, qui est par ailleurs l'un des plus importants et sournois dans la psychologie humaine, est tout à fait pertinent pour éclairer notre approche du développement logiciel.<br />
<br />
Il est mis en évidence par de nombreuses expériences dont les premières remontent aux années 1960 avec les travaux de Peter Wason.<br />
<br />
Wason montre à ses sujets un triplet composé de trois chiffres: (2, 4, 6) et indique que ce triplet répond à une "règle de construction" qu'il s'agit de deviner. Il demande aux sujets de lui fournir des exemples supplémentaires afin de "tester" diverses hypothèses quant à l'énoncé de cette règle. L'expérimentateur se borne à donner une réponse binaire: "oui, votre exemple est conforme à la règle" ou bien "non, votre exemple n'est pas conforme". C'est donc une tâche <a href="http://fr.wikipedia.org/wiki/Induction_%28logique%29">inductive</a>, très ouverte par nature.<br />
<br />
En étudiant de près les hypothèses formulées par les personnes confrontées à cet épreuve et les "essais" fournis successivement, Wason est en mesure de démontrer une tendance tout à fait systématique: on propose beaucoup plus facilement des exemples "de confirmation", c'est-à-dire conformes à l'hypothèse qu'on a la plus récemment formulée. Or <b>c'est une erreur</b>, car si des exemples confirmés peuvent nous amener à valider une réponse avant de la proposer, la démarche la plus fructueuse consiste à proposer des exemples qui (s'ils sont acceptés par l'expérimentateur comme conformes à la règle) invalident notre hypothèse et nous forcent à la reformuler.<br />
<br />
D'autres expériences de Wason conforteront le "biais de confirmation" comme une erreur de raisonnement tellement courante qu'on peut la considérer comme systématique chez l'être humain: ainsi sur une tâche consistant à déterminer lesquelles parmi quatre cartes on doit retourner pour vérifier une règle du type "SI telle figure apparaît au recto ALORS telle autre doit apparaître au verso", <b>seuls 10% des sujets donnent la bonne réponse!</b> Ceci alors que plus de 90% des sujets reconnaissent, une fois qu'on leur a donné cette réponse, qu'elle est effectivement correcte et qu'ils pouvaient logiquement le déterminer à la lecture de l'énoncé: ce qui écarte donc l'hypothèse d'une ambiguité ou d'une mauvaise compréhension de la tâche.<br />
<br />
(Si vous êtes tenté à la lecture de ce billet de développer vos propres facultés en matière d'induction et de formulation d'exemples contradictoires, essayez le jeu <a href="http://jeuxsoc.fr/?principal=/jeu/zendo?">Zendo</a>, passionnant pour les petits et les grands...)<br />
<br />
<b>Application au développement</b><br />
<br />
Revenons au développement de logiciels, et plus précisément à un des épisodes de l'historique du génie logiciel. En 1976, Glenford Myers, auteur de l'ouvrage de référence "<a href="http://www.amazon.fr/dp/0471627658">Software Reliability, Principles and Practices</a>", écrit ceci:<br />
<blockquote>Il est impossible de tester vos propres programmes. Aucun programmeur ne devrait tenter de tester son propre programme. Ceci s'applique à toutes les formes de test, que ce soit le test système, fonctionnel ou le test unitaire. [...] Le test doit être une activité extrêmement destructrice, et il est des raisons psychologiques profondes qui empêchent le programmeur d'adopter une attitude destructrice vis-à-vis de son propre programme."</blockquote>Les mots employés sont très forts: "<b>impossible</b>", "<b>toutes les formes de test</b>". Myers ne cite pas Wason et ne détaille pas dans cet ouvrage les "raisons psychologiques profondes" auxquelles il fait allusion, mais il semble clairement s'agir de notre tendance à imaginer plus facilement des jeux d'essais qui visent à confirmer nos hypothèses que ceux pouvant les infirmer. (Il existe d'ailleurs quelques études cherchant à <a href="http://portal.acm.org/citation.cfm?id=1868344&CFID=114193353&CFTOKEN=43946035">démontrer directement</a> l'impact du biais de confirmation sur l'incidence des défauts dans le code.)<br />
<br />
Cette affirmation que Myers présente comme un "axiome" deviendra pendant de nombreuses années l'orthodoxie en matière de test logiciel. (Une recherche Google avec la phrase "test their own code" donne assez facilement des <a href="http://www.testuff.com/blog/2008/07/why-developers-shouldnt-test-their-own-code/">exemples</a> <a href="http://jasonswett.net/why-developers-shouldnt-test-their-own-code/">récents</a> de billets d'opinion reprenant sans la critiquer cette idée, comme si elle allait de soi.)<br />
<br />
En un sens, cette affirmation a eu un effet positif: elle a favorisé l'apparition d'une sous-discipline, le test indépendant, dont l'apport est certainement bénéfique; bien qu'en France la culture soit apparemment bien moins sensible à l'intérêt d'employer des personnes dans un rôle dédié de "testeur" ou "assurance qualité", par rapport aux Etats-Unis.<br />
<br />
<b>TDD ou l'inversion géniale</b><br />
<br />
Pourtant, je soupçonne cette attitude d'avoir également <b>généré de sérieux dégâts</b>, en berçant d'innombrable développeurs dans la douillette illusion que "tester leur propre code" était non seulement une erreur mais une faute professionnelle. Pensez-y la prochaine fois que vous rencontrez sur un site Web une NullPointerException, l'exemple par excellence d'une défaillance logicielle qu'on peut parfaitement <b>éviter en testant plus soigneusement son code</b>.<br />
<br />
Les choses n'ont commencé à changer que relativement récemment, et grâce à l'introduction de la pratique agile du <a href="http://referentiel.institut-agile.fr/tdd.html">Développement par les Tests (ou TDD)</a>.<br />
<br />
Il s'agit pour moi (et pour d'autres, comme Steve McConnell dans Code Complete) de l'une des contributions majeures de la mouvance Agile à ce qu'il faut bien encore appeler le génie logiciel. Depuis les années 2000 le discours autour de cette pratique a considérablement évolué en sophistication, mais l'idée élémentaire est restée la même.<br />
<br />
Elle exploite la notion d'un <b>test unitaire automatisé</b>, c'est-à-dire un bout de code qu'on écrit uniquement pour mettre en évidence qu'un autre bout de code (celui-là utilisé directement dans le programme réel) fonctionne comme attendu. Il va de soi qu'un test unitaire automatisé, en soi, reste un "test", un "essai" qu'on confronte à une hypothèse: l'<b>automatisation ne change rien de fondamental</b>.<br />
<br />
Ce qui est radical, c'est l'idée suivante:<br />
<blockquote>écrire le test <b>avant</b> d'écrire le code correspondant</blockquote>Cela n'a l'air de rien mais cette simple inversion suffit simultanément:<br />
<ul><li>à <b>donner raison</b> à Glenford Myers sur l'importance du biais de confirmation en matière de test</li>
<li> à lui <b>donner tort</b> sur les conclusions: un développeur peut et doit tester son code</li>
</ul>En effet, avant d'avoir écrit un élément de programme, nous ne sommes pas sujets au biais de confirmation, puisque nous ignorons encore les détails de l'implémentation. Ces détails fonctionnenent en programmation comme l'hypothèse à tester dans la tâche de Wason: si nous avions connaissance de notre implémentation, nous serions tenté de ne penser qu'à des jeux d'essais qui confortent l'impression que nous avons que notre code est correct.<br />
<br />
En inversant l'ordre de marche, nous avons tenu compte de nos propres limitations cognitives, et nous leur avons apporté une solution nettement plus efficace, car nécessitant moins de coordination, que la solution classique "embaucher des testeurs indépendants pour tester le code mal fichu des développeurs". (Cette dernière solution garde cependant de son intérêt, car il existe bien d'autres aspects de la qualité logicielle qui peuvent bénéficier du travail d'un testeur que la seule qualité technique du code source.)<br />
<br />
<b>Conclusions</b><br />
<br />
Ce premier exemple donne une perspective un peu différente sur le TDD que celle habituellement présentée, et surtout démontrant à quel point s'intéresser au développement logiciel par le biais des sciences cognitives, et notamment par celui des biais cognitifs, peut être puissant et fructueux.<br />
<br />
<br />
L'approche usuelle du génie logiciel a été d'écarter systématiquement ces considérations, qui reposent pourtant sur des bases scientifiques robustes, pour ne considérer que les aspects "objectifs" du logiciel, vu comme une "chose naturelle" indépendante de l'esprit humain qui l'a créé: c'est pourquoi, à mon sens, cette discipline telle qu'elle a été conçue jusque là <b>ne peut pas</b> résoudre <a href="http://blog.institut-agile.fr/2010/10/chorus-une-histoire-pas-drole.html">les difficultés qu'elle prétendait aborder</a>. Pour progresser, il est impératif de tenir compte des aspects cognitifs qui jouent un rôle déterminant dans la création de logiciels.<br />
<br />
Le champ d'application de cette démarche va bien au-delà de la technique, on peut lui trouver des applications dans la gestion de projet, la gestion des compétences, l'estimation des délais, bref à l'ensemble des préoccupations des professions du logiciel.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-79874095790797872132010-11-12T08:51:00.000-08:002010-11-12T08:51:55.765-08:00Reykjavik, Prezi, conception AgileJeudi prochain, <a href="http://www.agilis.is/in-english.html">destination: Reykjavik</a>! Le choix du coeur, ayant beaucoup apprécié l'Islande lors de vacances passées là-bas il y a deux ans, et promis d'y revenir; mais également un coup de pouce à une communauté Agile très dynamique.<br />
<br />
J'avais bien apprécié l'<a href="http://agiletour.org/at2010Nancy/InitiationALaPenseeVisuelle">atelier</a> sur la pensée visuelle proposé par Benoit Gantaume (Agilidée, partenaire de l'Institut) lors de l'étape Nancéenne de l'Agile Tour et je m'étais promis de mettre en oeuvre les outils présentés à l'occasion d'un exposé pour une conférence.<br />
<br />
La session avec laquelle je "tourne" actuellement, "Quarante ans de crise, dix ans d'agilité, et après" est largement constituée des sujets que j'ai traité récemment sur ce blog, qui proviennent eux-mêmes des réflexions qui ont motivé le lancement de l'Institut; elle n'est pas vraiment pertinente pour mes amis Islandais (et une précédente expérience m'a appris que le caractère Nordique peut être impatient avec ce qui ne lui semble pas pertinent: c'est mon unique et cuisant souvenir d'un exposé où une bonne partie de la salle a "voté avec ses pieds").<br />
<br />
J'avais donc proposé un sujet sur les pratiques Agiles liées à la conception. Je souhaitais apporter une perspective un peu différente sur ce sujet: que nous a appris le mouvement Agile sur la conception, quelles pratiques sont utiles dans ce domaine et pourquoi, comment la prise en compte du non-technique et du "facteur humain" en Agile éclaire-t-elle notre compréhension de cette activité, vers quels sujets scientifiques nous pousse-t-elle à nous intéresser?<br />
<br />
Depuis quelque temps je voulais aussi sortir de l'ornière "PowerPoint" (en l'occurrence Keynote puisque je suis un "Apple fanboy", mais c'est du pareil au même) mais je ne me sens pas encore à l'aise, lorsque j'aborde des sujets un peu théoriques, avec un exposé sans aucun support visuel. D'expérience, mon auditoire est composé de personnes ayant des préférences cognitives diverses: certains sont plutôt visuels, d'autres plutôt auditifs, d'autres kinesthétiques. Je cherche à présenter le même contenu sous plusieurs formes pour m'assurer que le maximum de personnes en retirent l'essentiel.<br />
<br />
J'avais entendu parler de Prezi (et vu une présentation de Jonathan Perret utilisant cet outil à Agile France 2010), j'ai saisi l'occasion pour expérimenter.<br />
<br />
Mon retour, façon <a href="http://partageons-ce-qui-nous-departage.com/perfection-game">Perfection Game</a>: j'attribue largement 6/10, Prezi tient ses promesses de dépasser le carcan suranné du "slideware" directement hérité du projecteur de diapos (que mes parents avaient rangé dans un placard pour ne jamais le ressortir alors que j'avais, disons, 8 ou 10 ans). A la place, et après un démarrage très déroutant, on goûte un vrai sentiment de liberté devant le canevas sans limite et la possibilité de zoomer en avant, en arrière à l'infini (presque, j'ai réussi à me faire taper sur les doigts parce que ma présentation commençait à faire concurrence à "<a href="http://www.powersof10.com/film">powers of ten</a>" en termes de niveaux parcourus). On se sent vraiment incité à penser visuellement, à organiser spatialement des idées jetées pèle-mèle, à les hiérarchiser par la taille. Je me suis même pris à créer des jeux de mots visuels, alors que c'est tout sauf mon langage de prédilection!<br />
<br />
Pour avoir 10/10 il faudrait corriger quelques défauts d'ergonomie, mineurs et pas bloquants mais très, très frustrants par moments; il faudrait pouvoir copier-coller plus facilement entre présentations (à mon avis Prezi a loupé une grosse occasion d'exploiter la dimension "sociale" de leur outil, en encourageant les auteurs à se piquer des éléments réutilisables); il faudrait un peu plus de liberté dans le choix des polices et des couleurs de fond.<br />
<br />
Mon <a href="http://prezi.com/yuirqsqxl7cd/making-sense-of-agile-design-practices/">premier Prezi est en ligne</a> (c'est la règle du jeu, la gratuité de l'outil est au prix du partage, je trouve ça très bien mais encore une fois on peut regretter que ça ne soit pas mieux exploité), si vous avez envie de jeter un coup d'oeil, vos retours seront les bienvenus.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-81338636332787037692010-11-10T02:10:00.000-08:002010-11-10T02:10:20.948-08:00La danseuse et la dette techniqueUne "danseuse", dans l'expression héritée du XIXè siècle, désignait une maîtresse qu'on entretient à grand frais, et par extension un projet, une habitude auxquels on consacre une dépense excessive pour des raisons largement affectives et peu utilitaires.<br />
<br />
L'expression m'est revenue à l'esprit en réfléchissant à une conversation récente sur la "dette technique", le terme consacré pour désigner des logiciels dont le code source est mal fichu, à tel point qu'ils deviennent de plus en plus difficiles à faire évoluer. J'ai connu des projets de ce type, et j'ai été frappé de leur côté "danseuse": ce sont des projets sur lesquels on investit beaucoup d'argent, mais dont on retire très peu de profit; pourtant on ne se résigne pas à s'en séparer.<br />
<br />
L'une des difficultés est que les conséquences de la "dette technique" se font sentir de façon très tangible, mais la "dette" elle-même n'est pas visible, on ne sait pas la mesurer. Dès lors il est difficile de justifier des décisions radicales, puisqu'elles vont s'appuyer non pas sur des éléments objectifs mais sur le ressenti des développeurs. "La dette technique est trop élevée, on ne peut plus continuer!" - "Ah bon, à combien la chiffrez-vous?" - "Euh... on ne sait pas... mais c'est trop."<br />
<br />
Surgit alors une idée: <b>pouvons-nous trouver des outils d'analyse du code qui vont nous permettre de mesurer la dette technique? </b>Idée lumineuse sur le papier: non seulement elle va nous permettre d'objectiver quelque chose de flou et subjectif, mais en plus nous pourrions installer de tels outils dès le début du projet et ainsi éviter la dérive de la dette, en conserver le contrôle en permanence.<br />
<br />
Malheureusement, je crains que cette idée ne soit <b>un miroir aux alouettes</b>. Ce n'est pas que de tels outils soient inutiles; mais s'appuyer exclusivement sur eux révèle une <b>incompréhension majeure</b> de ce qu'est la dette technique, en présence de laquelle leurs résulats seront inexploitables. Pour résumer en quelques mots, <b>la dette technique n'est pas <i>dans</i> le code, elle est <i>entre</i> le code et ceux qui l'entretiennent. </b>Pour bien expliquer cette thèse je vais devoir faire intervenir... une autre danseuse.<br />
<br />
<b>L'autre danseuse</b><br />
<br />
Regardez bien l'image animée ci-dessous.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://upload.wikimedia.org/wikipedia/commons/2/21/Spinning_Dancer.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://upload.wikimedia.org/wikipedia/commons/2/21/Spinning_Dancer.gif" width="240" /></a></div><br />
Dans quel sens voyez-vous tourner la danseuse? De la gauche vers la droite, ou l'inverse? Dans un cas comme dans l'autre, si vous continuez à vous concentrer sur l'image pendant un moment, il y a de grandes chances pour que vous voyez ce sens de rotation s'inverser subitement, un effet visuel qui perturbe un peu: on se persuaderait facilement qu'il y a tromperie quelque part, que c'est <i>l'image qui a changé</i> et pas simplement notre perception de l'image. (Je connais des gens qui après avoir vu cette image ont passé un temps considérable à l'analyser avec Photoshop pour trouver "l'astuce". Il n'y a pas d'astuce.)<br />
<br />
La réalité est que cette animation fait partie de la même catégorie d'illusions d'optique que le fameux cube de Necker, celle des images ambigues. L'effet de silhouette supprime de l'image toutes les informations liées à la profondeur, et met sur un même plan tous les éléments d'anatomie, bras, jambes, cheveux, de sorte qu'il n'est tout simplement pas possible de savoir quel sens de rotation est "réellement" indiqué par l'image.<br />
<br />
Pourtant notre cerveau insiste: il ne peut pas tolérer l'ambiguité, il est donc obligatoire de voir la danseuse tourner dans un sens ou dans l'autre. Nous avons la sensation irréfutable que le mouvement est <b>dans l'image, pas dans notre esprit</b>.<br />
<br />
<b>Projection</b><br />
<br />
Cette sensation correspond à une classe de phénomènes cognitifs appelés "projection". Une projection, de manière générale, est une opinion ou une croyance qui ne regarde que nous mais que nous interprètons comme une réalité extérieure.<br />
<br />
Par exemple si je me promène le soir dans un quartier qui a une réputation "chaude", je ressens de l'inquiétude, et puis je vois arriver deux personnes qui parlent fort, je me dis "Ces gars-là ont l'air vachement aggressifs, sûrement des voyous" et m'enfuis en courant devant deux passants tout à fait normaux mais médusés...<br />
<br />
Localiser la "dette technique" <b>seulement dans le logiciel</b> relève de la projection. En fait la dette technique est un concept intrinsèquement relationnel, c'est un rapport entre des gens (une équipe de développement par exemple) et une collection d'artefacts logiciels dont du code source. La question qui se pose est "quels freins ces personnes rencontrent-elles quand elles cherchent à intervenir sur ce logiciel", est-ce qu'elles trouvent leur chemin, est-ce qu'elles sont forcés à du travail inutile, etc.<br />
<br />
<br />
<b>Bonne dette, mauvaise dette...</b><br />
<br />
Par exemple on dit qu'un des éléments majeurs de la dette technique c'est la duplication de code. Mais si on y réfléchit plus précisément, on se dit que le code est toujours dupliqué en plein d'endroits: chaque programmeur en a une copie intégrale, grâce à la gestion de versions! Et ça ne gêne personne, ce n'est pas de la dette, parce que l'outil gère très bien cette duplication. Donc il y a de la duplication qui n'est PAS de la dette technique. C'est comme le cholestérol en somme, il y a le bon et le mauvais...<br />
<br />
La mauvaise duplication par exemple, c'est quand d'autres programmeurs ont fait du copier-coller et que le taux de TVA à 18,6% se retrouve partout dans le code. Quand il passe à 19,6%, ça prend plus de temps de faire une recherche et un remplacement globals que si on pouvait simplement modifier le chiffre à un endroit unique dans le code. Et imaginez qu'en plus du copier-coller il y a des programmeurs qui ont écrit 0,186 à un endroit, 18,6 à un autre, 1,186 à un troisième: des variantes multiples qui font que rechercher-remplacer ne marche pas.<br />
<br />
La dette technique est faite de difficultés de ce type, des ruptures entre le modèle métier et son expression dans le code, ou bien des hypothèses non explicitées qui ne se révèlent que quand elles changent, et on se retrouve coincé: mais on se retrouve coincé <b>par rapport aux outils dont on dispose</b> ou <b>par rapport à un niveau de compétence</b> ou <b>par rapport à un état de connaissances de l'équipe</b>.<br />
<br />
<br />
<br />
<b>La dette est dans l'interaction</b><br />
<b> </b><br />
Il n'y a pas dans l'absolu de dette technique dans le code. Pour mesurer la dette, il faut penser en termes d'observation des <b>interactions entre les gens et le code</b>.<br />
<br />
On peut réfléchir à des métriques "objectives" telles que la complexité cyclomatique, mais ce qui est déterminant c'est <b>la façon dont l'esprit humain appréhende le code pour le modifier</b>, et ce qu'il faut donc expliciter, c'est ce que ces métriques peuvent avoir comme relation avec l'exécution par le programmeur des tâches courantes. Or c'est un sujet largement ignoré; la faute à notre tendance fâcheuse à la projection...Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-10672554870677699102010-11-08T01:07:00.000-08:002010-11-08T01:07:00.278-08:00Une Revue des Logiciels et Projets Agiles?Il m'est arrivé de parler à des collègues chercheurs dans le milieu universitaire, aussi bien en France qu'à l'étranger, et de leur poser la question: "Comment se fait-il qu'on voit si peu de recherche <i>spécifiquement</i> sur les approches Agiles?" J'en connais plusieurs qui s'y intéressent et travaillent "officiellement" sur des sujets connexes, par exemple en génie logiciel. Mais ils ne publient pas ou peu d'études visant à analyser précisément telle ou telle pratique, tel ou tel discours porté par la communauté Agile.<br />
<br />
Quand je m'en étonne, ils me font remarquer la chose suivante: pour un scientifique, <b>un critère d'évaluation important de son travail est la production de publications acceptées par des revues réputées dans son domaine</b>. Produire un "papier" qui ne trouverait pas un débouché dans une publication reconnue comme ayant un caractère scientifique constituerait un travail en pure perte. (Dans le secteur privé, un chercheur est un salarié, il ne rend finalement de comptes qu'à son employeur, et pour peu qu'il ait un manager éclairé il se verra imposer peu de contraintes. Il est possible que cette tyrannie des "bonnes" revues pour publier soit moins contraignante dans ce contexte.)<br />
<br />
Il n'existe pas, à ma connaissance, de revues scientifiques spécifiquement consacrées à l'etude des pratiques Agiles. Par conséquent, on ne publie pas sur ce sujet. Mais, bien évidemment, l'absence de travaux dans ce domaine contribue à pérenniser la fracture entre recherche et industrie, ce qui fait que les intervenants des projets Agiles pensent que le travail des chercheurs ne les concerne pas. L'industrie n'en faisant pas la demande, la recherche de son côté continue à ne pas s'intéresser à ce sujet, et a peu de chance de vouloir reconnaître sa pertinence. Cela ressemble pas mal à un cercle vicieux!<br />
<br />
Pourtant on peut facilement se convaincre qu'un canal de publication de ce type est nécessaire.<br />
<br />
Le modèle consacré est celui de <a href="http://fr.wikipedia.org/wiki/%C3%89valuation_par_les_pairs">l'évaluation par les pairs</a> ("peer review"), les publications se dotant d'un comité de lecture dont le rôle est de filtrer les travaux proposés pour veiller à ce que ce qui est publié répond à des critères de qualité spécifiques: il s'agit en fait d'assurer la bonne "circulation des références" <a href="http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scientifique-comment.html">comme l'a analysé Bruno Latour</a>, vérifier par exemple que les chercheurs sont au courant des travaux précédemment effectués dans leur domaine, les référencent et les sites, que leurs études permettent de combler les lacunes de ces antécédents et ainsi consolider les connaissances.<br />
<br />
Ainsi beaucoup de travaux portant sur des sujets tels que le développement par les tests ou la programmation en binômes souffrent d'un travers élémentaire: ils sont réalisés par des chercheurs qui utilisent <i>leurs propres étudiants</i> comme sujets d'étude. Mais, par définition, il s'agit d'une population non pas de programmeurs en exercice, mais de programmeurs en devenir! Pire encore, le protocole expérimental prévoit généralement un temps ridiculement court pour <i>former</i> ces sujets d'étude à la pratique dont on cherche à discerner les bénéfices.<br />
<br />
<b>On va donc passer une après-midi ou une journée à expliquer le développement par les tests (TDD) à des étudiants, puis comparer leur performance à celle d'autres étudiants, la condition expérimentale consistant pour l'essentiel à ce qu'un des deux groupes reçoit l'instruction "utilisez ce qu'on vous a appris"</b>. Quelle que soit la rigueur de l'analyse statistique qui vient ensuite, il est impensable de tirer de telles études la moindre conclusion définitive quant à l'intérêt que le TDD peut avoir en entreprise. Et ces études, même quand on les qualifie prudemment de "préliminaires", sont rarement suivies de nouvelles visant à corriger ces lacunes. Pour la simple et bonne raison qu'intervenir en entreprise coûte plus cher, et exige de surmonter la réticence, compréhensible mais pas nécessairement appropriée, de ces dernières à inviter des chercheurs dans leurs bureaux pour regarder de près ce qui s'y passe.<br />
<br />
Fédérer en <a href="http://wiki.institut-agile.fr/cgi-bin/wiki.pl?EnseignantsChercheursAgiles">réseau</a> les chercheurs qui oeuvrent dans ce domaine, et à terme contribuer à la création d'une telle revue, est une mission tout à fait naturelle pour l'Institut Agile. L'objectif est de <b>produire des connaissances affranchies des opinions</b> et idéologies qui soient <b>utiles aux intervenants des projets Agiles</b>.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com0tag:blogger.com,1999:blog-479555891921312205.post-6892285136903374842010-11-05T01:53:00.000-07:002010-11-05T01:53:01.023-07:00Le social a plus d'influence sur les bugs que la techniqueOn peut penser ce qu'on veut de Microsoft en tant qu'entreprise, force est de constater que l'éditeur offre un terrain propice à l'étude à grande échelle des réalités du développement logiciel; et que les moyens financiers de Microsoft lui servent entre autres choses à financer une recherche privée d'un excellent niveau. L'exemple emblématique pour moi en est <a href="http://research.microsoft.com/en-us/people/nachin/">Nachi Nagappan</a>, dont les travaux me fascinent.<br />
<br />
Nagappan a repris un sujet d'étude assez ancient, la notion de <i>susceptibilité aux bugs</i> ("defect proneness"). Si vous découpez un logiciel en modules, et que vous comptez à l'issue d'une analyse raisonnablement rigoureuse quels modules font l'objet du plus grand nombre de corrections de défauts, vous vous rendrez compte que tous les modules ne se valent pas. Certains accumulent les casseroles, pour ainsi dire. On peut donc se demander s'il existe des régularités qui caractériseraient les modules les plus (ou les moins) susceptibles de contenir des défauts, de façon par exemple à guider le travail des testeurs.<br />
<br />
On a beaucoup étudié les corrélations avec des mesures <i>techniques</i>, comme l'analyse des dépendances ou la complexité cyclomatique. Nagappan relève que c'est ignorer totalement l'aspect humain; on fait comme si le logiciel était en soi quelque chose d'objectif, une "chose" qu'on trouve telle quelle dans la nature et qu'on examine à la loupe comme un caillou ou une plante. Or ce qui est le plus important dans l'histoire c'est qu'un module ou un logiciel est <i>produit</i> par une organisation d'individus.<br />
<br />
Nagappan et ses collaborateurs se sont donc penchés sur des "métriques" caractérisant l'organisation sociale des équipes responsables de divers modules dans le code, proprement garguantuesque, du système Windows 7. La culture d'entreprise de Microsoft offre un environnement relativement homogène, dans lequel des équipes bien identifiées s'occupent de modules bien identifiés, le terrain est donc favorable à une étude comparative qui analyse des caractéristiques relativement stables des équipes et des modules logiciels concernés.<br />
<br />
Le <a href="http://portal.acm.org/citation.cfm?id=1368160">résultat obtenu</a> fait réfléchir (mais est-il vraiment surprenant): <b>les paramètres "sociaux" sont plus pertinents que les paramètres "techniques" pour prédire quels modules sont les plus susceptibles de contenir des défauts</b>.<br />
<br />
Comme je l'ai dit précédemment il convient de rester critique, et le travail de Nagappan mobilise des outils statistiques et des critères d'évaluation (<a href="http://fr.wikipedia.org/wiki/Pr%C3%A9cision_et_rappel">"précision" et "rappel"</a>) que je ne maîtrise pas, il me manque donc (pour l'instant) la culture nécessaire pour évaluer ces résultats.<br />
<br />
Il me semble cependant qu'ils sont sur une bonne voie, <b>qu'ils posent les bonnes questions</b>.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1tag:blogger.com,1999:blog-479555891921312205.post-77912806597959636502010-11-03T02:14:00.000-07:002010-11-03T03:20:46.300-07:00Un petit jeu de "Cinq Pourquoi"Hier matin j'ai eu le plaisir d'une discussion autour d'un café avec Hugo Heitz, responsable du déploiement Lean dans le département Exploitation d'une grande banque, dont j'avais bien apprécié l'intervention lors d'un précédent <a href="http://www.lean.enst.fr/wiki/bin/view/Lean/LesPresentations">séminaire consacré à l'approche Lean</a>, et avec qui je suis resté en contact depuis.<br />
<br />
A un moment la conversation a abordé les difficultés liées à la "dette technique", l'entropie qui semble frapper inexorablement tous les projets informatiques avec pour conséquences qu'après un temps plus ou moins long (trop souvent assez court), des évolutions qui auraient été considérées comme mineures en début de parcours deviennent de plus en plus coûteuses, laborieuses, pénibles à réaliser comme à négocier.<br />
<br />
Nous avons des constats très similaires malgré nos perspectives différentes, Hugo oeuvrant dans le domaine de l'exploitation, alors que je m'intéresse au développement; les deux mondes sont inexorablement liés mais semblent ne pas vouloir reconnaître leur existence mutuelle. (En plaisantant j'ai fait allusion à H.G. Wells pour décrire ce qui semble se passer entre ces deux populations: les "Morlocks de l'informatique" faisant un travail souterrain et ignoré tandis que les "Eloi du logiciel" mènent une vie insouciante. Evidemment ça nous a amenés à nous demander si de temps en temps un Eloi se faisait manger...)<br />
<br />
Nous nous sommes alors lancés, presque sans le remarquer, dans un petit jeu des "<a href="http://fr.wikipedia.org/wiki/Cinq_pourquoi">cinq pourquoi</a>", un des outils Lean qui a été assez joyeusement repris par les équipes Agiles. <b>Pourquoi</b> les projets finissent-ils par s'engluer, que ce soit du côté développement ou du côté exploitation? Parce que cette "dette technique" est composée de logiciel, et que le logiciel est par nature invisible, contrairement au hardware. On peut plus facilement mesurer l'âge moyen d'un parc matériel vieillissant et convaincre par des chiffres qu'il est temps d'investir, mais comment mesurer la "dette technique" logicielle?<br />
<br />
Alors <b>pourquoi</b> cette "dette technique" est-elle si difficile à mesurer? Parce que les programmeurs (je parlais alors pour ma partie) investissent leurs efforts sur les mauvaises priorités. "Pas le temps de mettre ce code au propre, il faut qu'on livre de nouvelles fonctionnalités." Et <b>pourquoi</b> les programmeurs ne se rendent-ils pas compte que ces choix sont contre-productifs? Parce que bien souvent il leur manque certains savoirs et savoirs-faire qui leur permettraient d'objectiver et d'argumenter en faveur de décisions plus appropriées. <b>Pourquoi</b> leur manque-t-il ces connaissances?<br />
<br />
A ce moment nous n'avions posé que quatre "pourquoi" (et il faudra sans doute un jour creuser plus loin) mais nous sommes tombés d'accord sur un constat: <b>tant que la formation des personnes entrant dans les métiers de l'informatique ne les prépare pas à imposer dans leurs entreprises des pratiques plus efficaces, il sera difficile d'espérer des améliorations</b>.<br />
<br />
En France les cursus de formations supérieures sont indissociablement liés aux organismes publics de recherche, la recherche en entreprise étant moins développée dans l'informatique que dans d'autres secteurs économiques; c'est donc à mon avis vers les <a href="http://fr.wikipedia.org/wiki/Enseignant-chercheur_%28France%29">enseignants-chercheurs</a> qu'il est important de se tourner pour trouver des réponses.<br />
<br />
Or la collaboration entre les professionnels en entreprise et ce monde de la recherche et de l'enseignement publics me semble extrêmement marginale, presque inexistante. C'est vrai de manière générale pour ce qui concerne le génie logiciel: combien de développeurs ou de chefs de projet travaillant en entreprise s'intéressent au travail des chercheurs dans ce domaine et les trouvent pertinents et concrètement utiles? Le seul domaine que je connaisse où il semble qu'une collaboration fructueuse se soit établie est celui de la "<a href="http://fr.wikipedia.org/wiki/Model_driven_architecture">programmation par les modèles</a>" ou "model driven".<br />
<br />
Concernant les approches Agiles, c'est carrément le désert. Un exemple: il existe des projets de recherche à l'échelle européenne, par exemple le programme <a href="http://www.itea2.org/">ITEA2</a>. Ces projets mutualisent des investissements publics et privés en R&D et visent à rendre l'Europe plus compétitive dans ce domaine. Au sein d'ITEA2, il existe un sous-projet <a href="http://www.flexi-itea2.org/index.php">FLEXI</a> réunissant des chercheurs en un réseau qui cible spécifiquement des pratiques Agiles. On n'y trouve... aucun partenaire industriel français, et apparemment aucun chercheur français.<br />
<br />
Le projet de l'Institut Agile prend très au sérieux ce rapprochement nécessaire entre le milieu de la recherche et de l'enseignement d'une part, et la communauté Agile et ses professionnels d'autre part. Rendre compte de la recherche sur les différentes pratiques est par exemple un des objectifs du <a href="http://referentiel.institut-agile.fr/">référentiel</a>.<br />
<br />
Il faut aller plus loin. J'ai publié aujourd'hui un premier appel en vue du <a href="http://wiki.institut-agile.fr/cgi-bin/wiki.pl?EnseignantsChercheursAgiles">recensement des chercheurs</a> en France (ou dans la sphère francophone plus largement) qui s'intéressent à ce sujet. Si vous exercez vous-même des activités d'enseignement et de recherche, je vous encourage vivement à vous inscrire; si ce n'est pas le cas, à diffuser autour de vous l'adresse de cette page.<br />
<br />
L'objectif dans un premier temps est de mieux connaître et mieux faire connaître cette partie de la communauté Agile. <b>Travailler ensemble, c'est pouvoir mieux faire valoir l'intérêt de ces recherches</b>, à la fois envers les organismes habilités à financer et favoriser des projets de recherche, mais aussi et surtout en direction des développeurs, chefs de projets et autres intervenants sur les projets Agiles.Anonymoushttp://www.blogger.com/profile/07379040637704958977noreply@blogger.com1