![Introduction ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Gestion des coûts et Projets Agiles
Ähnlich wie Gestion des coûts et Projets Agiles (20)
Gestion des coûts et Projets Agiles
- 1. Projets Agiles et Gestion des Coûts www.TimePerformance.com par Renaud Choné
- 3. 1. Pourquoi Gérer les coûts ?
- 5. 2. La Gestion des Coûts
- 8. Les formules de la valeur acquise Source
- 9. … et encore des formules Source
- 10. Plutôt indigeste, non ? CBTP ? CBTE ? CRTE ? CPI ? SPI ? BAT ? EC ?
- 13. Le diagramme de la Valeur Acquise Outil pour l’Agilité Simple, Efficace, Visuel.
- 14. Interprétation du diagramme VA Valeur Acquise > Coût réel économies par rapport au budget. Valeur Acquise > Coût budgété projet en avance ……………….
- 16. « En avance mais attention aux coûts ! »
- 17. « En retard mais surperforme »
- 18. Dépense > mais en Avance
- 19. Dépense < mais en Retard
- 23. 3. Les Projets Agiles coûtent-ils moins chers ?
- 25. Etude sur les Projets Agiles http://www.ambysoft.com/surveys/agileFebruary2008.html Scott Ambler
- 30. Questions ? [email_address] www.TimePerformance.com
Hinweis der Redaktion
- Segmentation de l’auditoire: Métier Informatique / Pas informatique Profile: Chef de Projet / Manager / Ingénieur Ma Présentation Direct Energie: besoin d’Agilité (environnement changeant, robustesse)
- Nécessaire pour parler de gestion de projet http://www.infoq.com/presentations/Agile-in-Practice-Scott-Ambler Agile Community is Developper Focused. (Cost is not important, UI and usability is not important, nothing in it) Scott Ambler 3 raisons de l’absence dans les méthodes agiles: Cela ne nous intéresse pas (car méthode développée par des techniciens pour un monde technique) Illusion des approches agiles: sharing risks, on peut changer les règles du business (fixed prices), productivité <> Vélocity Discours sur la notion de méthode/framework: gestion de projet/processus d’ingénierie Gestion de Projet (CDD) versus Gestion de Produit (CDI) C’est comme pour les autres projets (pas Agiles) donc rien a ajouté 3 objectifs: sensibilisez, montrer l’importance + présenter les techniques + argument du coût
- Par Contrainte: on vous le demande Pour gérer le projet (traduction du project manager : chef de projet ou gestionnaire de projet) Justification des choix et des investissements justification du projet, ROI Convaincre pour le passage à l’agilité § Motivation derrière l’agilité (efficacité, agilité = pouvoir arrêter un projet et en tirer de la valeur..) Justification des choix techniques (plusieurs alternatives toutes ne sont pas évaluables en terme de charge. Contre-exemple développement d’un framework maison, développement en interne plutôt qu’appel à de la sous-traitance) donc même le développeur est intéressé. ex: investissement 15 k€ dans un outil de test automatisé, mais permet d’économiser 50% des 200j de test (30 k€) Décision: Achat de Progiciel vs Dev specifique, Offshore vs onshore Pilotage survie du projet (mot magique ROI, arrêt suite à manque de budget) Alerter , Gérer la charge ≠ Gérer les coûts La charge ne suffit pas (ni pour le délais à cause de la productivité ni pour les coûts car dépend des ressources) Gérer la charge ne suffit pas (relation cout charge complexe) Gérer la charge = Burdown Chart Communiquer Exemple échelle pour la taille d’un projet: micro < 40 points, petit < 100 Points, moyen < 300 Points, grand < 1000 Points et très grand au delà micro < 6 MH, petit < 12 MH, moyen < 30 MH, grand < 100MH, très grand > 100 MH micro <10k€, petit < 100k€, moyen < 1M€, grand < 10M€, très grand au delà Crédibilité de l’approche Agile (se rapprocher des autres types de gestion de projet) L’importance pour le sponsor du projet (Business Value / cost). La BV seule c’est bon pour l’utilisateur. Rôle du manager votre CV Amputer d’une responsabilité (si vous ne le faîtes pas, quelqu’un le fait pour vous) On ne se met pas à la gestion de coût du jour au lendemain (réponse à l’objection: pas de gestion de coût car projet trop petit) Comment passer au stade supérieur: mode big bang ?
- Budget(!= Estimation 5 classes de l’AACE) / Compta Géné / Compta Analytique (l’ordre 2 3 1)
- VO: Earned Value Management, Earned Value Analysis Ne pas confondre avec la valeur ajoutée, ou l’analyse de la valeur, Net Present Value Un outil pertinent et puissant Projet de déploiement de missiles 1954 Budget and time Comparaison pertinente réalisé vs budgété Efficace car tout en un
- La théorie de la technique de la valeur acquise propose une dizaine de nouveaux indicateurs. C'est cette apparente complexité qui fait peur.
- 1) « Suivre les dépenses sans porter attention à la valeur du travail accompli pour ces mêmes dépenses (i.e. la valeur acquise) n'apporte que peu de valeur au projet. » Donc s'il n'y a pas de valeur acquise, il n'y a pas de contrôle des coûts. (Et dans ce cas, y-a-t'il vraiment une gestion de projet ?) Anecdote sur le sondage 2) 3 concepts fondamentaux: le budget , la coût réel = dépense et la valeur acquise . 2 premiers bien connus, cela n'en fait plus qu'un à découvrir. Tous les autres indicateurs (CV, SC, SPI, CPI, EAC etc.) peuvent être facilement réinventés. Leurs calculs sont très simples. En résumé, la théorie de la valeur acquise, c'est un seul nouveau concept à maîtriser. 3) La valeur acquise représente la valeur de ce qui a été fait (= acquis). La valorisation est calculée selon le budget initial. Ainsi la Valeur Acquise (VA) est le Coût Budgété du Travail Effectué (CBTE).
- 1) « Suivre les dépenses sans porter attention à la valeur du travail accompli pour ces mêmes dépenses (i.e. la valeur acquise) n'apporte que peu de valeur au projet. » Donc s'il n'y a pas de valeur acquise, il n'y a pas de contrôle des coûts. (Et dans ce cas, y-a-t'il vraiment une gestion de projet ?) 2) 3 concepts fondamentaux: le budget , la coût réel = dépense et la valeur acquise . 2 premiers bien connus, cela n'en fait plus qu'un à découvrir. Tous les autres indicateurs (CV, SC, SPI, CPI, EAC etc.) peuvent être facilement réinventés. Leurs calculs sont très simples. En résumé, la théorie de la valeur acquise, c'est un seul nouveau concept à maîtriser. 3) La valeur acquise représente la valeur de ce qui a été fait (= acquis). La valorisation est calculée selon le budget initial. Ainsi la Valeur Acquise (VA) est le Coût Budgété du Travail Effectué (CBTE).
- « Le projet idéal » Simple + Pertinent + Complet = Efficace
- Visualiser immédiatement si l'avance est suffisante pour justifier le surcoût. (retoucher pour enlever la valeur acquise)
- Visualiser immédiatement les causes d'un retard: mauvaise performance ou manque de ressource.
- Estimation pour la suite On conserve l’estimation initiale On réalise une nouvelle estimation complète On calcule la nouvelle estimation en fonction de la performance sur la première partie = Estimation initiale / Indice de performance Indice de performance (CPI, CPI * SPI, a * CPI + b * SPI, au jugé)
- Donner de la visibilité: Estimation <> budget
- BCR = benefit cost ratio = Benéfices / Coûts ROI = Revenu/Investissement Net Present Value = valeur actualisée des bénéfices – valeur actualisée des coûts IRR=> taux d’actualisation pour lequel NPV = 0 Coût global (cout de dev + cout opératoire) Business Earned Value Coûtenance: c'est le néologisme que les auteurs ont inventé pour désigner l'ensemble des méthodes permettant de maîtriser le coût des projets (analyse préalable, établissement des budgets, constatation et correction des écarts, application de la méthode aux études, aux approvisionnements et aux chantiers).
- http://www.infoq.com/news/2009/05/agile-migration-cost-justify
- Surcoût de la réduction des risques, Assurance (cycle itératif/incrémental)
- Risque de surqualité. Surqualité = qualité pour laquelle personne n’est prêt à payer. Excellence technique ! Le coûts des tests D’où vient le fameux facteur x10. Est-ce qu’il prend en compte tous les tests qui ne détecteront jamais de bug. Pour 1 ligne de code , combien de lignes de code de test ? Le code c’est la formule abstraite. Les tests c’est l’ensemble des possibilités => Combinatoire. Coût de maintenance des tests Les tests sont des lignes de code supplémentaires qui ont eux-aussi des bugs. Dette technique quand on ne fait pas de l’Agile. Un passif se crée au niveau du code. De test non écrits, de non refactoring. « As you can see Agile provides tremendous value and not necessarily project cost savings . » Cette dette sera potentiellement à payer. http://www.lostechies.com/blogs/joe_ocampo/archive/2007/09/20/agile-vs-traditional-development-cost-models-maybe.aspx Kent Beck (auteur de XP explained et TDD by Exempl) Suggests Skipping Testing for Very Short Term Projects http://www.infoq.com/news/2009/06/test-or-not JUnit Max reports all internal errors to a central server so that Kent can be aware of problems as they come up. This error log helped find two issues. For the first he was able to write a simple test that reproduced the problem and verified the fix. The second problem was easily fixed, but Kent estimated it would take several hours to write a test for it. In this case he just fixed it and shipped. ========= Idealiste: Kent Beck qui a du mal à se faire payer http://www.threeriversinstitute.org/blog/?p=231 Show me the money à lire http://www.infoq.com/news/2009/05/agile-migration-cost-justify
- Une comparaison futile Pas le même contenu (moins de doc + plus de tests et de qualité) Consensus sur le fait que c’est impossible à comparer en pratique L’agilité est une évidence Surcoût de la réduction des risques, Assurance (cycle itératif/incrémental) Champs d’application différents Projets à risques (spécifications qui changent, Moyen de résoudre un problème complexe avec une approche bottom-up même si le cahier des charges est fixe.) Projets à opportunité Projets à longue vie ..ni un argument de vente
- http://www.martinfowler.com/bliki/FixedPrice.html http://www.ambysoft.com/essays/whyAgileWorksFeedback.html Projet au forfait (fixed-price): * Non: on s’engage sur un budget et une durée et un scope ouvert Alistair Cockburn (créateur de Crystal Clear) Martin Fowler (OO, refactoring, analysis pattern, planning XP, UML) : Les méthodes agiles déconseillent le mode Forfait. Sinon il est conseillé de ne pas s’engager sur le périmètre ;-) (Martin Fowler) Illusion des approches agiles: sharing risks, on peut changer les règles du business (fixed prices), productivité <> Vélocity http://www.agilekiwi.com/gurus_on_contracts.htm Cockburn: « Secondly, we must consider what a fixed price contract really is. A fixed price contract is based on an estimate of the work required. Customers don't want fixed contracts because estimates are good ; they want fixed contracts because estimates are bad . The actual effort never matches the estimate, and fixed price contracts are simply a way of making the supplier responsible for the difference. » En fait ils sont d’accords mais ne parlent pas de la même chose. Il ne peut pas y avoir de fixed Price si les exigences changent. MF pense que l’agilité est réservé à des projets qui évoluent et A.C. dit qu’on gagne en productivité mais on ne pourra pas bénéficier de certaines choses (profiter sur une opportunité) Une solution est de pouvoir sortir du projet à chaque itération/release si la performance n’est pas suffisante et que le presta voit qu’il va perdre de l’argent.
- Pas besoin d’adaptation de la technique de la valeur acquise Personne ne veut de la qualité à tout prix ! Gagner la confiance du management avec une gestion rigoureuse, notamment en matière de coût => sortir de la marginalité, épiphénomène