Agile france 2013 - Dette Technique
•
1 like•3,038 views
Tenir un engagement et s’endetter techniquement ou ne pas transiger sur la qualité. Qui n’a jamais été confronté à ce dilemne ? La dette technique est une puissante métaphore, présenté par Ward Cunningham en 1992 pour symboliser le fait que la dette s’accumule et que les interêts sont de plus en plus importants. Pourtant cette dette est encore floue pour beaucoup d’équipes. Et il y a un lien évident mais parfois ignoré entre qualité et vélocité. En faisant toujours le choix de la dette, le risque est se rapprocher d’un code legacy dont l’équipe a perdu le contrôle. Cette présentation en binôme vous donnera des clés pour visualiser et maitriser votre qualité avec de grandes exigences tout en restant concret et pragmatique. Nous vous proposerons différentes stratégies pour faire face à ce dilemme. Nous montrerons des exemples et des outils en java. Que votre application ait un mois ou 10ans, en repartant de cette session vous aurez des outils, des pratiques et du vocabulaire pour faire vos choix en connaissance de cause. Devenez un fin gestionnaire de votre patrimoine de code.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Agile france 2013 - Dette Technique
Similar to Agile france 2013 - Dette Technique (20)
More from François Wauquier
More from François Wauquier (10)
Agile france 2013 - Dette Technique
- 1. La dette technique Francois Wauquier @wokier Aurélien Pelletier @toutantic #AgileFrance
- 2. C'est la crise !
- 3. Ward Explain Debt Metaphor
- 13. Vélocité / Dette Technique Temps
- 14. Vélocité / Dette Technique Temps
- 15. Vélocité / Dette Technique Temps
- 16. Vélocité / Dette Technique Temps
- 17. Vélocité / Dette Technique Temps
- 18. Délais pour corriger un bug en production ● Minute ● Heure ● Jour ● Semaine ● ...
- 19. Taille du Bug Tracker
- 20. Temps d'intégration d'un nouveau développeur
- 23. Quadrant de Martin Fowler Aventureux Prudent Délibéré Pas le temps de designer Nous devons livrer et assumer Négligeant C'est quoi ces couches ? Nous savons maintenant comment nous aurions du faire
- 24. Dette technique
- 25. Vélocité en chute libre
- 26. Faillite
- 27. Motivation
- 28. Problème
- 33. Comportements d'équipe ● Endettement ● Economie ● Remboursement
- 36. Livrer des story 'presque fini' Endettement Faire la demo, livrer mais ne pas clore la story pour rattrapper le retard dans le sprint suivant + Client est content M
- 37. Sprint de livraison Endettement Réaliser des story 'presque finie' et dédier un sprint à la préparation de la mise en production. - Casse le rythme L
- 38. Story Technique Endettement ● Intégrer au backlog des Story Technique ● Valeur métier : 0 ● Définir des règles avec le PO + Endettement visible Visible Invisible Valeur Métier Forte User Story Architecture Valeur Métier Faible Bug Story Technique L
- 39. Livrer et oublier Endettement Livrer 'en l'état' à la fin du sprint - Le code n' oubliera pas... L
- 40. Livrer et oublier Endettement Livrer 'en l'état' à la fin du sprint - Le code n' oubliera pas...
- 42. "Definition Of Done" forte Economies Ne pas livrer une story qui ne respecte pas tous les critères Done Done + Qualité - Risque de paralysie
- 43. TDD Economies ● Test ● Code ● Refactor + Couverture + Documentation + Design
- 45. Revue de code à chaud Economies Revue sur place avant commit + Au plus proche
- 46. Revue de code à froid Economies Revue à distance ● Pull Request ● Document de revue de code + Outillage - Moins formateur que Binômage
- 47. Quick Start Economies ● Documentation proche du code ○ README / Getting started ● Utilisation de standards ○ git clone ○ vagrant up ○ mvn clean install ○ mvn jetty:run + Gain de temps d'intégration d'un nouveau ○ bower install ○ npm install ○ grunt server
- 48. Règles de code Economies ● Style ● Design ○ Single Responsibility Principle ○ Couches / Couplage faible ○ Communication adaptée + Facilité lecture de code + Détection Bug simples
- 50. Remboursement Opportuniste Remboursement Profiter d'une évolution fonctionnelle pour rembourser Seule la User Story est visible Rien ne se fait sans valeur métier associée + Transparent L
- 51. Remboursement Opportuniste Remboursement Profiter d'une évolution fonctionnelle pour rembourser Seule la User Story est visible Rien ne se fait sans valeur métier associée + Transparent L
- 52. Remboursement "Le camp doit être plus propre que lorsque l'on est arrivé" Baden Powell + Amélioration progressive - Pas visible SBoy Scout
- 53. Refactoring Remboursement Remaniement de code pour ● le rendre plus lisible ● éviter les duplications ● faciliter la maintenance ● permettre l'extension + Qualité - Nécessite bonne couverture AVANT L
- 55. Objectif de couverture Remboursement Définir un nouveau seuil minimum de couverture + Rattrape le retard L
- 56. Automatiser Remboursement ● Livraison ● Tests Fonctionnels ● Documentation ● Installation Poste Dev + Gain temps - Coût du Ticket d'entrée L
- 57. Accélérer Remboursement Accélérer ce qui est déjà automatisé Définir stratégie de tests automatiques + Gain temps S
- 58. Migration Version Remboursement ● Suivre les versions stables par petit pas + Bénéficier des corrections S
- 60. Informatif
- 61. Analyse de code (informatif) ● IDE vérification active ● IDE vérification à la demande ● Contrôle durant IC build séparé ● Outils Externe (ex: Sonar) Distance du développeur IDE Intégration Continue Outil Externe Build Local
- 62. Poka Yoke
- 63. Poka Yoke
- 64. Analyse de code (Poka Yoke) ● Contrôle durant IC build principal ● Contrôle au commit ○ Server-less Continuous Integration ○ Unbreakable build Distance du développeur IDE Intégration Continue Outil Externe Build Local
- 69. Do Thing Right, but... Do Right Thing Do Thing Right Fast
- 70. Merci Francois Wauquier @wokier Aurélien Pelletier @toutantic #AgileFrance