Ou la quête de la recette miracle L’agilité dans des projets de grande envergure
Présentation  <ul><li>Objectif </li></ul><ul><ul><li>Démontrer que les grands projets peuvent être agiles et qu’ils en ont...
Les prémisses <ul><li>Oubliez ça! Il n’y a pas de recette! </li></ul><ul><li>Gardez ça simple et stupide (KISS) </li></ul>
C’est quoi un projet d’envergure? <ul><li>Plus de 10 000 jours-personnes? </li></ul><ul><li>Réalisé dans une grande organi...
Quelques exemples <ul><li>Les projets ponts </li></ul><ul><ul><li>Grande complexité </li></ul></ul><ul><ul><li>Planificati...
Quelques exemples <ul><li>Les projets cathédrales </li></ul><ul><ul><li>Durent longtemps </li></ul></ul><ul><ul><li>On pla...
Quelques exemples <ul><li>Les projets pyramides </li></ul><ul><ul><li>Grande complexité de conception </li></ul></ul><ul><...
Quelques exemples <ul><li>GIRES, 200 millions </li></ul><ul><ul><li>Radio-Canada, septembre 2003 </li></ul></ul><ul><li>CS...
La valeur <ul><li>Difficulté de définir la valeur </li></ul><ul><ul><li>Paradoxe de l’eau et du diamant, Adam Smith, 1776 ...
La complexité des projets <ul><li>La technologie </li></ul><ul><ul><li>N-tiers </li></ul></ul><ul><ul><li>3GL </li></ul></...
Traditionnellement Complexité Valeur d’affaires
Où on veut des projets agiles? Complexité Valeur d’affaires
Les livraisons <ul><li>But : Livrer de la valeur souvent </li></ul><ul><ul><li>Radically Simple IT , David M. Upton, Brada...
Les acteurs d’un projet Les affaires Les fournisseurs Les utilisateurs
La gestion du changement <ul><li>Les utilisateurs seront touchés </li></ul><ul><ul><li>Nouvelle version plus souvent, form...
L’engagement de la direction <ul><li>Facteurs d’engagement de la direction </li></ul><ul><ul><li>Leadership </li></ul></ul...
Les rôles et responsabilités <ul><li>Les rôles SCRUM traditionnels </li></ul><ul><li>Les nouveaux rôles hors SCRUM </li></...
Le contrôle <ul><li>« You can’t control what you can’t measure » </li></ul><ul><li>Tom de Marco,  Controlling Software Pro...
La structure des équipes <ul><li>Trois niveaux de structure </li></ul><ul><ul><li>La structure utilisateurs/affaires </li>...
Des équipes à dimension humaine <ul><li>Divide et impera </li></ul><ul><li>Wikipedia : En politique et en sociologie,  div...
La structure des équipes TI
Les comités nécessaires Comité d’arrimage avec les partenaires Comité utilisateur Comité suivi de programme Comité directe...
La structure des équipes TI Les équipes sont responsables de l’architecture et du support de l’environnement
Motivation des ressources Charge de travail Motivation … je crois que la façon la plus sûre de tuer un homme c'est de l'em...
La qualité <ul><li>Il y a un coût à la qualité </li></ul><ul><ul><li>Ressources </li></ul></ul><ul><ul><li>Outils </li></u...
Quoi documenter? Quoi! Documenter!  <ul><li>Habituellement les gros projets se font dans de grandes organisations </li></u...
Documentation légère
Documentation légère
Conclusion <ul><li>« La vitesse est une chose merveilleuse, </li></ul><ul><li>sauf si vous allez dans la mauvaise directio...
Prochain SlideShare
Chargement dans…5
×

L’agilité dans des projets d’envergure

1 578 vues

Publié le

Présentation de Léo Lachance de Pyxis Technologies lors de l'Agile Tour 2009 Québec.

Publié dans : Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 578
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
26
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

L’agilité dans des projets d’envergure

  1. 1. Ou la quête de la recette miracle L’agilité dans des projets de grande envergure
  2. 2. Présentation <ul><li>Objectif </li></ul><ul><ul><li>Démontrer que les grands projets peuvent être agiles et qu’ils en ont besoin </li></ul></ul><ul><li>Qui suis-je? </li></ul><ul><ul><li>Ex-directeur TI d’une compagnie financière </li></ul></ul><ul><ul><li>Projet de 20 000 jours-personnes </li></ul></ul><ul><li>La vraie vie </li></ul><ul><ul><li>Des bonnes pratiques basées sur une expérience vécue </li></ul></ul>
  3. 3. Les prémisses <ul><li>Oubliez ça! Il n’y a pas de recette! </li></ul><ul><li>Gardez ça simple et stupide (KISS) </li></ul>
  4. 4. C’est quoi un projet d’envergure? <ul><li>Plus de 10 000 jours-personnes? </li></ul><ul><li>Réalisé dans une grande organisation? </li></ul><ul><li>Voué à l’échec? </li></ul><ul><li>De plus de 1 000 000$ ? </li></ul><ul><li>Inutile? </li></ul><ul><li>Longgggggggggggggggggggggggg? </li></ul><ul><li>Avec beaucoup de ressources? </li></ul><ul><li>Avec des nouvelles technologies? </li></ul><ul><li>… </li></ul>
  5. 5. Quelques exemples <ul><li>Les projets ponts </li></ul><ul><ul><li>Grande complexité </li></ul></ul><ul><ul><li>Planification hyper-détaillée </li></ul></ul><ul><ul><li>Valeur d’affaires importante </li></ul></ul>
  6. 6. Quelques exemples <ul><li>Les projets cathédrales </li></ul><ul><ul><li>Durent longtemps </li></ul></ul><ul><ul><li>On plante les chênes au départ pour faire des bancs à la fin </li></ul></ul><ul><ul><li>La valeur est produite qu’à la toute fin </li></ul></ul><ul><ul><li>Le résultat final correspond rarement au besoins initiaux </li></ul></ul>
  7. 7. Quelques exemples <ul><li>Les projets pyramides </li></ul><ul><ul><li>Grande complexité de conception </li></ul></ul><ul><ul><li>Valeur discutable </li></ul></ul><ul><ul><li>Mode de construction peu collaboratif </li></ul></ul>
  8. 8. Quelques exemples <ul><li>GIRES, 200 millions </li></ul><ul><ul><li>Radio-Canada, septembre 2003 </li></ul></ul><ul><li>CSST, 30 millions </li></ul><ul><ul><li>La Presse, janvier 2009 </li></ul></ul><ul><li>Carra, 53 millions </li></ul><ul><ul><li>La Presse, mars 2009 </li></ul></ul><ul><li>Dossier de santé du Québec, 178 millions </li></ul><ul><ul><li>MSSS, avril 2009 </li></ul></ul><ul><li>Ontario e-health system, 1 milliard </li></ul><ul><ul><li>National Post, octobre 2009 </li></ul></ul>
  9. 9. La valeur <ul><li>Difficulté de définir la valeur </li></ul><ul><ul><li>Paradoxe de l’eau et du diamant, Adam Smith, 1776 </li></ul></ul><ul><li>La définition de la valeur en économie : </li></ul><ul><ul><li>Utilité dans l’organisation </li></ul></ul><ul><ul><li>Rapport de l’offre et de la demande </li></ul></ul><ul><ul><li>Investissement nécessaire </li></ul></ul><ul><li>La valeur varie selon les projets et est basée sur l’apport à la mission et à la vision de l’organisation (alignement avec les affaires). </li></ul>
  10. 10. La complexité des projets <ul><li>La technologie </li></ul><ul><ul><li>N-tiers </li></ul></ul><ul><ul><li>3GL </li></ul></ul><ul><ul><li>Multiples vendeurs </li></ul></ul><ul><ul><li>Open Source </li></ul></ul><ul><li>Les êtres humains </li></ul><ul><ul><li>Le choc des générations </li></ul></ul><ul><ul><li>Les personnalités </li></ul></ul><ul><ul><li>Les trois « dités » </li></ul></ul>
  11. 11. Traditionnellement Complexité Valeur d’affaires
  12. 12. Où on veut des projets agiles? Complexité Valeur d’affaires
  13. 13. Les livraisons <ul><li>But : Livrer de la valeur souvent </li></ul><ul><ul><li>Radically Simple IT , David M. Upton, Bradaly R. Staats, Harvard Business Review, Article R0830J </li></ul></ul><ul><li>Mais : Livrer souvent a des impacts sur : </li></ul><ul><ul><li>Les utilisateurs (essais continus, présence constante, rétroaction rapide, …); </li></ul></ul><ul><ul><li>Les développeurs (intégration continue, humilité, rigueur,…); </li></ul></ul><ul><ul><li>Les affaires (nouveaux indicateurs de gestion, perte du sentiment de contrôle, …); </li></ul></ul><ul><ul><li>Les fournisseurs TI : infrastructures, support, DBA, orientations technologiques,… </li></ul></ul>
  14. 14. Les acteurs d’un projet Les affaires Les fournisseurs Les utilisateurs
  15. 15. La gestion du changement <ul><li>Les utilisateurs seront touchés </li></ul><ul><ul><li>Nouvelle version plus souvent, formation adaptation des processus d’affaires plus rapide </li></ul></ul><ul><ul><li>Les former sur l’Agilité </li></ul></ul><ul><ul><li>Éviter le clivage – informatique – utilisateurs - affaires </li></ul></ul><ul><li>Les TI seront touchées </li></ul><ul><ul><li>Ne pas l’oublier </li></ul></ul><ul><ul><li>Le rôle des gestionnaires </li></ul></ul><ul><li>Ça prend : </li></ul><ul><ul><li>Une volonté de la direction (engagement); </li></ul></ul><ul><ul><li>Une équipe ou une personne dédiée à la gestion du changement. </li></ul></ul>
  16. 16. L’engagement de la direction <ul><li>Facteurs d’engagement de la direction </li></ul><ul><ul><li>Leadership </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Implication </li></ul></ul><ul><ul><li>Adhésion </li></ul></ul><ul><ul><li>Confiance </li></ul></ul><ul><li>Concrètement </li></ul><ul><ul><li>Donner les moyens aux équipes </li></ul></ul><ul><ul><ul><li>Aménagement adaptée </li></ul></ul></ul><ul><ul><ul><li>Formations </li></ul></ul></ul><ul><ul><ul><li>Technologies (vidéo conférence, écrans, post-it, salles pour démo…) </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><li>S’intéresser à l’Agilité (en faire la promotion) </li></ul></ul><ul><ul><li>Célébrer le succès </li></ul></ul>
  17. 17. Les rôles et responsabilités <ul><li>Les rôles SCRUM traditionnels </li></ul><ul><li>Les nouveaux rôles hors SCRUM </li></ul><ul><ul><li>Liés au scrum de scrum </li></ul></ul><ul><ul><li>Liés à la gestion de projet </li></ul></ul><ul><ul><li>Reddition de compte </li></ul></ul><ul><ul><li>Coordination </li></ul></ul><ul><li>Hiérarchie – Pouvoir - Responsabilisation </li></ul><ul><ul><li>Favoriser le leadership </li></ul></ul><ul><ul><li>Attention aux rôles de gestion à des gens innovants (principe de Peter, 3M) </li></ul></ul><ul><ul><li>Attention au contrôle </li></ul></ul>
  18. 18. Le contrôle <ul><li>« You can’t control what you can’t measure » </li></ul><ul><li>Tom de Marco, Controlling Software Projects: Management, Measurement, and Estimation, Prentice Hall/Yourdon Press, 1982 </li></ul><ul><li>«  Implicit in the quote is that control is an important aspect, maybe the most important, of any software project. But it isn’t. » … «  Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go. » </li></ul><ul><li>- Tom de Marco , Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009 </li></ul>
  19. 19. La structure des équipes <ul><li>Trois niveaux de structure </li></ul><ul><ul><li>La structure utilisateurs/affaires </li></ul></ul><ul><ul><li>La structure de projet </li></ul></ul><ul><ul><li>La structure de l’équipe de développement </li></ul></ul><ul><li>La structure doit être comprise de tous </li></ul><ul><ul><li>Communiquée à tous les niveaux – attention à la « réunionite aiguë » </li></ul></ul><ul><ul><li>À garder simple à tous les niveaux </li></ul></ul>
  20. 20. Des équipes à dimension humaine <ul><li>Divide et impera </li></ul><ul><li>Wikipedia : En politique et en sociologie, diviser pour régner </li></ul><ul><li>est une stratégie gagnante visant à réduire des concentrations </li></ul><ul><li>de pouvoir en éléments qui, pris individuellement, </li></ul><ul><li>ont moins de puissance que celui qui implémente la stratégie. </li></ul><ul><li>Le Petit Robert : Créer des rivalités, des discordes entre ceux </li></ul><ul><li>qu'on gouverne, qu'on dirige, afin qu'ils ne s'unissent </li></ul><ul><li>pas contre le dominateur. </li></ul>
  21. 21. La structure des équipes TI
  22. 22. Les comités nécessaires Comité d’arrimage avec les partenaires Comité utilisateur Comité suivi de programme Comité directeur du projet Comité organique Comité d’arrimage technologique Comité de suivi en projet Scrum de scrum Comité de gestion du changement Comité de formation Comité d’architecture fonctionnelle
  23. 23. La structure des équipes TI Les équipes sont responsables de l’architecture et du support de l’environnement
  24. 24. Motivation des ressources Charge de travail Motivation … je crois que la façon la plus sûre de tuer un homme c'est de l'empêcher de travailler en lui donnant de l'argent. – Félix Leclerc
  25. 25. La qualité <ul><li>Il y a un coût à la qualité </li></ul><ul><ul><li>Ressources </li></ul></ul><ul><ul><li>Outils </li></ul></ul><ul><ul><li>Processus </li></ul></ul><ul><li>Selon l’équipe TI </li></ul><ul><ul><li>Équipe dédiée </li></ul></ul><ul><ul><li>Intégrée aux équipes </li></ul></ul><ul><ul><li>Coordination avec les utilisateurs </li></ul></ul><ul><li>Il y a un coût à ne pas faire de qualité </li></ul><ul><ul><li>Beaucoup plus élevé </li></ul></ul>The biggest defect we have now [in software development] is tolerating defects - Mary Poppendieck
  26. 26. Quoi documenter? Quoi! Documenter! <ul><li>Habituellement les gros projets se font dans de grandes organisations </li></ul><ul><ul><li>Il y a déjà une culture de documentation </li></ul></ul><ul><ul><li>Des rôles existent déjà en ce sens </li></ul></ul><ul><li>Livrer du code fonctionnel avant la documentation </li></ul><ul><ul><li>Agilité et documentation ne sont pas incompatibles </li></ul></ul><ul><ul><li>On peut faire autre chose que du code de façon agile </li></ul></ul>
  27. 27. Documentation légère
  28. 28. Documentation légère
  29. 29. Conclusion <ul><li>« La vitesse est une chose merveilleuse, </li></ul><ul><li>sauf si vous allez dans la mauvaise direction. »* </li></ul><ul><li>* The value habit (A practical guide to creating value), Deloitte Development, Deloitte Touche Tohmatsu </li></ul>

×