Successfully reported this slideshow.
Your SlideShare is downloading. ×

Estimer les projets TI, même en Agile

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Atelier de simulation DevOps
Atelier de simulation DevOps
Loading in …3
×

Check these out next

1 of 20 Ad

More Related Content

Slideshows for you (20)

Similar to Estimer les projets TI, même en Agile (20)

Advertisement

Recently uploaded (20)

Advertisement

Estimer les projets TI, même en Agile

  1. 1. Colloque en gestion de projet 2017 1 Estimer les projets TI, même en Agile Frédéric Paquet et Renaud Poirier
  2. 2. Colloque en gestion de projet 2017 2 Estimer les projets TI, en AGILE ? #NOESTIMATEESSENTIEL
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Colloque en gestion de projet 2017 12 Architecte  Leader  Facilitateur
  13. 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. 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. 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. 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. 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. 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. 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. 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

Editor's Notes

  • 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 …

×