Améliorer avant de Stabiliser
[QualityManagement, TDD, Test]
Vous ne pouvez pas améliorer un système sans d’abord le stabiliser. Pour le stabiliser, il faut s’intéresser à ses régulateurs.
Le système qui préoccupe Xavier (le CTO des posts précédents), en l’occurrence cette équipe et ses POs qui semblent coincés dans des impasses de négociation du backlog, des bugs en veux tu en voilà, des injonctions contradictoires, des plannings acrobatiques etc., ce système est très stable. Il change lentement. Après chaque crise, tout rentre dans l’ordre.
Puisqu’il est stable, ce système peut donc évoluer. C’est une bonne nouvelle. Un système instable ne le pourrait pas. Un système instable ça s’écroule, implose, s’enraye en quelques jours voire quelques heures et on n’en parle plus.
En considérant l’activité du système qui nous intéresse ici, la conception de logiciel, on peut considérer les stratégies de prévention des défauts dont il est muni comme autant de sous-systèmes régulateurs. Ces régulateurs sont en place afin de réduire les “bruits” c’est à dire les variations incontrôlées du comportement du logiciel produit. Ils sont censés faire cela au meilleur coût, dans un temps raisonnable, et sans pour autant interdire les variations contrôlées, qui correspondent à des évolutions souhaitées dans le comportement du logiciel.
Ce dernier point est particulièrement important. Un des objectifs de Xavier est que son équipe réussisse à faire évoluer une petite partie du comportement du logiciel, tout en préservant tout le reste. Sans un ensemble de régulateurs subtils (tels que ceux vus dans cette série de posts par ex.) la tâche s’avère impossible.
À défaut de régulateurs subtils pour contrôler les changements, une entreprise mettra en place des régulateurs moins subtils, qui limitent plus brutalement les évolutions contrôlées ou incontrôlées :
Code Freeze : à un certain point de “maturité” de la version du produit, il est interdit d’en modifier la conception et/ou le code
Lotissement : les demandes d’évolutions (dûment approuvées) sont ajoutées comme travail à venir dans un lot qui sera livré dans plusieurs semaines
Big Bang Delivery : toutes les évolutions — et donc tout le bruit potentiel qu’elles recèlent — est ramassé en une seule livraison, qui va faire du bruit !
Refonte : le système est figé plusieurs années, jusqu’à sa réécriture intégrale (par vos successeurs)
Pour améliorer un système, il faut donc le munir de régulateurs subtils, ce qui signifie le complexifier progressivement.
À l’inverse pour détériorer un système, il suffit d’en ôter les régulateurs c’est à dire de le simplifier, et de laisser l’entropie faire son travail.
- lâcher vos stratégies de prévention lorsque leur maintien vous met en retard
- semer la confusion dans les objectifs du projet ou de l’organisation
- laisser le savoir-faire et les standards filer au gré des démissions
Stratégies funestes qui mériteraient leur petit anti-guide, “Comment Détériorer Votre État de l’Art une Urgence à la Fois”
Stay Tuned!