2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile

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

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)

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

• 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

Fondements d’estimation des
projets informatiques

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

 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?

• 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

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

Estimation de projets informatiques
« traditionnels » (Waterfall)

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

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

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

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

• 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

• 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

 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)

• «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)

• 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

• 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

• 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

• 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

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

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

• 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

• 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

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

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

• 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

Estimation de projets agiles

• 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

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

• 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

• 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

• 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

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

• 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

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
…

• 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

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

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

• 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

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

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

• 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

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

• 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

Proposition d’une approche standardisée
d’estimation agile

• 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

“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

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

• 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

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)

• 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

• 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

• 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

Pour plus d’informations:
www.rsmtechno.ca
radenko.corovic@rsmtechno.com
C| 418 657-0905

60
Cette présentation sera disponible sur le site web
du PMI Lévis-Québec à compter du 1 mai 2016

2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile

Similaire à 2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile (20)

Plus de PMI Lévis-Québec

Plus de PMI Lévis-Québec (20)

Dernier

Dernier (20)

2016-04-13 Radenko Corovic TI -Estimation de projets informatiques traditionnels et Agile