Your SlideShare is downloading. ×
0
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Agile expliqué aux managers
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile expliqué aux managers

3,756

Published on

Qu'est-ce que la méthode Agile? Est-ce la bonne méthode pour votre organisaiton ? Quels sont les impacts de son adoption?

Qu'est-ce que la méthode Agile? Est-ce la bonne méthode pour votre organisaiton ? Quels sont les impacts de son adoption?

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,756
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
263
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Insist on Highsmith’s citation Agile Manifesto 2001
  • Take time to review the 3 parts No silver bullet (part 1) Practice (part 1) Discuss the balance Review the 13 Principles (not shown here)
  • CLASSIFICATION Roles (Customer, Development Team, Scrum Master, Chicken) A pig and chicken discussed the name of their new restaurant. The chicken suggested Ham n’ Eggs. “No thanks” said the pig, “I‘d be committed, but you’d only be involved. Backlog Graph not shown on the image Pre Sprint Planning Sprint Post-Sprint Meeting (Software – No powerpoint) Monitoring progress
  • DSDM (Dynamic Solutions Delivery Model) Formalization of RAD practices 3 timeboxed iteration models FDD Develop an overall model Build a feature lists Plan by feature Design by feature Build by feature
  • il faut redonner une fierté à notre profession Contrer l’outsourcing en étant plus productif Déjà une amélioration vs le rapport de 1994 (16% success, 53%, challenged, 31% echec)
  • Poppendiek: Software Development Productivity
  • Poppendiek: 7 wastes
  • R évisé avec Nath jusqu’ICI
  • This deep appreciation – that building software is complex product development with high change rates, and not predictable manufacturing – is at the heart of the motivation for agile and iterative methods.
  • Poppendiek: 7 wastes
  • Saying that software development is a cooperative game of communication implies that a project's rate of progress is linked to how long it takes information to get from one person’s mind to another’s.. If Marie knows something that Pat needs, the project's progress depends on How long it takes Paul to discover that Marie knows something useful How much energy it costs Paul and Marie together to get the knowledge transferred to Paul While writing, reading, typing, or talking, we pick up traces of the ongoing sounds around us, using some background listening mode even though we are not consciously paying attention. If someone says something interesting, we may perk up and join the conversation. Otherwise, the sound goes through some background processing, either just above or just below our conscious level. In some cases, we register enough about the conversation to be able to develop what we need directly from memory. Otherwise, we may recall a phrase that was used or perhaps only that a particular person was discussing a particular topic. In any case, we register enough to ask about it. This taking in of information without directly paying attention to it is like the process of osmosis, in which one substance seeps from one system, through a separator, into another. Osmotic communication further lowers the cost of idea transfer. We have seen three separate effects that office layout has on communication costs within a project: The lost opportunity cost of not asking questions The overall cost of detecting and transferring information (erg-seconds) The reduction in cost when people discover information in background sounds (osmotic communication)
  • This deep appreciation – that building software is complex product development with high change rates, and not predictable manufacturing – is at the heart of the motivation for agile and iterative methods.
  • Overview d’un processus Agile: Itératif Incrémentale Timeboxing Product Backlog Étapes du processus Planification Développement (Desing) Acceptance
  • Other point of view. 3. Example at Pyxis – Focusing on improving one practice at a time IT IS IMPORTANT TO UNDERSTAND THE DIFFERENCE BETWEEN EMPIRICAL VS DEFINED & PRESCRIPTIVE PROCESS IT IS IMPORTANT TO UNDERSTAND THE DIFFERENCE BETWEEN PRINCIPLE-BASED VERSUS RULE BASED. AGILE PROJECT MANAGEMENT IS MORE THAN A SET OF PRACTICES – IT IS A MINDSET RECOGNIZE FACTORS SUCH AS : ENJOYMENT, SIMPLICITY, SHORT TERM REWARD, PEER PRESSURE
  • 1. Deliver working software in small iterations, early and often. 2. Gather frequent feedback, hold retrospectives, learn and adjust. 3. Work in colocated, collaborative, multi-discipline teams. 4. Empower your teams with shared vision and responsibility. 5. Use direct, immediate communication (talk a lot). 6. Break work in to small tasks, performed just-in-time. 7. Maintain high quality and good design - avoid "debt." 8. Strive for simple and minimal solutions. 9. Work with a sustainable, predictable pace. 10. Have fun!
  • 1. Deliver working software in small iterations, early and often. 2. Gather frequent feedback, hold retrospectives, learn and adjust. 3. Work in colocated, collaborative, multi-discipline teams. 4. Empower your teams with shared vision and responsibility. 5. Use direct, immediate communication (talk a lot). 6. Break work in to small tasks, performed just-in-time. 7. Maintain high quality and good design - avoid "debt." 8. Strive for simple and minimal solutions. 9. Work with a sustainable, predictable pace. 10. Have fun!
  • 1. Deliver working software in small iterations, early and often. 2. Gather frequent feedback, hold retrospectives, learn and adjust. 3. Work in colocated, collaborative, multi-discipline teams. 4. Empower your teams with shared vision and responsibility. 5. Use direct, immediate communication (talk a lot). 6. Break work in to small tasks, performed just-in-time. 7. Maintain high quality and good design - avoid "debt." 8. Strive for simple and minimal solutions. 9. Work with a sustainable, predictable pace. 10. Have fun!
  • Transcript

    • 1. Stéphane Lécuyer [email_address] La méthode Agile… Pour qui, pourquoi ?
    • 2. Objectifs de la présentation <ul><li>Vous informer à propos des approches Agile et vous faire part des principes </li></ul><ul><li>Aller au-delà des idées préconçues </li></ul><ul><li>Vous permettre d’affiner votre réflexion pour l’adoption d’Agile dans votre organisation </li></ul>
    • 3. Déroulement <ul><li>Agile… pourquoi ? </li></ul><ul><li>Agile… les impacts ? </li></ul><ul><li>Agile dans mon organisation ? </li></ul><ul><li>Conclusion </li></ul>
    • 4. Agile… pourquoi ? <ul><li>Qu’est-ce qu’Agile ? </li></ul><ul><ul><li>Survol et définitions </li></ul></ul><ul><ul><li>Écosystèmes Agile </li></ul></ul><ul><li>Motivations </li></ul><ul><ul><li>ROI </li></ul></ul><ul><ul><li>Complexité </li></ul></ul><ul><ul><li>Communication </li></ul></ul>
    • 5. Agilité – Définitions <ul><li>L’Agilité est l’habilité de créer et de répondre au changement dans le but d’avoir du succès dans un environnement d’affaires turbulent. - Jim Highsmith </li></ul><ul><li>Certaines problématiques sont difficiles, certains individus sont difficiles. Les méthodes Agile ne sont pas une garantie de succès. - Craig Larman </li></ul><ul><li>Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente, mais celle qui s’adapte le mieux - Charles Darwin </li></ul>
    • 6. Le Manifeste Agile <ul><li>Février 2001, 17 leaders en développement « léger » se rencontre. </li></ul><ul><li>Adoption du terme « Agile » </li></ul><ul><li>Entente sur l’ensemble des valeurs fondamentales qui devraient être à la base de toutes les méthodologies Agile. </li></ul><ul><li>De ces valeurs, 12 principes fondamentaux en sont extraits. </li></ul><ul><li>Le détail des opérations a été laissé au bon soin des diverses méthodologies Agile. </li></ul>
    • 7. Survol – Manifeste Agile <ul><li>Nous sommes à découvrir de meilleures manières pour développer des logiciels en aidant les autres et en développant nous-mêmes. </li></ul><ul><li>Par ce travail, nous en sommes venus à valoriser: </li></ul><ul><li>les individus et les interactions davantage </li></ul><ul><ul><li>que les processus et les outils </li></ul></ul><ul><li>les logiciels fonctionnels davantage </li></ul><ul><ul><li>que la documentation détaillée </li></ul></ul><ul><li>la collaboration avec le client davantage </li></ul><ul><ul><li>que la négociation de contrat </li></ul></ul><ul><li>la réponse au changement davantage </li></ul><ul><ul><li>que le suivi d&apos;un plan </li></ul></ul><ul><li>En fait, bien que les éléments de droite soient importants, nous considérons que les éléments de gauche le sont encore plus. </li></ul>
    • 8. Agilité – Les Valeurs <ul><li>Les individus et les interactions davantage que les processus et les outils </li></ul><ul><li>Optimiser la communication et la collaboration </li></ul><ul><li>Produire des solutions logicielles utiles </li></ul><ul><li>Réduire les inefficacités </li></ul><ul><li>Gérer la complexité </li></ul>Nous sommes à découvrir de meilleures manières pour développer des logiciels. Par ce travail, nous en sommes venus à valoriser: Manifesto Agile, Février 2001 <ul><li>Le logiciel fonctionnel davantage que la documentation détaillée </li></ul><ul><li>La collaboration avec le client davantage que la négociation de contrat </li></ul><ul><li>La réponse au changement davantage que le suivi d’un plan </li></ul>
    • 9. Les Principes Agile <ul><li>La priorité est de satisfaire le client par la livraison rapide et continuelle de solutions logicielles utiles. </li></ul><ul><li>Intégrer les changements, même ceux de dernière minute, car ils fourniront un avantage compétitif à votre client. </li></ul><ul><li>Élaborez des projets autour d’individus motivés, fournissez le support nécessaire et faites confiance. </li></ul><ul><li>Les meilleures solutions émergent des équipes auto organisées. </li></ul><ul><li>Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence </li></ul><ul><li>Porter une attention continue à l’excellence technique et à un bon design améliore l’agilité . </li></ul><ul><li>La simplicité est essentielle </li></ul>
    • 10. Principes – les Individus <ul><li>Le processus est uniquement un effet de deuxième ordre. L’unicité des individus, leurs émotions et qualités ainsi que la communication ont une plus grande influence. - Alistair Cockburn </li></ul><ul><li>Élaborez des projets autour d’individus motivés, fournissez le support nécessaire et faites confiance. </li></ul><ul><li>Les meilleurs solutions émergent des équipes auto organisées. </li></ul><ul><li>Les gens d’affaires et les gens techniques doivent collaborer tout au long du projet </li></ul>
    • 11. Principes – le Logiciel <ul><li>La priorité est de satisfaire le client par la livraison rapide et continuelle de solutions logicielles utiles. </li></ul><ul><li>Le logiciel fonctionnel est la principale mesure de progrès. </li></ul><ul><li>Intégrer les changements, même ceux de dernière minute, car ils fourniront un avantage compétitif à votre client. </li></ul>
    • 12. Principes – l’Amélioration continue <ul><li>L’agilité n’est pas un item que l’on peut rayer de la liste de nos initiatives organisationnelles. C’est une façon de vivre. </li></ul><ul><li>Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence. </li></ul><ul><li>Porter une attention continue à l’excellence technique et à un bon design améliore l’agilité . </li></ul><ul><li>La simplicité est essentielle </li></ul>
    • 13. Agile… pourquoi ? <ul><li>Qu’est-ce qu’Agile ? </li></ul><ul><ul><li>Survol et définitions </li></ul></ul><ul><ul><li>Écosystèmes Agile </li></ul></ul><ul><li>Motivations </li></ul><ul><ul><li>ROI </li></ul></ul><ul><ul><li>Complexité </li></ul></ul><ul><ul><li>Communication </li></ul></ul>
    • 14. Agilité : définition
    • 15. Écosystème Agile – Contributions de Scrum <ul><li>Très bonne explication et application d’un processus empirique. </li></ul><ul><li>Simple et « facile » à mettre en place. </li></ul><ul><li>Niveau de « cérémonie » ajustable. </li></ul><ul><li>Applicable avec diverses pratiques d’ingénierie de logiciels. </li></ul><ul><li>Compagnon parfait pour effectuer une transition Agile </li></ul>
    • 16. Écosystème Agile – XP
    • 17. Écosystème Agile – Contributions de XP <ul><li>A généré le plus d’intérêt. </li></ul><ul><li>Est le plus concret en termes de pratiques spécifiques. </li></ul><ul><li>A ravivé l’intérêt pour les bonnes pratiques d’ingénierie de logiciels. </li></ul><ul><li>Les débats et discussions animés par la communauté XP ont été grandement bénéfiques à notre profession. </li></ul><ul><li>Valeurs : engagement, simplicité, rétroaction, courage. </li></ul>
    • 18. Écosystèmes Agiles – Autres <ul><li>Adaptive Software Development </li></ul><ul><li>Crystal Clear </li></ul><ul><li>FDD </li></ul><ul><li>DSDM </li></ul><ul><li>Agile Modeling </li></ul><ul><li>Lean Development </li></ul><ul><li>MSF for Agile Software Development </li></ul><ul><li>RUP? (AUP) </li></ul>
    • 19. Agile… pourquoi ? <ul><li>Qu’est-ce qu’Agile ? </li></ul><ul><ul><li>Survol et définitions </li></ul></ul><ul><ul><li>Écosystèmes Agile </li></ul></ul><ul><li>Motivations </li></ul><ul><ul><li>ROI </li></ul></ul><ul><ul><li>Complexité </li></ul></ul><ul><ul><li>Communication </li></ul></ul>
    • 20. Motivations – Succès ! Standish Group CHAOS Report, 2003 Réussite : Le projet est complété en temps, selon le budget et contient les fonctionnalités initialement prévues. Problèmes : Le projet est complété et opérationnel, mais il y a eu dépassement de coût et de budget. De plus, certaines fonctionnalités originalement spécifiées sont manquantes. Échec : Le projet à été annulé en cours de développement
    • 21. Motivations – ROI <ul><li>Réduire les coûts </li></ul><ul><ul><li>En optimisant le processus de développement </li></ul></ul><ul><ul><li>En éliminant les fonctionnalités superflus </li></ul></ul><ul><li>Augmenter les revenus </li></ul><ul><ul><li>En maximisant la valeur du logiciel </li></ul></ul><ul><ul><li>En capitalisant sur les investissements le plus tôt et le plus fréquemment possible </li></ul></ul>
    • 22. ROI - Processus inefficace <ul><li>Changements de tâches fréquents </li></ul><ul><li>Travail en trop </li></ul><ul><li>Paperasse </li></ul><ul><li>Réunionnite </li></ul><ul><li>Délais </li></ul><ul><li>Transferts (inter-projets) </li></ul><ul><li>Défectuosités (inventaire) </li></ul>
    • 23. ROI – fonctionnalités superflus Jim Johnson, Standish Group, XP 2002
    • 24. ROI – Valeur du logiciel
    • 25. ROI - Capitalization Hakan Herdogmus, GUAM 2005
    • 26. Motivations – Complexité <ul><li>Les individus ajoutent un autre niveau de complexité </li></ul>Spécifications Technologie
    • 27. Motivations – Complexité <ul><li>Développement d’un nouveau produit vs Fabrication prévisible </li></ul><ul><ul><li>Impossible de créer des spécifications complètes et détaillées d&apos;avance </li></ul></ul><ul><ul><li>Impossible d’estimer avec précision l’effort et le coût. </li></ul></ul><ul><ul><li>Le taux de changement est élevé. </li></ul></ul><ul><li>Étant donné que la fabrication prévisible n’est pas le bon paradigme pour le développement logiciel, les pratiques et les valeurs qui y sont enracinées ne sont pas utiles. </li></ul>
    • 28. <ul><li>Le développement de logiciel est un jeu collaboratif d&apos;invention et de communication </li></ul><ul><li>Alistair Cockburn </li></ul><ul><li>Optimisation des canaux de communication </li></ul><ul><ul><li>Client : Clarifier les besoins </li></ul></ul><ul><ul><li>Équipe : Collaborer, Innover, Apprendre </li></ul></ul><ul><ul><li>Management : Communiquer le progrès et les obstacles </li></ul></ul>Motivations- Communication
    • 29. Quel type de communication est le plus efficace ?
    • 30. À quelle vitesse transférons-nous l’information ? Configuration Cubicule Configuration « War Room »
    • 31. Motivations – Résumé <ul><li>Nous sommes donc à la recherche d’une approche qui nous permettra de: </li></ul><ul><ul><li>Produire des solutions logicielles utile à nos clients </li></ul></ul><ul><ul><li>Réduire les inefficacités </li></ul></ul><ul><ul><li>Gérer la complexité </li></ul></ul><ul><ul><li>Optimiser la communication </li></ul></ul>
    • 32. Déroulement <ul><li>Agile… pourquoi ? </li></ul><ul><li>Agile… les impacts ? </li></ul><ul><li>Agile dans mon organisation ? </li></ul><ul><li>Conclusion </li></ul>
    • 33. Agile… les impacts <ul><li>Impact organisationnel </li></ul><ul><ul><ul><li>Processus </li></ul></ul></ul><ul><ul><ul><li>Culture </li></ul></ul></ul><ul><ul><ul><li>Livraison (par les tests) </li></ul></ul></ul><ul><ul><ul><li>Gestion de projet </li></ul></ul></ul>
    • 34. Processus Agile
    • 35. Modélisation Agile <ul><li>Compréhension initiale du projet </li></ul><ul><li>Architecture initiale </li></ul><ul><li>Exploration rapide de la fonctionnalité à développer </li></ul><ul><li>Développement évolutif de la fonctionnalité </li></ul>Scott Ambler, Agile Modeling
    • 36. Planification Agile <ul><li>Livraison: vision moyen terme (6-9 mois). </li></ul><ul><ul><li>Comprend plusieurs itérations </li></ul></ul><ul><li>Itération: vision court terme (4-6 semaines). </li></ul><ul><ul><li>Permet de développer un ensemble de fonctionnalités </li></ul></ul><ul><li>Fonctionnalité: Tranche verticale du système </li></ul><ul><ul><li>Estimé en points de fonctionnalité </li></ul></ul><ul><ul><li>Séparé en tâches </li></ul></ul><ul><li>Vélocité: Nombre de points livrables en une itération </li></ul>
    • 37. Prévisibilité: Vélocité Prévision: 9 points seront livrés
    • 38. Réévaluation constante de la date de livraison
    • 39. Tests d’acceptation Agile <ul><li>Sont automatisés </li></ul><ul><li>Sont écrits dans un langage de très haut niveau </li></ul><ul><li>Sont exécutés fréquemment </li></ul><ul><li>Sont écrit par les propriétaires du produit, les spécialistes en AQ et les analystes d’affaires </li></ul>
    • 40. À quel moment doivent-ils être écrits? <ul><li>À mesure que les fonctionnalités sont définies et développées </li></ul><ul><li>Les tests d’acceptation sont la spécification des fonctionnalités </li></ul><ul><li>Les tests deviennent le vrai document des besoins </li></ul><ul><ul><li>Un document qui est sans ambiguïté, </li></ul></ul><ul><ul><ul><li>ne peut devenir désynchronisé avec le projet, </li></ul></ul></ul><ul><ul><ul><li>est exécutable. </li></ul></ul></ul>
    • 41. Une fonctionnalité n’est pas complète… <ul><li>Tant que tous les tests d’acceptation pour cette fonctionnalité ne s’exécutent pas correctement. </li></ul><ul><li>Il n’existe pas de complétion “partielle”. </li></ul>
    • 42. Lorsque vu de cette façon… <ul><li>Les test servent à spécifier </li></ul><ul><ul><li>À quel moment le travail est complété </li></ul></ul><ul><li>Ils ne sont pas remis à la fin du processus </li></ul><ul><ul><li>En effet, l’AQ est réalisée en amont du processus pour aider à spécifier </li></ul></ul>
    • 43. Équipe Agile <ul><li>Multidisciplinaire: Généralistes-Spécialistes </li></ul><ul><li>Autonome et responsable </li></ul><ul><li>Colocalisée </li></ul><ul><li>Heures supplémentaires </li></ul><ul><li>Collaboration </li></ul><ul><li>Collaboration </li></ul><ul><li>Collaboration </li></ul>
    • 44. Gestion de projet Agile Augustine and Woodcock 1. Guiding Vision – Establish a guiding vision for the project and continuously reinforce it through words and actions. 4. Open Information – Provide visible and open access to project management and other information. 2. Teamwork &amp; Collaboration – Facilitate collaboration and teamwork through relationships and community. 5. Light Touch – Apply just enough control to foster emergent behavior in a self-directed team. 3. Simple Rules – Establish and support the team’s set of guiding practices such as Scrum or XP. 6. Agile Vigilance – Reinforce the vision, follow or adapt the rules, listen to the people.
    • 45. Déroulement <ul><li>Agile… pourquoi ? </li></ul><ul><li>Agile… les impacts ? </li></ul><ul><li>Agile dans mon organisation ? </li></ul><ul><li>Conclusion </li></ul>
    • 46. Agile dans mon organisation ? <ul><li>Le développement Agile amène certains changements de paradigmes fondamentaux </li></ul><ul><ul><li>Processus: Analyse, Design, Développement, Tests </li></ul></ul><ul><ul><li>Gestion: guider et non contrôler </li></ul></ul><ul><ul><li>Équipe: multidisciplinaire et autonome </li></ul></ul><ul><ul><li>Communication et collaboration (les individus au premier plan) </li></ul></ul><ul><ul><li>Orientation sur les buts (accent sur les résultats, valeur d’affaires ) </li></ul></ul><ul><ul><li>Lean (simplicité, processus minimal) </li></ul></ul><ul><ul><li>Rétrospection </li></ul></ul>
    • 47. Agile dans mon organisation ? <ul><li>Agile est pour vous si vous désirez: </li></ul><ul><ul><li>Livrer du logiciel fonctionnel en petites itérations, de manière rapide et fréquente </li></ul></ul><ul><ul><li>Mettre en place des techniques vous permettant d’aller chercher de la rétroaction de manière fréquente afin d’apprendre et de vous ajuster </li></ul></ul><ul><ul><li>Responsabiliser et stimuler vos équipes en partageant avec eux la vision d’affaire. </li></ul></ul><ul><ul><li>Mettre en place des mécanismes optimaux pour favoriser la communication entre les différents intervenants </li></ul></ul><ul><ul><li>Améliorer la qualité du produit fini ainsi qu’un haut niveau de design vous permettant de diminuer significativement l’ inventaire </li></ul></ul><ul><ul><li>Maintenir un rythme de production prévisible et soutenu </li></ul></ul>
    • 48. Agile dans mon organisation ? <ul><li>Agile est pour vous si vous désirez: </li></ul><ul><ul><li>Mettre l’accent sur les activités importantes (à plus grande valeur ajoutée) pour votre organisation </li></ul></ul><ul><ul><li>Effectuer des investissements beaucoup plus judicieux </li></ul></ul><ul><ul><li>Mettre en place une méthodologie qui s’intègre rapidement et s’adapte à votre réalité </li></ul></ul><ul><ul><li>AVOIR DU PLAISIR !! </li></ul></ul>
    • 49. Déroulement <ul><li>Agile… pourquoi ? </li></ul><ul><li>Agile… les impacts ? </li></ul><ul><li>Agile dans mon organisation ? </li></ul><ul><li>Conclusion </li></ul>
    • 50. If you can innovate better and faster—you create change for your competitors. If you can respond quickly to competitive initiatives, new technology and customers’ requirements—you create change for your competitors. If you are slower, less innovative, less responsive—you are doomed to survival strategies in a sea of chaos imposed by others. Jim Highsmith
    • 51. The real challenge when adopting an iterative or Agile approach is to stick to it. Whether you call your approach agile or something else doesn&apos;t matter—results do. The goal is to balance forces to develop software intelligently. In my opinion, this approach requires brutal honesty all the time. It requires radical commitment so you don&apos;t buckle under the constant pressure to quit and do things the old way. It also takes skills. Roy W. Miller
    • 52. Transition Agile <ul><li>La transition se fait sur un continuum partant d’une approche traditionnelle vers une approche Agile </li></ul><ul><li>Chaque implantation d’un processus Agile est unique et adaptée, avec des particularités qui répondent à la réalité et au fonctionnement de l’organisation cible </li></ul><ul><li>La migration vers une approche Agile se fait graduellement, en intégrant les pratiques proposées étape par étape </li></ul><ul><li>Il s’agit d’un processus d’amélioration continu </li></ul><ul><li>Appréciez la résistance </li></ul><ul><li>Faites preuve de transparence </li></ul>
    • 53. Transition – Feuille de Route
    • 54. Quelques lectures <ul><ul><li>Agile &amp; Iterative Development: A Manager&apos;s Guide par Craig Larman </li></ul></ul><ul><ul><li>Agile Software Development Ecosystems par Jim Highsmith </li></ul></ul><ul><ul><li>Agile Software Development, evaluating the methods for your organization par Alan S, Koch </li></ul></ul>Merci! Questions?

    ×