Les 8 et 9 février 2024 s’est déroulée la 6e édition de la Touraine Tech, dont Sopra Steria était l’un des sponsors.
Parmi les quelques 75 conférences qui s’y sont déroulées, je voudrais vous inciter à visionner celle qui m’a le plus marquée, et qui s’intitule « Grosse fonctionnalité, petites livraisons : l'art du découpage » présentée par Yann Bertrand, disponible ici en rediffusion. Vous pourrez y découvrir des méthodes de livraison et de découpage qui sortent de l’ordinaire, illustrées ludiquement via un serveur Minecraft.
J’aimerais plus particulièrement vous détailler la dernière partie de ce talk, additionnée de recherches personnelles, pour tenter de répondre à la question suivante :
Quelle est la taille idéale d’un lot ?
Plus précisément, quelle taille doit faire une tâche de développement pour apporter régulièrement de la valeur à mon client, en assurant la qualité de mon code, tout en favorisant la motivation dans l’équipe ?
On se placera dans le cas le plus répandu qui est la revue asynchrone, où une personne va développer le code dans un premier temps, puis son code sera relu et approuvé par au moins un de ses pairs qui s’assurera que les standards de qualités établis au préalable au sein de l’équipe de développeurs sont respectés.
La littérature nous indique qu’une session de relecture de code ne doit pas excéder 200 à 400 lignes relues, et ne pas durer plus d’1h30, ce qui permettrait de détecter 70 à 90% des bugs.
On pourrait se cantonner à ces recommandations génériques, mais allons plus loin avec le « Lean Product Development ». Il s’agit d’une approche de développement de produits axée sur la réduction des pertes, l'accélération de la livraison et l'augmentation des bénéfices et de la valeur pour le client. Donald Reinertsen, consultant pionnier de cette méthode, a formalisé dans son best-seller « The Principles of Product Development Flow » le graphique qui suit :
En appliquant cette approche au domaine du développement logiciel, on peut analyser ce graphique de la façon suivante :
Coût de stockage
Cette droite décrit que plus la tâche est longue :
- plus le temps nécessaire pour la revue sera long ; il y aura donc plus de risque que la relecture devienne inefficace.
- moins il y aura de chances que le code passe la revue du premier coup ; il devra donc faire l'objet de plusieurs revues, ce qui implique un changement de contexte régulier, délétère pour la productivité globale.
- plus cela augmente la quantité de travail à refaire si le développeur a fait une mauvaise hypothèse de départ.
- moins le développeur aussi bien que le relecteur seront motivés à s’atteler à cette tâche. La perception d’urgence sur cette tâche sera également moindre.
- plus il y aura de risque de conflit de merge.
- plus il faudra de temps pour que le code soit mis en production et apporte une valeur ajoutée au client.
Coût de transaction
Cette courbe, qui décroît à mesure que la taille de la tâche augmente, représente le coût pour diviser le travail à accomplir en tâches de la taille voulue, qui soient suffisamment indépendantes pour permettre à plusieurs développeurs de travailler en parallèle.
Ce coût comprend également le fait de devoir créer les tickets associés, mais également un plan de test correspondant, générer des environnements dédiés si nécessaire, etc.
On s’aperçoit ainsi de l’importance d’automatiser un maximum de processus techniques afin de diminuer ce coût de transaction.
Coût total
En additionnant ces deux métriques, on obtient un courbe en cloche avec un minimum correspondant à la taille de lot optimale.
Ainsi, bien que la qualité finale du code soit améliorée en faisant des lots de taille réduite, on se rend compte avec ce graphique qu’il ne s’agit pas d’avoir des tâches les plus petites possibles, mais de trouver un juste milieu, le coût de transaction étant limitant.
Conclusion
Ces éléments ne nous permettent donc pas de déterminer de façon absolue une taille de lot idéale.
On peut s’accorder à dire qu’il n’est pas souhaitable de réaliser une tâche tenant en plus de quelques centaines de lignes, mais il s’agit surtout de rechercher cet équilibre de « taille optimale » de façon empirique, en fonction de l’équipe et du contexte dans lesquels on travaille.
Cette expérimentation sera facilitée dans un contexte agile, ou on pourra découper les fonctionnalités à développer plus ou moins finement selon les itérations, tout en automatisant un maximum de processus, et ainsi se rapprocher progressivement de cet optimum
Bonus
Stand Sopra Steria lors de l’évènement Touraine Tech 2024