Dans l’épaisseur du trait
Dans le domaine du développement logiciel, on oppose fréquemment le travail de mise en œuvre de fonctionnalités à celui des tâches dites techniques.
Ainsi, sur un site marchand, l’ajout d’un système de points de fidélité constitue un plus pour les utilisateurs : il s’agit donc d’une fonctionnalité.
À l’inverse, la réalisation d’une montée de version (d’une bibliothèque, d’une base de données ou de tout autre composant) relève d’une tâche technique. Cette opération, n’ayant aucune incidence immédiate sur l’expérience de l’utilisateur, est classée parmi les travaux techniques.
Photo : Nicolas Éliard
La priorisation des fonctionnalités destinées par les utilisateurs ou leurs représentants, bien que rarement triviale, demeure généralement accessible. En revanche, la priorisation des tâches techniques s’avère nettement plus ardue. Il est ainsi aisé de comparer la mise en place d’un programme de fidélité, l’optimisation du tunnel de commande et l’amélioration de l’accessibilité. Dès que les interventions techniques entrent en jeu, la complexité augmente considérablement, et le danger d’un report perpétuel (véritable bombe à retardement dont le risque s’amplifie chaque jour) devient palpable.
Un des principaux freins réside dans l’opposition systématique entre les fonctionnalités et les tâches techniques. Cette dichotomie apparaît notamment dans les environnements prédictifs. Lorsqu’au moyen de points de complexité, des estimations de chaque développement sont réalisé. Ou que des sprints sont utilisé afin de prédire ce qui sera livré (ou pas) dans X semaines. Ce qui, dans un contexte imprévisible, est une pure perte. Dans ces contextes, nous opposons les fonctionnalités aux tâches techniques. C’est soit l’un, soit l’autre.
Dans une démarche purement adaptative, la problématique de ce qui sera prêt ne se pose pas. De même qu’en présence d’un public non technique, nous évitons de parler technique, les tâches techniques peuvent être réalisées dans l’épaisseur du trait. Ainsi, pour chuaque mise à jour fonctionnelle, dès qu’un petit incrément technique est prêt, il est déployé. Avec une cadence de livraison hebdomadaire, on peut ainsi mettre en production cinquante incréments techniques chaque année. Avec une mise à jour quotidienne, ce chiffre atteint deux cent cinquante incréments annuels, assurant ainsi un système à jour. Avec cette approche, plus nous livrons de fonctionnalités, plus nous livrons de tâches dites techniques.
Cette approche simplifie considérablement la priorisation des tâches dites techniques. Dans un prochain article, nous étudierons une autre manière de faire.