Your SlideShare is downloading. ×
0
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
l'Agilité dans les projets Envergure Mtl
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

l'Agilité dans les projets Envergure Mtl

2,342

Published on

La présentation démontre que les grands projets peuvent être Agile et qu’ils en ont besoin ! …

La présentation démontre que les grands projets peuvent être Agile et qu’ils en ont besoin !

Présentation faite sur l'Agile Tour à Montréal le 27 octobre 2009.
Retrouvez la biographie de Léo et plus d'informations et des photos sur www.SeDevelopperAgilement.com

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,342
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

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
  • Compagne d’assurance, que je ne peux pas nommer, siège social à Québec, pas à Lévis, SSQue vous avez deviné?La vraie vie - Faire mon acte d’humilité
  • Puisque ça m’a pris une demi heure à dessiner le premier logo, j’y ai été au plus simple pour le suivant.
  • Avant toutExpliquer qu’on va essayer de déterminer ce qu’est un projet d’envergure. Un gros projet.Ce qui est écrit est vrai mais - ça peut varier d’une entreprise à l’autre : gros pour un peut être petit pour une autre
  • Souligner l’aspect itératif de ce projet
  • Complexité de conception du à l’avant-gardisme et aux outils disponibles.Mode de construction basé sur l’esclavage et la dictature (pendant que les esclavestravaillaient, le roiétaitdansuneorgie)
  • Des exemples plus contemporains en informatiqueEst-ce que ce sont des projets ponts, des projets cathédrales ou des projets pyramides? Pas de réponse.Ce qui ressort ici, c’est le montant. On dirait que c’est là-dessus qu’on détermine si c’est gros ou pas. Mais a-t-on raison?
  • Exemple : Pour une entreprise dans le domaine manufacturier, un projet de développement d’un outil de suivi de la production à plus de valeur qu’un outil de gestion de la documentation.Ce qu’il faut retenir c’est que la valeur est relative à l’utilitéOn se donne ici une définitiion, question de finir la présentation dans les tempsParler de l’alignement avec les affaires p/r Cobit
  • La stupidité, oui ça existe, il y a des gens stupides. Crétin, abruti, borné, atteint d’itertie mentale, faire des choses absurdes, insensées,… JE vois des gens réagir, ça m’inquiète. Les gens stupides ne savent pas qu’ils le sont et sont surpris d’apprendre que ça existe.La cupidité. Ce sont ceux qui veulent que ça marche à tout prix. Souvent les gestionnaires. Souvent pas pour les bonnes raisons, je parle ici de l’argent. Ce sont ceux pour qui tout est facile. Attention…Les crudités, ce sont les légumes. Ceux qui ne font rien. À part le vent, il ne semble pas se mouvoir d’eux-mêmes. Il ne faut pas les laisser détruire le climat. Mettez-les
  • Même si vous avez une belle structure et des beaux comités pour gérer les impacts sur toutes ces personnes, ils ont besoin d’être préparer. Pour ce faire, c’est la gestion du changement.
  • Les affaires : la direction, ceux pour qui on livre de la valeur reliée à la missionLes utilisateurs : ceux qui ont les mains dans la graisse de char, c’est-à-dire ceux qui sont dans le quotidien, dans l’opérationnelLes fournisseurs : C’est un triangle : Les rôles et responsabilités doivent être fait en fonction d’une relation entre tous ces points. Par exemple :Les fournisseurs doivent évidemment se soucier des utilisateurs, mais aussi des affaires à qui on livre de la valeurLes utilisateurs doivent travailler avec les fournissseurs pour bien exprimer le besoin mais aussi s’assurer que c’est en ligne avec la volonté des affaires- Les affaires doivent interagir avec les utilisateurs pour avec un feedback de ce qui se passe d’un point de vue opérationnel avec le nouveau système, les affaires doivent aussi maintenir un avec les fournisseurs (même si ça ne les intéressent peut-être pas, car ils doivent connaître le point de vue TI et s’y intéresser.
  • Là où il y a des impacts
  • Comment s’engager dans une hiérarchieParler du leadership, sortir éléments du livre de Melchers
  • Mon exemple de directeur de département qui animait des SCRUM au départÇa prend de bons gestionnaires (RH)Gérer le changementGérer les conflitsGérer les attentesLa structure mettre en place se doit de contrôler les bonnes choses.
  • Dans le passé, on disait qu’il fallait mesurer pour contrôler.Aujourd’hui, on constate que cette approche n’est pas la bonne.Tom deMarco, dans un acte d’humilité, le dit dans son article : le conseil n’était pas approprié à l’époque, il ne l’est pas plus aujourd’hui et les métriques ne sont pas un gage de succès des projets.Les métriques coûtent argent et temps et doivent être utilisés avec modérationLe développement logiciel est différent des sciences pures telles la PhysiqueLien avec valeur et complexité.Prenons les exemples de projets ponts, cathédrales et pyramidesUn projet qui coûte 1 million et qui rapporte une valeur de 1.1 million versus un projet de 1 million avec valeur de 50 millionsLe contrôle est important pour le premier pas pour le deuxièmeOn peut en déduire que le contrôle est important sur les projets cabanons ou les projets pyramidesIl faut réduire nos attentes face au contrôle possibleComment gérer un projet sans le contrôler?Il faut gérer les gens et contrôler le temps et l’argent.
  • Les niveaux pour la structure sont ceux qu’on voit le plus souvent dans les grandes organisations à mon avis.Comment savoir si c’est assez simple : avant de communiquer la structure à tout le monde faites-vous valider par quelqu’un qui ne comprend habituellement rien, idéalement un gestionnaire. Si vous n’en trouvez pas, il y a toujours les politiciens, faciles à trouver sur les pancartes ces jours-ci. Mais attention, il pourrait vous dire qu’ils comprennent même si c’est pas le cas.Structure pour projet de 6 personnesEst différentStructure pour projet de 24 personnesOn va parler surtout de la structure de projet pour l’équipe de développement
  • L’erreur est souvent faite de diviser en petite équipe pour les mauvaises raisons. Il faut diviser les équipes pour favoriser la communication, il faut leur donner les moyens d’interagir au maximum – idéalement en étant physiquement au même endroit, sinon en ayant des moyens technologiques adéquats.
  • L’erreur est souvent faite de diviser en petite équipe pour les mauvaises raisonsOn contrôle l’argent et le temps, on gère les humainsIl y a différentes façons de gérer les humaines hierarchie, collaborativement, etc.Le graphique ci-dessus ne fit pas avec l’approche contrôle argent et tempsSi on tient compte de l’utilisateur et des affaires et de la coordonation
  • L’erreur est souvent faite de diviser en petite équipe pour les mauvaises raisonsOn contrôle l’argent et le temps, on gère les humainsIl y a différentes façons de gérer les humaines hierarchie, collaborativement, etc.Le graphique ci-dessus ne fit pas avec l’approche contrôle argent et temps
  • La structure doit permettre d’éviter les bottleneck (équipe de qui dépend les autres), La structure des équipes est en fonction du projet, il n’y a pas de recette. Le leader du projet se doit de garder les ressources motivées.
  • Poppendieck said that that “the biggest defect we have now [in software development] is tolerating defects”. She advised treating each failure (defect that escaped) as a learning opportunity. Determining the root cause of the failure and eliminating it so that the defect does not reappear in the future is the way forward.
  • Le gestionnaire demande « Quoi documenter? »Le développeur dit « Quoi! Documenter! »
  • Pas une méthode à appliquer, une philosophie à adopter (je ne pense pas l’avoir parfaitement appliquer jusqu’à présent)
  • Transcript

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

    ×