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
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 …
It appears that you have an ad-blocker running. By whitelisting SlideShare on your ad-blocker, you are supporting our community of content creators.
Hate ads?
We've updated our privacy policy.
We’ve updated our privacy policy so that we are compliant with changing global privacy regulations and to provide you with insight into the limited ways in which we use your data.
You can read the details below. By accepting, you agree to the updated privacy policy.