« Fonctionnel » versus « technique » 

Une apparente opposition ?

Et si nous stoppions l’exécution des tâches techniques ?

Pour s’en convaincre, nous pouvons effectuer l’expérience de pensée suivante : « Que se passerait-t-il si les tâches techniques disparaissent de l’univers du développement logiciel ? »

Pour une équipe convaincue que les tâches qui lui incombent sont strictement circonscrites à la technique. Présentant des difficultés à identifier le fonctionnel, le lien à ses utilisateurs, il s’agit d’un exercice révélateur. L’abandon, par cette équipe, des tâches techniques aura de fait un impact potentiellement lourd sur beaucoup d’utilisateurs. Et ce, directement ou indirectement. Nous venons de découvrir que toutes les actions techniques n’ont pour raison d’être que de servir in fine des utilisateurs. Elles sont toutes entières dirigées vers un objectif pragmatique lié aux besoins des utilisateurs.

Mais l’inverse est tout aussi vrai. A titre d’illustration, il est fort probable qu’une équipe veuille, à terme, désinstaller une base de données qui ne serait jamais utilisée. De même, un code source qui ne serait pas exécuté, un embranchement dans un code source qui ne serait jamais appelé – ce qu’on appelle du code mort* – nécessiterait d’être supprimé.

Ainsi, chaque tâche technique est réalisée au service du fonctionnel, et le fonctionnel est toujours adossé à un prérequis technique. Les deux ensembles se recouvrent parfaitement. Et le fonctionnel et la technique ne sont pas tant deux objets différents que deux manières de les percevoir. Les octets* fonctionnels sont donc les mêmes que les octets techniques.

Une petite anecdote

Pour compléter la démonstration ci-dessus, voici une anecdote directement tirée de mon expérience :

Un jour, alors que j’accompagnais une équipe de développement, apparut la tâche « parallélisation des threads* ». Je demandais à l’équipe s’il était possible de reformuler cette tâche en adoptant le point de vue de l’utilisateur. La réaction de mes interlocuteurs fut vive : « Bien sûr que non, pardi ! [Puisqu’il s’agissait d’une tâche purement technique (paralléliser des processus) et qu’il n’y avait rien de fonctionnel dans cette action] ».

Or, quand on parallélise des processus, il est relativement aisé d’identifier l’objectif fonctionnel subjacent… Étant convaincu que chaque tâche technique sert du fonctionnel, et que chaque tâche fonctionnelle a une contrepartie technique. Je demandais donc à l’équipe :

«  Que se passerait-il si nous décidions d’abandonner cette parallélisation des threads ?

– Mais tu n’y penses pas ! Nous aurions beaucoup de problèmes de performance. Nous ne serions pas en mesure de livrer des données à temps pour un de nos autres services [une autre équipe avec laquelle nous travaillions]. En outre, cela nous empêcherait de délivrer des informations à un prestataire, ce qui bloquerait un second prestataire et finalement les clients de notre organisation ! »

Ainsi, grâce à l’expérience de pensée consistant à abandonner volontairement une tâche technique, nous avions souligné d’une part que nous cherchions à accroître la performance ; et c’était bien là le but visé. Mais également que si nous cherchions à accroître cette performance, c’était au service d’une autre équipe de l’entreprise, de deux prestataires et des clients finaux de l’organisation. Nous venions de découvrir qu’il y avait en fait pas moins de quatre groupes d’utilisateurs directement concernés par l’apport fonctionnel résultant de cette action technique.

Nous reformulâmes alors cette dernière en une tâche fonctionnelle : « en tant que prestataire, je reçois ces données sous tel délai. » Nous avions en fait élaboré ce qui s’appelle une histoire utilisateur*, que nous aurions pu compléter comme suit : « en tant que prestataire, je reçois les données sous tel délai… afin de pouvoir délivrer une information à tel autre prestataire et aux clients finaux ».

Nous avions donc déterminé à la fois le quoi (c’est-à-dire la finalité ; en l’occurrence, accroître la performance) et le pour qui (c’était pour servir un autre prestataire et des clients).

En d’autres termes, le questionnement portant sur le fait de réaliser ou pas une tâche technique permit à l’équipe de conscientiser l’aspect fonctionnel latent derrière cette tâche technique.

Des vertus de la reformulation des tâches techniques sous une forme fonctionnelle

Mais il y eut d’autres avantages. À partir du moment où nous avions reformulé le besoin sous forme fonctionnelle – c’est-à-dire une question de performance, et non pas une simple question de parallélisation de threads – l’équipe découvrit et proposa d’autres possibilités pour avancer vers ce quoi, vers l’amélioration de la performance.

Un premier développeur proposa notamment d’optimiser certaines parties de code source qui pouvaient l’être. Un deuxième membre de l’équipe suggéra d’accroître temporairement la puissance des serveurs puisque ce traitement critique était exécuté une seule fois par an. Une troisième personne enfin proposa de réaliser des tests de performance, ce qui nous permettrait d’obtenir des informations fiables et de s’adapter en l’espèce.

Lorsque les enjeux étaient formulés de manière purement technique, ces solutions restaient dans l’ombre et n’apparaissaient pas spontanément. A partir du moment où nous les avions énoncés sous une forme fonctionnelle – à savoir des contraintes de performance. En plus de cette parallélisation des threads – nous vîmes émerger l’amélioration du code source, la possibilité d’avoir des serveurs plus puissants pour une courte période, ainsi que la pertinence de réaliser des tests de performance.

Pour conclure

Exprimer le fonctionnel, c’est exprimer le quoi, le résultat attendu du point de vue de l’utilisateur ; et donc laisser à l’équipe de réalisation le soin du comment elle va s’y prendre. Une telle approche ouvre pléthore de possibilités techniques pour répondre aux besoins de nos utilisateurs… Mais dans tous les cas, le fonctionnel et la technique sont bien les deux faces d’un même objet.

Exprimer sous forme fonctionnelle permet de livrer rapidement quelque chose qui fonctionne, c’est un des multiples moyens de donner de la visibilité et donc d’atténuer les estimations.

Si vous souhaitez aller plus loin sur le sujet des estimations, vous pouvez consulter l’article « Estimations et développement logiciel » ainsi que notre page formation « Par-delà les estimations« .

---

Glossaire :

• octet : multiple de 8 bits codant une information
• parallélisation des « threads » (ou des processus) : exécution simultanée de plusieurs processus souvent utilisée afin d’accroître la performance globale