2. Pourquoi l’agilité a besoin d’un code modifiable
2.1 Petites expériences, rétroaction et livraison
L’agilité repose sur des itérations assez petites pour apprendre rapidement. On réalise une expérience, recueille des données ou une rétroaction, puis ajuste la suite. Cette démarche s’applique au produit comme à l’organisation du travail. Une méthode ou une fonctionnalité n’a pas à rester inchangée parce qu’elle a été choisie au départ.
La capacité à livrer fréquemment réduit aussi le délai entre une idée et sa validation. Christian Desrosiers indique pouvoir livrer plusieurs fois par jour dans son entreprise; certaines organisations ont des cadences encore plus élevées. L’objectif n’est pas d’imposer la même fréquence partout, mais de rendre le produit livrable lorsque cela devient utile. La cadence doit correspondre au contexte du client et du système.
Cette capacité demande un code que l’équipe peut comprendre, modifier et vérifier sans recommencer une validation manuelle interminable. Les tests et le refactoring soutiennent ainsi les principes agiles au niveau technique.
2.2 Distinguer un problème compliqué d’un problème complexe
Le conférencier utilise un pont comme exemple de problème compliqué : les principes sont maîtrisés, on peut établir un plan et décomposer le travail en éléments connus. La difficulté peut être grande, mais le chemin de résolution est relativement compris.
Le logiciel innovant peut au contraire présenter un problème complexe. Les usages, les besoins et la bonne solution ne sont pas entièrement connus. Le chemin compte autant que la destination envisagée, parce que les expériences peuvent révéler qu’il faut aller ailleurs.
Dans ce deuxième contexte, suivre obstinément un plan sans rétroaction peut conduire à réaliser correctement la mauvaise chose. Les petites expériences servent à vérifier les hypothèses avant d’investir tout le projet sur elles. L’acceptation du changement découle de cette incertitude, plutôt que d’un goût pour les modifications permanentes.
2.3 La simplicité : ne pas développer ce qui n’est pas encore nécessaire
Une preuve de concept de location de voitures n’exige pas de proposer immédiatement tous les modèles et tous les forfaits imaginables. Quelques possibilités suffisent pour observer les usages auprès de personnes représentatives. Leurs réactions peuvent ensuite orienter l’évolution du service.
Cet exemple illustre la simplicité comme recherche du travail utile et évitement du travail prématuré. Ce qui n’est pas développé n’a pas encore à être testé, maintenu et adapté. Le choix reste une expérience d’apprentissage, pas une réduction arbitraire de la qualité attendue.
2.4 Refactoring et tests rendent le changement soutenable
Un produit professionnel ne se termine pas au premier dépôt du code. Ses besoins et sa structure évoluent. Le refactoring consiste ici à améliorer l’organisation du code tout en conservant son comportement attendu. Pour le faire avec confiance, il faut un moyen de reconnaître les effets de bord.
Le conférencier défend fortement l’idée qu’une pratique agile sans tests est incomplète : avancer vite sans savoir si l’on casse le produit ne donne pas la maîtrise recherchée. Les tests n’empêchent pas tous les problèmes; ils fournissent une protection vérifiable pour les comportements qu’ils couvrent. Le choix et la qualité de ces comportements restent déterminants.