Slides de la conférence donnée lors de l'Agile Tour 2010 à Vannes.
L'objectif de la conférence est d'expliquer en quoi les pratiques agiles permettent de réduire les coûts de développement.
2. Notre objectif « Nous voulons délivrer des applications de qualité durablement » « Nous définissons la qualité comme la maximisation du ratio Satisfaction utilisateur / Coût Attaquons-nous aux COÛTS 2
5. Les 3 piliers du Lean Le Juste à Temps : « Conserver les stocks nécessaires à chaque étape de la fabrication au plus faible niveau possible, idéalement nul » Les stocks coutent de l’argent Les stocks diminuent la valeur de l’élément stocké Les stocks dissimulent les défauts : la ligne de flottaison L’« Autonomation » (Jidoka) : Autonome + Automatisation Capacité d’une machine à contrôler automatiquement son bon fonctionnement Permet de construire la qualité intrinsèque Ne pas reléguer le test à la fin La chasse aux gaspillages (Muda) 5
6. Qu’est-ce qu’un gaspillage ? Wikipedia : « Le gaspillage est l'action qui consiste à utiliser une ressource de manière non rationnelle ou à mauvais escient » Objectifs du Lean Les identifier Diminuer leur impact Les supprimer Qualité totale Réduisons les gaspillages ! 6
7. Quels sont les objectifs affichés ? Industrialiser pour marginaliser certains coûts Augmenter l’efficacité opérationnelle des équipes Réduire de manière drastique les coûts 7
8. Les types de gaspillage dans le Lean La surproduction L’attente Le transport Le travail mal exécuté ou inadapté La complexité Les défauts Les stocks 8
9. La chasse aux gaspillages Partons à la chasse aux gaspillages ! 9
10. La surproduction Le plus fondamental des gaspillages Constat dans le développement 60% des fonctionnalités sont très rarement ou pas du tout utilisées Quel pourcentage chez vous ? Quelles conséquences ? On investit dans des fonctionnalités inutiles La spécification, la conception, le développement, la recette, la correction de bugs, la maintenance, etc. Pour un bénéfice nul ! Quels progrès offrent l’Agile ? Ce que l’on ne développe pas ne coûte rien : YAGNI Prioriser Par la valeur d’affaire, la satisfaction utilisateur, etc. Développer par itération Pour pouvoir réviser les priorités Pour supprimer les fonctionnalités devenues inutiles Pour s’arrêter quand la valeur produite est suffisante 10
11. L’attente et les retards Comment cela se caractérise-t-il ? Les spécifications sont en cours de validation Les testeurs sont en attente d’une version en recette Le développement a démarré 4 mois après la prise de décision Les utilisateurs attendent 9 mois qu’une première version de l’application soit disponible Quelles conséquences ? Le changement est pris en compte difficilement et à un coût élevé La rentabilité de l’investissement est retardée, voire annulée Quels progrès dans l’Agile ? Travailler par itération : Réduction de l’attente Obeya : salle de guerre Regroupement géographique Equipes auto-organisées 11
14. Les actions inutiles ou répétées Autres types d’actions inutiles ou répétées Les compilations manuelles, Les tests manuels (unitaires, non régression,…), etc. Quelles conséquences ? Perte évidente de temps, et donc retard dans la rentabilité de l’investissement Perte de l’information et apparition de défauts Le papier élu « pire moyen de communication » Quels progrès trouve-t-on dans l’Agile ? Le pilotage par les tests Favoriser les interactions directes L’intégration continue Les rétrospectives Composante essentielle du cycle d’amélioration continue PDCA : Roue de Deming 14
15. Les défauts Peuvent être de tout type, et intervenir à tout moment Bugs (de fonctionnement, de sécurité, etc.) Fonctionnalités non conformes Ergonomie non adaptée (nombre de clic, performance, messages inadaptés etc.) Quelles conséquences ? Coût lié à la détection du défaut, à la correction, à la vérification de la non-régression, au passage en production Diminution de la rentabilité de l’investissement Quels progrès apporte l’Agile ? Le pilotage par les tests (TDD, User Stories, spécifications exécutables) La notion de « Terminé » Garde-fou de la qualité dans l’Agile Les démonstrations fréquentes L’intégration continue 15
16. Les stocks – Les types de stock dans le développement Stock d’idées Stock de besoins CDC MOA Fonctionnels Stock de conception Stock de spécifications DSD DCT, DAT,... Développeurs Architectes Stock de développements Testeurs Manuels Stock de tests Stock de défauts Stock de documentation Cahier de tests 16
17. Les stocks – Les types de stock dans le développement Stock d’idées Stock de besoins MOA Fonctionnels Stock de conception Stock de spécifications Développeurs Architectes Stock de développements Testeurs Stock de tests Stock de défauts Stock de documentation 17
18. Les stocks – Histoire d’un projet Temps : J + 0 jours 10 jours 18 jours 38 jours 53 jours 113 jours 123 jours 138 jours 145 jours 8j 20j 10j 15j 60j 10j 15j 7j J+0 J+10 J+18 J+38 CDC DSD DCT, DAT,… J+53 J+113 J+123 J+138 J+145 18
19. Les stocks – Histoire d’une fonctionnalité Temps : J + 0 jours 10 jours 18 jours 38 jours 53 jours 113 jours 123 jours 138 jours 145 jours 8j 20j 10j 15j 60j 10j 15j 7j J+0 J+10 J+18 2h 2h 0,5j 0,5j 3j 0,5j 1j 0,5j 19,5j 14,5j 57j 9,5j 14j 6,5j J+38 7,25j 9,75j 6,5j 138,5j CDC DSD DCT, DAT,… J+53 J+113 J+123 J+138 J+145 19
20. Les stocks – Bilan de l’histoire En définitive, le temps passé dans le stock est important Pour quelle raison ? Parce que la fonctionnalité est réalisée en même temps que toutes les autres, formant ainsi un lot, un palier, une version… Temps utile : 4,5% Temps de Stock : 95,5% 20
21. Les stocks – Pour quelles conséquences ? L’investissement consacré n’est potentiellement rentable qu’au bout de 145 jours Pendant toute la durée du temps de stock, la valeur de la fonctionnalité a diminué Les défauts ne sont détectés qu’à la fin !... … Et se sont potentiellement dissimulés dans la plupart de stocks ! Le stock engendre un risque très important de dépassement des coûts Défauts Inadéquation de l’application au besoin 21
22. Les stocks – Les pistes d’amélioration Quelles pistes d’amélioration apporte l’Agile ? L’itération, associée à la priorisation Le pilotage par les tests, associée aux démonstrations Le design incrémental : KISS Principes de l’itération C’est une durée fixe Par Exemple : 2 semaines C’est une durée fixe !! En anglais : une Timebox Ce que livre l’équipe peut potentiellement être mis en production L’équipe s’engage En début d’itération,… Sur les fonctionnalités à livrer au bout de l’itération,… Mais… …C’est une durée fixe !!!! Une itération n’est pas un lot 22
23. La dette – Principes d’une dette Ce que contient un stock induit un coût de possession Ce coût s’apparente à une dette Principes d’une dette : Un capital est emprunté : c’est le principal Tout au long de la période d’emprunt, des intérêts sont payés Si on veut éviter le surendettement, il faut aussi rembourser du principal Deux types de dettes : La mauvaise dette Le capital emprunté sert à financer ce qui ne présente aucune valeur La bonne dette L’investissement est utilisé pour créer de la valeur Avoir de la dette n’est pas une mauvaise chose… …Mais il faut maîtriser sa dette Eliminer la mauvaise dette au profit de la bonne dette Rembourser continuellement le principal, et limiter les intérêts à payer 23
24. La dette – Les types de dette technique La dette d’obsolescence Utilisation d’anciennes versions de technologies ou de frameworks La dette de qualité de code Qualité de code médiocre, dont l’amélioration est remise au lendemain La dette de tests Ensemble des tests unitaires et de non régression non automatisés La dette de fonctionnalités Ensemble des fonctionnalités encore non implémentées et non prioritaire 24
25. La dette – Exemple : la dette de tests Au fur et à mesure qu’on ajoute des fonctionnalités sans tests automatiques, on augmente le principal On contracte ainsi une dette de tests Tout au long du développement, on paye les intérêts suivants : Temps de correction de bugs Tests manuels répétés (non régression) Bugs encore présents après la mise en production 25
26. La dette – Exemple : la dette de tests Au fur et à mesure qu’on ajoute des fonctionnalités sans tests automatiques, on augmente le principal On contracte ainsi une dette de tests Tout au long du développement, on paye les intérêts suivants : Temps de correction de bugs Tests manuels répétés (non régression) Bugs encore présents après la mise en production Peur du changement à cause de la peur de la régression On contracte d’autres types de dette : obsolescence et qualité de code Si on ne rembourse pas progressivement le principal, le poids des intérêts s’accentue Lorsque les intérêts deviennent trop lourds, on est obligé de faire défaut : c’est la refonte ! 26
28. Comment ? Les cycles itératifs Eviter la surproduction Diminuer les impacts des attentes et des retards Repérer et éliminer les défauts au plus tôt, en réduisant les stocks Favoriser la prise en compte du changement et l’apprentissage La priorisation Ne pas investir dans ce qui n’a pas de valeur Le pilotage par les tests, les démonstrations, la notion de « Terminé » Eviter les erreurs d’interprétation Approcher le zéro défaut Maitriser sa dette technique en éliminant la peur du changement Les rétrospectives Favoriser l’apprentissage et la standardisation des pratiques Marginaliser les coûts liées aux tâches répétées 28
29. Comment ? Les équipes auto-organisées, le regroupement géographique Favoriser les échanges directs Limiter les attentes et les retards Favoriser l’apprentissage Les principes et les pratiques de développement, issues d’XP L’intégration continue, le TDD, le design incrémental, le pair-programming, etc. YAGNI, KISS, Fail-fast, SoC, etc. Améliorer la qualité et marginaliser le coût de maintenance (évolutive ou corrective) 29
30. Finalement, 3conseils Adoptez les cycles itératifs Favorisez l’apprentissage Multipliez les interactions 2recommandations Réduisez vos gaspillages Maitrisez votre dette 1 mot de la fin MERCI de votre attention ! 30
Notes de l'éditeur
A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : fabrication d’un avion, en cas de crash
A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : fabrication d’un avion, en cas de crash