« Changez votre façon de construire » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| Ligne 51 : | Ligne 51 : | ||
Ce n'est pas un secret dans notre domaine que de nombreuses entreprises ont un bilan terrible en termes de respect de ce type de promesses. Mais les entreprises de produits fortes savent combien cela est important pour établir et maintenir la confiance avec nos clients. | Ce n'est pas un secret dans notre domaine que de nombreuses entreprises ont un bilan terrible en termes de respect de ce type de promesses. Mais les entreprises de produits fortes savent combien cela est important pour établir et maintenir la confiance avec nos clients. | ||
==PETITES VERSIONS, FRÉQUENTES, FIABLES== | |||
La technique de base utilisée pour répondre à chacun de ces principes est la notion de versions petites, fréquentes et fiables. | |||
Cela signifie, au minimum, que chaque équipe produit publie une version toutes les deux semaines. Pour les entreprises de produits les plus fortes, cela signifie qu'elles publient plusieurs fois par jour. | |||
La raison pour laquelle vous ne savez probablement pas que cela se passe avec vos produits préférés est précisément parce qu'ils publient un flux quasi constant de petites versions. | |||
Et afin de proposer constamment de petites versions, fréquentes et fiables, nous devons prendre très au sérieux notre obligation de tester, connue plus officiellement sous le nom d'assurance qualité. | |||
Mais les tests sont plus compliqués qu'il n'y paraît. En général, nous travaillons pour tester deux aspects principaux de ce que nous construisons, le premier est simple, le second l'est moins. | |||
Le premier est que lorsque nous construisons une nouvelle capacité, nous devons tester que cette nouvelle capacité fonctionnera comme prévu. C'est simple, mais comme nous devrons probablement tester et retester cette nouvelle capacité des milliers de fois au cours des mois et des années à venir, nous investissons généralement dans un certain niveau d'automatisation des tests. | |||
La seconde consiste à s'assurer que les changements apportés pour activer la nouvelle capacité ne cassent pas autre chose de manière involontaire ou par inadvertance. C'est ce que l'on appelle le test de non-régression, et lorsque l'on sait que de nombreux produits et services technologiques sont aujourd'hui le résultat du travail de centaines d'ingénieurs pendant de nombreuses années, créant des dizaines de milliers d'interactions, on comprend que s'assurer qu'un produit complexe ne régresse pas lorsqu'une nouvelle capacité est introduite peut être une affaire de taille. | |||
La principale méthode utilisée par les équipes produit pour s'assurer que les nouvelles capacités fonctionnent comme prévu et n'introduisent pas de régressions, consiste à déployer une série de changements très fréquents et de très petite taille. | |||
Plus l'incrément de version est petit, plus vite nous pouvons garantir la qualité de la nouvelle fonctionnalité et plus vite nous pouvons être sûrs que nous n'introduisons pas de régressions. Et avec ces versions petites et fréquentes, si un problème est introduit, il est beaucoup plus facile et rapide d'en identifier la cause (puisque nous n'avons changé qu'un petit nombre de choses). | |||
Si cela vous semble contre-intuitif et si vous continuez à croire que pour garantir la qualité, il faut publier lentement et rarement, vous vous devez, pour vous-même et votre entreprise, d'examiner à la fois la théorie et les preuves qui expliquent pourquoi des versions fréquentes et plus petites permettent d'augmenter le débit et d'améliorer la qualité des entreprises de produits fortes. Nous vous recommandons l'excellent livre [https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 Accelerate]. | |||
Malheureusement, de nombreuses entreprises n'ont pas encore atteint la capacité de réaliser ces petites versions fréquentes. | |||
Au lieu de cela, elles effectuent des centaines, voire des milliers de changements, puis, une fois par mois, par trimestre ou même par an, elles s'efforcent d'intégrer tous ces changements ensemble, puis elles essaient de tester que toutes ces nouvelles capacités fonctionnent comme prévu, et enfin elles commencent à identifier et à supprimer toutes les conséquences involontaires (régressions). | |||
Comme vous commencez, je l'espère, à le comprendre, c'est la raison pour laquelle les grandes versions comme celle-ci (connues sous le nom de "big bang") sont connues pour leurs retards de plusieurs semaines, voire de plusieurs mois, pour essayer de tout remettre dans un état fiable et publiable. | |||
