Le développement Agile c’est la fréquence des livraisons des produits.

Comme nous avons pu le constater dans le principe n°5, les méthodes de gestion de projet traditionnelles réalisent la livraison une fois l’ensemble du produit terminé. On se demande pourquoi ne pas vous vouloir en tirer certains avantages plus tôt? Pourquoi ne voulez pas entendre le retour de l’utilisateur avant de tout construire ? Pourquoi ne pas vouloir regarder ce qui fonctionne et ce qui ne fonctionne pas, avant de tout construire ?

Ce n’est réellement possible qu’en raison de certains des principes importants de développement Agile tels que l’approche itérative, des fonctionnalités simples et réalisées justes à temps, la conduite par itération, les tests intégrés dans le cycle de vie, et ainsi de suite.

Garder en vue la livraison, la constance des livraisons des différentes itérations permet de réduire les risques sur les projets et de conserver l’équipe dans une dynamique. On remarque dans tous les nouveaux projets, une « euphorie », une dynamique de groupe au lancement du projet. Cette dynamique s’atténue rapidement plus le projet avance. Agile permet de conserver cette énergie, par cette constance de la livraison.

Ainsi, la fréquence est fréquente ?

Scrum propose des développements par itération (sprint) sur un maximum de 30 jours. À partir de cette période, il doit être possible de réaliser une démonstration de l’itération. Cette démonstration doit permettre de prendre une décision sur cette itération telle que changer certaines fonctionnalités, l’intégrer dans l’architecture globale, la livrer, etc. La réactivité est un important avantage concurrentiel.

Ce qui est assez important, c’est d’en faire une décision positive, de décider ce qui est approprié pour vous. Et puis de s’en tenir, si vous le pouvez conserver un cycle régulier. Un cycle régulier vous permet de planifier, de construire et parce que des travaux de développement agile à un calendrier fixe, la planification est assurée.

Un cycle régulier vous permet également d’apprendre plus efficacement. Votre estimation pourrait être la bonne, elle pourrait être aussi la mauvaise. Si vous estimez des caractéristiques à un niveau granulaire (idéalement moins de 1 jour) et si vous réalisez un suivi dans le temps, vous commencez à connaitre votre taux normal de réalisation. Et quand vous comprenez cela, vous serez surpris de voir à quel point vous réussissez vos prévisions.

Ainsi, en développement agile on se concentre souvent sur la livraison des produits. Et peut-être encore plus important, se concentrer sur des livraisons de produits.