BLOGUE – La mésaventure du projet « Obamacare »* aux États-Unis m’a rappelé d’autres projets où l’on croyait avoir terminé, mais dont le produit a déçu par sa performance au moment de la mise en service.
Je suis persuadé qu’au moment de la livraison, le projet Obamacare comportait l’ensemble des fonctionnalités requises pour assurer l’inscription des citoyens au régime d’assurance santé et que les tests de performance ont été effectués seulement vers la fin du projet.
Si mon hypothèse est juste, la découverte d’importantes lacunes en fin de projet a dû être difficile à gérer avant la date butoir de la mise en vigueur de la loi.
L’installation du piège
En reportant d’importants tests à la période de validation finale, on risque de perdre la marge de manoeuvre requise pour rectifier le produit avant la date de livraison, à l’intérieur de la balance du budget.
Certains diront qu’avec l’adoption de plus en plus grande de l’agilité, ce n’est plus un enjeu aussi important. Je n’en suis pas convaincu.
Le développement agile propose de livrer un incrément fonctionnel fréquemment, ce qui encourage à vérifier son fonctionnement continuellement. Par contre, plusieurs équipes limitent la vérification au niveau fonctionnel et ne soumettent pas leurs incréments à des tests d’acceptation dans un contexte semblable à celui de la production.
Du coup, plusieurs facteurs de qualité des produits logiciels (performance, charge, documentation, sécurité, etc.) deviennent soudainement de mauvaises surprises en fin de projet. La promesse des approches agiles d’avoir un incrément potentiellement livrable à tout moment devient alors une illusion, due aux validations insuffisantes pendant le déroulement du projet.
Augmenter le niveau de transparence
Je crois que le niveau de qualité devient une bombe à retardement lorsqu’il est :
- inconnu : tout ce qui n’est pas fréquemment vérifié en cours de projet s’accumule et risque de mettre en péril le projet;
- arbitraire : tout ce qui n’est pas entendu entre les différentes parties prenantes risque de générer des attentes non comblées.
Augmenter la transparence, par une validation fréquente avec les parties prenantes et l’exécution de tests d’acceptation en cours de projet, permet de prendre la mesure du véritable niveau de qualité et peut même devenir un indicateur de performance (KPI) supplémentaire au projet.
Le jeu en vaut-il la chandelle?
La vérification en continu de la qualité demande de la rigueur et augmente évidemment les coûts de développement. Pour s’assurer que cet investissement soit rentable, je crois que l’on doit non seulement comprendre comment cela peut soutenir la gestion du risque, mais aussi comment cela peut devenir un avantage compétitif :
- Livrer une plus grande valeur d’affaires Il est inutile de continuer le développement d’un produit si les parties prenantes ne sont pas satisfaites. Il est préférable de les rencontrer fréquemment pour vérifier leur satisfaction;
- Accélérer le temps de mise en marché / réduire les périodes de stabilisation Pour être en mesure de livrer un produit à n’importe quel moment, il est important d’avoir confiance que la version en cours de développement est conforme à la qualité attendue;
- Améliorer les coûts de développement Lorsque les tests sont planifiés à la fin d’un projet, il n’est pas possible de mesurer les coûts associés aux travaux d’acceptation avant la fin du projet. Et comme les résultats des travaux d’acceptation sont un bon indicateur de la qualité du développement, cela retarde l’évaluation de la performance du processus de développement.
Le désir de bénéficier de ces avantages compétitifs justifie les efforts investis à la vérification de la qualité en continu :
- Si on ne présente pas des incréments complets et validés aux parties prenantes, on risque de réduire leur confiance plutôt que de l’augmenter;
- Si tous les travaux que l’on planifie habituellement à la fin du projet ne sont pas distribués sur la durée, l’importance et les délais de la période d’acceptation ne pourront jamais être réduits;
- Si les résultats du développement ne sont pas validés complètement par des tests d’acceptation, les équipes de projet pourront difficilement identifier les pratiques devant être améliorées pour augmenter la fiabilité de leurs travaux.
* [NDLR] Dans le cadre du Patient Protection and Affordable Care Act (Loi sur la protection des patients et des soins abordables), surnommé « Obamacare », une place de marché électronique nommée Healthcare.gov a été établie par le gouvernement des États-Unis pour permettre aux citoyens américains de sélectionner et d’adhérer à un programme d’assurance maladie.
Au moment de sa mise en activation, au début d’octobre 2013, le portail a fait l’objet de pannes en raison d’une importante affluence, mais aussi de fonctions non disponibles.