Présenté Nick Stock à l'occasion des conférences Agile en Seine le 29 septembre 2020
http://agileenseine.com
Vidéo de la conférence disponible sur Youtube :
https://youtu.be/1KlCStACDxI
Dans cette présentation, Nick reste en adéquation avec le thème principal de l'événement: l'évolution.
La culture d’innovation est primordiale dans un monde qui avance aussi vite. Les équipes techniques les plus performantes vont de 5 à 10 fois plus vite que les autres.
Et cela est dû à un apprentissage continu des meilleures pratiques adaptées au contexte changeant de l’entreprise.
Il est facile de mettre l'évolution des techniciens à un plan secondaire.
Ainsi Nick nous aide à répondre à la question suivante : Comment s’assurer que les développeurs fassent des améliorations constantes de leurs méthodes de travail?
4. 4
Nick Stock
Fondateur de Gembani
18 ans d'expérience professionnelle
10 ans dans la silicon valley
ruby, python, javascript, java, php
langage de prédilection: ruby
Contact :
nick@gembani.com
Intervenant
6. 6
Définition de l’atrophie
1. Diminution acquise de poids et de volume d'une
cellule, d'un tissu ou d'un organe.
2. Perte ou affaiblissement d'une faculté : Atrophie de
l'intelligence.
3. Réduction de l'activité : L'atrophie progressive d'une
industrie.
8. Vélocité
● La volatilité est la mesure de la variance dans la vélocité
Volatilité
● La vélocité d'un sprint représente le nombre de points d'effort
total de l'ensemble des éléments qui sont terminés à 100%
● On compte seulement les points des features qui apportent de
la valeur au client
Métriques permettant de mesurer l’atrophie technique
10. 10
Symptômes de l’atrophie dans les équipes IT
● Conséquence d’une forte volatilité : l’équipe IT
est incapable de prédire quand les prochaines
fonctionnalités seront terminées.
● Les estimations des développeurs sont fausses
d’au moins un ordre de magnitude.
12. 12
Quelles sont les causes de l’atrophie?
● Modèle en V, 3 grandes phases : design, développement, test
● Agile : on réduit la taille du batch
○ Les développeurs se focalisent trop sur les fonctionnalités
○ Il faut délivrer à chaque sprint : si on est en retard, on prend
des raccourcis!
13. 13
Quelles sont les causes de l’atrophie?
● Dette technique : décrit les conséquences des actions de
développement logiciel qui accordent une priorité,
intentionnelle ou non, à la valeur client et / ou aux contraintes
du projet, telles que les délais de livraison, par rapport à des
considérations plus techniques de mise en œuvre et de
conception
14. 14
Réaction face à l’atrophie : les mauvais réflexes!
● Optimisations prématurées
● Technique du Big Bang: “Let’s start over!”
○ Changement de stack technique
○ Multiples sprints liés à de longues refactorisations
⇨ Conséquences :
● Burn out
● Turnover
15. 15
Valeurs clés de l’Agile
● La technique du Big Bang n’est pas Agile : Créer une
culture consistant à prendre des petits risques
mesurés est encouragé!
● Investir dans ses employés : Ils sont plus productifs
s’ils sont formés régulièrement
16. 16
Agile Engineers checklist
Clear clean readable codebase
● High level frameworks - RoR,
Django, Emberjs
Tests at many granularities
● TDD
● Builds/packaging/Deploys are
automatic.
Continuous Integration
● Continuous integration for
building testing on every
commit.
New dev can be integrated easily
● Local development
● Easy readme
Shared responsibility
Cross functional teams
17. ⇨ Comment faire pour appliquer les valeurs de l’agile et
réduire l’atrophie technique?
18. 18
Tech Days
Un jour par sprint consacré à l’amélioration
continue. Les développeurs ne sont pas autorisés à
travailler sur de nouvelles fonctionnalités (ou des
bugs).
● Refactoring du code existant
● Création et amélioration des tests
● Amélioration de l’automation
● Développement des outils de débug
19. 19
Règle d’or des Tech Days
Afin de créer de la valeur immédiatement, il faut timeboxer
l’exercice. Les développeurs doivent effectuer de petites
améliorations qui doivent être terminées à la fin du Tech Day.
Le but n’est pas d’effectuer un gros refactor tous les 6 mois
mais d’apporter de l’amélioration continue à chaque session.
⇨ Chaque développeur doit pouvoir merger son commit à la fin
de la journée
20. 20
Organisation des Tech Days
1. Standup meeting lors duquel les développeurs
proposent leurs idées
2. Choix des problèmes prioritaires et formation
des paires de développeurs
3. Résolution des problèmes
4. Rétrospective rédaction de l’email de conclusion
21. 21
Rôle du tech lead
Interagit avec chaque paire pour s’assurer que la
règle d’or du Tech Day est bien respectée.
⇨ Cela signifie souvent réduire le scope du
problème
22. 22
Rétrospective
● Trouver un problème qui peut être résolu en une
journée est une tâche difficile.
⇨ Il faut discuter ensemble des erreurs commises
pour ne pas les répéter à l’avenir.
● La connaissance apportée par le Tech Day doit être
redistribuée à l’ensemble de l’équipe .
● Un email destiné au management est rédigé, décrivant
les victoires et les défaites de la journée.
23. 23
Résultat: Etude de cas “Arenametrix”
1. Tous les développeurs pratiquent désormais le TDD
2. La plupart des outils de débug expérimentaux
développés durant un Tech Day ont été montrés au
management et sont maintenant intégrés au
workflow standard
3. La qualité globale du code a été significativement
améliorée
4. La variance a été significativement diminuée
24. 24
Conclusion
Il est possible de combattre l’atrophie technique tout
en restant en accord avec les valeurs de l’agile.
- Le timeboxing force les développeurs à réfléchir de
manière agile
- On améliore la qualité du code petit à petit.
- Les améliorations combattent la dette technique
⇨ On sort enfin de l’atrophie technique
25. Questions
Let’s stay in touch!
website : www.gembani.com
Nicholas Stock
nicholasjstock
https://www.gembani.com/fr/office_hours.html
26. Le combat contre l’atrophie technique
— Nick Stock —
Mardi 29 septembre 2020 13:00
https://roti.express/r/aes20-009
A vos feedback !
website : www.gembani.com
Nicholas Stock
nicholasjstock
https://www.gembani.com/fr/office_hours.html