Cependant, l’époque de l’ancien modèle en cascade est révolue depuis longtemps. Pourtant, l’approche plus moderne de Scrum, avec ses sprints fixes de deux à six semaines (qui font potentiellement perdre du temps), ne protège pas les développeurs contre la fabrication d’un mauvais produit. Faisons le calcul, sur la base d’un sprint de 4 semaines. Supposons qu’une entreprise compte 50 développeurs travaillant à plein temps sur son produit logiciel. Si 75 % de leur temps est consacré au développement de nouvelles fonctionnalités, cela représente un total de 6 000 heures consacrées à de nouvelles fonctionnalités au cours de l’un de ces sprints.
C’est beaucoup de travail et de temps passé avant d’obtenir un retour d’information.
Bien sûr, des mécanismes de retour d’information internes sont en place, mais en fin de compte, c’est le verdict des clients qui compte. Ce qu’il faut faire, c’est réduire au minimum le temps qui s’écoule entre le développement et le déploiement.
L’objectif est d’être toujours prêt à publier toutes les nouvelles fonctionnalités dès qu’elles ont passé l’assurance qualité. En fait, nous visons une mise en production – au moins pour nos clients candidats à la mise en production – dès que le produit minimum viable d’une certaine fonctionnalité a passé l’assurance qualité.
Dans la pratique, on utilise le processus Kanban, où chaque fonctionnalité passe par notre processus de développement d’analyse, de développement et de test, indépendamment des autres fonctionnalités. Pour chaque fonctionnalité, un nouveau paquet d’installation est créé, prêt à être déployé pour un retour d’information instantané.
Cela permet de minimiser le gaspillage dans le processus de développement et de consacrer plus de temps à la conception d’excellentes fonctionnalités, ce qui se traduit par un meilleur produit pour les clients.
