1. L’adoption de l’agilité:
Impacts sur l’organisation
•
•
ISACA - Québec
12 avril 2012

2. Qui suis-je?
•
Sylvie Trudel
–
Coach Agile
–
Chargé de cours Université de Sherbrooke
–
Doctorat de l’ETS
–
Co-auteur d’un livre avec Mathieu Boivert

3. Agenda
•
•
Introduction à l’agilité
Impacts de l’agilité au-delà des projets
–
–
–
–
–
–
•
•
Activité limitrophes
Encadrement
Coûts
Gouvernance
Culture organisationnelle
Gestion du changement
Pratiques liées à l’ACQ dans les projets agiles
Discussion et conclusion

4. •
Valeurs, principes et méthodes
Introduction à l’agilité

5. Qu’est-ce que l’Agilité?
L’agilité est une philosophie de travail basée sur
4 valeurs et 12 principes
 Les méthodes et approches qui sont dites « agiles »
sont cohérentes avec ces valeurs et ces
principes

6. Les 4 valeurs de l’agilité
L’agilité valorise:
1.
Les individus et les interactions
2. Les logiciels fonctionnels
3. La collaboration avec le client
4. La réponse au changement
davantage que:
les processus et les outils
une documentation exhaustive
la négociation de contrat
le suivi d'un plan
Utiles, nécessaires,
mais moins importants que

7. Les 12 principes de l’agilité
1.
2.
3.
4.
5.
6.
Notre première priorité est de satisfaire le
client en livrant tôt et régulièrement des
logiciels utiles
7.
8.
Le changement est accepté, même
tardivement dans le développement. Les
processus agiles exploitent le changement
comme avantage compétitif pour le client
Livrer fréquemment une application
fonctionnelle, toutes les deux semaines à deux
mois, avec une tendance pour la période la
plus courte
Les experts métier et les développeurs doivent
collaborer quotidiennement au projet
Bâtissez le projet autour de personnes
motivées. Donnez-leur l'environnement et le
soutien dont elles ont besoin, et croyez en leur
capacité à faire le travail
La méthode la plus efficace pour transmettre
l'information est une conversation en face à
face
9.
10.
11.
12.
Un logiciel fonctionnel est la meilleure
unité de mesure de la progression du projet
Les processus agiles promeuvent un rythme
de développement durable.
Commanditaires, développeurs et
utilisateurs devraient pouvoir maintenir le
rythme indéfiniment
Une attention continue à l'excellence
technique et à la qualité de la conception
améliore l'agilité
La simplicité - l'art de maximiser la quantité
de travail à ne pas faire - est essentielle
Les meilleures architectures, spécifications
et conceptions sont issues d'équipes qui
s'auto-organisent
À intervalle régulier, l'équipe réfléchit aux
moyens de devenir plus efficace, puis
accorde et ajuste son comportement dans
ce sens

8. Méthodes agiles
•
Scrum
–
–
–
•
Extreme Programming (XP)
–
–
•
Méthode inspirée du domaine manufacturier
•
•
•
engagement des équipes de
développement
collaboration avec les clients
plus grande valeur ajoutée
possible
•
•
•
•
Qualité du code
Souplesse du code
Amélioration continue
Élimination du gaspillage
AgileUP
–
•
Méthode agile la plus technique
Pratiques rigoureuses d’ingénierie logicielle
Lean / Kanban
–
•
Méthode agile la plus adoptée
Gestion de projet et gestion des exigences
Peu restrictive mais demande de la rigueur
Adaptation de RUP, la plus prescriptive des méthodes agiles
Crystal
–
Une famille de méthodes adaptées au contexte de l’organisation et à
l’envergure des projets

9. L’approche Scrum: un survol
ScrumMaster
Équipe Scrum
Utilisateurs
Product
Owner
Vision

10. Pourquoi l’agilité?
•
•
•
•
•
•
•
•
Pour satisfaire rapidement le client avec des solutions logicielles
utiles
Pour faire face à la complexité en générant rapidement de la
connaissance
Pour que la qualité soit prise en compte dès le début du projet
Pour rendre visible les inefficacités
Pour éviter les longues périodes de stabilisation en fin de projet
Pour maximiser la collaboration entre tous les intervenants
Pour augmenter la motivation et l’engagement des individus
Pour avoir du plaisir au travail

11. Cartographie des pratiques agiles
Source: Blogue Développement Agile, Le guide des pratiques Agile, Mercredi 7 mars 2012,
http://developpementagile.com/posts/2012/march/le-guide-des-pratiques-agile

12. •
Ce qui n’est pas couvert directement par les
méthodes agiles
Impacts de l’Agilité
au-delà des projets

13. Culture
Gouvernance
Soutien au développement
Architecture
Projets
Infrastructure
technologique
Gestion de
projets
Déploiement
Gestion des individus
Impacts
de
l’Agilité
au-delà
des
projets

14. $
(1 à 4 mois)
(2 à 8 mois)
(6 à 36 mois)
(Durée de vie utile)
$
(2 à 8 mois)
La cible
Transition agile
Le point de départ
Cycle de vie des projets (1er niveau)
(2 à 4 semaines)
(de 2 jours à
4 semaines)
$
(5 à 10 jours)
(2 à 4 semaines)
(1/2 journée)
(<= 1 journée)

15. Quels sont les éléments différents?
•
Méthodologie traditionnelle
–
–
–
–
Améliorations ponctuelles,
parfois rares
Documentation lourde,
dogmatique, peu gérée
Bilans de projet comptables
Cycle de développement
souvent en cascades
Architecture
Analyse
Design
Program.
Test
•
Méthodologie Agile
(Scrum, TDD et/ou XP)
–
–
–
–
Améliorations mensuelles
Documentation réfléchie,
améliorée et gérée
Rétrospectives régulières
Cycle de développement itératif
et incrémental

16. Pratiques non couvertes de l’Agilité
À peu près tout ce qui contient ou sous-entend
le mot « organisationnel »
à
Typiquement en dehors
de la portée des méthodes agiles
•
•
•
•
Processus organisationnel
Gouvernance
Assurance qualité sur des activités organisationnelles
(ex. bureau de projet)
Gestion des individus
Parce que les méthodes agiles sont peu
prescriptives, une organisation a toute la
latitude pour entourer et soutenir ses équipes

17. Pratiques limitrophes (2e niveau)
•
Gestion de projet: reddition de compte
–
•
Architecture: de linéaire à incrémentale
–
•
Adopter une approche et une façon différente de
découper un projet, tant organique que fonctionnel
Déploiements: plus fréquents, à la fin de chaque
itération
–
•
Tenir compte des mesures de progression basées sur du
logiciel fonctionnel
Rendre le processus de déploiement plus efficient
Infrastructure technologique: juste à temps
–
Obtenir les différents environnements dès le début

18. État d’avancement: le Sunset Graph
Projection optimiste : 69 pts avec
une vélocité estimée à 13
pts/itération
70
Cône
d’incertitude
60
Points
50
Catégories du
carnet de
commandes:
Projection pessimiste : 51 pts avec
une vélocité estimée à 7pts/itération
Obligatoire
40
Important
Facultatif
13
30
7
20
10
Catégories des
livraisons :
Obligatoire
Actuel: 30 pts réalisés
10
Important
Facultatif
0
1
2
3
4
Itérations
5
6
7

19. Encadrement (3e niveau)
•
Soutien au développement
–
–
–
–
•
Prodiguer la formation continue sur les nouvelles pratiques
Coacher sur les pratiques agiles
Gérer le processus organisationnel
Obtenir des ressources [matérielles] aux équipes
Gestion des individus: rôles et responsabilités
–
–
–
Identifier et résoudre les dysfonctionnements des équipes
Revoir les descriptions de postes, et peut-être les échelles
de rémunération associées
Impliquer les pairs dans le processus de GRH

20. Performance attendue d’une transition agile:
impact sur les coûts unitaires
Effort
Processus
traditionnel
non amélioré
Processus en
transition
Processus
agile
Taille (PFC)
Amélioration
anticipée
de 20% à 30%
sur les 1ers
projets
Amélioration
potentielle
de 50% + en
± 3 ans

21. Gouvernance (4e niveau)
•
•
Alignement stratégique: ROI plus rapide
Répercussions sur les objets de gouvernance
opé Risqu
rat es
i on
ne l
s
•
Gérer cet enjeu tant du côté affaires que du côté TI
Transformation du rôle de gestionnaire
–
•
et
ôles ités
R
f
il
Af
onsab
resp
Confo
TI
rmité
Ge
Ge
st
cha stion
pr ion
oj
n g e du
et de
me
s
nt
Positionnement de l’imputabilité des affaires
–
•
s
ire
a
Ils ne gèrent plus
les mêmes éléments
avec les mêmes paramètres
Structures organisationnelle et de gouvernance
–
Revoir les matrices RACI
é
it
r
cu
Sé

22. Processus
Possibilités
•
Toute transformation implique la perte des acquis
… pour en gagner d’autres!
–
Gérer le changement est essentiel
Impersonnel
Certaines cultures
se prêtent mieux
que d’autres à l’Agilité
Actualité et réalité
Contenu
•
Personnel
La culture (5e niveau)

23. La gestion du changement –
Ingrédients menant au succès
1- Pression pour changer
2-Vision
3-Capacité à changer
4-Actions
5-Résultats
Compétences
Motivation
Ressources
Plan
d’action
Changement
Compétences
Vision
Motivation
Ressources
Plan
d’action
Confusion
Motivation
Ressources
Plan
d’action
Anxiété
Ressources
Plan
d’action
Changement
graduel
Plan
d’action
Frustration
Vision
Vision
Compétences
Vision
Compétences
Motivation
Vision
Compétences
Motivation
Ressources
Faux départs
Source: adapté de Dolores Ambrose, 1987. Personal Communication.
Ce modèle provient originalement de « The Enterprise Corporation », une firme de consultants qui a cessé d’exister.

24. •
Les activités menant à la qualité
Pratiques liées à l’ACQ
dans les projets agiles

25. Principes et orientations de qualité
1.
2.
3.
4.
La qualité est l'affaire de tous
 rôles et responsabilités
Chaque pratique et livrables du processus doit être
conforme avec ses critères de qualité, soit ses
objectifs à atteindre
 pratiques agiles d’inspection
 pratique du carnet de produit
«Qualité» de nos applications et de nos processus en
tant que critère non négociable
 définition de terminé
L’équipe applique les principes d’amélioration
continue  Rétrospectives

26. 1. Rôles et responsabilités
imputable d’un
carnet de qualité,
du ROI et
de l’acceptation
du produit
responsable des estimations,
de prendre des engagements et
de livrer des résultats
surveille
l’application du
processus agile

27. 2a. Pratiques agiles d’inspection
Mêlée
quotidienne pour
assurer le bon
déroulement de
l’itération
Rétrospective
pour vérifier et
améliorer le
processus de
l’équipe
Tests automatisés
pour
valider la qualité
du produit
à chaque
mouvement de
code
Revue d’itération
pour
valider le dernier
incrément
de logiciel
Pratiques adaptées au cycle de
Verification, Validation, Revue, et Audit

28. 2b. Pratique du carnet de produit
Chaque itération
met en œuvre les
exigences
prioritaires
Chaque nouvelle
exigence est
insérée dans la
liste selon sa
priorité
Il est possible en
tout temps de
changer l’ordre de
priorité des
exigences
Les exigences
peuvent être
supprimées en
tout temps

29. Le carnet de produit (suite)
•
•
Chaque item est un « contrat » entre l’équipe
et le client
Chaque item est un projet en soit:
•
•
•
•
•
Requiert toutes les disciplines, de l’analyse jusqu’au tests
Définit un test d’acceptation
Répond à la définition de terminé
Adapté aux tests automatisés: unitaires et fonctionnels,
parfois intégrés
Ne peut pas être partiellement livré
 qualité « production »

30. La User Story ou scénario utilisateur
•
Comprend 3 éléments:
1.
Un besoin d’affaires en 3 parties
a.
b.
c.
2.
Une description
•.
3.
En tant que <rôle>
Je veux <besoin/fonctionnalité/feature>
Afin de <bénéfices attendus>
Toute l’information jugée utile et nécessaire pour
développer et maintenir le besoin/fonctionnalité
Des conditions de succès
•.
Ce qui sera démontré lors de la revue de sprint et qui
aura été préalablement testé

31. 3. Définition de terminé
•
•
•
•
Entente sur les pratiques de qualité entre le client et l’équipe
La définition de « terminé » devrait s'étendre à toutes les
activités nécessaires à la livraison en production
Le travail qui n'est pas couvert pas la définition de «terminé»
(travail « non terminé ») doit être identifié et porté au carnet
de produit
Tout élément qui ne respecte pas la définition de «terminé»
n'est pas présenté à la revue d’itération

32. Définition de terminé (exemple)
Période
Définition de terminé
Story
•
•
•
•
•
•
•
•
Devis fonctionnel rédigé
Code intégré au gestionnaire de code source
Intégration continue réussie
Tests unitaires écrits et réussis à 100%
Remodelage effectué
Code revu par un pair
Respect des normes IUG
Aucun avertissement lors de la compilation
Itération
•
•
Mêmes éléments que pour la story, plus:
Bilan d’itération publié sur le Wiki
Livraison
•
•
Déployé sur l'espace de pré-production
Répond au plan de Tests de stabilisation (à
préciser)
Procédure de déploiement fonctionnelle et
documentée
Guide utilisateur rédigé au niveau du dernier
incrément
•
•
Phase
•
Déployé sur l'espace de production
Équivalente au
plan qualité
logiciel (SQAP)
en grande
partie!

33. Un produit de
qualité production …
… à chaque itération!

34. Dette technique

35. 4. Rétrospective
•
•
•
•
La rétrospective fait suite à la revue d’itération
Permet à l'équipe de prendre du recul sur l'itération
terminée et le processus de travail
L'équipe s'auto-évalue sur ce qui a bien fonctionné,
ce qu'on doit faire autrement, et les axes
d'amélioration
L’équipe définit des actions pour s'améliorer dès la
prochaine itération

36. •
Défis et enjeux d’une organisation vers
l’Agilité
Discussion et Conclusion

37. Discussion
•
à
Défis et enjeux liés au non-respect des
meilleures pratiques au regard de la qualité et
des risques, quels sont-ils?
Similaires, peu importe que l’équipe soit agile
ou pas:
•
•
•
Processus non suivi  AQ déficiente
Pratiques bâclées de contrôle de la qualité
(vérification)
Pas la bonne personne dans des rôles clés

38. Points à surveiller pour un auditeur
•
Respect de la définition de terminé
–
•
Reddition de compte
–
•
Les résultats sont-ils conformes avec la réalité? Comment s’en est-on
assuré?
Prise en charge des risques par le PO
–
–
–
•
Y a-t-il accumulation d’une dette technique? De quelle valeur?
Est-ce la bonne personne, avec les bonnes connaissances du domaine
d’affaires?
Le contenu et l’ordonnancement du carnet de produit
opérationnalisent la gestion des risques
La conformité et la sécurité ont-elles été prises en charge?
Gestion de la transition à l’Agilité
–
Le changement est-il soutenu adéquatement?

39. Conclusion
•
•
•
Le principe directeur Agile est de livrer le bon produit
fonctionnel, de qualité production, en ligne avec les
objectifs d’affaires et de continuité
Les pratiques agiles offrent de multiples points
d’inspection pour combler les besoins liés à la
gouvernance (gestion de risques) et
à l’amélioration continue
Une transition agile nécessite presque toujours de
l’accompagnement pour réduire les risques liés aux
changements et tendre vers de meilleures pratiques,
tant dans les projets de développement qu’au niveau
de la gouvernance

40. Vos questions
?