Upload
francois-wauquier
View
1.615
Download
2
Embed Size (px)
DESCRIPTION
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.
Citation preview
La dette technique
Francois Wauquier @wokierAurélien Pelletier @toutantic
#AgileFrance
C'est la crise !
Ward Explain Debt Metaphor
3,93 % TEG FIXE
Entropie logicielle
Entropie
Temps
Entropie logicielle
Entropie
Temps
Entropie logicielle
Entropie
Temps
Vélocité / Dette Technique
Temps
Vélocité / Dette Technique
Temps
Vélocité / Dette Technique
Temps
Vélocité / Dette Technique
Temps
Vélocité / Dette Technique
Temps
Délais pour corriger un bug en production
● Minute● Heure● Jour● Semaine● ...
Taille du Bug Tracker
Temps d'intégration d'un nouveau développeur
Build long
http://xkcd.com/303/
Environnement obsolète
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
Dette technique
Vélocité en chute libre
Faillite
Motivation
Problème
Planning Game
Complexité
XLValeur métier
0
Comportements d'équipe● Endettement● Economie● Remboursement
[Effet]
[Description...]
[Avantage] [Inconvénient]
[Pattern]
S M L
ComportementsEndettement
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
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
Story Technique
Endettement
● Intégrer au backlogdes Story Technique● Valeur métier : 0● Définir des règlesavec le PO
+ Endettement visible
Visible Invisible
Valeur Métier Forte
User Story Architecture
Valeur Métier Faible
Bug Story Technique
L
Livrer et oublier
Endettement
Livrer 'en l'état' à la fin du sprint
- Le code n' oubliera pas...
L
Livrer et oublier
Endettement
Livrer 'en l'état' à la fin du sprint
- Le code n' oubliera pas...
ComportementsEconomies
"Definition Of Done" forte
Economies
Ne pas livrer une story qui ne respecte pas tous les critères Done Done
+ Qualité- Risque de paralysie
TDD
Economies
● Test● Code● Refactor
+ Couverture+ Documentation+ Design
Binomage
Economies
Revue de code à chaud
Economies
Revue sur place avant commit
+ Au plus proche
Revue de code à froid
Economies
Revue à distance● Pull Request● Document de revue de code
+ Outillage- Moins formateur que Binômage
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
Règles de code
Economies
● Style● Design
○ Single Responsibility Principle○ Couches / Couplage faible○ Communication adaptée
+ Facilité lecture de code+ Détection Bug simples
ComportementsRemboursement
Remboursement Opportuniste
Remboursement
Profiter d'une évolution fonctionnelle pour rembourserSeule la User Story est visibleRien ne se fait sans valeur métier associée
+ Transparent
L
Remboursement Opportuniste
Remboursement
Profiter d'une évolution fonctionnelle pour rembourserSeule la User Story est visibleRien ne se fait sans valeur métier associée
+ Transparent
L
Remboursement
"Le camp doit être plus propre que lorsque l'on est arrivé"
Baden Powell
+ Amélioration progressive- Pas visible
SBoy Scout
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
Bug DayEconomie
L
Objectif de couverture
Remboursement
Définir un nouveau seuil minimum de couverture
+ Rattrape le retard
L
Automatiser
Remboursement
● Livraison● Tests Fonctionnels● Documentation● Installation Poste Dev
+ Gain temps- Coût du Ticket d'entrée
L
Accélérer
Remboursement
Accélérer ce qui est déjà automatisé
Définir stratégie de tests automatiques
+ Gain temps
S
Migration Version
Remboursement
● Suivre les versions stables par petit pas
+ Bénéficier des corrections
S
OutilsAnalyse de code
Informatif
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
Poka Yoke
Poka Yoke
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
Do Thing Right, but...
DoRightThing
DoThingRight
Fast
Merci
Francois Wauquier @wokierAurélien Pelletier @toutantic
#AgileFrance
http://c2.com/cgi/wiki?WardExplainsDebtMetaphorhttp://martinfowler.com/bliki/TechnicalDebt.htmlhttp://www.targetprocess.com/rightthing.htmlhttp://www.andrejkoelewijn.com/blog/2010/11/25/lac2010-technical-debt/http://www.infoq.com/articles/managing-technical-debt
Sources