Lors du précédent billet, nous avions mis en œuvre la réduction des stocks de spécifications, de développements, et de tests.

Construire du logiciel de façon itérative nécessite cependant une phase importante d’apprentissage. Je vous propose donc de suivre cet apprentissage au travers d’une petite histoire.

C’est pas du gâteau

La société Legia est un éditeur qui fournit une solution de e-commerce…

La société MacaronDuPlaisir décide de déployer cette solution et de profiter de la période de soldes pour lancer son nouveau site internet de e-commerce.

Afin de pouvoir ajuster certaines fonctionnalités et observer le comportement des internautes, la société décide de mettre en production la solution de e-commerce, 6 semaines avant le début des soldes. En quelques heures, la société se retrouve submergée par les appels de clients mécontents. Régulièrement, lorsqu’un client choisit un article dans le panier promotionnel, le paiement carte bleu affiche une erreur.

L’alerte est remontée à la société Legia. L’équipe de recette décide de réaliser des tests sur des sites clients en utilisant la carte bleue de la société, soit une centaine de paiements. L’équipe en charge des tests conduit l’investigation. Elle montre que l’erreur se produit chaque fois qu’un article a un prix qui comporte des décimales.

Or, le module incriminé a été déployé sur une dizaine de sites internet clients. Dans 6 semaines, la période des soldes commence.

Comment en est-on arrivé là ?

Une réunion de crise est organisée. L’équipe tente de comprendre ce qui s’est passé.

Lors de la phase de recette, le module n’a pas été testé. Raisonnablement, il aurait fallu re-tester toute l’application, mais l’équipe de recette a du renoncer en raison des délais de livraison de l’itération. En effet, l’équipe de recette a été parasitée par de nombreuses anomalies techniques, nécessitant de nombreux de retours vers l’équipe de développement.

Pendant la phase de développement, plusieurs développeurs ont eu des difficultés à interpréter les spécifications du module. Ils ont cependant préféré résoudre les problèmes seul, et n’ont pas jugé bon de solliciter un fonctionnel.

Les échanges entre fonctionnels et développeurs restent difficiles. Les 2 équipes travaillent en effet sur des sites différents.

Les problèmes apparaissent plus tôt

L’équipe expérimente depuis peu la méthode Scrum.

Lorsque l’équipe travaillait avec une méthode classique (la fameuse cascade), les problèmes apparaissaient en toute fin de développement, après 1 an de tranquillité. Le calme avant la tempête.

Avec la méthode agile (ici Scrum), les mêmes problèmes apparaissent dès la première itération. En réduisant les stocks, les équipes font apparaitre les problèmes bien plus tôt.

Autant les résoudre durablement

La réduction des stocks agit comme un véritable révélateur des problèmes. Il est alors venu le temps de s’attaquer aux causes profondes, plutôt que de différer l’apparition des problèmes, et de se bercer de douces illusions.

Billets sur le même thème