Le titre de ce post paraphrase le titre d’un roman de science-fiction que vous connaissez peut-être : « Do Androids Dream of Electric Sheep? ».

Cette nouvelle de Philip K. Dick a servi de base au film « Blade Runner » de Ridley Scott, dans lequel un détective du futur doit retrouver et neutraliser des androïdes que rien ne diffère des humains.

Dans le livre, ce détective possède un mouton en chair et en os, qu’il remplace, à sa mort, par un mouton ‘électrique’. Il en vient à se demander si les androïdes rêvent comme lui d’un animal de compagnie, mais dans leur version ‘animaloïde’.

Cette œuvre de K. Dick soulève une réflexion sur la différence entre l’humain et le robot, entre le réel et l’automatisé. Elle m’est revenue à l’esprit lorsque je me suis posé la question de la différence entre les Points de Fonction (Function Points ou FP) manuels et automatisés (Automated Function Points ou AFP).

Aujourd’hui, de plus en plus de développeurs utilisent quotidiennement les métriques d’outils d’analyse de code, les statistiques de tests, de suivi de corrections/évolutions, les données de Dette Technique, etc. dans le cadre de leur projet ou d’un processus d’Intégration Continue.
Je me suis donc demandé pourquoi les développeurs, de plus en plus friands de mesures concernant leur code et leur projet, ignorent généralement tout de ce qui touche aux Points de Fonction. Est-ce que cette mesure pourrait les intéresser ?

Points de Fonction

Je ne vais pas vous expliquer ce que sont les Points de Fonction : ce n’est pas l’objet de ce post et il faudrait de nombreuses pages pour y parvenir. D’autant que ce vocable recouvre différentes normes et méthodes, pour ne pas dire différentes écoles. Disons simplement que les FP sont une mesure de la taille fonctionnelle d’une application basée sur les flux transactionnels et les structures de données.

Je sais, ce n’est pas une définition précise ni parfaite, mais encore une fois, je ne veux pas entrer dans cette discussion, sinon simplement rappeler quels en sont les objectifs principaux :

• mesurer les fonctionnalités d’une application existante ou future,
• de manière normalisée et objective, indépendamment des technologies et des organisations, ce qui permet donc des comparaisons (benchmarking),
• avec pour conséquence que cette mesure est souvent utilisée pour apprécier la productivité des développeurs.

Les développeurs connaissent-ils les Points de Fonction ?

Non, les développeurs ne connaissent pas les Points de Fonction. Affirmation osée ? Peut-être. Mais je n’ai jamais rencontré un seul développeur qui sache ce dont il s’agit.

Une raison pourrait être que, selon moi, les développeurs ne sont pas naturellement intéressés par les aspects fonctionnels. Je ne dis pas que cela leur importe peu, nombre de développeurs se spécialisent dans les métiers de la banque, de la finance, de l’industrie, etc. ou sur certains processus : Gestion de stocks, Logistique, Ressources Humaines, etc. Mais nous savons bien qu’il vaut mieux leur parler de nouvelles technologies, de nouveaux langages informatiques, de frameworks, éventuellement de méthodologies de développement ou de projet, afin de retenir leur attention, plutôt que de processus métier et de fonctionnalités.

Autres raisons pour lesquelles ils ne vont pas s’intéresser naturellement à cette métrique :

• C’est complexe à comprendre : les développeurs savent ce qu’est une transaction ou une structure de données, mais bon courage pour leur expliquer les subtilités de notions telles que les ‘frontières’ applicatives et autres ‘facteurs d’ajustement’.
• Il s’agit d’un processus manuel, généralement long et fastidieux, mais surtout non automatisable. Nous reviendrons là-dessus dans une seconde partie sur les Automated Function Points.

Je pense qu’il existe également certaines raisons culturelles. Les sociétés et les savoirs anglo-saxons sont assez orientés vers le  quantitatif, alors que nous autres européens et latins sont plus portés vers le qualitatif.

Je me souviens de mes cours de sociologie du travail à l’université. Lorsqu’une équipe de sociologues américains voulait étudier une organisation – par exemple, une équipe d’ouvriers au travail – et voir quels enseignements en tirer ou comment l’améliorer, ils favorisaient l’observation et la collecte de données afin de mesurer la durée d’une opération, le temps passé pour que le produit X aille du point A au point B, le nombre de produits fabriqués, le nombre de défauts, etc.

Une équipe, disons française, commencait par des interviews avec les employés, afin de noter leur intérêt (ou non) au travail, leurs remarques sur le processus de fabrication et ses défauts, leurs suggestions en matière d’organisation de la chaîne de production, etc. L’approche était essentiellement qualitative, non pas tant quantitative.
Nombre de personnes considèrent d’ailleurs qu’il n’est pas possible de mesurer la productivité du travail intellectuel et d’une manière générale, toute production immatérielle.

Points de fonction et productivité

Autre raison pour laquelle les Points de Fonction suscitent un intérêt plus important dans les contrées anglo-saxonnes que dans nos pays latins : la mesure de la productivité. La capacité à benchmarker les équipes de projet et les outsourceurs afin de vérifier lesquels sont capable de produire du code (si possible de qualité) le plus rapidement possible constitue une sorte de Saint Graal au sein de la communauté des consultants anglo-saxons.

Ces aspects de productivité n’occupent pas une place aussi importante dans nos organisations. Je me souviens d’un manager anglais auquel j’expliquais que j’avais rencontré des développeurs qui ne souhaitaient pas utiliser un logiciel d’analyse de code, malgré toutes les incitations et les efforts de leur hiérarchie. Il m’a immédiatement répondu que cela n’arriverait pas avec lui car il aurait viré immédiatement les réticents. Ce qui serait quasiment impossible dans des pays plus ‘latins’, sinon en France, tout au moins en Espagne.

Évidemment, un développeur ne peut pas refuser un ordre direct de son boss, mais imposer à toute une équipe de projet l’utilisation d’un outil est impensable, sous peine de voir celle-ci soulever toutes sortes d’objections, de dangers et de risques, compromettant le développement de la prochaine version, et finalement de la voir succomber à une sorte d’apathie qui confine à l’inertie la plus totale sur le sujet. C’est d’ailleurs une des raisons pour lesquelles je dis toujours que la qualité applicative vient des développeurs et ne se décrète pas. Convaincre oui, imposer non.

De surcroît, autant les développeurs sont le plus souvent très enthousiastes à découvrir de nouveaux outils, autant ils vont se révéler naturellement assez méfiants s’il s’agit de contrôler leur travail ou leur productivité.

Les développeurs ont-ils besoin de Points de Fonction ?

Je ne pense pas que les développeurs aient besoin de Points de Fonction.

Ils seraient bien sûr intéressés par une mesure précise des fonctionnalités à implémenter dans un logiciel, mais ils sont surtout plus attentifs à ce que celles-ci n’évoluent pas constamment durant la phase de développement. D’ailleurs, un bon chef de projet avec de l’expérience saura estimer la charge de travail représentée par ces fonctionnalités. Et il saura qu’il existe également toutes sortes de facteurs qui peuvent handicaper son équipe à l’heure de livrer une application en temps et en heure : l’emploi d’une nouvelle technologie pas complètement déboguée, des processus de projet inadéquats, un outillage imparfait ou mal intégré, une équipe mal formée ou manquant d’expérience, etc.

Je pense également que les développeurs n’ont pas besoin des Points de Fonction pour connaître leur productivité. Il existe aujourd’hui tant de métriques qui permettent de savoir qui fait quoi dans une équipe de projet, et si c’est bien fait : nombre de check-in/check-out, couverture de tests, nombre de défauts trouvés en QA, etc. Sans parler des métriques d’analyse de code : il est très facile de savoir qui fait du copier-coller, qui ne commente jamais ou très peu son code, qui ignore une best practice et nécessite un rappel, etc.

Il m’est d’ailleurs arrivé de présenter à un client une mesure de l’effort de développement entre deux versions, sans passer par les Points de Fonction. Si je sais combien de composants ont été ajoutés, modifiés, supprimés entre ces versions, et si j’affecte une charge de travail à chacune de ces tâches (en fonction de la complexité de ces composants par exemple), je suis capable d’estimer le nombre de jours rendus nécessaires par la réalisation de cette nouvelle version.

Bien sûr, je n’obtiendrai pas un résultat très précis (1). Cependant, je préfère une mesure imprécise mais facilement compréhensible, à une métrique qui se prétend exacte mais dont on ne sait pas exactement comment elle a été calculée. Et mon client également : il souhaite savoir si, par exemple, son outsourceur a réellement passé les 500 jours qu’il lui a facturés, et qui lui paraissent exagérés au vu du travail fourni. Si mon estimation est facilement compréhensible, au point qu’il puisse lui-même en utiliser la formule d’une manière assez objective et réaliste, une différence de 10% ou 20% dans l’évaluation ne sera pas vraiment un problème. Mais si notre calcul aboutit à 200 ou 300 jours de charge estimée au lieu des 500 facturés, cet outsourceur va se voir poser quelques questions.

Cela joue dans les deux sens d’ailleurs. On m’a demandé une fois un audit ‘à l’aveugle’ d’une application critique qui avait plus de quatre mois de retard. Je dis ‘à l’aveugle’ car je n’ai pu obtenir aucune information concernant le contexte ou l’historique de ce projet (je déteste cela). J’ai alors constaté un nombre très élevé de composants ajoutés puis supprimés entre les deux dernières versions, et j’ai expliqué au client et son outsourceur que cela me semblait caractéristique d’évolutions importantes des requirements fonctionnels entre ces deux releases. C’est effectivement ce qui s’était passé, et dont a dû convenir ce client, sur la base d’une estimation certes imprécise mais néanmoins suffisamment objective pour résoudre un différent avec son prestataire, et dont celui-ci n’était, en définitive, pas responsable.

Cet exemple montre qu’une telle mesure est utile, et c’est d’ailleurs la raison d’être des Points de Fonction, qui supposent une précision bien plus appréciable que mon simple calcul. Imaginons maintenant que l’estimation des Points de Fonction puisse être automatisée: cela suffirait-il pour que les développeurs utilisent cette mesure ?

C’est ce que nous verrons dans notre prochain post.

                                                                                

(1) J’ai noté cependant que les chiffres obtenus pour des L4G type Cobol ou client-serveur sont un peu plus précis qu’avec des langages orientés objet.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.