Projets Agiles et Gestion des Coûts www.TimePerformance.com par Renaud Choné
Introduction <ul><li>Le constat  </li></ul><ul><li>Les méthodes Agiles n’abordent que très peu le domaine des coûts </li><...
1. Pourquoi Gérer les coûts ?
Les motivations <ul><li>Par Obligation </li></ul><ul><li>Pour gérer le projet </li></ul><ul><ul><li>Prise de décision </li...
2. La Gestion des Coûts
Qu’est-ce que c’est ? <ul><li>Le budget (référentiel de coût) </li></ul><ul><li>Le suivi des dépenses </li></ul><ul><li>Le...
<ul><li>Origine: D.O.D, U.S. Government 50s-60s </li></ul><ul><li>Earned Value Management (EVM)  Earned Value Analysis (EV...
Les formules de la valeur acquise Source
… et encore des formules Source
Plutôt indigeste, non ? CBTP ? CBTE ? CRTE ? CPI ? SPI ? BAT ? EC ?
Retour à l’essentiel <ul><li>La seule technique de contrôle des coûts </li></ul><ul><li>Un seul nouveau concept </li></ul>...
Retour à l’essentiel <ul><li>Pourquoi c’est indispensable ? </li></ul><ul><li>AgileEVM, Budget and Time Chart... </li></ul>
Le diagramme de la Valeur Acquise Outil pour l’Agilité Simple, Efficace, Visuel.
Interprétation du diagramme VA Valeur Acquise > Coût réel    économies par rapport au budget. Valeur Acquise > Coût budgé...
« La situation problématique »
« En avance mais attention aux coûts ! »
« En retard mais surperforme »
Dépense > mais en Avance
Dépense < mais en Retard
L’estimé à terme (EAC) <ul><li>EAC = Coût réalisé + Estimation du coût restant </li></ul><ul><li>Coût restant = Estimation...
Spécificités des projets Agiles <ul><li>Estimer le connu & Budgéter l’inconnu </li></ul><ul><li>Utiliser la Valeur Acquise...
Sujets connexes <ul><li>Coût facturé / Coût de revient  </li></ul><ul><li>Coût de ne pas faire </li></ul><ul><li>Indicateu...
3. Les Projets Agiles coûtent-ils moins chers ?
Les Projets Agiles coûtent moins chers… <ul><li>+ de chances de succès </li></ul><ul><li>Equipes plus productives </li></u...
Etude sur les Projets Agiles http://www.ambysoft.com/surveys/agileFebruary2008.html   Scott Ambler
…  ou plus chers ? <ul><li>Risque de surqualité </li></ul><ul><li>Coût des tests </li></ul><ul><li>Itératif = tâtonner </l...
Le coût dans le choix de l’Agilité <ul><li>Une comparaison futile </li></ul><ul><ul><li>Pas le même contenu </li></ul></ul...
Projets Agiles au forfait ? <ul><li>L’avis de 2 signataires du Manifeste Agile </li></ul>http://www.agilekiwi.com/contract...
Conclusion <ul><li>Coûts: Pas une justification, juste une composante des projets agiles </li></ul><ul><li>Une seule techn...
Questions ? [email_address] www.TimePerformance.com
Prochain SlideShare
Chargement dans…5
×

Gestion des coûts et Projets Agiles

6 359 vues

Publié le

Présentation sur la gestion des coûts pour les projets agiles (Agile Tour 2010)

Publié dans : Business
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
6 359
Sur SlideShare
0
Issues des intégrations
0
Intégrations
889
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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é &lt;&gt; 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 &lt; 40 points, petit &lt; 100 Points, moyen &lt; 300 Points, grand &lt; 1000 Points et très grand au delà micro &lt; 6 MH, petit &lt; 12 MH, moyen &lt; 30 MH, grand &lt; 100MH, très grand &gt; 100 MH micro &lt;10k€, petit &lt; 100k€, moyen &lt; 1M€, grand &lt; 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&apos;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&apos;apporte que peu de valeur au projet.  » Donc s&apos;il n&apos;y a pas de valeur acquise, il n&apos;y a pas de contrôle des coûts.   (Et dans ce cas, y-a-t&apos;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&apos;en fait plus qu&apos;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&apos;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&apos;apporte que peu de valeur au projet.  » Donc s&apos;il n&apos;y a pas de valeur acquise, il n&apos;y a pas de contrôle des coûts.   (Et dans ce cas, y-a-t&apos;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&apos;en fait plus qu&apos;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&apos;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&apos;avance est suffisante pour justifier le surcoût. (retoucher pour enlever la valeur acquise)
  • Visualiser immédiatement les causes d&apos;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 &lt;&gt; 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=&gt; taux d’actualisation pour lequel NPV = 0 Coût global (cout de dev + cout opératoire) Business Earned Value Coûtenance: c&apos;est le néologisme que les auteurs ont inventé pour désigner l&apos;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 =&gt; 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é &lt;&gt; 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&apos;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 =&gt; sortir de la marginalité, épiphénomène
  • Gestion des coûts et Projets Agiles

    1. 1. Projets Agiles et Gestion des Coûts www.TimePerformance.com par Renaud Choné
    2. 2. Introduction <ul><li>Le constat </li></ul><ul><li>Les méthodes Agiles n’abordent que très peu le domaine des coûts </li></ul><ul><li>L’approche traditionnelle définit la théorie mais ne l’applique pas </li></ul><ul><li>Pourquoi ? </li></ul><ul><li>Agilité focalisée sur le processus et l’équipe de développement </li></ul><ul><li>Gestion de Projet vs Gestion de Produit </li></ul><ul><li>Rien de nouveau à ajouter par rapport à l’approche traditionnelle ? </li></ul>
    3. 3. 1. Pourquoi Gérer les coûts ?
    4. 4. Les motivations <ul><li>Par Obligation </li></ul><ul><li>Pour gérer le projet </li></ul><ul><ul><li>Prise de décision </li></ul></ul><ul><ul><li>Pilotage </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><li>Pour son CV </li></ul>
    5. 5. 2. La Gestion des Coûts
    6. 6. Qu’est-ce que c’est ? <ul><li>Le budget (référentiel de coût) </li></ul><ul><li>Le suivi des dépenses </li></ul><ul><li>Le suivi de la performance </li></ul><ul><ul><li>Valeur Acquise </li></ul></ul><ul><li>L’analyse des coûts </li></ul>
    7. 7. <ul><li>Origine: D.O.D, U.S. Government 50s-60s </li></ul><ul><li>Earned Value Management (EVM) Earned Value Analysis (EVA) </li></ul><ul><li>Objectif: Mesurer la performance </li></ul><ul><li>Incluse dans tous les référentiels traditionnels </li></ul><ul><ul><ul><li>PMBoK, IPMA, ITIL, Prince2, ANSI… </li></ul></ul></ul>La gestion de la valeur acquise
    8. 8. Les formules de la valeur acquise Source
    9. 9. … et encore des formules Source
    10. 10. Plutôt indigeste, non ? CBTP ? CBTE ? CRTE ? CPI ? SPI ? BAT ? EC ?
    11. 11. Retour à l’essentiel <ul><li>La seule technique de contrôle des coûts </li></ul><ul><li>Un seul nouveau concept </li></ul><ul><li>Définition intuitive de la valeur acquise </li></ul>
    12. 12. Retour à l’essentiel <ul><li>Pourquoi c’est indispensable ? </li></ul><ul><li>AgileEVM, Budget and Time Chart... </li></ul>
    13. 13. Le diagramme de la Valeur Acquise Outil pour l’Agilité Simple, Efficace, Visuel.
    14. 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 ……………….
    15. 15. « La situation problématique »
    16. 16. « En avance mais attention aux coûts ! »
    17. 17. « En retard mais surperforme »
    18. 18. Dépense > mais en Avance
    19. 19. Dépense < mais en Retard
    20. 20. L’estimé à terme (EAC) <ul><li>EAC = Coût réalisé + Estimation du coût restant </li></ul><ul><li>Coût restant = Estimation initiale / Indice de performance </li></ul>
    21. 21. Spécificités des projets Agiles <ul><li>Estimer le connu & Budgéter l’inconnu </li></ul><ul><li>Utiliser la Valeur Acquise sur des périodes plus petites (release ou sprint) </li></ul><ul><li>Outillage pour prendre en compte facilement les évolutions (comme pour les tests) </li></ul><ul><li>Donner de la visibilité à l’instant t </li></ul>
    22. 22. Sujets connexes <ul><li>Coût facturé / Coût de revient </li></ul><ul><li>Coût de ne pas faire </li></ul><ul><li>Indicateurs financiers </li></ul><ul><ul><li>BCR , ROI </li></ul></ul><ul><ul><li>Net Present Value </li></ul></ul><ul><ul><li>Internal Rate of Return </li></ul></ul><ul><ul><li>Payback Period </li></ul></ul><ul><ul><li>Coût global (TCO) </li></ul></ul>
    23. 23. 3. Les Projets Agiles coûtent-ils moins chers ?
    24. 24. Les Projets Agiles coûtent moins chers… <ul><li>+ de chances de succès </li></ul><ul><li>Equipes plus productives </li></ul><ul><li>Qualité supérieure </li></ul><ul><li>Clients plus satisfaits </li></ul><ul><li>Les projets Agiles coûtent moins chers </li></ul>
    25. 25. Etude sur les Projets Agiles http://www.ambysoft.com/surveys/agileFebruary2008.html Scott Ambler
    26. 26. … ou plus chers ? <ul><li>Risque de surqualité </li></ul><ul><li>Coût des tests </li></ul><ul><li>Itératif = tâtonner </li></ul><ul><li>Faut-il payer la dette technique ? </li></ul>
    27. 27. Le coût dans le choix de l’Agilité <ul><li>Une comparaison futile </li></ul><ul><ul><li>Pas le même contenu </li></ul></ul><ul><ul><li>Impossible à comparer en pratique </li></ul></ul><ul><li>L’Agilité = Assurance contre les risques + Capacité à saisir des opportunités </li></ul><ul><li>Le contexte du projet impose le choix de l’Agilité </li></ul><ul><li>Le coût ne doit pas être un critère pour le choix de l’approche Agile ou non </li></ul>
    28. 28. Projets Agiles au forfait ? <ul><li>L’avis de 2 signataires du Manifeste Agile </li></ul>http://www.agilekiwi.com/contracts_for_agile_projects.htm Be Pragmatic not Dogmatic OUI Alistair Cockburn http://www.agilekiwi.com/fixed_price_contracts.htm http://www.agilekiwi.com/fixed_price_contracts.htm www.martinfowler.com/bliki/FixedPrice.html NON * Martin Fowler NON * www.martinfowler.com/bliki/FixedPrice.html NON * Martin Fowler NON *
    29. 29. Conclusion <ul><li>Coûts: Pas une justification, juste une composante des projets agiles </li></ul><ul><li>Une seule technique: la Valeur Acquise </li></ul><ul><li>Valeur acquise : un outil pour l’Agilité </li></ul><ul><ul><li>Simplicité, Visibilité, Crédibilité++ </li></ul></ul><ul><ul><li>Facilite l’adoption de l’Agile par le Management </li></ul></ul>
    30. 30. Questions ? [email_address] www.TimePerformance.com

    ×