L’agilité dans des projets d’envergure
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

L’agilité dans des projets d’envergure

  • 1,737 views
Uploaded on

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

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

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,737
On Slideshare
1,736
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 1

http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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