l'Agilité dans les projets Envergure Mtl
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,279 vues
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
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à l'Agilité dans les projets Envergure Mtl
Similaire à l'Agilité dans les projets Envergure Mtl (20)
Plus de Pyxis Technologies
Plus de Pyxis Technologies (20)
l'Agilité dans les projets Envergure Mtl
- 1. L’agilité dans des projets de grande envergure Ou la quête de la recette miracle SeDevelopperAgilement.com
- 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 2
- 3. Les prémisses Oubliez ça! Il n’y a pas de recette! Gardez ça simple et stupide (KISS) PAS DE RECETTE 3
- 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? … 4
- 5. Quelques exemples Les projets ponts Grande complexité Planification hyper-détaillée Valeur d’affaires importante 5
- 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 6
- 7. Quelques exemples Les projets pyramides Grande complexité de conception Valeur discutable Mode de construction peu collaboratif 7
- 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 8
- 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). 9
- 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 » 10
- 11. Traditionnellement Valeur d’affaires Projets Agiles PAS DE RECETTE Complexité 11
- 12. Où on veut des projets agiles? Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Valeur d’affaires Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Projets Agiles Complexité 12
- 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,… 13
- 14. Les acteurs d’un projet Les affaires Les fournisseurs Les utilisateurs 14
- 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. 15
- 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 Leadership 16
- 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 PAS DE RECETTE 17
- 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 PAS DE RECETTE 19
- 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. 20
- 21. La structure des équipes TI Comité d’arrimage avec les partenaires Comité d’arrimage technologique Comité organique Comité de formation Comité utilisateur Scrum de scrum Comité de suivi en projet Comité suivi de programme Comité d’architecture fonctionnelle PAS DE RECETTE Comité de gestion du changement Comité directeur du projet 21
- 22. La structure des équipes TI Les équipes sont responsables de l’architecture et du support de l’environnement 22
- 23. Motivation des ressources Motivation Charge de travail …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 23
- 24. 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 biggestdefectwe have now [in software development] istoleratingdefects - Mary Poppendieck 24
- 25. 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 25
- 26. Documentation légère PAS DE RECETTE 26
- 28. Conclusion « La vitesse est une chose merveilleuse, sauf si vous allez dans la mauvaise direction. »* * The value habit (A practical guide to creating value), DeloitteDevelopment, Deloitte Touche Tohmatsu 28
Notes de l'éditeur
- 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)