agile france 2013 - dette technique
Post on 21-Jun-2015
1.615 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related