Estimer les projets TI, même en Agile
•Télécharger en tant que PPTX, PDF•
3 j'aime•2,263 vues
Présentation de Renaud Poirier et Frédéric Paquet présenté dans le cadre du Collogue PMI LÉVIS-QUÉBEC les 25 et 26 avril 2017
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Estimer les projets TI, même en Agile
Similaire à Estimer les projets TI, même en Agile (20)
Plus de CGI Québec Formation
Plus de CGI Québec Formation (20)
Estimer les projets TI, même en Agile
- 1. Colloque en gestion de projet 2017 1 Estimer les projets TI, même en Agile Frédéric Paquet et Renaud Poirier
- 2. Colloque en gestion de projet 2017 2 Estimer les projets TI, en AGILE ? #NOESTIMATEESSENTIEL
- 3. Colloque en gestion de projet 2017 3 Vos conférenciers Frédéric Paquet – Chef de projet – Coach Agile / CDA – fpaquet@facilite.com Renaud Poirier – Architecte – Macroscope / Agile CDA – rpoirier@facilite.com
- 4. Colloque en gestion de projet 2017 4 Pourquoi estimer, même en Agile • Autoriser le démarrage d’un projet sans une estimation, même grossière ? NON, mais … • Agenda : – Pourquoi et quand estimer ? – Estimer l’envergure d’une solution (avant-projets) – Estimer l’architecture d’une solution (démarrage de projet) – Trucs réutilisables (du cascade à l’Agile)
- 5. Colloque en gestion de projet 2017 5 Une estimation est « nécessaire » si … • Projet … vs Produit vs Maintenance • Envergure … vs Capacité vs Fournisseur externe • Gestion du Risque et des Budgets (relatifs) Attention de balancer les niveaux de précision, de risque et de temps en fonction du contexte
- 6. Colloque en gestion de projet 2017 6 Estimations itératives / Niveau de détail • Quatre niveaux de découpage • Quatre niveaux d’estimation • Quatre objectifs Temps Envergure du projet 1 Estimation du budget global Dates 2 Planification des livraisons 3 Points d’efforts Préparation des 3 premières itérations Tâches estimées en heures 4
- 7. Colloque en gestion de projet 2017 7 Stratégie de financement https://disciplinedagileconsortium.org Coût + Temps et matériel Financement par jalon Prix / Coût fixe
- 8. Colloque en gestion de projet 2017 8 Estimer l’envergure d’une solution • Quand ? • Comment ? – Blocs fonctionnels et Scénarios d’utilisation – Coûts de réalisation vs d’opportunité – Comparables vs expériences des « évaluateurs » – Pas plus bas de 100jp
- 9. Colloque en gestion de projet 2017 9 Concevoir … pour tester, utiliser et « aimer » le plus rapidement possible http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp#more-7646 Produit peut être testé Produit peut être utilisé Produit est aimé Visez le ciel … Mais livrez en petites étapes
- 10. Colloque en gestion de projet 2017 10 Anticipation vs Adaptation • Planification à l’avance • Architecture détaillée en amont (BDUF) • Tests à la fin • Spécifications complètes en amont • Planification JAJAT (juste assez, juste à temps) • Spécifications JAJAT • Architecture émergente • Tests intégrés • Discussions collaboratives Source: Mike Cohn - https://www.mountaingoatsoftware.com/blog/balancing-anticipation-and-adaptation
- 11. Colloque en gestion de projet 2017 11 Estimer l’envergure d’une solution • Ne pas oublier que même en Agile – Impact des contributeurs à un projet – Effet des intégrations et du temps • Sauf que le « projet » n’est pas le seul véhicule pour livrer du logiciel
- 12. Colloque en gestion de projet 2017 12 Architecte Leader Facilitateur
- 13. Colloque en gestion de projet 2017 13 Estimer l’architecture d’une solution • Une vision plutôt que des plans et devis – Juste assez pour estimer et orienter – Sans se perdre dans la technique et la documentation • Préparer un carnet de commandes – Attention au niveau de détail – Fonction des risques d’intégration et de l’horizon de temps
- 14. Colloque en gestion de projet 2017 14 Estimer le coût de la vision (solution) • Évaluer des blocs de fonctionnalités, les mandats des contributeurs ou le travail d’une équipe – Impliquer des gens d’expérience – Impliquer ceux qui le feront vraiment – S’appuyer sur du vécu « partagé » • Évaluer les items d’un carnet – À géométrie variable dans le temps (par jalon) – En restant Agile face aux changements
- 15. Colloque en gestion de projet 2017 15 Cône d’incertitude LivraisonRéalisation Dossier d’Affaires Opportunité Attention aux promesses faites ici Attendez d’avoir la chance de stabiliser les risques Restez toujours ouvert aux opportunités Estimationvsvariabilité Temps
- 16. Colloque en gestion de projet 2017 16 L’évaluation et les biais cognitifs http://dispatchist.com/mind-hacks-cognitive-bias/ • Biais d’ancrage • Biais de confirmation • L’effet Dunning- Kruger • L’illusion de savoir
- 17. Colloque en gestion de projet 2017 17 Le meilleur de chaque approche • Décomposer jusqu’à un niveau « estimable » – Avec des comparatifs communs / ou des barèmes • Comparer les résultats de deux approches – Vive la convergence – Monitorer et approfondir les écarts lors du développement • Se concentrer sur l’effort de réalisation !!!
- 18. Colloque en gestion de projet 2017 18 Quelques trucs à réutiliser • Pourquoi et quand se passer des estimés ? • Étaler le risque et l’attribution du budget – De la conception à la livraison • Initier les preuves de concepts au plus vite – Investigations ou « spikes »
- 19. Colloque en gestion de projet 2017 19 Références et liens utiles • //excellenceagile.com • //blog.goood.pro/2014/07/25/developper-sans-faire-destimation-le-mouvement- noestimates • //www.infoq.com/news/2016/09/estimation-techniques-psychology • //www.qsm.com/articles/big-rock-estimation-using-agile-techniques-provide- rough-software-schedule-resource?utm=gcaccess • Gestion de projet 3.0 • https://disciplinedagileconsortium.org • http://dispatchist.com/mind-hacks-cognitive-bias/ • https://www.mountaingoatsoftware.com/blog/balancing-anticipation-and- adaptation • http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp#more-7646 Il n’est pas requis de se « saigner » pour estimer de façon « Agile »
- 20. Colloque en gestion de projet 2017 20 Cette présentation sera disponible sur le site web du PMI Lévis-Québec à compter du 1er mai 2017
Notes de l'éditeur
- Aucun gestionnaire sensé n’autoriserait le démarrage d’un projet sans une estimation, même grossière, des travaux à réaliser. Même en agile, cette prémisse demeure. Mais comment estimer un projet TI sans préalablement en faire une architecture détaillée? Pourquoi et quand estimer Le bon, la brute et le truand : Confrontation de culture (sans intro) Renaud – Architecte Macroscope – me permet de … Fred – Coach agile no-estimate – me permet de … Laisser émerger un compromis Vers le balancier selon le contexte Produit vs projet vs maintenance Envergure vs capacité Gestion du risque et des budgets (relatifs)
- on s’introduit (pluger Martin et sa formation)
- Aucun gestionnaire sensé n’autoriserait le démarrage d’un projet sans une estimation, même grossière, des travaux à réaliser. Même en agile, cette prémisse demeure. Mais comment estimer un projet TI sans préalablement en faire une architecture détaillée? La conférence propose quelques techniques pour estimer les projets TI, fonction du niveau de compréhension de la solution à mettre en place, s’appuyant en cela sur des acquis solides et du vécu en projet Agile. La conférence se structure en quatre temps : Message d’intro de la conférence
- Estimer l’envergure d’une solution (opportunité, dossier d’affaires, budgets) No project : beaucoup d’effort pour partir, trop lourd pour le faire tendre Met parfois en danger l’intégration et la vue plus large
- Démarche des Blocs fonctionnels (TI) vs Scénario d’utilisation (Affaires) Avec un exemple, dont certaines fonctionnalités qu’on n’a pas (ex. générateur de rapports) Important : bloc de dollars coûts vs bénéfices avec gestion de l’imprécision et du risque par bloc incluant le coût de ne pas avoir la patente et celui d’opportunité (bénéfices vs coûts) : ce que je perds de ne pas l’avoir Comparables vs expériences des « évaluateurs » : pif / + ou – Minimum viable par jalon : livrer une version 0.3 testable, mais qui n’ira pas en prod, ou pourrait être déployer (nouveau produit) si le besoin est pressant livrer une version 0.8 utilisable, qui va en prod même si pas chick livrer une version 1.0 indispensable, qui répond au besoin Effets du modèle de réalisation
- Objectif(s) Comprendre la nuance entre MVP et plus rapidement testable, utilisable et appréciable À retenir On veut avoir du FEEDBACK le plus rapidement possible et valider nos hypothèses Discussions Quels seront les défis d’une telle approche?
- On cherche à s’adapter plus qu’a anticiper, mais cela ne veut pas dire que rien ne va être fait en amont… Plan macro au début, le plan se detail en cours de route L’architectures doit être pensée, mais il n’est pas souhaitable d’avoir tous les éléments d’architectures dès le depart On peu établir une stratégie de test au depart
- Impact des contributeurs à un projet Effet des intégrations Effet de la compétition des équipes / les triangles de chaque chargé de projet SAFE : Éviter les trous entre les triangles Gantt détaillé vs enveloppe budgétaire … tout en challengeant notre capacité
- Attention danger : Estimation détaillée vs spécifications trop détaillées ex. forfait ou engagement de budgets non négociable sans se perdre dans les specs Documentation de soutien : la modération a meilleur goût (permanent vs temporaire) Utiliser les facteurs de risques et de contexte pour nuancer notre estimé Ex. cocomo II …
- Par bloc ou mandat ou équipe : gérer l’envergure (pas les storys), la portée et le budget … et l’accueil au changement (enlever ou …) Minimum viable (portée vs type solution), tout en restant agile au changement : PAR JALON Place du sunset graph dans l’estimation et le suivi
- Les biais nuisent à la pensé rationnelle Le biais d'ancrage Le biais d'ancrage est la tendance à utiliser indument une information comme référence. Il s'agit généralement du premier élément d'information acquis sur le sujet. Le biais de confirmation : Le biais de confirmation est la tendance, très commune, à ne rechercher et ne prendre en considération que les informations qui confirment les croyances et à ignorer ou discréditer celles qui les contredisent. L'effet Dunning-Kruger L'effet Dunning-Kruger est le résultat de biais cognitifs qui amènent les personnes les moins compétentes à surestimer leurs compétences et les plus compétentes à les sous-estimer. Ce biais a été démontré dans plusieurs domaines. Le biais rétrospectif Le biais rétrospectif est la tendance à surestimer, une fois un événement survenu, comment on le jugeait prévisible ou probable. L'excès de confiance L'excès de confiance est la tendance à surestimer ses capacités. Ce biais a été mis en évidence par des expériences en psychologie qui ont montré que, dans divers domaines, beaucoup plus que la moitié des participants estiment avoir de meilleures capacités que la moyenne. Le biais de négativité Le biais de négativité est la tendance à donner plus de poids aux expériences négatives qu'aux expériences positives et à s'en souvenir davantage. L'illusion de corrélation L'illusion de corrélation consiste à percevoir une relation entre deux événements non reliés ou encore à exagérer une relation qui est faible en réalité. Le biais de cadrage Le biais de cadrage est la tendance à être influencé par la manière dont un problème est présenté. Le biais de la disponibilité en mémoire Le biais de la disponibilité en mémoire consiste à porter un jugement sur une probabilité selon la facilité avec laquelle des exemples viennent à l'esprit. Ce biais peut, par exemple, amener à prendre pour fréquent un événement récent. L'illusion de savoir L'illusion de savoir consiste à se fier à des croyances erronées pour appréhender une réalité et à ne pas chercher à recueillir d'autres informations.
- Comment je l’ai fait : Par bloc avec ceux qui savent : Capitale Deux approches par induction : Protecteur Citoyen carnet par point via comparatif fonctionnalités par JP via barèmes dans les temps, mais surtout sous le budget Appliquer l’agilité aux barèmes : Desjardins Avec ceux qui savent Avec des comparatifs communs (vs complexité) Sans égard à l’encadrement
- Pourquoi no estimate Trop souvent basé sur les croyances et le biais cognitif de l’évaluateur Expliquer la liste Si trop précis, notre équipe est sous challenger, livre tout croche pour y arriver, ou perd du temps étalement du risque et de l’attribution du budget : tout le projet / par livraison par livraison avec bonus de satisfaction par itération SPIKE à initier au plus vite (échoué rapidement / testé notre compréhension On n’arrêtera pas le projet, autant s’y brûler plus vite Autre contexte : En mode progiciel … attention aux « adaptations » et réutilisation des façons de faire de développement En entretien : Attention aux barèmes trop « incluant » Plus d’une technique, mais : point de fonction et barèmes macroscopique Pas pour estimer car nécessite trop de détails Force une sur-architecture détaillée Utilisable en fin de livraison ou d’itération, pour challenger notre vélocité de façon objective (vs les points par fonctionnalité) Références et formations dispos sur le sujet beaucoup de concepts qu’on a dû prendre pour acquis Si vous cherchez du contenu là-dessus …
- Références et formations dispos sur le sujet beaucoup de concepts qu’on a dû prendre pour acquis Si vous cherchez du contenu là-dessus …