SlideShare une entreprise Scribd logo
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Préenregistrement et diapositives
Diapositives DevOps et Vélocité
https://is.gd/L2cc00
Préenregistrement vidéo
https://is.gd/4poXhn
22
COSMIC
https://cosmic-sizing.org/
Le vélocité,
c’est quoi?
3
La vélocité, c’est …
4
~ Productivité = Efficacité + Efficience
~
Selon Larousse: « Grande rapidité dans le mouvement »
En Waterfall,
«Productivité de livraison
du logiciel»:
Quantité de logiciel
/ mois-personne
• 4 sem. de 35h = 140h
• 4,3 sem. de 40h = 172h
 Variable !
En Agile,
Vélocité
=
# USP / Sprint
2, 3 ou 4 semaines ?
 Variable !
?
Subjectif!
Non reproductible
En DevOps, la vélocité ça pourrait être…
• Comme en Waterfall: Quantité de logiciel / mois-personne  Variable!
• Comme en Agile: # USP / Sprint  Variable!
• Quelques équipes utilisent le temps de cycle moyen (de Lean/Kanban)
• Différences importantes de l’effort et la durée, entre:
5
Retour du terrain sur la vélocité
Résultat attendu Agile et DevOps
• Augmentation de notre vélocité avec
le temps:
• Bonnes rétrospectives
• + de réutilisation
• + de maturité de l’équipe
• + compréhension du domaine d’affaires et
des besoins
Résultat obtenu
• En Agile:
• Tendance à stagner
• Parfois ça diminue
• En DevOps:
• Tendance générale à diminuer avec
le temps!
6
Mais qui a volé la
vélocité?
7
Baisse de vélocité en DevOps? Quel est le coupable?
8
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
USP
? ?
?
Parlons de la portée!
9
Activités en Waterfall classique
10
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Équipe de projet Équipes de maintenance et opérations
Activités en Agile
11
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Équipe de projet Équipe(s) de maintenance et opérations
Activités en DevOps
12
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Équipe de produit
Grande portée == petite vélocité ?
En Agile et en DevOps:
• Automatisation : accélère la livraison
• Tests automatisés : favorise la qualité
• Meilleure qualité : favorise la vélocité
Mais en DevOps:
• Supporter la production demande de l’effort
13
La portée est-elle coupable ?
14
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
? ?
?
Coupable !
15
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
? ?
Les causes de l’augmentation de la portée
• En DevOps, beaucoup de travaux qui appartenaient aux opérations
16
Système de surveillance permettant d’éclairer
les décisions métiers
Notification proactive des échecs
Surveillance et observabilité
Automatisation des déploiements
Développement à branche unique
Livraison continue
Tests continus
Architecture (découplée)
Intégrer la sécurité dès le départ
Gestion des données de test
Gestion du changement de base de données
Infrastructure cloud (Infonuagique)
Gestion du code (qualité, réutilisable, maintenable)
Solution  pour mieux gérer la portée
•Ajuster la définition de terminé
• Inclure les tâches d’opérations
 Qu’elles soient VISIBLES afin d’être estimées!
•Avoir des membres d’équipe experts en opérations
• Parce qu’ils savent ce qui est nécessaire, alors on évite de les oublier!
• Ça va plus vite aussi!
• Équipe multidisciplinaire: les Ops doivent en faire partie!
• Possibilité: équipe un peu plus grosse…
17
Parlons de la
dette technique!
18
Pensez-vous qu’il s’agit d’une dette technique …
Fonctionnalité manquante ?
Vulnérabilité de sécurité (découverte en 2021) ?
Absence de surveillance et notification ?
19
Définition
« Dans les logiciels d’envergure, la dette technique consiste en un ensemble
de conceptions et d’implémentations plus rapides originalement, mais qui
mettent en place un contexte technique qui peut rendre un changement futur
plus couteux ou impossible.
Il s’agit d’une obligation potentielle de réaliser des travaux dont les impacts
sont limités aux caractéristiques internes du système, principalement, mais
non uniquement la maintenabilité et l’évolutivité. »
- Philippe Kruchten, Ipek Ozkaya
20
Source: Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering)
1st Edition, Philippe Kruchten, Ipek Ozkaya
Ou plus simplement…
•Prendre des raccourcis
•Pelleter par en avant
•Faire une première version techniquement minimaliste
•Solution technique qui n’est plus adéquate parce que les besoins
ont changés
21
Paysage de la Dette Technique
22
Source: Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering)
1st Edition, Philippe Kruchten, Ipek Ozkaya
Maintenabilité
Évolutivité
Visible Presque invisible
Architecture Code
Infrastructure de production
Nouvelles fonctionnalités Anomalies
Visible
Activités en Waterfall classique
23
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Activités en Waterfall classique
24
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Dette technique
Les effets de la dette technique en Waterfall
Waterfall  autre équipe qui va s’en occuper et vivre avec
25
Équipe de
projet
Équipe de
maintenance
Équipe des
opérations
Activités en Agile
26
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Activités en Agile
27
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Dette technique
Les effets de la dette technique en Agile
Agile  Ralentissement pour l’équipe pendant le
développement, mais aussi pour les opérations
28
Activités en DevOps
29
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Activités en Devop
30
Tests manuels
Tests automatisés
Évolution et maintenance
Automatisation des déploiements
Correctifs d'anomalies
Correctifs de sécurité
Architecture découplée
Outillage pour la production
Surveillance et notifications
Mesure
Confirmité et audits
Support aux usagers
Développement
Dette technique
Les effets de la dette technique en DevOps
DevOps  Plusieurs sources de dette,
incluant les opérations
31
La dette est-elle coupable ?
32
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
? ?
Coupables !
33
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
?
Les causes de la dette technique
•Habitude de ne faire que des fonctionnalités
• Accumule de la dette technique
•L’importance de la dette technique est sous-estimée
•En DevOps, beaucoup plus de travaux invisibles au PO et aux
utilisateurs
34
Médianes des ratios d’effort (State of DevOps, 2018)
35
Source: https://www.devops-research.com/research.html
0 10 20 30 40 50 60 70 80 90 100
Faible
Moyen
Élevé
Élite
% d’effort pour nouveau développement
Solution  pour mieux gérer la dette technique
•Ajuster la définition de terminé pour éviter la dette technique
•Respecter de bons ratios:
• Allouer assez de temps pour compléter correctement chaque récit
• Aller du temps pour corriger les dettes techniques existantes
•Gérer la dette technique comme d’autres récits
36
Un BON récit de Dette Technique, ça contient:
•Cause
•Problématique
•Impact
•Solution
•Retour sur investissement
•Niveau d’effort requis
•Bénéfice attendu
37
Comment choisir quelle dette régler ?
38
Considérer le type de dette et les coûts associés
• Frais récurrents  étapes manuelles à reprendre
• Intérêts composés  tout ajout va coûter plus cher par la suite
Considérer le retour sur investissement
Considérer les objectifs d’affaires
Décrire adéquatement la dette technique
 pour la rendre visible et compréhensible
Parlons de la dérive
des estimations !
39
La dérive des estimations: un exemple
40
Niche 3 pts
Cabanon 5 pts
Bungalow 8 pts
Cottage 13 pts
Cottage 13 pts
Duplex 20 pts
Bloc 40 pts
Cottage 8 pts
Cabanon 5 pts
Niche 2 pts
Le problème avec les USP…
• Valeur subjective
• N’a du sens que pour l’équipe dans CE projet:
• Incomparable avec les autres équipes
• Incomparable avec les autres projets de cette équipe
• Alors… ce « niveau d’effort largement approximatif » est
parfois (ou souvent) utilisé comme si c’était une mesure
objective et comparable
Et cette pratique est considérée comme de « faute professionnelle »
en gestion!
Immanquablement, on aura des écarts parfois important sur nos
estimations!
41
La dérive des estimations est-elle coupable ?
42
1
2
3
5
8
13
Portée Dette
technique
Dérive des
estimations
?
Coupables !
43
1
2
3
5
8
13
Portée
(DoD)
Dette
technique
Dérive des
estimations
Les causes de la dérive des estimations
•Les estimations ne sont pas «ancrées» sur une référence
•Tendance à sous-évaluer les travaux répétés
•Tendance à dire 1 USP = 1 jour
•Estimation != mesure
44
Estimations découlant de nos données de vélocité
45
Valeur d’Affaires
Date
Coût
Effort de l’équipe
Productivité
(ou vélocité)
Taux de livraison
Taille du logiciel
Source: Trudel, S. (2019). « Agile & COSMIC, a Good Integration! », CNMES, Mexico, 24 Octobre 2019.
Problème:
Comment
mesurer la taille
objectivement?
Solution  pour mieux estimer
•Employer une échelle de référence
•Employer une mesure objective
46
Pourrait-on utiliser l’analogie de la construction?
•En construction: coût moyen = $/pi2
•En développement logiciel
= les données utilisées ou traitées:
• # Entrées, # Sorties, # Lecture, # Écritures?
•Mais OUI! Ça s’appelle la « méthode COSMIC »!
47
La méthode COSMIC (ISO 19761), en bref
48
Données
Processus
fonctionnel 1
Logiciel à mesurer Infrastructure de
stockage
Write (W)
Read (R)
Processus
fonctionnel 2
Processus
fonctionnel n
…
Matériel
d’Entrée/
Sortie
Entry (E)
eXit (X)
‘Front end’ ‘Back end’
Utilisateurs
ou
Autres
systèmes
Dispositifs
d’ingénierie
ou
Utilisateurs
fonctionnels
Frontière
Exemple de données réelles:
logiciel de sécurité et surveillance
49
0
20
40
60
80
100
120
140
160
180
200
0 10 20 30 40 50 60 70 80
Actual
Effor
(Hours)
Functional Size in CFP
Y = 2.35 x CFP - 0.08hrs and R2 = 0.977)
0
20
40
60
80
100
120
140
160
180
200
0 20 40 60 80 100 120 140 160 180 200
Actual
Effort
(hours)
Estimated Effort (Hours)
Effort = 0.47 x Story Points + 17.6 hours and R2 = 0.33)
User Story Points
COSMIC
Scrum + TDD, sprints de 2
semaines:
• 24 tâches en 9 sprints
• Estimées en #USP
• Effort mesuré en #Heures
• Mesurées en #PFC
Source: C. Commeyne, A. Abran, R. Djouab (2016). «Effort Estimation with Story Points and COSMIC Function Points -
An Industry Case Study». Disponible de www.cosmic-sizing.org ‘Software Measurement News’. Vol 21, No. 1, 2016
Exemple de mesure d’un micro-service
qui rehausse le profil de l’utilisateur
50
Récupérer le
profil
utilisateur pour
l’afficher
User_ID (E)
Interface
(UI)
Autre
micro-service
User_ID (X)
Profil (E)
BD
Adresse
(R)
Profil (X)
Adresse (X)
Mettre à jour
l’adresse de
l’utilisateur
Interface
(UI)
Adresse (E)
User_ID (E)
BD
Adresse
(W)
Err. format
d’adresse (X)
Code
succès
/échec
(E)
SGBD
Succès/
échec(X)
6
PFC!
2E
3X
1R
6
PFC!
3E
2X
1W
Total:
12 PFC!
1er Flux: 2e Flux:
En DevOps, la vélocité ça pourrait être…
• Coût unitaire: # Heures/PFC  coût de développement @200$/hr
• Taux de livraison: #PFC/mois ou #PFC/sprint  date de livraison prévisible
51
Total:
12 PFC!
Mode Vélocité Effort Coûts
Waterfall 10 à 45 Hrs/PFC 120 à 540 hrs 24 000$ à 108 000$
Agile 2 à 20 Hrs/PFC 24 à 240 hrs 4 800$ à 48 000$
Incluant Dev, Test, Bug fix
COSMIC c’est…
•Une organisation sans but lucratif: https://cosmic-sizing.org/
•Mission: maintenir la méthode et les guides GRATUITEMENT
52
Conclusion
•On a identifié 3 coupables avec des solutions pour les contourner
• Portée, avec plus de tâches
• Dette technique
• Dérive des estimations
•Encore faut-il appliquer les solutions adéquatement!
53
Questions
54

Contenu connexe

Similaire à Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel

Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Sébastien Bourguignon
 
Vincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops SherbrookeVincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops Sherbrooke
Vincent Biret
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
agnes_crepet
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Jason De Oliveira
 
Surmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOpsSurmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOps
Agile Montréal
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
qsdqsd4
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?
Innobec
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
ZALIMAZA
 
20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps
LeClubQualiteLogicielle
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
Agile Toulouse
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
Goood!
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
boulonvert
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
Goood!
 
DSI, c'est vous le chef d'orchestre!
DSI, c'est vous le chef d'orchestre!DSI, c'est vous le chef d'orchestre!
DSI, c'est vous le chef d'orchestre!
Microsoft Ideas
 
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continueOmnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Xavier Callens
 
Le long chemin du PMU vers la tech company
Le long chemin du PMU vers la tech companyLe long chemin du PMU vers la tech company
Le long chemin du PMU vers la tech company
Agile En Seine
 
Business case pour une solution d'intégration de la chaîne d'outils
Business case pour une solution d'intégration de la chaîne d'outilsBusiness case pour une solution d'intégration de la chaîne d'outils
Business case pour une solution d'intégration de la chaîne d'outils
Planview
 

Similaire à Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel (20)

Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
Vincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops SherbrookeVincent Biret Societic devops Sherbrooke
Vincent Biret Societic devops Sherbrooke
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
 
Surmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOpsSurmonter les anti-patrons culturels nuisant à DevOps
Surmonter les anti-patrons culturels nuisant à DevOps
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
 
20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps
 
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisationAgileTour Toulouse 2012 : de la livraison continue dans mon organisation
AgileTour Toulouse 2012 : de la livraison continue dans mon organisation
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?De la livraison continue dans mon organisation?
De la livraison continue dans mon organisation?
 
DSI, c'est vous le chef d'orchestre!
DSI, c'est vous le chef d'orchestre!DSI, c'est vous le chef d'orchestre!
DSI, c'est vous le chef d'orchestre!
 
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continueOmnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
Omnilog 2016 - Apéro techno : Rex Identicar sur l'intégration continue
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Le long chemin du PMU vers la tech company
Le long chemin du PMU vers la tech companyLe long chemin du PMU vers la tech company
Le long chemin du PMU vers la tech company
 
Business case pour une solution d'intégration de la chaîne d'outils
Business case pour une solution d'intégration de la chaîne d'outilsBusiness case pour une solution d'intégration de la chaîne d'outils
Business case pour une solution d'intégration de la chaîne d'outils
 

Plus de Agile Montréal

ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
Agile Montréal
 
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
Agile Montréal
 
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander DurATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
Agile Montréal
 
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
Agile Montréal
 
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
Agile Montréal
 
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
Agile Montréal
 
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
Agile Montréal
 
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
Agile Montréal
 
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
Agile Montréal
 
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
Agile Montréal
 
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
Agile Montréal
 
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
Agile Montréal
 
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi RocheATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
Agile Montréal
 
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
Agile Montréal
 
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline Tissier
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline  TissierATMTL23 - La collaboration intergénérationnelle au travail par Apolline  Tissier
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline Tissier
Agile Montréal
 
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl MétivierATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
Agile Montréal
 
ATMTL23 - Économie coopérative et agilité par Dominique Pothier
ATMTL23 - Économie coopérative et agilité par Dominique PothierATMTL23 - Économie coopérative et agilité par Dominique Pothier
ATMTL23 - Économie coopérative et agilité par Dominique Pothier
Agile Montréal
 
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
Agile Montréal
 
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
Agile Montréal
 
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
Agile Montréal
 

Plus de Agile Montréal (20)

ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
ATMTL23 - L'agilité augmentée par ChatGPT: comment utiliser l'agent intellige...
 
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
ATMTL23 - How to create and elevate top talent? A cohort-based learning metho...
 
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander DurATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
ATMTL23 - TANS: there always a next sprint by Tom Siebeneicher and Sander Dur
 
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
ATMTL23 - Dépasser les frontières : Réinterpréter les Principes ISTQB avec un...
 
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
ATMTL23 - Comment mieux atteindre vos objectifs grâce à l'agilité comportemen...
 
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
ATMTL23 - Le multivers Agile - Volume 2: Odyssée vers Agiletopia par Martin L...
 
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
ATMTL23 - Créer une entreprise apprenante : Les principes de Peter Senge pour...
 
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
ATMTL23 - De la Zone de Guerre à la Zone de Cœur : Un Voyage de Résilience, d...
 
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
ATMTL23 - Réussir sa transformation agile c'est d’abord changer son état d'es...
 
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
ATMTL23 - The Happiness Blueprint: Positivity Experiments for Powerful Teamwo...
 
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
ATMTL23 - Le Developer Experience au service de la livraison en continu par A...
 
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
ATMTL23 - L'Arbre de vie - Une pratique narrative pour se réapproprier son pa...
 
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi RocheATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
ATMTL23 - Atelier PNL pour ameliorer la communication par Remi Roche
 
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
ATMTL23 - Remettre l'humain au coeur de l'agilité avec le Mind Mapping par Re...
 
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline Tissier
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline  TissierATMTL23 - La collaboration intergénérationnelle au travail par Apolline  Tissier
ATMTL23 - La collaboration intergénérationnelle au travail par Apolline Tissier
 
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl MétivierATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
 
ATMTL23 - Économie coopérative et agilité par Dominique Pothier
ATMTL23 - Économie coopérative et agilité par Dominique PothierATMTL23 - Économie coopérative et agilité par Dominique Pothier
ATMTL23 - Économie coopérative et agilité par Dominique Pothier
 
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
ATMTL23 - Agnostic Agile, un mouvement en Agilité qui respecte les bases les ...
 
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
ATMTL23 - Innovation Unleashed: Inspiring Agile Teams through Creative Thinki...
 
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
ATMTL23 - « A community of Scientists » Saisir le pouvoir du Toyota Kata pour...
 

Dernier

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
Friends of African Village Libraries
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
Txaruka
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
Txaruka
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
TimogoTRAORE
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
Editions La Dondaine
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
NadineHG
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
NadineHG
 

Dernier (7)

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
 

Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel

  • 2. Préenregistrement et diapositives Diapositives DevOps et Vélocité https://is.gd/L2cc00 Préenregistrement vidéo https://is.gd/4poXhn 22 COSMIC https://cosmic-sizing.org/
  • 4. La vélocité, c’est … 4 ~ Productivité = Efficacité + Efficience ~ Selon Larousse: « Grande rapidité dans le mouvement » En Waterfall, «Productivité de livraison du logiciel»: Quantité de logiciel / mois-personne • 4 sem. de 35h = 140h • 4,3 sem. de 40h = 172h  Variable ! En Agile, Vélocité = # USP / Sprint 2, 3 ou 4 semaines ?  Variable ! ? Subjectif! Non reproductible
  • 5. En DevOps, la vélocité ça pourrait être… • Comme en Waterfall: Quantité de logiciel / mois-personne  Variable! • Comme en Agile: # USP / Sprint  Variable! • Quelques équipes utilisent le temps de cycle moyen (de Lean/Kanban) • Différences importantes de l’effort et la durée, entre: 5
  • 6. Retour du terrain sur la vélocité Résultat attendu Agile et DevOps • Augmentation de notre vélocité avec le temps: • Bonnes rétrospectives • + de réutilisation • + de maturité de l’équipe • + compréhension du domaine d’affaires et des besoins Résultat obtenu • En Agile: • Tendance à stagner • Parfois ça diminue • En DevOps: • Tendance générale à diminuer avec le temps! 6
  • 7. Mais qui a volé la vélocité? 7
  • 8. Baisse de vélocité en DevOps? Quel est le coupable? 8 1 2 3 5 8 13 Portée Dette technique Dérive des estimations USP ? ? ?
  • 9. Parlons de la portée! 9
  • 10. Activités en Waterfall classique 10 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Équipe de projet Équipes de maintenance et opérations
  • 11. Activités en Agile 11 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Équipe de projet Équipe(s) de maintenance et opérations
  • 12. Activités en DevOps 12 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Équipe de produit
  • 13. Grande portée == petite vélocité ? En Agile et en DevOps: • Automatisation : accélère la livraison • Tests automatisés : favorise la qualité • Meilleure qualité : favorise la vélocité Mais en DevOps: • Supporter la production demande de l’effort 13
  • 14. La portée est-elle coupable ? 14 1 2 3 5 8 13 Portée Dette technique Dérive des estimations ? ? ?
  • 16. Les causes de l’augmentation de la portée • En DevOps, beaucoup de travaux qui appartenaient aux opérations 16 Système de surveillance permettant d’éclairer les décisions métiers Notification proactive des échecs Surveillance et observabilité Automatisation des déploiements Développement à branche unique Livraison continue Tests continus Architecture (découplée) Intégrer la sécurité dès le départ Gestion des données de test Gestion du changement de base de données Infrastructure cloud (Infonuagique) Gestion du code (qualité, réutilisable, maintenable)
  • 17. Solution  pour mieux gérer la portée •Ajuster la définition de terminé • Inclure les tâches d’opérations  Qu’elles soient VISIBLES afin d’être estimées! •Avoir des membres d’équipe experts en opérations • Parce qu’ils savent ce qui est nécessaire, alors on évite de les oublier! • Ça va plus vite aussi! • Équipe multidisciplinaire: les Ops doivent en faire partie! • Possibilité: équipe un peu plus grosse… 17
  • 18. Parlons de la dette technique! 18
  • 19. Pensez-vous qu’il s’agit d’une dette technique … Fonctionnalité manquante ? Vulnérabilité de sécurité (découverte en 2021) ? Absence de surveillance et notification ? 19
  • 20. Définition « Dans les logiciels d’envergure, la dette technique consiste en un ensemble de conceptions et d’implémentations plus rapides originalement, mais qui mettent en place un contexte technique qui peut rendre un changement futur plus couteux ou impossible. Il s’agit d’une obligation potentielle de réaliser des travaux dont les impacts sont limités aux caractéristiques internes du système, principalement, mais non uniquement la maintenabilité et l’évolutivité. » - Philippe Kruchten, Ipek Ozkaya 20 Source: Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering) 1st Edition, Philippe Kruchten, Ipek Ozkaya
  • 21. Ou plus simplement… •Prendre des raccourcis •Pelleter par en avant •Faire une première version techniquement minimaliste •Solution technique qui n’est plus adéquate parce que les besoins ont changés 21
  • 22. Paysage de la Dette Technique 22 Source: Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering) 1st Edition, Philippe Kruchten, Ipek Ozkaya Maintenabilité Évolutivité Visible Presque invisible Architecture Code Infrastructure de production Nouvelles fonctionnalités Anomalies Visible
  • 23. Activités en Waterfall classique 23 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement
  • 24. Activités en Waterfall classique 24 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Dette technique
  • 25. Les effets de la dette technique en Waterfall Waterfall  autre équipe qui va s’en occuper et vivre avec 25 Équipe de projet Équipe de maintenance Équipe des opérations
  • 26. Activités en Agile 26 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement
  • 27. Activités en Agile 27 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Dette technique
  • 28. Les effets de la dette technique en Agile Agile  Ralentissement pour l’équipe pendant le développement, mais aussi pour les opérations 28
  • 29. Activités en DevOps 29 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement
  • 30. Activités en Devop 30 Tests manuels Tests automatisés Évolution et maintenance Automatisation des déploiements Correctifs d'anomalies Correctifs de sécurité Architecture découplée Outillage pour la production Surveillance et notifications Mesure Confirmité et audits Support aux usagers Développement Dette technique
  • 31. Les effets de la dette technique en DevOps DevOps  Plusieurs sources de dette, incluant les opérations 31
  • 32. La dette est-elle coupable ? 32 1 2 3 5 8 13 Portée Dette technique Dérive des estimations ? ?
  • 34. Les causes de la dette technique •Habitude de ne faire que des fonctionnalités • Accumule de la dette technique •L’importance de la dette technique est sous-estimée •En DevOps, beaucoup plus de travaux invisibles au PO et aux utilisateurs 34
  • 35. Médianes des ratios d’effort (State of DevOps, 2018) 35 Source: https://www.devops-research.com/research.html 0 10 20 30 40 50 60 70 80 90 100 Faible Moyen Élevé Élite % d’effort pour nouveau développement
  • 36. Solution  pour mieux gérer la dette technique •Ajuster la définition de terminé pour éviter la dette technique •Respecter de bons ratios: • Allouer assez de temps pour compléter correctement chaque récit • Aller du temps pour corriger les dettes techniques existantes •Gérer la dette technique comme d’autres récits 36
  • 37. Un BON récit de Dette Technique, ça contient: •Cause •Problématique •Impact •Solution •Retour sur investissement •Niveau d’effort requis •Bénéfice attendu 37
  • 38. Comment choisir quelle dette régler ? 38 Considérer le type de dette et les coûts associés • Frais récurrents  étapes manuelles à reprendre • Intérêts composés  tout ajout va coûter plus cher par la suite Considérer le retour sur investissement Considérer les objectifs d’affaires Décrire adéquatement la dette technique  pour la rendre visible et compréhensible
  • 39. Parlons de la dérive des estimations ! 39
  • 40. La dérive des estimations: un exemple 40 Niche 3 pts Cabanon 5 pts Bungalow 8 pts Cottage 13 pts Cottage 13 pts Duplex 20 pts Bloc 40 pts Cottage 8 pts Cabanon 5 pts Niche 2 pts
  • 41. Le problème avec les USP… • Valeur subjective • N’a du sens que pour l’équipe dans CE projet: • Incomparable avec les autres équipes • Incomparable avec les autres projets de cette équipe • Alors… ce « niveau d’effort largement approximatif » est parfois (ou souvent) utilisé comme si c’était une mesure objective et comparable Et cette pratique est considérée comme de « faute professionnelle » en gestion! Immanquablement, on aura des écarts parfois important sur nos estimations! 41
  • 42. La dérive des estimations est-elle coupable ? 42 1 2 3 5 8 13 Portée Dette technique Dérive des estimations ?
  • 44. Les causes de la dérive des estimations •Les estimations ne sont pas «ancrées» sur une référence •Tendance à sous-évaluer les travaux répétés •Tendance à dire 1 USP = 1 jour •Estimation != mesure 44
  • 45. Estimations découlant de nos données de vélocité 45 Valeur d’Affaires Date Coût Effort de l’équipe Productivité (ou vélocité) Taux de livraison Taille du logiciel Source: Trudel, S. (2019). « Agile & COSMIC, a Good Integration! », CNMES, Mexico, 24 Octobre 2019. Problème: Comment mesurer la taille objectivement?
  • 46. Solution  pour mieux estimer •Employer une échelle de référence •Employer une mesure objective 46
  • 47. Pourrait-on utiliser l’analogie de la construction? •En construction: coût moyen = $/pi2 •En développement logiciel = les données utilisées ou traitées: • # Entrées, # Sorties, # Lecture, # Écritures? •Mais OUI! Ça s’appelle la « méthode COSMIC »! 47
  • 48. La méthode COSMIC (ISO 19761), en bref 48 Données Processus fonctionnel 1 Logiciel à mesurer Infrastructure de stockage Write (W) Read (R) Processus fonctionnel 2 Processus fonctionnel n … Matériel d’Entrée/ Sortie Entry (E) eXit (X) ‘Front end’ ‘Back end’ Utilisateurs ou Autres systèmes Dispositifs d’ingénierie ou Utilisateurs fonctionnels Frontière
  • 49. Exemple de données réelles: logiciel de sécurité et surveillance 49 0 20 40 60 80 100 120 140 160 180 200 0 10 20 30 40 50 60 70 80 Actual Effor (Hours) Functional Size in CFP Y = 2.35 x CFP - 0.08hrs and R2 = 0.977) 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 Actual Effort (hours) Estimated Effort (Hours) Effort = 0.47 x Story Points + 17.6 hours and R2 = 0.33) User Story Points COSMIC Scrum + TDD, sprints de 2 semaines: • 24 tâches en 9 sprints • Estimées en #USP • Effort mesuré en #Heures • Mesurées en #PFC Source: C. Commeyne, A. Abran, R. Djouab (2016). «Effort Estimation with Story Points and COSMIC Function Points - An Industry Case Study». Disponible de www.cosmic-sizing.org ‘Software Measurement News’. Vol 21, No. 1, 2016
  • 50. Exemple de mesure d’un micro-service qui rehausse le profil de l’utilisateur 50 Récupérer le profil utilisateur pour l’afficher User_ID (E) Interface (UI) Autre micro-service User_ID (X) Profil (E) BD Adresse (R) Profil (X) Adresse (X) Mettre à jour l’adresse de l’utilisateur Interface (UI) Adresse (E) User_ID (E) BD Adresse (W) Err. format d’adresse (X) Code succès /échec (E) SGBD Succès/ échec(X) 6 PFC! 2E 3X 1R 6 PFC! 3E 2X 1W Total: 12 PFC! 1er Flux: 2e Flux:
  • 51. En DevOps, la vélocité ça pourrait être… • Coût unitaire: # Heures/PFC  coût de développement @200$/hr • Taux de livraison: #PFC/mois ou #PFC/sprint  date de livraison prévisible 51 Total: 12 PFC! Mode Vélocité Effort Coûts Waterfall 10 à 45 Hrs/PFC 120 à 540 hrs 24 000$ à 108 000$ Agile 2 à 20 Hrs/PFC 24 à 240 hrs 4 800$ à 48 000$ Incluant Dev, Test, Bug fix
  • 52. COSMIC c’est… •Une organisation sans but lucratif: https://cosmic-sizing.org/ •Mission: maintenir la méthode et les guides GRATUITEMENT 52
  • 53. Conclusion •On a identifié 3 coupables avec des solutions pour les contourner • Portée, avec plus de tâches • Dette technique • Dérive des estimations •Encore faut-il appliquer les solutions adéquatement! 53