vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0
Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité ; pour satisfaire les besoins, pour mettre rapidement à disposition les logiciels ; recherche de plus de réactivité (gestion du changement continue) ;
Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité ; pour satisfaire les besoins, pour mettre rapidement à disposition les logiciels ; recherche de plus de réactivité (gestion du changement continue) ;
Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité ; pour satisfaire les besoins, pour mettre rapidement à disposition les logiciels ; recherche de plus de réactivité (gestion du changement continue) ;
Introduction Contexte Les exigences des usagers bougent aussi exigences de fonctionnalités ; exigences de qualité ; exigences de fiabilité, de robustesse ; exigences de disponibilité, d ergonomie ;...
Introduction Contexte Les exigences des usagers bougent aussi exigences de fonctionnalités ; exigences de qualité ; exigences de fiabilité, de robustesse ; exigences de disponibilité, d ergonomie ;...
Introduction Contexte Les exigences des usagers bougent aussi exigences de fonctionnalités ; exigences de qualité ; exigences de fiabilité, de robustesse ; exigences de disponibilité, d ergonomie ;...
Introduction Contexte Les exigences des usagers bougent aussi exigences de fonctionnalités ; exigences de qualité ; exigences de fiabilité, de robustesse ; exigences de disponibilité, d ergonomie ;...
Introduction Contexte Les exigences des usagers bougent aussi exigences de fonctionnalités ; exigences de qualité ; exigences de fiabilité, de robustesse ; exigences de disponibilité, d ergonomie ;...
Introduction Motivation 1 Est-il possible de produire des logiciels de qualité avec des équipes réduites? 2 Quelles activités pouvons-nous abandonner sans diminuer la qualité? 3 Comment collaborer avec les usagers pour mieux répondre à leurs attentes et être aussi réactifs que possible?
Introduction Motivation 1 Est-il possible de produire des logiciels de qualité avec des équipes réduites? 2 Quelles activités pouvons-nous abandonner sans diminuer la qualité? 3 Comment collaborer avec les usagers pour mieux répondre à leurs attentes et être aussi réactifs que possible?
Introduction Motivation 1 Est-il possible de produire des logiciels de qualité avec des équipes réduites? 2 Quelles activités pouvons-nous abandonner sans diminuer la qualité? 3 Comment collaborer avec les usagers pour mieux répondre à leurs attentes et être aussi réactifs que possible?
Les processus traditionnels Le modèle en V de l AFNOR Le cycle en V tel qu il devrait se dérouler en théorie Spécification des besoins du Logiciel 1 guide Validation du logiciel 7 Conception de l architecture du Logiciel 2 guide Tests 6 d Intégration des composants vérification validation Conception détaillée 3 Codage des composants 4 Test Unitaire 5
Les processus traditionnels Le modèle en V de l AFNOR Le cycle en V tel qu il se déroule en réalité, Spécification des besoins du Logiciel 1 Conception de l architecture du Logiciel 2 10 8 Tests 7 d Intégration des composants Validation du logiciel 9 vérification validation 5 Conception détaillée 3 Codage des composants 4 Test Unitaire 6
1 2 3 guide guide 4 5 d 6 7 Les processus traditionnels Le modèle en spirale de Barry Boehm les objectifs sont définis à chaque itération ; piloté par les risques il convient aux grands projets difficiles ; Planification Analyse des risques Décisions d engagement du cycle suivant Evaluation CdC v0 engagement financier v1 v2 Développement prototype initial deuxième prototype produit final
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Lourdeur 1 Vouloir spécifier à priori une fois pour toutes les propriétés d un système est très souvent une utopie ; 2 dans ce modèle le coût de la modification croit de façon exponentielle avec le temps ; 3 à ce contexte il faut ajouter les exigences de l assurance qualité, et du management ; 4 les processus séquentiels de développement sont lourds, coûteux et peu performant ; 5 le processus itératif de B.BOEHM est plus réaliste mais reste très lourd financièrement et très gourmand en ressources humaines ; Lourd Qui se meut avec peu d aisance et souvent avec lenteur ; Qui se caractérise par un manque de souplesse ;
Les processus traditionnels Agilité Agile Le contraire de la lourdeur ; Légèreté, souplesse dans les mouvements ; Qui manifeste de la promptitude et de l aisance quel que soit l environnement ; Agile c est le trait de caractère fondateur de XP
Les auteurs Proposé par Kent Beck et Ron Jeffries pendant le projet C3 (Chrysler Comprehensive Compensation System), le terme devient public avec la parution en 2000 de l ouvrage Extreme Programming Explained de Kent Beck. Ward Cunningham est avec Kent Beck un acteur très actif dans le domaine de Design Patterns, domaine qui a beaucoup inspiré XP. Ken Beck Ron Jeffries Ward Cunningham
En 2001 17 personnalités du Genie Logiciel signent l Agile Manifesto, ce manifeste fonde est à la fois 1 un processus de développement ; 2 un état d esprit et des valeurs ; 3 un ensemble de bonnes pratiques.
En 2001 17 personnalités du Genie Logiciel signent l Agile Manifesto, ce manifeste fonde est à la fois 1 un processus de développement ; 2 un état d esprit et des valeurs ; 3 un ensemble de bonnes pratiques.
En 2001 17 personnalités du Genie Logiciel signent l Agile Manifesto, ce manifeste fonde est à la fois 1 un processus de développement ; 2 un état d esprit et des valeurs ; 3 un ensemble de bonnes pratiques.
XP s articule autour de quelques idées simples : 1 le client est dans l arène avec les développeurs ; 2 le développement est itératif, et les itérations sont courtes (2 semaines en moyenne) ; 3 les développeurs sont polyvalents et inter-opérables (compétences et connaissances) ; 4 chaque composant est vérifié par une campagne de tests automatisés ; 5 chaque itération doit être validé par le client.
XP s articule autour de quelques idées simples : 1 le client est dans l arène avec les développeurs ; 2 le développement est itératif, et les itérations sont courtes (2 semaines en moyenne) ; 3 les développeurs sont polyvalents et inter-opérables (compétences et connaissances) ; 4 chaque composant est vérifié par une campagne de tests automatisés ; 5 chaque itération doit être validé par le client.
XP s articule autour de quelques idées simples : 1 le client est dans l arène avec les développeurs ; 2 le développement est itératif, et les itérations sont courtes (2 semaines en moyenne) ; 3 les développeurs sont polyvalents et inter-opérables (compétences et connaissances) ; 4 chaque composant est vérifié par une campagne de tests automatisés ; 5 chaque itération doit être validé par le client.
XP s articule autour de quelques idées simples : 1 le client est dans l arène avec les développeurs ; 2 le développement est itératif, et les itérations sont courtes (2 semaines en moyenne) ; 3 les développeurs sont polyvalents et inter-opérables (compétences et connaissances) ; 4 chaque composant est vérifié par une campagne de tests automatisés ; 5 chaque itération doit être validé par le client.
XP s articule autour de quelques idées simples : 1 le client est dans l arène avec les développeurs ; 2 le développement est itératif, et les itérations sont courtes (2 semaines en moyenne) ; 3 les développeurs sont polyvalents et inter-opérables (compétences et connaissances) ; 4 chaque composant est vérifié par une campagne de tests automatisés ; 5 chaque itération doit être validé par le client.
la première phase expression initiale des besoins dure un mois (en moyenne) ; la première phase produit un prototype opérationnel ; à chaque itération on choisi les scenarii à réaliser en deux semaines (en moyenne) ;... le cycle XP ecriture, choix et plannification des scenarii du cycle suivant Spécification initiale des besoins redaction des principaux scenarii choix des scenarii réalisés dans la première itération Evaluation v1 v0 CdC Developpement, programmation, test, amélioration continue v2 livraison de version opérationnelle à chaque cycle
la première phase expression initiale des besoins dure un mois (en moyenne) ; la première phase produit un prototype opérationnel ; à chaque itération on choisi les scenarii à réaliser en deux semaines (en moyenne) ;... le cycle XP ecriture, choix et plannification des scenarii du cycle suivant Spécification initiale des besoins redaction des principaux scenarii choix des scenarii réalisés dans la première itération Evaluation v1 v0 CdC Developpement, programmation, test, amélioration continue v2 livraison de version opérationnelle à chaque cycle
la première phase expression initiale des besoins dure un mois (en moyenne) ; la première phase produit un prototype opérationnel ; à chaque itération on choisi les scenarii à réaliser en deux semaines (en moyenne) ;... le cycle XP ecriture, choix et plannification des scenarii du cycle suivant Spécification initiale des besoins redaction des principaux scenarii choix des scenarii réalisés dans la première itération Evaluation v1 v0 CdC Developpement, programmation, test, amélioration continue v2 livraison de version opérationnelle à chaque cycle
le rôle du client C est un des élément clef de XP le client pilote les objectifs opérationnels de chaque itération, en choisissant les scenarii qui seront réalisés ; ce faisant il définit les priorités ; il réceptionne et évalue chaque prototype (éventuellement avec d autres usagers) ; il a la possibilité d orienter le développement en fonction des réactions des usagers, par les choix des scenarii suivants ; le choix de cette personne est un point sensible, en toute circonstance il est le représentant (délégué) de la maîtrise d ouvrage ;
le rôle du client C est un des élément clef de XP le client pilote les objectifs opérationnels de chaque itération, en choisissant les scenarii qui seront réalisés ; ce faisant il définit les priorités ; il réceptionne et évalue chaque prototype (éventuellement avec d autres usagers) ; il a la possibilité d orienter le développement en fonction des réactions des usagers, par les choix des scenarii suivants ; le choix de cette personne est un point sensible, en toute circonstance il est le représentant (délégué) de la maîtrise d ouvrage ;
le rôle du client C est un des élément clef de XP le client pilote les objectifs opérationnels de chaque itération, en choisissant les scenarii qui seront réalisés ; ce faisant il définit les priorités ; il réceptionne et évalue chaque prototype (éventuellement avec d autres usagers) ; il a la possibilité d orienter le développement en fonction des réactions des usagers, par les choix des scenarii suivants ; le choix de cette personne est un point sensible, en toute circonstance il est le représentant (délégué) de la maîtrise d ouvrage ;
le rôle du client C est un des élément clef de XP le client pilote les objectifs opérationnels de chaque itération, en choisissant les scenarii qui seront réalisés ; ce faisant il définit les priorités ; il réceptionne et évalue chaque prototype (éventuellement avec d autres usagers) ; il a la possibilité d orienter le développement en fonction des réactions des usagers, par les choix des scenarii suivants ; le choix de cette personne est un point sensible, en toute circonstance il est le représentant (délégué) de la maîtrise d ouvrage ;
le rôle du client C est un des élément clef de XP le client pilote les objectifs opérationnels de chaque itération, en choisissant les scenarii qui seront réalisés ; ce faisant il définit les priorités ; il réceptionne et évalue chaque prototype (éventuellement avec d autres usagers) ; il a la possibilité d orienter le développement en fonction des réactions des usagers, par les choix des scenarii suivants ; le choix de cette personne est un point sensible, en toute circonstance il est le représentant (délégué) de la maîtrise d ouvrage ;
le scénario XP Inspiré des Use Case de Ivar Jacobson un scénario XP est l expression informelle d un usage élémentaire. C est aussi l unité de développement d XP. Les scenarii sont rédigés en langue naturelle, un scénario doit pouvoir être réalisé dans une itération. (ce qui ne veut pas dire que l implémentation soit définitive - principe de refactoring) Exemples : je choisi dans une liste la radio de mon choix, apparaît alors le programme de diffusion de cette radio ; je choisi d écouter la radio en actionnant un bouton, apparaît alors dans une fenêtre des boutons de réglages (son+, son-, arrêt du son, arrêt de l écoute, ), le nom du morceau qui passe, le nom de l auteur, sa photo ou la photo de l album, la durée du morceau et le temps écoulé depuis le début ; réalisation d une visuel graphique pour la radio ;
le scénario XP Inspiré des Use Case de Ivar Jacobson un scénario XP est l expression informelle d un usage élémentaire. C est aussi l unité de développement d XP. Les scenarii sont rédigés en langue naturelle, un scénario doit pouvoir être réalisé dans une itération. (ce qui ne veut pas dire que l implémentation soit définitive - principe de refactoring) Exemples : je choisi dans une liste la radio de mon choix, apparaît alors le programme de diffusion de cette radio ; je choisi d écouter la radio en actionnant un bouton, apparaît alors dans une fenêtre des boutons de réglages (son+, son-, arrêt du son, arrêt de l écoute, ), le nom du morceau qui passe, le nom de l auteur, sa photo ou la photo de l album, la durée du morceau et le temps écoulé depuis le début ; réalisation d une visuel graphique pour la radio ;
le scénario XP Inspiré des Use Case de Ivar Jacobson un scénario XP est l expression informelle d un usage élémentaire. C est aussi l unité de développement d XP. Les scenarii sont rédigés en langue naturelle, un scénario doit pouvoir être réalisé dans une itération. (ce qui ne veut pas dire que l implémentation soit définitive - principe de refactoring) Exemples : je choisi dans une liste la radio de mon choix, apparaît alors le programme de diffusion de cette radio ; je choisi d écouter la radio en actionnant un bouton, apparaît alors dans une fenêtre des boutons de réglages (son+, son-, arrêt du son, arrêt de l écoute, ), le nom du morceau qui passe, le nom de l auteur, sa photo ou la photo de l album, la durée du morceau et le temps écoulé depuis le début ; réalisation d une visuel graphique pour la radio ;
le scénario XP Inspiré des Use Case de Ivar Jacobson un scénario XP est l expression informelle d un usage élémentaire. C est aussi l unité de développement d XP. Les scenarii sont rédigés en langue naturelle, un scénario doit pouvoir être réalisé dans une itération. (ce qui ne veut pas dire que l implémentation soit définitive - principe de refactoring) Exemples : je choisi dans une liste la radio de mon choix, apparaît alors le programme de diffusion de cette radio ; je choisi d écouter la radio en actionnant un bouton, apparaît alors dans une fenêtre des boutons de réglages (son+, son-, arrêt du son, arrêt de l écoute, ), le nom du morceau qui passe, le nom de l auteur, sa photo ou la photo de l album, la durée du morceau et le temps écoulé depuis le début ; réalisation d une visuel graphique pour la radio ;
Les douze piliers de XP (Agile Manifesto) Client sur site
Les douze piliers de XP (Agile Manifesto) Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Livraisons frequentes Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Livraisons frequentes Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Travail en binome Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Travail en binome Remaniement Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Travail en binome Integration continue Remaniement Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Travail en binome Metaphore Integration continue Remaniement Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Conception simple Livraisons frequentes Travail en binome Metaphore Integration continue Remaniement Client sur site Responsabilite collective du code Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Règles de codage Conception simple Livraisons frequentes Travail en binome Metaphore Integration continue Remaniement Client sur site Responsabilite collective du code Planification iterative
Les douze piliers de XP (Agile Manifesto) Développement piloté par les tests Règles de codage Conception simple Livraisons frequentes Travail en binome Metaphore Integration continue Remaniement Rythme durable Responsabilite collective du code Client sur site Planification iterative
Les douze piliers de XP (Agile Manifesto) RESPONSABILITE COLLECTIVE DU CODE (COLLECTIVE CODE OWNERSHIP) METAPHORE INTEGRATION CONTINUE (CONTINUOUS INTEGRATION) CONCEPTION SIMPLE (SIMPLE DESIGN) LIVRAISONS FREQUENTES (FREQUENT RELEASE) DEVELOPPEMENT PILOTE PAR LES TESTS (TEST FIRST PROGRAMMING) REMANIEMENT (REFACTORING) PLANIFICATION ITERATIVE (PLANNING GAME) CLIENT SUR SITE (ON SITE CUSTOMER) RYTHME DURABLE (SUSTAINABLE PACE) TRAVAIL EN BINOME (PAIR PROGRAMMING) REGLES DE CODAGE (CODING STANDARDS) Faire de l c est ni plus ni moins que de s appuyer sur ces douze piliers.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
XP et le Capability Maturity Model (CMM) 1 niveau 1 : le processus de développement n est pas formalisé, le travail s organise spontanément en fonction des personnalités et des compétence ; 2 niveau 2 : l équipe de développement décrit et planifie le travail en termes d activités de coûts et de délais ; elle est capable de contrôler l état d avancement par rapport aux prévisions ; 3 niveau 3 : le processus de développement est défini, connus et compris par tous les intervenants du projet, 4 niveau 4 : les performances du processus de développement sont mesurables objectivement ; 5 niveau 5 :les données de contrôle des performances du processus permettent son amélioration. Selon C.Beard XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Conclusion Les valeurs d XP L approche Agile est une alternative à l approche Taylorienne de l organisation scientifique du travail. XP donne la primeur aux facteurs humains et se fonde sur quatre valeurs : 1 communication : XP favorise le contact humain et la communication directe plutôt que le cloisonnement des rôles et des activités ; 2 feedback : les pratiques d XP visent à donner un maximum de retour au client aussi bien qu aux développeurs ; 3 simplicité : XP privilégie les formes simples aussi bien sur le produit en construction que sur le processus de construction lui-même (recherche de l efficience) ; 4 courage : accepter la remise en question, accepter d être piloté par le client, accepter une part d inconnu (tout n est pas spécifié à l avance).
Conclusion Les valeurs d XP L approche Agile est une alternative à l approche Taylorienne de l organisation scientifique du travail. XP donne la primeur aux facteurs humains et se fonde sur quatre valeurs : 1 communication : XP favorise le contact humain et la communication directe plutôt que le cloisonnement des rôles et des activités ; 2 feedback : les pratiques d XP visent à donner un maximum de retour au client aussi bien qu aux développeurs ; 3 simplicité : XP privilégie les formes simples aussi bien sur le produit en construction que sur le processus de construction lui-même (recherche de l efficience) ; 4 courage : accepter la remise en question, accepter d être piloté par le client, accepter une part d inconnu (tout n est pas spécifié à l avance).
Conclusion Les valeurs d XP L approche Agile est une alternative à l approche Taylorienne de l organisation scientifique du travail. XP donne la primeur aux facteurs humains et se fonde sur quatre valeurs : 1 communication : XP favorise le contact humain et la communication directe plutôt que le cloisonnement des rôles et des activités ; 2 feedback : les pratiques d XP visent à donner un maximum de retour au client aussi bien qu aux développeurs ; 3 simplicité : XP privilégie les formes simples aussi bien sur le produit en construction que sur le processus de construction lui-même (recherche de l efficience) ; 4 courage : accepter la remise en question, accepter d être piloté par le client, accepter une part d inconnu (tout n est pas spécifié à l avance).
Conclusion Les valeurs d XP L approche Agile est une alternative à l approche Taylorienne de l organisation scientifique du travail. XP donne la primeur aux facteurs humains et se fonde sur quatre valeurs : 1 communication : XP favorise le contact humain et la communication directe plutôt que le cloisonnement des rôles et des activités ; 2 feedback : les pratiques d XP visent à donner un maximum de retour au client aussi bien qu aux développeurs ; 3 simplicité : XP privilégie les formes simples aussi bien sur le produit en construction que sur le processus de construction lui-même (recherche de l efficience) ; 4 courage : accepter la remise en question, accepter d être piloté par le client, accepter une part d inconnu (tout n est pas spécifié à l avance).
Conclusion A chacun son XP XP n est pas une approche dogmatique, elle se fonde sur des valeurs et quelques principes dont la mise en oeuvre très libre appartient à chaque équipe ; l industrialisation du Genie Logiciel, le mouvement pour la qualité, le diktat du management nous avait peu à peu fait oublier qu il n y a pas de logiciel sans développeurs ; XP met l accent sur l importance des facteurs humains et redonne aux développeurs la place qu ils avaient peu à peu perdue.
Conclusion A chacun son XP XP n est pas une approche dogmatique, elle se fonde sur des valeurs et quelques principes dont la mise en oeuvre très libre appartient à chaque équipe ; l industrialisation du Genie Logiciel, le mouvement pour la qualité, le diktat du management nous avait peu à peu fait oublier qu il n y a pas de logiciel sans développeurs ; XP met l accent sur l importance des facteurs humains et redonne aux développeurs la place qu ils avaient peu à peu perdue.
Conclusion A chacun son XP XP n est pas une approche dogmatique, elle se fonde sur des valeurs et quelques principes dont la mise en oeuvre très libre appartient à chaque équipe ; l industrialisation du Genie Logiciel, le mouvement pour la qualité, le diktat du management nous avait peu à peu fait oublier qu il n y a pas de logiciel sans développeurs ; XP met l accent sur l importance des facteurs humains et redonne aux développeurs la place qu ils avaient peu à peu perdue.
Conclusion Des questions?
Conclusion Quelques références Livre-Articles-Web Bénard-Bossavit-Medina-Williams, Gestion de projet - [Eyrolles] R.Medina, L extreme programming - processus de développement [http ://www.design-up.com] Agile Manifesto, [http ://agilemanifesto.org/] M.Kircher, XP in Open-Source and distributed environments - Siemens AG - 2001 C.Beard, A look at Extreme Programming, SEPG 2001, New Orleans Sucess Stories Eclipse "Callisto" ACE - Adaptive Communication Environment (Siemens) TAO(TM) A Real Time CORBA (The ACE ORB) (Siemens)