Contenu connexe Similaire à 2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile (20) Plus de PMI Lévis-Québec (20) 2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile1. Colloque en gestion de projet 2016
1 © 2016 Copyrights : RSM Technologies inc.
Estimation de projets informatiques –
« traditionnels » et agiles
Radenko Corovic
Président
RSM Technologies
2. Colloque en gestion de projet 2016
2 © 2016 Copyrights : RSM Technologies inc.
Contenu
Fondements d’estimation des projets informatiques
Caractéristiques de l’approche
Démarche d’estimation
Forces et faiblesses de l’approche
Estimation de la taille vs efforts vs durée
Techniques d’estimation
Estimation des projets informatiques « traditionnels » (Waterfall)
3. Colloque en gestion de projet 2016
3 © 2016 Copyrights : RSM Technologies inc.
Estimation de projets agiles
Estimation agile - Approche standardisée
Estimation agile - Composants (items)
Estimation agile - Démarche
Avantages de l’approche
Estimation de la taille vs efforts vs durée
Estimation agile - Techniques
Méthode agile - caractéristiques
Contenu
4. Colloque en gestion de projet 2016
4 © 2016 Copyrights : RSM Technologies inc.
• Spécialisé en estimation et la performance de projets des TI
• Plus de 20 ans d'expérience dans le domaine de gestion de la
performance de projets
• Expert en pratiques d’estimation des projets TI, des mesures
de performance de projet et de la performance des TI
• Plusieurs publications (articles, recherches, blogues, etc.)
dans les sites et les revues spécialisées
• Présentations dans les différentes conférences (International
workshop on Software Measurement, PMI-Project World,
Colloque PMI, IT Management Forum)
• Fondateur du Comité des responsables en métriques TI du
Gouvernement du Québec
5. Colloque en gestion de projet 2016
5 © 2016 Copyrights : RSM Technologies inc.
Fondements d’estimation des
projets informatiques
6. Colloque en gestion de projet 2016
6 © 2016 Copyrights : RSM Technologies inc.
Pourquoi estimer?
“The single most important task of a project: setting realistic
expectations.”*
La tâche la plus importante d'un projet : établir des attentes réalistes
“Unrealistic expectations based on inaccurate estimates are the
single largest cause of software failure.”*
Des attentes irréalistes basées sur des estimations inexactes sont la
principale cause d’échec de mise en place d’un logiciel)
*Futrell, Shafer and Shafer, Quality Software Project Management
7. Colloque en gestion de projet 2016
7 © 2016 Copyrights : RSM Technologies inc.
Répercutions d’une sous-estimation :
• Ressources non suffisantes
◦ Épuisement des membres de l’équipe de projet
• Plan de projet non réaliste
◦ Dépassements
◦ Qualité compromise
• Création d’attentes non réalistes
• Promesses non tenues
◦ Votre crédibilité mise en question
Si on surestime :
• Projet va coûter plus qu’il devrait coûter (Loi de Parkinson)
• Projet va durer plus longtemps que nécessaire
◦ On remet les choses à plus tard
• Ressources non disponibles pour les autres projets
Pourquoi estimer?
8. Colloque en gestion de projet 2016
8 © 2016 Copyrights : RSM Technologies inc.
• Exactitude et précision d’un estimé
– L’exactitude fait référence à la qualité du résultat
– La précision caractérise la fiabilité du résultat (ex. de 1 à 1,5 M)
• Un estimé de 5 321 J-P fait dans la phase d’initiation de projet est précis,
mais probablement pas exact
• Un estimé, par définition, n’est pas exact
• “It is better to be roughly right, than precisely wrong”.*
• Une bonne estimation devrait estimer le projet dans
l’intervalle de +/- 25% dans 75% des cas
• Ne pas oublier : L’estimation est un processus itératif
* John Maynard Keynes
9. Colloque en gestion de projet 2016
9 © 2016 Copyrights : RSM Technologies inc.
Questions Réponses
Revenus totaux au box-office pour le film Avatar ($)
Latitude de Montréal
Longueur des côtes du Canada (en kilomètres)
Nombre moyen de livres publiés au Canada chaque année
La profondeur maximale du lac Baïkalle (le plus profond du monde)
2 781 505 847 $
45° 30'N
202 080 km
16 000
1 637 mètres
10. Colloque en gestion de projet 2016
10 © 2016 Copyrights : RSM Technologies inc.
Estimation de projets informatiques
« traditionnels » (Waterfall)
11. Colloque en gestion de projet 2016
11 © 2016 Copyrights : RSM Technologies inc.
Démarche en 4 étapes :
• Estimer la taille du projet
• Estimer les efforts du projet
• Estimer la durée du projet
• Raffiner les estimations (facteurs d’ajustement)
Taille
Efforts
Durée
Raffinement
12. Colloque en gestion de projet 2016
12 © 2016 Copyrights : RSM Technologies inc.
• La taille (l’envergure) est de loin le facteur le plus déterminant
de l’effort et de la durée du projet…
• …mais, en même temps, la taille est le facteur que les
développeurs connaissent le moins
• Cependant, l’estimation de la taille est la plus difficile étape
d’estimation
• Méthodes de mesure de la taille du logiciel :
– Lignes de code
– Points de fonction
– Use case
– Objets graphiques
– …
13. Colloque en gestion de projet 2016
13 © 2016 Copyrights : RSM Technologies inc.
• L’estimation des efforts/coûts du projet exige d’identifier,
d’évaluer et d’additionner les travaux nécessaires afin de
développer la solution
• 2 façons d’estimer les efforts du projet :
– Estimer les efforts nécessaires pour réaliser chacun des composants
de la solution et les additionner. Ajouter les efforts au niveau du projet
(intégration, gestion de projet, gestion du changement, documentation,
etc.)
– Appliquer les modèles paramétriques (ex. Boehm ou Putnam) qui ont
expérimenté la relation entre la taille et les efforts (ex. : 1 point de
fonction vaut 1 J-P)
• Multiplier les efforts estimés avec le taux en $ pour obtenir les
coûts du projet associés aux ressources humaines. Ajouter
les coûts d’acquisitions, du matériel, etc.
14. Colloque en gestion de projet 2016
14 © 2016 Copyrights : RSM Technologies inc.
• «Plus de projets informatiques ont mal tourné à cause du
calendrier non réaliste qu’à cause de tous les autres facteurs
combinés» (Brooks)
• Il s’agit d’estimer la durée dans laquelle le projet peut être
réalisé.
• 2 approches:
– Décomposer le projet en activités, estimer la durée de chaque activité
et les agencer dans le temps (« scheduling »)
– Appliquer un des modèles paramétriques qui contiennent les formules
basées sur les efforts du projet
• Les efforts sont le facteur principal influençant la durée du
projet
• Si vous n’avez pas vos propres barèmes, vous pouvez utiliser
la formule ci-dessous (autres formules sont présentées sur la
diapo suivante) :
Mois calendrier = 3.0 x Efforts en mois 1/3
15. Colloque en gestion de projet 2016
15 © 2016 Copyrights : RSM Technologies inc.
• Facteurs d’ajustement modifient les résultats d’estimation
permettant de prendre en compte les caractéristiques du
logiciel, du matériel, du personnel et du projet
• Le modèle COCOMO (Constructive Cost Model) de B. Boehm
le plus utilisé
• 4 groupes importants :
– Facteurs personnels
– Facteurs du produit
– Facteurs du projet
– Facteurs liés à la plateforme
• Le modèle donne la valeur des facteurs d’ajustement, mais
vous devez le calibrer selon les données de vos projets
16. Colloque en gestion de projet 2016
16 © 2016 Copyrights : RSM Technologies inc.
• Si vous ne disposez d’autres métriques, vous pouvez ajouter :
– 5 % à 10 % d’efforts pour le support administratif
– 3 % à 5 % pour le support informatique
– 20 % à 40 % pour le développement avec de nouvelles technologies
– 20 % à 40 % pour le développement avec le nouvel environnement
• Coût moyen d’estimation :
– De 0,5% (petits projets) à 1% (gros projet) du coût de développement
18. Colloque en gestion de projet 2016
18 © 2016 Copyrights : RSM Technologies inc.
Progiciels : Selon Gartner, le coût moyen annuel de maintenance
des progiciels se situe entre 20% (si rien n’est personnalisé, ce qui
est rare) et 50% du coût d’acquisition
% de budget de maintenance sur le
coût de développement (barèmes)
Remarque
1re année 2e année
Années
suivantes
Industrie
(Gartner)
28% 17-25% 17-25%
Forrester
Research
20% 20% 20%
Ils recommandent au moins
20% si on veut éliminer les
risques liés au bon
fonctionnement des systèmes
Projets publics
(Qc)
10-15% 7-10% 7-10%
Budget planifié (cela varie
beaucoup d’une organisation à
l’autre)
19. Colloque en gestion de projet 2016
19 © 2016 Copyrights : RSM Technologies inc.
• «Top-down»
– Fait l’estimation de la totalité du projet (1er niveau du WBS) sans
nécessairement considérer les niveaux plus détaillés (phases ou
activités)
– Utilisée souvent dans la phase d’initiation d’un projet
• «Bottom-up»
– Basée sur la structure de découpage (WBS) où chaque activité est
estimée séparément
– Les estimations de chaque activité sont assemblées afin d’obtenir
l’estimé du projet
– Assez précise si le projet est suffisamment détaillé
– Peut sous-estimer les coûts des activités au niveau projet (gestion de
projet, intégration, gestion du changement, gestion de la
documentation, etc.)
– Ne peut pas être utilisée tôt dans le projet (manque d’informations)
20. Colloque en gestion de projet 2016
20 © 2016 Copyrights : RSM Technologies inc.
• Estimation paramétrique (algorithmique)
– Une approche basée sur les informations disponibles des projets
antérieurs et qui est généralement liée à la taille du logiciel à
développer
– Le coût et la durée sont estimés en se basant sur un modèle
mathématique des caractéristiques de produit (système), du projet et
du processus
21. Colloque en gestion de projet 2016
21 © 2016 Copyrights : RSM Technologies inc.
• Jugement d’expert
– Demander un estimé d’une ou plusieurs personnes (experts)
– Méthode la plus utilisée dans l’estimation de projets (parce que la plus
facile à appliquer)
– Utilisée dans Planning Poker
22. Colloque en gestion de projet 2016
22 © 2016 Copyrights : RSM Technologies inc.
• Estimation par analogie
– Utilise les projets similaires (caractéristiques techniques, taille,
complexité) antérieurs comme base d’estimation
– Demande un jugement technique pour comparer les caractéristiques
avec les projets similaires
– Technique assez fiable si les informations sur les projets passés sont
fiables
– Utilisée dans Planning Poker
23. Colloque en gestion de projet 2016
23 © 2016 Copyrights : RSM Technologies inc.
• Dépend de plusieurs facteurs: l’envergure du projet, type de
développement, phase actuelle du projet, etc.
• Toutes les techniques expliquées précédemment peuvent être
effectuées soit avec la méthode « top-down » soit avec la
méthode « bottom-up »
• La meilleure méthode à appliquer dépend de la phase du
projet: Au début il faut utiliser la méthode « top-down » et les
techniques paramétriques et vers la fin du projet la méthode «
bottom-up » et les techniques analytiques
• Il est recommandé d’utiliser plusieurs techniques à la fois
(habituellement technique « jugement d’expert » combinée
avec une autre technique)
• La plupart d’outils commerciaux utilisent plus de deux
techniques d’estimation
24. Colloque en gestion de projet 2016
24 © 2016 Copyrights : RSM Technologies inc.
Petits projets
Généralement réalisés par les petites
équipes (une à trois personnes) en
moins de 6 mois
Méthode recommandée:
• « Bottom-up » ou l’estimation par
activité
Estimations très dépendantes de la
productivité et de l’efficacité de
l’équipe de projet
Estimation devrait être faite par les
individus qui vont réaliser le projet
Grandes projets
Généralement réalisés par des
grandes équipes (sept personnes et
+) en plus de 6 mois
Méthode recommandée :
• Initiation du projet
◦ « Top-down »
• Analyse préliminaire
◦ « Top-down » et « Bottom-up »
• Après l’architecture
◦ « Bottom-up »
À cause de leur complexité, les
larges projets devraient être
estimés à l’aide d’un outil
25. Colloque en gestion de projet 2016
25 © 2016 Copyrights : RSM Technologies inc.
Faisabilité Analyse
préliminaire
Système
accepté
Arch.
détaillée
Architecture
globale
1
0,5
2
4
0,25
Taille
relative
Prendre
l’engagement
ici
Estimé, non
engagement
26. Colloque en gestion de projet 2016
26 © 2016 Copyrights : RSM Technologies inc.
• Le développement de logiciels est un processus de
raffinement progressif et l’estimation doit l’être aussi
• Le cône d’incertitude représente le meilleur estimé possible
dans les différentes phases d’un projet
• Il est facilement possible de faire pire, mais difficilement
possible de faire mieux
• Engagement significatif n’est pas possible dans la portion la
plus large du cône
• Pas d’économie d’échelle : Les grandes projets durent plus
long temps et coûtent plus cher par unité de produit que les
petits projets
27. Colloque en gestion de projet 2016
27 © 2016 Copyrights : RSM Technologies inc.
• L’estimation n’est pas une planification et la planification n’est
pas une estimation
• Estimation: Processus indépendant et analytique
• Planification: Processus subjectif et influencé par la cible à
atteindre
• L’estimation est la base de la planification et non vice versa
• Les estimations sont la responsabilité des personnes qui font
le travail
• Les objectifs sont fixés par les gens qui paient pour le travail
• Les engagements sont des accords entre les personnes qui
font le travail et les gens qui paient pour le travail
– Engagement est atteint par la négociation
28. Colloque en gestion de projet 2016
28 © 2016 Copyrights : RSM Technologies inc.
• Estimation n’est pas un engagement
• Engagement raisonnable peut être fait avec l’intervalle de
confiance de 25-30%
• L’engagement devrait être exprimé de façon spécifique (ne
pas utiliser l’intervalle)
• Estimé doit être neutre, il ne faut donc pas le négocier
• Par contre, l’engagement peut être négocié, mais il devrait
être présenté avec le niveau de confiance (ex. 75% de
probabilité que le projet va durer 10 mois)
• Vous pouvez faire un engagement à n’importe quel point de
l’intervalle de confiance de votre estimation, mais il faut
l’accompagner avec le niveau de confiance approprié
30. Colloque en gestion de projet 2016
30 © 2016 Copyrights : RSM Technologies inc.
Budget total alloué au projet
Budget autorisé du projet (baseline)
Reserve pour
imprévus
Coût estimé du projet Contingence
Probabilité Sévérité Exposition au
risque
Risque 1 10% 300 000$ 30 000$
Risque 2 30% 200 000$ 60 000$
Risque 3 40% 100 000$ 40 000$
… … … …
Total à ajouter: 130 000$
Calculer la contingence en fonction des risques du projet
Même approche pour les efforts et pour les délais
31. Colloque en gestion de projet 2016
31 © 2016 Copyrights : RSM Technologies inc.
• Utilisez plusieurs méthodes (techniques) d’estimation
• Réalisez plusieurs estimations au cours de cycle de vie d’un projet
• Évitez les estimés trop précis (ex.: coût = 2 354 231 $);
• Utilisez plutôt les estimés avec l’intervalle (coût = entre 2 et 2,5 M)
• Ne faites pas l’engagement trop tôt dans le projet
• Attendez d’arriver à 20-25% de confiance
• Documentez vos estimés, vous allez gagner en crédibilité
• Évitez de donner des estimés impromptus (« elevator estimate ») à
votre patron
• Ne pas oublier : L’estimation est un processus itératif
32. Colloque en gestion de projet 2016
32 © 2016 Copyrights : RSM Technologies inc.
Estimation de projets agiles
33. Colloque en gestion de projet 2016
33 © 2016 Copyrights : RSM Technologies inc.
• Agile Manifesto
– Individus et Interactions vs Processus et outils
– Logiciel qui fonctionne vs Documentation exhaustive
– Collaboration avec les clients vs Négociation contractuelle
– Adaptation au changement vs Suivi du plan
• Agile – 12 principes
• Différentes méthodes (EP, Scrum, Lean, Kanban, etc.)
• Scrum la méthode la plus rependue
• Dans cette formation on fait référence à la méthode Scrum
34. Colloque en gestion de projet 2016
34 © 2016 Copyrights : RSM Technologies inc.
Estimation
Contraintes Fonctionnalités (Taille)
Fonctionnalités (Taille)CoûtTemps
TempsCoût
Processus prédictif
(Waterfall)
Processus adaptatif
(Agile)
Piloté
par le
plan
Piloté par la
valeur
35. Colloque en gestion de projet 2016
35 © 2016 Copyrights : RSM Technologies inc.
• Product > Épics (features) > User Stories > Tâches
Product Backlog
Release/Project
Backlog
Tâche
US
Epic
US
Release/Project
Backlog
Tâche
Tâche
Tâche
US
US
Tâche
Tâche
Tâche
US
Sprint
36. Colloque en gestion de projet 2016
36 © 2016 Copyrights : RSM Technologies inc.
• User Story exprime l’objectif d’affaires dans le langage du client
• User Story est le point de départ de la discussion concernant l’item à
développer
• US permet au propriétaire du produit et à l'équipe de développement de
discuter des exigences lors de l'itération
• User Stories ne sont pas les exigences fonctionnelles
• User Stories bien écrites suivent le modèle INVEST :
– Indépendants - histoires doivent être indépendantes les uns des autres (autant
que possible)
– Négociable - les détails techniques (fonctionnels) sont élaborés au fur et à
mesure que US progresse
– Utile (Valuable) - sinon, pourquoi la faire?
– Estimable - pas trop grand, pas trop ambiguë
– Suffisamment petite - devrait pouvoir être achevé dans un sprint par quelques
personnes
– Testable - critères d'acceptation devraient être claires et précises
37. Colloque en gestion de projet 2016
37 © 2016 Copyrights : RSM Technologies inc.
• L’emphase sur les besoins et les avantages, pas de l'interface utilisateur ou la
mise en œuvre
• US sont des espaces réservés pour une discussion et ne sont pas considérées
comme des exigences dans le sens de développement
• Le texte de description d’une US est moins importante que les conversations de
l'équipe a ce sujet
• Un bon modèle de description: En tant que <rôle> Je veux <capacité> Afin de
<valeur d’affaires>
User Story
En tant que: Scrum Master
Je veux: estimer la taille et les efforts
d’un item du Product backlog
Afin de: bien planifier mes prochaines
itérations
Tâches (Sprint)
• Définir le type d’item à estimer
• Créer un UI Web
• Définir les facteurs de productivité
de l’équipe
• Programmer les algorithmes
d’estimation
• Réaliser les testes
38. Colloque en gestion de projet 2016
38 © 2016 Copyrights : RSM Technologies inc.
• Utilise la taille relative (Story Points)
• Garde le simple: ne dépense pas trop de temps pour estimer
• Utilise les techniques et les outils faciles (Planning Poker; T-
Shirt Sizing, Relative Mass Valuation)
• Estimé par les gens qui vont développer le système
• Unité de mesure n’est pas vraiment importante (unitless)
39. Colloque en gestion de projet 2016
39 © 2016 Copyrights : RSM Technologies inc.
• Utilise la loi de grand nombre
• Release Backlog
– Construire le Release Backlog
– Peut avoir les items de différente taille (Épics, US)
– Estimer la taille (complexité) et la valeur d’affaires (valeur relative via
T-Shirt Sizing ou Relative Mass Valuation)
– Prioriser les items (PO) en se basant sur la valeur d’affaires
– Minimum Marketable Feature (MMF)
• Sprint Backlog
– Estimer la vélocité (recommandé: deux-trois Sprints, parfois plus)
– Choisir les US dont la taille (pts) correspond à la capacité du Sprint
– Décomposer les US qui dépassent la capacité du Sprint
(recommandation: jusqu’à 50% de votre iteration)
– Estimer les efforts pour chaque item
40. Colloque en gestion de projet 2016
40 © 2016 Copyrights : RSM Technologies inc.
L’estimation basée sur les données historiques est la forme la plus
exacte d’estimation
Product Backlog – No
entièrement décomposé
ni ordonné
Release Backlog – Items
du Product Backlog
planifiés d être réalisés
dans une période (3 à 6
mois)
Estimation sommaire
avant-projet (pattern,
Mois par équipe, etc.)
Sprint Backlog – Tâches
planifiées pour une
itération (2 à 4 sem)
Estimation des items du
Backlog (SP, Ideal Days,
etc.)
Estimation détaillée
des tâches (heures)
Produit final
Taille finale
du produit
Sprint
1
Sprint
2
Sprint
…
41. Colloque en gestion de projet 2016
41 © 2016 Copyrights : RSM Technologies inc.
• Le niveau de précision d’estimation doit correspondre au niveau de
détail du système:
– Estimation au niveau de projet:
• Team-sprints, team-mois, pattern, etc.
– Grands items (épics)
• T-shirt estimation, catégories de complexité
– User Story
• Story Points, SP Standardisés, Ideal Days
– Tâches (composants d’item)
• Ideal hours restants
• “It is better to be roughly right, than precisely wrong”.
• “Il vaut mieux avoir approximativement raison que
précisément tort. »
John Maynard Keynes
42. Colloque en gestion de projet 2016
42 © 2016 Copyrights : RSM Technologies inc.
Taille du système
• Basée sur les fonctionnalités du système et ne dépend pas de la
technologie, de la productivité, de l’environnement, etc.
• Exprimée en points (Story Points, Feature Points, Ideal Days, SSP)
• Une mesure fondamentale permettant de comparer la
productivité/efficacité (effort réel/pts), qualité (anomalies/pts) et les délais
(pts par unité de temps) entre les différentes équipes et différents projets
Effort
• Taille est le « driver » principal d’effort
• Dépend aussi de la productivité d’équipe, facteurs d’environnement,
technologie utilisée, etc.
• Exprimé en heures/personne ou J-P
Durée
• Effort est le principal « driver » de la durée
• Dans Agile la durée peut être calculée : Durée du Sprint x Nombre de
Sprints
43. Colloque en gestion de projet 2016
43 © 2016 Copyrights : RSM Technologies inc.
• T-shirt estimation est une façon d’estimer sommairement les items du
Backlog
• Une approche plus créative qu’analytique
• Faiblesses
– Les valeurs ne sont pas additives (un large + un moyen = ?)
– Votre point de vue d'un XL peut ne pas correspondre au mien
• Les valeurs habituelles : extra-petite, petite, moyenne, large et extra-large
• Une estimation rapide, mais aussi moins précise
• Convient aux équipes qui commencent avec agile
• Conseil : Associez un nombre à chaque taille (exemple : un moyen = 5 un
XL = 20…)
44. Colloque en gestion de projet 2016
44 © 2016 Copyrights : RSM Technologies inc.
• Planning Poker est une technique d’estimation et de la
planification agile qui est basée sur le consensus
• La suite de Fibonacci est utilisée pour les évaluations des
efforts de développement de chaque item
45. Colloque en gestion de projet 2016
45 © 2016 Copyrights : RSM Technologies inc.
Comment ca fonctionne:
• Le PO présente et explique un item du backlog
• L’équipe fait l’estimation
– Chaque membre choisi une carte qui présente son estimation de l’item
– Tous le monde montre la carte à même temps
– L’équipe discute les estimations individuelles
– On demande aux membres qui ont l’estimation la plus élevée et la
moins élevée d’expliquer leur raisonnement
– L’équipe répète l’estimation tant que le consensus est atteint
• On prend un autre item et on répète le processus
46. Colloque en gestion de projet 2016
46 © 2016 Copyrights : RSM Technologies inc.
Conseils:
• Choisissez un bon facilitateur (habituellement Scrum Master)
• Faites participer tous les membres de l’équipe
• Expliquez bien les règles de jeu
• Laissez exprimer tous le monde librement
• Commencez avec la plus petite histoire, habituellement la
taille 2
• Après deux itérations, si l’écart persiste, laissez cette histoire
de côté et continuez avec les autres
47. Colloque en gestion de projet 2016
47 © 2016 Copyrights : RSM Technologies inc.
• Utilisée quand on a un grand nombre d’items à estimer en
même temps
• Évaluation relative de chaque item
– Chaque item est décrit sur une carte
– Chaque carte est placée une à coté de l’autre selon leur taille relative
– Placez un grand item à une extrémité de la table, un petit item à l'autre
bout de la table et un item moyenne au milieu
– Allez à la carte suivante et la placez selon sa taille relative
• L'étape suivante consiste à associer les points en fonction de
la position des items sur la table
– Commencez avec l‘item le plus simple et attribuez 1 point
– Attribuez 2 points à la prochaine carte et continuez comme ca jusqu’ à
la fin
• L’idée est d’avoir une estimation sommaire de tous les items
et non de les arranger selon l’ordre de réalisation
48. Colloque en gestion de projet 2016
48 © 2016 Copyrights : RSM Technologies inc.
• L’estimation est assez rapide et ne demande pas d’outils
spécifiques d’estimation
• Les estimateurs ne doivent pas avoir des connaissances
spécifiques des techniques d’estimation
• L’approche favorise la discussion entre les membres de
l’équipe sur les fonctionnalités à développer
• L’approche avec les Story points respecte la séquence du
processus d’estimation: estimer la taille (SP) > estimer les
efforts > estimer la durée
• Compte tenu que les estimations sont faites par l’équipe qui
va développer le système, les membres de l’équipe sont
souvent très à l’aise avec l’estimé
49. Colloque en gestion de projet 2016
49 © 2016 Copyrights : RSM Technologies inc.
• Le calcul de SP n’est pas basé sur une méthode
standardisée; une même User Story peut avoir différent
nombre de SP si estimée par différentes équipes
• Étant une mesure relative, les SP ne permettent pas de
comparer la productivité de développement entre les
équipes, entre les projets d’une même organisation
(benchmarking interne) et encore moins avec les projets de
l’industrie (benchmarking externe)
• L’utilité des données collectées du projet agile (ex. effort par
SP, nombre de SP par mois de développement, etc.) est très
limitée pour l’organisation
• Les SP diffèrent considérablement d’une équipe/projet à
l’autre et ont une signification seulement aux membres de
l’équipe qui les estiment
50. Colloque en gestion de projet 2016
50 © 2016 Copyrights : RSM Technologies inc.
Proposition d’une approche standardisée
d’estimation agile
51. Colloque en gestion de projet 2016
51 © 2016 Copyrights : RSM Technologies inc.
• Agile est en train de devenir la méthode principale de
développement de systèmes informatiques
• Cependant, la transition de la méthode séquentielle
(Waterfall) vers agile pose des questions importantes:
o Combien le projet va couter (estimation up-front)?
o Quand le produit va être livré (durée du projet)?
o Le projet, est-il performant par rapport à d’autres projets similaires
(productivité)?
o Comment intégrer le projet agile dans le portefeuille corporatif de
projets (agiles avec waterfall)?
• Agile a beaucoup de difficultés à répondre à ces questions,
parce que la mesure de taille de projets agiles n’est pas
standardisée
52. Colloque en gestion de projet 2016
52 © 2016 Copyrights : RSM Technologies inc.
“Without a standard there can be no improvement”
Taicho Ohno, primary inventor of Lean/TPS
• Basée sur les principes agiles: simplicité, rapidité, efficacité
• Calcule la taille (points standardisés) de façon automatisée et
simplifiée tout en gardant les avantages de l’approche agile
• Simple à utiliser, ne demande pas la formation en estimation ni le
calcul de la taille
• Basée sur les meilleurs pratiques de l’industrie (COSMIC,
COCOMO)
• Alignée avec la méthode et l’esprit agiles
53. Colloque en gestion de projet 2016
53 © 2016 Copyrights : RSM Technologies inc.
Résultats d estimation
Équipe de projet
Estimer les items
(complexité – Early
Points ou critères -
détaillée)Responsable
du projet
Taille (pts)
Efforts (hrs)
Coûts ($)
Items
Facteurs de
productivité
Expérience avec la
technologie, avec
les outils, avec
l agile, etc.
Inscrire les items
(epics&US) dans
l outil d estimation
Effort unitaire
(données historiques)
Composition
d équipe
Rôles, capacité, taux
horaire
Durée
Efforts (hrs)
Vélocité
Projet
Ajuster l effort unitaire (hrs/pts)
Équipe de projet
Durée de
l itération
54. Colloque en gestion de projet 2016
54 © 2016 Copyrights : RSM Technologies inc.
• L’approche paramétrique d’estimation basée sur la taille
fonctionnelle et la taille non-fonctionnelle
• Exigences fonctionnelles
– Basées sur la méthode simplifiée du COSMIC
– La méthode COSMIC (originellement - Full Function Points) est une
méthode de mesure fonctionnelle du logiciel internationalement
reconnue et standardisée ISO
– La méthode permet d’automatiser le calcul de points de la taille
• Facteurs de productivité
– Basé sur la méthode COCOMO II, une référence en estimation des
coûts de développement
• Exigences non-fonctionnelles
– Normalisées par IFPUG
– Différentes par rapport à la taille fonctionnelle
– L’approche considère à la fois les exigences fonctionnelles et les
exigences non-fonctionnelles pour calculer la taille du système
55. Colloque en gestion de projet 2016
55 © 2016 Copyrights : RSM Technologies inc.
L’approche standardisée permet de:
• Estimer la taille, les efforts et la durée d'un projet agile pendant
tout le cycle de développement
• Comparer la performance / productivité entre les équipes agiles
et/ou entre les projets
• Comparer la qualité des logiciels sur la base de mesures
standardisées
• Faciliter l'intégration de projets agiles dans le portefeuille de
projets (« scaled agile »)
• Suivre et mesurer l'avancement des projets agiles avec la
méthode de la valeur acquise (surtout les projets avec plusieurs
équipes)
• Estimer la taille et les efforts avec les données historiques de
l’organisation (vélocité organisationnelle)
56. Colloque en gestion de projet 2016
56 © 2016 Copyrights : RSM Technologies inc.
• Ingrédients:
– Un bon chef et le personnel
de cuisine qualifié
– Un bon système de
communication dans la
cuisine
– Les outils de cuisine
standards
– Pas trop d’ingrédients:
choisissez juste les
ingrédients essentiels
57. Colloque en gestion de projet 2016
57 © 2016 Copyrights : RSM Technologies inc.
• Durée de cuisson:
– Pas plus de 6 mois
• Pour les repas particulièrement
complexes: 12 mois max
• Coût total de repas:
– Pas plus d’un million $
– ou de 1 000 J-P
• Nombre de personnel
– Pas plus de 7 personnes dans
la cuisine
58. Colloque en gestion de projet 2016
58 © 2016 Copyrights : RSM Technologies inc.
• Méthode de cuisson:
– Simple et efficace
• Éviter d’augmenter la
température de cuisson au-
delà de la température
optimale
– Au lieu de sauver le temps,
vous allez juste bruler votre
repas
– Gouter souvent pour
s’assurer que le repas
correspond à ce que le client
veut
59. Colloque en gestion de projet 2016
59 © 2016 Copyrights : RSM Technologies inc.
Pour plus d’informations:
www.rsmtechno.ca
radenko.corovic@rsmtechno.com
C| 418 657-0905
60. Colloque en gestion de projet 2016
60
Cette présentation sera disponible sur le site web
du PMI Lévis-Québec à compter du 1 mai 2016