{"id":2429,"date":"2015-04-05T11:41:41","date_gmt":"2015-04-05T10:41:41","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2429"},"modified":"2015-04-15T10:26:16","modified_gmt":"2015-04-15T09:26:16","slug":"les-developpeurs-revent-ils-de-points-de-fonction-automatises-1","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/les-developpeurs-revent-ils-de-points-de-fonction-automatises-1\/","title":{"rendered":"Les d\u00e9veloppeurs r\u00eavent-ils de points de fonction automatis\u00e9s ? (I)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-2430\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2015\/04\/Qualilogy_FP2.jpg\" alt=\"Qualilogy - Automated Function Points\" width=\"359\" height=\"239\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2015\/04\/Qualilogy_FP2.jpg 359w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2015\/04\/Qualilogy_FP2-300x200.jpg 300w\" sizes=\"(max-width: 359px) 100vw, 359px\" \/><\/a>Le titre de ce post paraphrase le titre d\u2019un roman de science-fiction que vous connaissez peut-\u00eatre : \u00ab Do Androids Dream of Electric Sheep? \u00bb.<\/p>\n<p>Cette nouvelle de Philip K. Dick a servi de base au film \u00ab Blade Runner \u00bb de Ridley Scott, dans lequel un d\u00e9tective du futur doit retrouver et neutraliser des andro\u00efdes que rien ne diff\u00e8re des humains. <!--more--><\/p>\n<p>Dans le livre, ce d\u00e9tective poss\u00e8de un mouton en chair et en os, qu\u2019il remplace, \u00e0 sa mort, par un mouton \u2018\u00e9lectrique\u2019. Il en vient \u00e0 se demander si les andro\u00efdes r\u00eavent comme lui d\u2019un animal de compagnie, mais dans leur version \u2018animalo\u00efde\u2019.<\/p>\n<p>Cette \u0153uvre de K. Dick soul\u00e8ve une r\u00e9flexion sur la diff\u00e9rence entre l\u2019humain et le robot, entre le r\u00e9el et l\u2019automatis\u00e9. Elle m\u2019est revenue \u00e0 l\u2019esprit lorsque je me suis pos\u00e9 la question de la diff\u00e9rence entre les Points de Fonction (Function Points ou FP) manuels et automatis\u00e9s (Automated Function Points ou AFP).<\/p>\n<p>Aujourd\u2019hui, de plus en plus de d\u00e9veloppeurs utilisent quotidiennement les m\u00e9triques d\u2019outils d\u2019analyse de code, les statistiques de tests, de suivi de corrections\/\u00e9volutions, les donn\u00e9es de Dette Technique, etc. dans le cadre de leur projet ou d\u2019un processus d\u2019Int\u00e9gration Continue.<br \/>\nJe me suis donc demand\u00e9 pourquoi les d\u00e9veloppeurs, de plus en plus friands de mesures concernant leur code et leur projet, ignorent g\u00e9n\u00e9ralement tout de ce qui touche aux Points de Fonction. Est-ce que cette mesure pourrait les int\u00e9resser ?<\/p>\n<h2>Points de Fonction<\/h2>\n<p>Je ne vais pas vous expliquer ce que sont les Points de Fonction : ce n\u2019est pas l\u2019objet de ce post et il faudrait de nombreuses pages pour y parvenir. D\u2019autant que ce vocable recouvre diff\u00e9rentes normes et m\u00e9thodes, pour ne pas dire diff\u00e9rentes \u00e9coles. Disons simplement que les FP sont une mesure de la taille fonctionnelle d\u2019une application bas\u00e9e sur les flux transactionnels et les structures de donn\u00e9es.<\/p>\n<p>Je sais, ce n\u2019est pas une d\u00e9finition pr\u00e9cise ni parfaite, mais encore une fois, je ne veux pas entrer dans cette discussion, sinon simplement rappeler quels en sont les objectifs principaux :<\/p>\n<ul>\n<li>mesurer les fonctionnalit\u00e9s d\u2019une application existante ou future,<\/li>\n<li>de mani\u00e8re normalis\u00e9e et objective, ind\u00e9pendamment des technologies et des organisations, ce qui permet donc des comparaisons (benchmarking),<\/li>\n<li>avec pour cons\u00e9quence que cette mesure est souvent utilis\u00e9e pour appr\u00e9cier la productivit\u00e9 des d\u00e9veloppeurs.<\/li>\n<\/ul>\n<h2>Les d\u00e9veloppeurs connaissent-ils les Points de Fonction ?<\/h2>\n<p>Non, les d\u00e9veloppeurs ne connaissent pas les Points de Fonction. Affirmation os\u00e9e ? Peut-\u00eatre. Mais je n\u2019ai jamais rencontr\u00e9 un seul d\u00e9veloppeur qui sache ce dont il s\u2019agit.<\/p>\n<p>Une raison pourrait \u00eatre que, selon moi, les d\u00e9veloppeurs ne sont pas naturellement int\u00e9ress\u00e9s par les aspects fonctionnels. Je ne dis pas que cela leur importe peu, nombre de d\u00e9veloppeurs se sp\u00e9cialisent dans les m\u00e9tiers de la banque, de la finance, de l\u2019industrie, etc. ou sur certains processus : Gestion de stocks, Logistique, Ressources Humaines, etc. Mais nous savons bien qu\u2019il vaut mieux leur parler de nouvelles technologies, de nouveaux langages informatiques, de frameworks, \u00e9ventuellement de m\u00e9thodologies de d\u00e9veloppement ou de projet, afin de retenir leur attention, plut\u00f4t que de processus m\u00e9tier et de fonctionnalit\u00e9s.<\/p>\n<p>Autres raisons pour lesquelles ils ne vont pas s\u2019int\u00e9resser naturellement \u00e0 cette m\u00e9trique :<\/p>\n<ul>\n<li>C\u2019est complexe \u00e0 comprendre : les d\u00e9veloppeurs savent ce qu\u2019est une transaction ou une structure de donn\u00e9es, mais bon courage pour leur expliquer les subtilit\u00e9s de notions telles que les \u2018fronti\u00e8res\u2019 applicatives et autres \u2018facteurs d\u2019ajustement\u2019.<\/li>\n<li>Il s\u2019agit d\u2019un processus manuel, g\u00e9n\u00e9ralement long et fastidieux, mais surtout non automatisable. Nous reviendrons l\u00e0-dessus dans une seconde partie sur les Automated Function Points.<\/li>\n<\/ul>\n<p>Je pense qu\u2019il existe \u00e9galement certaines raisons culturelles. Les soci\u00e9t\u00e9s et les savoirs anglo-saxons sont assez orient\u00e9s vers le\u00a0 quantitatif, alors que nous autres europ\u00e9ens et latins sont plus port\u00e9s vers le qualitatif.<\/p>\n<p>Je me souviens de mes cours de sociologie du travail \u00e0 l\u2019universit\u00e9. Lorsqu\u2019une \u00e9quipe de sociologues am\u00e9ricains voulait \u00e9tudier une organisation \u2013 par exemple, une \u00e9quipe d\u2019ouvriers au travail \u2013 et voir quels enseignements en tirer ou comment l\u2019am\u00e9liorer, ils favorisaient l\u2019observation et la collecte de donn\u00e9es afin de mesurer la dur\u00e9e d\u2019une op\u00e9ration, le temps pass\u00e9 pour que le produit X aille du point A au point B, le nombre de produits fabriqu\u00e9s, le nombre de d\u00e9fauts, etc.<\/p>\n<p>Une \u00e9quipe, disons fran\u00e7aise, commencait par des interviews avec les employ\u00e9s, afin de noter leur int\u00e9r\u00eat (ou non) au travail, leurs remarques sur le processus de fabrication et ses d\u00e9fauts, leurs suggestions en mati\u00e8re d\u2019organisation de la cha\u00eene de production, etc. L\u2019approche \u00e9tait essentiellement qualitative, non pas tant quantitative.<br \/>\nNombre de personnes consid\u00e8rent d\u2019ailleurs qu\u2019il n\u2019est pas possible de mesurer la productivit\u00e9 du travail intellectuel et d\u2019une mani\u00e8re g\u00e9n\u00e9rale, toute production immat\u00e9rielle.<\/p>\n<h2>Points de fonction et productivit\u00e9<\/h2>\n<p>Autre raison pour laquelle les Points de Fonction suscitent un int\u00e9r\u00eat plus important dans les contr\u00e9es anglo-saxonnes que dans nos pays latins : la mesure de la productivit\u00e9. La capacit\u00e9 \u00e0 benchmarker les \u00e9quipes de projet et les outsourceurs afin de v\u00e9rifier lesquels sont capable de produire du code (si possible de qualit\u00e9) le plus rapidement possible constitue une sorte de Saint Graal au sein de la communaut\u00e9 des consultants anglo-saxons.<\/p>\n<p>Ces aspects de productivit\u00e9 n\u2019occupent pas une place aussi importante dans nos organisations. Je me souviens d\u2019un manager anglais auquel j\u2019expliquais que j&rsquo;avais rencontr\u00e9 des d\u00e9veloppeurs qui ne souhaitaient pas utiliser un logiciel d\u2019analyse de code, malgr\u00e9 toutes les incitations et les efforts de leur hi\u00e9rarchie. Il m\u2019a imm\u00e9diatement r\u00e9pondu que cela n\u2019arriverait pas avec lui car il aurait vir\u00e9 imm\u00e9diatement les r\u00e9ticents. Ce qui serait quasiment impossible dans des pays plus \u2018latins\u2019, sinon en France, tout au moins en Espagne.<\/p>\n<p>\u00c9videmment, un d\u00e9veloppeur ne peut pas refuser un ordre direct de son boss, mais imposer \u00e0 toute une \u00e9quipe de projet l\u2019utilisation d\u2019un outil est impensable, sous peine de voir celle-ci soulever toutes sortes d\u2019objections, de dangers et de risques, compromettant le d\u00e9veloppement de la prochaine version, et finalement de la voir succomber \u00e0 une sorte d\u2019apathie qui confine \u00e0 l\u2019inertie la plus totale sur le sujet. C\u2019est d\u2019ailleurs une des raisons pour lesquelles je dis toujours que la qualit\u00e9 applicative vient des d\u00e9veloppeurs et ne se d\u00e9cr\u00e8te pas. Convaincre oui, imposer non.<\/p>\n<p>De surcro\u00eet, autant les d\u00e9veloppeurs sont le plus souvent tr\u00e8s enthousiastes \u00e0 d\u00e9couvrir de nouveaux outils, autant ils vont se r\u00e9v\u00e9ler naturellement assez m\u00e9fiants s\u2019il s\u2019agit de contr\u00f4ler leur travail ou leur productivit\u00e9.<\/p>\n<h2>Les d\u00e9veloppeurs ont-ils besoin de Points de Fonction ?<\/h2>\n<p>Je ne pense pas que les d\u00e9veloppeurs aient besoin de Points de Fonction.<\/p>\n<p>Ils seraient bien s\u00fbr int\u00e9ress\u00e9s par une mesure pr\u00e9cise des fonctionnalit\u00e9s \u00e0 impl\u00e9menter dans un logiciel, mais ils sont surtout plus attentifs \u00e0 ce que celles-ci n\u2019\u00e9voluent pas constamment durant la phase de d\u00e9veloppement. D\u2019ailleurs, un bon chef de projet avec de l\u2019exp\u00e9rience saura estimer la charge de travail repr\u00e9sent\u00e9e par ces fonctionnalit\u00e9s. Et il saura qu\u2019il existe \u00e9galement toutes sortes de facteurs qui peuvent handicaper son \u00e9quipe \u00e0 l\u2019heure de livrer une application en temps et en heure : l\u2019emploi d\u2019une nouvelle technologie pas compl\u00e8tement d\u00e9bogu\u00e9e, des processus de projet inad\u00e9quats, un outillage imparfait ou mal int\u00e9gr\u00e9, une \u00e9quipe mal form\u00e9e ou manquant d\u2019exp\u00e9rience, etc.<\/p>\n<p>Je pense \u00e9galement que les d\u00e9veloppeurs n\u2019ont pas besoin des Points de Fonction pour conna\u00eetre leur productivit\u00e9. Il existe aujourd\u2019hui tant de m\u00e9triques qui permettent de savoir qui fait quoi dans une \u00e9quipe de projet, et si c\u2019est bien fait : nombre de check-in\/check-out, couverture de tests, nombre de d\u00e9fauts trouv\u00e9s en QA, etc. Sans parler des m\u00e9triques d\u2019analyse de code : il est tr\u00e8s facile de savoir qui fait du copier-coller, qui ne commente jamais ou tr\u00e8s peu son code, qui ignore une best practice et n\u00e9cessite un rappel, etc.<\/p>\n<p>Il m\u2019est d\u2019ailleurs arriv\u00e9 de pr\u00e9senter \u00e0 un client une mesure de l\u2019effort de d\u00e9veloppement entre deux versions, sans passer par les Points de Fonction. Si je sais combien de composants ont \u00e9t\u00e9 ajout\u00e9s, modifi\u00e9s, supprim\u00e9s entre ces versions, et si j\u2019affecte une charge de travail \u00e0 chacune de ces t\u00e2ches (en fonction de la complexit\u00e9 de ces composants par exemple), je suis capable d\u2019estimer le nombre de jours rendus n\u00e9cessaires par la r\u00e9alisation de cette nouvelle version.<\/p>\n<p>Bien s\u00fbr, je n\u2019obtiendrai pas un r\u00e9sultat tr\u00e8s pr\u00e9cis (1). Cependant, je pr\u00e9f\u00e8re une mesure impr\u00e9cise mais facilement compr\u00e9hensible, \u00e0 une m\u00e9trique qui se pr\u00e9tend exacte mais dont on ne sait pas exactement comment elle a \u00e9t\u00e9 calcul\u00e9e. Et mon client \u00e9galement : il souhaite savoir si, par exemple, son outsourceur a r\u00e9ellement pass\u00e9 les 500 jours qu\u2019il lui a factur\u00e9s, et qui lui paraissent exag\u00e9r\u00e9s au vu du travail fourni. Si mon estimation est facilement compr\u00e9hensible, au point qu\u2019il puisse lui-m\u00eame en utiliser la formule d\u2019une mani\u00e8re assez objective et r\u00e9aliste, une diff\u00e9rence de 10% ou 20% dans l\u2019\u00e9valuation ne sera pas vraiment un probl\u00e8me. Mais si notre calcul aboutit \u00e0 200 ou 300 jours de charge estim\u00e9e au lieu des 500 factur\u00e9s, cet outsourceur va se voir poser quelques questions.<\/p>\n<p>Cela joue dans les deux sens d\u2019ailleurs. On m\u2019a demand\u00e9 une fois un audit \u2018\u00e0 l\u2019aveugle\u2019 d\u2019une application critique qui avait plus de quatre mois de retard. Je dis \u2018\u00e0 l\u2019aveugle\u2019 car je n\u2019ai pu obtenir aucune information concernant le contexte ou l\u2019historique de ce projet (je d\u00e9teste cela). J\u2019ai alors constat\u00e9 un nombre tr\u00e8s \u00e9lev\u00e9 de composants ajout\u00e9s puis supprim\u00e9s entre les deux derni\u00e8res versions, et j\u2019ai expliqu\u00e9 au client et son outsourceur que cela me semblait caract\u00e9ristique d\u2019\u00e9volutions importantes des requirements fonctionnels entre ces deux releases. C\u2019est effectivement ce qui s\u2019\u00e9tait pass\u00e9, et dont a d\u00fb convenir ce client, sur la base d\u2019une estimation certes impr\u00e9cise mais n\u00e9anmoins suffisamment objective pour r\u00e9soudre un diff\u00e9rent avec son prestataire, et dont celui-ci n&rsquo;\u00e9tait, en d\u00e9finitive, pas responsable.<\/p>\n<p>Cet exemple montre qu\u2019une telle mesure est utile, et c\u2019est d\u2019ailleurs la raison d\u2019\u00eatre des Points de Fonction, qui supposent une pr\u00e9cision bien plus appr\u00e9ciable que mon simple calcul. Imaginons maintenant que l\u2019estimation des Points de Fonction puisse \u00eatre automatis\u00e9e: cela suffirait-il pour que les d\u00e9veloppeurs utilisent cette mesure ?<\/p>\n<p>C\u2019est ce que nous verrons dans notre prochain post.<\/p>\n<p><span style=\"text-decoration: underline\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/span><\/p>\n<p>(1) J\u2019ai not\u00e9 cependant que les chiffres obtenus pour des L4G type Cobol ou client-serveur sont un peu plus pr\u00e9cis qu\u2019avec des langages orient\u00e9s objet.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Le titre de ce post paraphrase le titre d\u2019un roman de science-fiction que vous connaissez peut-\u00eatre : \u00ab Do Androids Dream of Electric Sheep? \u00bb. Cette nouvelle de Philip K. Dick a servi de base au film \u00ab Blade Runner \u00bb de Ridley Scott, dans lequel un d\u00e9tective du futur doit retrouver et neutraliser des [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2429","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2429"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=2429"}],"version-history":[{"count":11,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2429\/revisions"}],"predecessor-version":[{"id":2435,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2429\/revisions\/2435"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=2429"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=2429"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=2429"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}