Partage d'un bel exemple de ce que l'adoption de l'Agilité peut apporter à une organisation, au-delà de la simple utilisation de Scrum. En particulier, sa présentation porte sur les pratiques mises en place à la Société immobilière du Québec (SIQ) dans un contexte d'équipes nombreuses : - la définition de la portée par les processus d'affaires; - la planification du développement avec les cas d'utilisation; - l'établissement d'un cadre méthodologique Agile; - la qualification des exigences fonctionnelles par des tests automatisés (BDD). La présentation s'adresse à n'importe quelle personne qui veut des exemples d'une transition réussie ou qui souhaite découvrir le potentiel de l'Agilité.

1. La revue
d'itération
intégrée…
Et autres fabuleuses pratiques
Agiles adaptées au contexte
de la SIQ
Agile Tour Ottawa / Gatineau
28 novembre 2012

2. Société Immobilière de Québec (SIQ)
• Gestion du parc immobilier des ministères et
organismes publics;
• 5,5 millions de mètres carrés d’espaces
répartis;
• Plus de 1300 édifices en propriété et location.

3. , c’est plus de 12 ans en
formation, accompagnement et développement
Agile :
Collaborateurs passionnés;
Montréal, Québec, Genève (Suisse);
Plus de 200 clients.

4. Qui sommes-nous?
Guy Rochette (grochette@siq.gouv.qc.ca)
•Directeur général des TI à la SIQ.
Mathieu Boisvert (mboisvert@pyxis-tech.com)
•Architecte fonctionnel agile à la SIQ;
•Coach agile à Pyxis;
•Chargé de cours à l’UQAM;
•Co-Auteur du livre Choisir l’agilité.

5. Contexte

6. Le programme de modernisation
• Architecture actuelle manquant de cohérence:
44 systèmes différents;
• Infrastructure désuète;
• Information de gestion déficiente: qualité des
données compromises sans des sources
uniques et fiables.

7. Enjeux
• Livrer dans le budget et les temps:
– Nouvelle phase chaque année pendant 6 ans;
• Projet capital:
– 11 000 j/h en 2011 sur 19 000 j/h planifiés en 2011,
35 ressources TI, 15 ressources affaires;
• Nouvelles technologies:
– Web et .NET;
• Nouveau processus de développement:
– Scrum, XP et Agile UP.

8. Pourquoi Agile?
• Bâtir le meilleur logiciel possible dans les ressources
disponibles;
• Valeurs humaines enlignées avec la vision des
gestionnaires;
• Hypothèse que le coût total de développement sera
moins élevé.

9. Démarrage de
la transition

10. Manifeste comme système de valeurs
pour la SIQ
• le logiciel fonctionnel est la meilleure façon de
mesurer l’état d’avancement;
• les conversations sont plus importantes que les
processus en place, et;
• accepter les changements, selon le contexte, est plus
utile que le suivi d’un plan rigide.

11. Défis de l’adoption de la méthode SCRUM
• Livrer un nouvel incrément à tous les mois;
• Documenter de manière incrémentale;
• Découvrir le rôle du responsable de produit: cadence
difficile pour les experts affaires;
• Apprivoiser les pratiques agiles, comme
l’engagement et la définition de terminé.

12. Rédaction d’un cadre méthodologique
• Pour évaluer les incidences sur l’organisation;
• Servir de base au matériel de formation: introduction
au processus, introduction au rôle de responsable de
produit;
• Assurer la pérennité des façons de faire;

13. Vue d’ensemble de l’organisation

14. Cadre méthodologique – Vue Globale

15. Cadre méthodologique - Détail

16. Gestion de
produit

17. Défis du développement d’une solution
intégrée
• Livrer une solution intégrée et fonctionnelle à toutes les
itérations;
• Résoudre les dépendances entre les carnets de produit
des différents domaines d’affaires;
• Coordonner le développement des liens inter-système;
• Maîtriser les pratiques de développement logiciel XP.

18. Nouvelle relation avec les unités d’affaires
• Expert affaires: Implication des directeurs immobiliers et
propriétaires de processus aux démarrage de chaque phase;
• Responsable de produit (RP) : Des employés d’expérience par
équipe;
• Coordonnateur des RP: Un directeur soutien à l’exploitation
pour coordonner la planification de haut niveau;
• Une démonstration à chacune des itérations au reste à
l’organisation (affaires et TI) .

19. Stratégie pour livrer un système utile
Comprendre les processus
d’affaires et leurs liens
Identifier les événements de
vie et rédaction des cas
d’utilisation
Fixer la priorité des éléments des
carnets de produit
19

20. Planification intégrée entre plusieurs équipes
Processus d’affaire
Coordonnateur
responsable de
la vision
systémique
Les carnets
découlent
Projet A Projet B Projet C
des
RP et RP et RP et
processus
son équipe son équipe son équipe d’affaires
20

21. Exemple d’un cas d’utilisation
Description du cas d’utilisation
Projet mineur en construction de 15000$ en gré à gré en réparation majeure.
Ordre Id de l’activité / Nom processus Intrants Extrants Remarques et descriptions
Nom de l’activité du processus
1 CB1- Projet +/- 100k --- ---
Réparation majeur / Amélioration
2 CB3- Créer un contrat Données relatives aux ---
contrats
3 CB4 - Choix du mode de sollicitation --- --- Gré-à-Gré
4 CB5 - Autorisation choix du Vérifier licence Demande d'exception aux règles
fournisseur d'attribution de contrat
5 CB7 - Saisir résultats --- nom fournisseur + montant
6 CB9 - Adjuger le contrat ? Oui- Cocher M3- Contrat publié dans SEAO
l'adjudicataire
7 CB10 - Inscrire garanties, assurances Inscrire licence ---
et licences
8 CB11 - Émettre le contrat Inscrire Date signature + Commande d'exécution Bloquer la CE
nom signataire
9 PD- Réalisation des travaux Processus Parallèle : PD-CP1 à PD-CP4
21

22. La fabuleuse revue d'itération
intégrée !

23. Reddition de
compte

24. Suivi du projet •Pour l’ensemble des projets
• Indices de performance des coûts et des
délais
• Sun Set Graph agrégé
• Suivi de la livraison des fonctionnalités
Programme selon les points d’efforts estimés pour
l’ensemble des projets
•Indicateurs traditionnels (faits, saillants, coûts,
Projet demandes de changement, points en suspens
et gestion des risques)
•Indices de performance des coûts et des délais
Itération •Sun Set Graph
•Parking Graph
•Suivi de la livraison des fonctionnalités selon les
points d’efforts estimés
•Indicateurs traditionnels (Faits
saillants, coûts, demandes de
changement, points en suspens et gestion des
risques)
•Carnet de commande
•Stories et les tâches sont décrites et suivies
dans un outil (URBAN TURTLE)
•Burndown
•Bilan de l’itération

25. Suivi de l’Itération
Carnet de Graphique
l’itération d’avancement
(Burndown)
Bilan de
l’itération

26. Suivi du projet - SunSet Graph

27. Suivi du projet – cas d’utilisation (Parking Graph)

28. Reddition de compte – Programme ou projet
Suivi de la livraison selon les
points d’efforts estimés
Faits DDC
saillants Points en suspens
Risques

29. Reddition de compte (suite)
Indicateurs Sunset Graph
Budget restant agrégé
traditionnels

30. Reddition de compte (suite)

31. Dynamique de
groupe

32. Dynamique des équipes
Analyste
organique
Développeurs Scrum Master
Équipe
Analyste Responsable
fonctionnel de produit

33. Dynamique de gestion
Coordonnateur
des
Architectes
responsables
de produit
Coordonateur
Bureau de
des Scrum
projet
Masters
Équipes

34. Mécanismes décisionnels
Règlements des points en suspens
•Lorsque la vision
Niveau Comité
Directeur
nécessite des
stratégique clarifications, le point est
(décisionnel) soulevé au
coordonnateur des
responsables de produits
Registre points
en suspens (CRP) ou à l’architecte
fonctionnel (AF)
Niveau
Chef de •Si le point n’est pas résolu rapidement
tactique Directeur
Projet projets TI et nécessite une recherche ou de le
(vision)
documenter, un point en suspens est
Comité architecture soulevé par le CRP ou l’AF
•Le point est adressé à la personne
ayant la responsabilité ou les
connaissances requises pour apporter
Niveau Scrum une solution rapidement et selon le délai
opérationnel Coordonnateur
de Scrum requis; si le point n’est pas résolu en
des RP
(réalisation) Comité intégration temps opportun, le CRP ou l’AF fera une
interprocessus proposition au comité d’architecture
•Le comité d’architecture fait un suivi
Rencontre hebdomadaire des points en suspens et
organique s’il n’y a pas consensus, le point est
Équipes de amené au comité directeur pour
réalisation décision

35. Pratiques
agiles

36. Culture du test et de développement
• Nouvelles pratiques d’ingénierie et de
programmation (orienté-objet, mock, services,
composant web)
• Intégration à tous les mois
• Apprentissage du TDD (test-driven
development) et BDD (behavior-driven
development)

37. Implantation d’un serveur d’intégration continue

38. Conclusion

39. Conclusion
• Adaptez l’Agilité à la culture de votre organisation
• Implantez l’Agilité par palier
• Faites-vous appuyer pendant la transition
• Pensez, dans le contexte multi-projets, à implanter rapidement,
les moyens permettant la collaboration entre les équipes
• Mettez en place une structure qui permet de régler rapidement
les points en suspens
• Pensez à adapter votre message, surtout en reddition de compte,
aux différentes catégories de personnes qui le reçoivent
• Adaptez votre style de gestion afin de ne pas faire d’ingérence
tout en étant proche des équipes et informé
• Évitez de prendre les crises à la légère.
• Pensez à la pérennité

40. Questions?