La dette technique est pour certain un terme barbare réservé aux spécialistes.... ET pourtant : elle est essentielle dans la vie saine d'un produit. Comment l'expliquer facilement et se familiariser avec ce concept qui peut paraître obscur ? Voici les slides d'un petit meet-up pour débutants, afin qu'ils jouent à découvrir la dette technique, et à préparer la gestion de cette dernière chez eux.

1. La dette technique
Qu’est ce que c’est ? A quoi ça sert ? Combien ça coûte ?
Initiation pour Investisseurs débutants

2. Est-ce vous ?
- Vous entendez tous les jours parler de “dette
technique” alors que votre compte en banque va très
bien.
- On vous demande d’en payer régulièrement et
pourtant vous payez déjà bien assez d’impôts
OU BIEN
- Vous aimeriez bien en payer, mais ne connaissez pas
les meilleurs moyens de paiement

3. Cet atelier vous aidera
1. A débroussailler le vocabulaire
2. A comprendre les éléments de la dette technique en
termes de conséquences concrètes sur votre service
final ou sur votre équipe
3. A connaître les quelques méthodes et outils à essayer
autour de ce sujet

4. Nous invitons...
Le public novice à poser des questions (à tous ou aux
experts)
Le public expert à aider le public novice (à tous ou
discrètement)
Tous à s’écouter ET (contrepartie naturelle) à rester concis

5. La dette technique, en gros ?
Tout ce qu’il faut faire… pour continuer à faire
sereinement.
(Ne se voit pas forcément directement sur le
service final)

6. Oui mais quel est le R.o.I de
la dette ?

7. Les conséquences sur le Retour
Interruption de service
final ⇒ Coût
d’oppportunité
Problème de
performance
⇒ Coût d’opportunité

8. Les conséquences sur le Retour

9. Les conséquences sur le Retour
Stats US
http://activemobi.com/blog/dedicated-mobile-vs-responsive-websites-state-of-affairs

10. Les conséquences sur
l’Investissement
Coûts croissants
Effort/Temps croissant à chaque nouvel ajout

11. Les autres conséquences
Equipe mécontente

12. Les autres conséquences

13. Bon OK ! Un peu plus en
détail alors ?

14. Dev pour
stabilité,
scalabilité
Outils de réaction rapide (backup &
restore, rollback, vitesse de MEP …)
Monitoring
Travail de performance
produit
Tests (non reg,
unitaires, etc.)
Outils de
mesure de
performance
Préparation aux
futurs ajouts
Une façon(parmi d’autres)de découper la dette technique
Amélioration
des outils de
dev

15. Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Conséquences possibles
Prochains
développements
moins chers
Equipe
mécontente
Problème de
performance
Meilleures
performances
du produit
Moins de
risques
techniques
Equipe plus
performante

17. Refactoring du code
Description
Réécriture d’un
morceau de code
pour le rendre plus
- lisible
- flexible
- performant
- réutilisable
- testable
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers
Equipe
mécontente
Problème de
performance
Meilleures
performances
du produit
Moins de
risques
techniques
Interruption
de service
final

18. Mise à jour de sécurité
Description
Changer une
partie du code qui
est devenue
obsolète vis-à-vis
des failles de
sécurité
récemment
découvertes
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Moins de
risques
Interruption
de service
final

19. A vous de deviner

20. Tests fonctionnels automatisés
Description
Code supplémentaire
qui va simuler un
“parcours utilisateur”
et vérifier qu’il
fonctionne toujours.
Il peut se lancer
facilement à chaque
nouveau
développement
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

21. Tests fonctionnels automatisés
Description
Code supplémentaire
qui va simuler un
“parcours utilisateur”
et vérifier qu’il
fonctionne toujours.
Il peut se lancer
facilement à chaque
nouveau
développement
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Moins de
risques
techniques
Interruption
de service
final
Equipe plus
performante

22. P.o.C (Proof of Concept) Technique
Description
Développer
rapidement un
code jetable pour
valider la faisabilité
d’un
développement qui
aurait lieu plus tard
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

23. P.o.C (Proof of Concept) Technique
Description
Développer
rapidement un
code jetable pour
valider la faisabilité
d’un
développement qui
aurait lieu plus tard
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers
Moins de
risques

24. Documentation Technique
Description
Documenter le
code existant afin
de clarifier les
choix de
développement
précédents
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

25. Documentation Technique
Description
Documenter le
code existant afin
de clarifier les
choix de
développement
précédents
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers
Equipe
mécontente
Equipe plus
performante

26. Industrialisation de process
Description
Mettre en place
des outils et du
code qui
automatisent
certaines tâches
lourdes du
développement
(déploiement, etc.)
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

27. Industrialisation de process
Description
Mettre en place
des outils et du
code qui
automatisent
certaines tâches
lourdes du
développement
(déploiement, etc.)
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers
Equipe
mécontente
Equipe plus
performante

28. Veille technique / Guilde
Description
Se renseigner sur
les prochaines
tendances
technologiques
pour anticiper les
futurs
développements
ou mettre à jour
les pratiques
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

29. Veille technique / Guilde
Description
Se renseigner sur
les prochaines
tendances
technologiques
pour anticiper les
futurs
développements
ou mettre à jour
les pratiques
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers

30. Tuning de performance
Description
Ajuster le code et
certains
paramètres
techniques pour
améliorer la
rapidité du produit
ou son coût en
ressources
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

31. Tuning de performance
Description
Ajuster le code et
certains
paramètres
techniques pour
améliorer la
rapidité du produit
ou son coût en
ressources
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Problème de
performance
Meilleures
performances
du produit

32. Outils pour développeur
Description
Installer des outils
qui aident les
développeurs dans
leur travail
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

33. Outils pour développeur
Description
Installer des outils
qui aident les
développeurs dans
leur travail
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Prochains
développements
moins chers
Equipe
mécontente
Equipe plus
performante

34. Mise en place d’environnement / d’exploitation
Description
Mettre en place
l’architecture
technique
nécessaire à faire
fonctionner le
produit
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire

35. Mise en place d’environnement / d’exploitation
Description
Mettre en place
l’architecture
technique
nécessaire à faire
fonctionner le
produit
Equipe Produit
Avantages directs à
faire
Risques à ne pas
faire
Equipe
mécontente
Interruption
de service
final

36. Ok, Bien compris,
comment on paye ?

37. 1 . Prendre le temps de
tracer la dette
Exemples logistiques : Rendez-vous régulier dédié par l’équipe de Dev
Exemples d’outils d’enregistrement : Tableau de post-it, section spécifique
dans le Backlog produit, Backlog à part
Exemples de processus formel :
- Le faire rentrer dans la Definition of Ready (pré-requis d’une
fonctionnalité, tests fonctionnels qui va avec, industrialisation, etc)
- ou dans la Definition of Done

38. Et vous dans votre équipe ?
Que faites-vous ?
Que pourriez-vous faire ?
STOP :
Writer time !

39. 2. Lui donner l’importance qu’elle
mérite AVANT de payer
Exemples d’outils d’enregistrement :
- Exprimer les éléments techniques dans les mêmes critères que le
reste des éléments du Backlog fonctionnel (Valeur business, risque,
complexité, etc.)
Exemples de processus :
- Définir un “Product Owner technique” qui gère un backlog +
processus d’arbitrage “fonctionnel / technique”
- Convier les Product Owners aux “grooming technique”
- Information / Formation de sponsor en amont
Nouvelle
fonction
Dette
technique

40. Et vous dans votre équipe ?
Que faites-vous ?
Que pourriez-vous faire ?
STOP :
Writer time !

41. 3. Suivre le paiement et le
célébrer
Outils de suivi :
- Outils de qualimétrie (SonarQube, Lint, PMD, Checkstyles, etc…)
Processus formel :
- Montrer l’avancement régulièrement aux démonstrations
- Suivre une notion “d’avancement technique” en tant qu’indicateur de
performance de l’équipe

42. Et vous dans votre équipe ?
Que faites-vous ?
Que pourriez-vous faire ?
STOP :
Writer time !

43. 1. En binôme, racontez votre retour sur expérience
(Tickets Que faites vous ?)
2. En équipe produit, faites un point sur “ce que vous
pourriez faire ?”

44. Rappelez-vous les
conséquences d’une
mauvaise gestion de dette

45. “I live in a
tormented state
knowing the
pain and
suffering I have
created.”
Bernard Madoff, mauvais
gestionnaire de dette

46. Merci !

47. Aller plus loin
Où allez-vous appliquer ce que vous avez appris dans
cet atelier ?
A partir de quand ?
Avec quoi peut-on compléter cet atelier ?

48. Alexandre QUACH
http://www.investirdigital.fr