Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programmingvers plus d’agilité
F. Miller
FC INPG
Octobre 2008 - version 1.0
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 changementcontinue) ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 changementcontinue) ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 changementcontinue) ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 Les processus traditionnels eXtreme Programming Conclusion
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 Les processus traditionnels eXtreme Programming Conclusion
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 Les processus traditionnels eXtreme Programming Conclusion
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 Les processus traditionnels eXtreme Programming Conclusion
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 Les processus traditionnels eXtreme Programming Conclusion
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 laqualité ?
3 Comment collaborer avec les usagers pour mieux répondre àleurs attentes et être aussi réactifs que possible ?
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 laqualité ?
3 Comment collaborer avec les usagers pour mieux répondre àleurs attentes et être aussi réactifs que possible ?
Introduction Les processus traditionnels eXtreme Programming Conclusion
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 laqualité ?
3 Comment collaborer avec les usagers pour mieux répondre àleurs attentes et être aussi réactifs que possible ?
Introduction Les processus traditionnels eXtreme Programming Conclusion
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écificationdes besoinsdu Logiciel
Conception de l’architecturedu Logiciel
Codagedes composants
Conceptiondétaillée
Tests d’Intégrationdes composants
Validation dulogiciel
guide
guide
Test Unitaire
1
2
3
4
5
6
7
vérification
validation
Introduction Les processus traditionnels eXtreme Programming Conclusion
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écificationdes besoinsdu Logiciel
Conception de l’architecturedu Logiciel
Codagedes composants
Conceptiondétaillée
Tests d’Intégrationdes composants
Validation dulogiciel
Test Unitaire
1
2
3
4
56
78
9
10
vérification
validation
Introduction Les processus traditionnels eXtreme Programming Conclusion
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éveloppement
Evaluation
CdC
v0
v2
v1
prototype initialdeuxième prototypeproduit final
Décisionsd’engagementdu cycle suivant
engagementfinancier
d’
guide
guide
1
2
3
4
5
6
7
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
Les processus traditionnels
Lourdeur
1 Vouloir spécifier à priori “une fois pour toutes” les propriétésd’un système est très souvent une utopie ;
2 dans ce modèle le coût de la modification croit de façonexponentielle avec le temps ;
3 à ce contexte il faut ajouter les exigences de l’assurancequalité, 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 restetrès lourd financièrement et très gourmand en ressourceshumaines ;
Lourd
Qui se meut avec peu d’aisance et souvent avec lenteur ;
Qui se caractérise par un manque de souplesse ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
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
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les auteurs
Proposé par Kent Beck et Ron Jeffries pendant le projet“C3” (Chrysler Comprehensive Compensation System), le termeeXtreme Programming devient public avec la parution en 2000 del’ouvrage Extreme Programming Explained de Kent Beck. Ward
Cunningham est avec Kent Beck un acteur très actif dans ledomaine de “Design Patterns”, domaine qui a beaucoup inspiré XP.
Ken Beck Ron Jeffries Ward Cunningham
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
En 2001 17 personnalités du Genie Logiciel signent l’Agile
Manifesto, ce manifeste fonde eXtreme Programming
eXtreme Programming est à la fois1 un processus de développement ;2 un état d’esprit et des valeurs ;3 un ensemble de bonnes pratiques.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
En 2001 17 personnalités du Genie Logiciel signent l’Agile
Manifesto, ce manifeste fonde eXtreme Programming
eXtreme Programming est à la fois1 un processus de développement ;2 un état d’esprit et des valeurs ;3 un ensemble de bonnes pratiques.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
En 2001 17 personnalités du Genie Logiciel signent l’Agile
Manifesto, ce manifeste fonde eXtreme Programming
eXtreme Programming est à la fois1 un processus de développement ;2 un état d’esprit et des valeurs ;3 un ensemble de bonnes pratiques.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
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 (2semaines 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 testsautomatisés ;
5 chaque itération doit être validé par le client.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
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 (2semaines 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 testsautomatisés ;
5 chaque itération doit être validé par le client.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
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 (2semaines 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 testsautomatisés ;
5 chaque itération doit être validé par le client.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
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 (2semaines 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 testsautomatisés ;
5 chaque itération doit être validé par le client.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
eXtreme Programming
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 (2semaines 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 testsautomatisés ;
5 chaque itération doit être validé par le client.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le cycle XP
Evaluation
CdC
v0
v2
v1
ecriture, choix et plannificationdes scenarii du cycle suivant
Developpement,programmation, test, amélioration continue
livraison de versionopérationnelleà chaque cycle
Spécification initiale des besoinsredaction des principaux scenariichoix des scenarii réalisés dans la première itération
la première phase “expression initiale des besoins” dure unmois (en moyenne) ;la première phase produit un prototype opérationnel ;à chaque itération on choisi les scenarii à réaliser en deuxsemaines (en moyenne) ;. . .
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le cycle XP
Evaluation
CdC
v0
v2
v1
ecriture, choix et plannificationdes scenarii du cycle suivant
Developpement,programmation, test, amélioration continue
livraison de versionopérationnelleà chaque cycle
Spécification initiale des besoinsredaction des principaux scenariichoix des scenarii réalisés dans la première itération
la première phase “expression initiale des besoins” dure unmois (en moyenne) ;la première phase produit un prototype opérationnel ;à chaque itération on choisi les scenarii à réaliser en deuxsemaines (en moyenne) ;. . .
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le cycle XP
Evaluation
CdC
v0
v2
v1
ecriture, choix et plannificationdes scenarii du cycle suivant
Developpement,programmation, test, amélioration continue
livraison de versionopérationnelleà chaque cycle
Spécification initiale des besoinsredaction des principaux scenariichoix des scenarii réalisés dans la première itération
la première phase “expression initiale des besoins” dure unmois (en moyenne) ;la première phase produit un prototype opérationnel ;à chaque itération on choisi les scenarii à réaliser en deuxsemaines (en moyenne) ;. . .
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 (éventuellementavec d’autres usagers) ;
il a la possibilité d’orienter le développement en fonction desréactions des usagers, par les choix des scenarii suivants ;
le choix de cette personne est un point sensible, en toutecirconstance il est le représentant (délégué) de la maîtrised’ouvrage ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 (éventuellementavec d’autres usagers) ;
il a la possibilité d’orienter le développement en fonction desréactions des usagers, par les choix des scenarii suivants ;
le choix de cette personne est un point sensible, en toutecirconstance il est le représentant (délégué) de la maîtrised’ouvrage ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 (éventuellementavec d’autres usagers) ;
il a la possibilité d’orienter le développement en fonction desréactions des usagers, par les choix des scenarii suivants ;
le choix de cette personne est un point sensible, en toutecirconstance il est le représentant (délégué) de la maîtrised’ouvrage ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 (éventuellementavec d’autres usagers) ;
il a la possibilité d’orienter le développement en fonction desréactions des usagers, par les choix des scenarii suivants ;
le choix de cette personne est un point sensible, en toutecirconstance il est le représentant (délégué) de la maîtrised’ouvrage ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 (éventuellementavec d’autres usagers) ;
il a la possibilité d’orienter le développement en fonction desréactions des usagers, par les choix des scenarii suivants ;
le choix de cette personne est un point sensible, en toutecirconstance il est le représentant (délégué) de la maîtrised’ouvrage ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le scénario XP
Inspiré des “Use Case” de Ivar Jacobson un scénario XP estl’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 doitpouvoir être réalisé dans une itération. (ce qui ne veut pas dire quel’implémentation soit définitive - principe de refactoring)Exemples :
je choisi dans une liste la radio de mon choix, apparaît alors leprogramme de diffusion de cette radio ;
je choisi d’écouter la radio en actionnant un bouton, apparaîtalors dans une fenêtre des boutons de réglages (son+, son-,arrêt du son, arrêt de l’écoute, ), le nom du morceau quipasse, le nom de l’auteur, sa photo ou la photo de l’album, ladurée du morceau et le temps écoulé depuis le début ;
réalisation d’une visuel graphique pour la radio ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le scénario XP
Inspiré des “Use Case” de Ivar Jacobson un scénario XP estl’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 doitpouvoir être réalisé dans une itération. (ce qui ne veut pas dire quel’implémentation soit définitive - principe de refactoring)Exemples :
je choisi dans une liste la radio de mon choix, apparaît alors leprogramme de diffusion de cette radio ;
je choisi d’écouter la radio en actionnant un bouton, apparaîtalors dans une fenêtre des boutons de réglages (son+, son-,arrêt du son, arrêt de l’écoute, ), le nom du morceau quipasse, le nom de l’auteur, sa photo ou la photo de l’album, ladurée du morceau et le temps écoulé depuis le début ;
réalisation d’une visuel graphique pour la radio ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le scénario XP
Inspiré des “Use Case” de Ivar Jacobson un scénario XP estl’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 doitpouvoir être réalisé dans une itération. (ce qui ne veut pas dire quel’implémentation soit définitive - principe de refactoring)Exemples :
je choisi dans une liste la radio de mon choix, apparaît alors leprogramme de diffusion de cette radio ;
je choisi d’écouter la radio en actionnant un bouton, apparaîtalors dans une fenêtre des boutons de réglages (son+, son-,arrêt du son, arrêt de l’écoute, ), le nom du morceau quipasse, le nom de l’auteur, sa photo ou la photo de l’album, ladurée du morceau et le temps écoulé depuis le début ;
réalisation d’une visuel graphique pour la radio ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
le scénario XP
Inspiré des “Use Case” de Ivar Jacobson un scénario XP estl’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 doitpouvoir être réalisé dans une itération. (ce qui ne veut pas dire quel’implémentation soit définitive - principe de refactoring)Exemples :
je choisi dans une liste la radio de mon choix, apparaît alors leprogramme de diffusion de cette radio ;
je choisi d’écouter la radio en actionnant un bouton, apparaîtalors dans une fenêtre des boutons de réglages (son+, son-,arrêt du son, arrêt de l’écoute, ), le nom du morceau quipasse, le nom de l’auteur, sa photo ou la photo de l’album, ladurée du morceau et le temps écoulé depuis le début ;
réalisation d’une visuel graphique pour la radio ;
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Client sur site
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Planification iterative
Client sur site
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Planification iterative
Client sur site
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Développement piloté par les tests
Planification iterative
Client sur site
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Integration continue
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Livraisons frequentes
Metaphore Integration continue
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Responsabilite collective du code
Livraisons frequentes
Metaphore Integration continue
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Responsabilite collective du code
Livraisons frequentes
Metaphore Integration continue
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur site
Travail en binome
Règles de codage
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
Responsabilite collective du code
Livraisons frequentes
Metaphore Integration continue
Remaniement
Développement piloté par les tests
Conception simple
Planification iterative
Client sur siteRythme durable
Travail en binome
Règles de codage
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
Les douze piliers de XP (Agile Manifesto)
CONCEPTION SIMPLE(SIMPLE DESIGN) REMANIEMENT
(REFACTORING)
DEVELOPPEMENT PILOTE PAR LES TESTS (TEST FIRST PROGRAMMING)
TRAVAIL EN BINOME(PAIR PROGRAMMING)
RESPONSABILITE COLLECTIVE DU CODE(COLLECTIVE CODE OWNERSHIP)
REGLES DE CODAGE(CODING STANDARDS)
METAPHOREINTEGRATION CONTINUE(CONTINUOUS INTEGRATION)
LIVRAISONS FREQUENTES(FREQUENT RELEASE)
PLANIFICATION ITERATIVE(PLANNING GAME)
CLIENT SUR SITE(ON−SITE CUSTOMER)
RYTHME DURABLE(SUSTAINABLE PACE)
Faire de l’eXtreme Programming c’est ni plus ni moins que des’appuyer sur ces douze piliers.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
eXtreme Programming
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 despersonnalités et des compétence ;
2 niveau 2 : l’équipe de développement décrit et planifie letravail en termes d’activités de coûts et de délais ; elle estcapable de contrôler l’état d’avancement par rapport auxprévisions ;
3 niveau 3 : le processus de développement est défini, connus etcompris par tous les intervenants du projet,
4 niveau 4 : les performances du processus de développementsont mesurables objectivement ;
5 niveau 5 :les données de contrôle des performances duprocessus permettent son amélioration.
Selon C.Beard
XP est suffisamment abouti pour atteindre le niveau 3 du CMM.
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
Les valeurs d’XP
L’approche Agile est une alternative à l’approche Taylorienne del’organisation scientifique du travail. XP donne la primeur auxfacteurs humains et se fonde sur quatre valeurs :
1 communication : XP favorise le contact humain et lacommunication directe plutôt que le cloisonnement des rôleset des activités ;
2 feedback : les pratiques d’XP visent à donner un maximum deretour au client aussi bien qu’aux développeurs ;
3 simplicité : XP privilégie les formes simples aussi bien sur leproduit en construction que sur le processus de constructionlui-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 passpécifié à l’avance).
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
Les valeurs d’XP
L’approche Agile est une alternative à l’approche Taylorienne del’organisation scientifique du travail. XP donne la primeur auxfacteurs humains et se fonde sur quatre valeurs :
1 communication : XP favorise le contact humain et lacommunication directe plutôt que le cloisonnement des rôleset des activités ;
2 feedback : les pratiques d’XP visent à donner un maximum deretour au client aussi bien qu’aux développeurs ;
3 simplicité : XP privilégie les formes simples aussi bien sur leproduit en construction que sur le processus de constructionlui-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 passpécifié à l’avance).
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
Les valeurs d’XP
L’approche Agile est une alternative à l’approche Taylorienne del’organisation scientifique du travail. XP donne la primeur auxfacteurs humains et se fonde sur quatre valeurs :
1 communication : XP favorise le contact humain et lacommunication directe plutôt que le cloisonnement des rôleset des activités ;
2 feedback : les pratiques d’XP visent à donner un maximum deretour au client aussi bien qu’aux développeurs ;
3 simplicité : XP privilégie les formes simples aussi bien sur leproduit en construction que sur le processus de constructionlui-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 passpécifié à l’avance).
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
Les valeurs d’XP
L’approche Agile est une alternative à l’approche Taylorienne del’organisation scientifique du travail. XP donne la primeur auxfacteurs humains et se fonde sur quatre valeurs :
1 communication : XP favorise le contact humain et lacommunication directe plutôt que le cloisonnement des rôleset des activités ;
2 feedback : les pratiques d’XP visent à donner un maximum deretour au client aussi bien qu’aux développeurs ;
3 simplicité : XP privilégie les formes simples aussi bien sur leproduit en construction que sur le processus de constructionlui-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 passpécifié à l’avance).
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
A chacun son XP
XP n’est pas une approche dogmatique, elle se fonde sur desvaleurs et quelques principes dont la mise en oeuvre très libreappartient à chaque équipe ;
l’industrialisation du Genie Logiciel, le mouvement pour laqualité, le diktat du management nous avait peu à peu faitoublier qu’il n’y a pas de logiciel sans développeurs ;
XP met l’accent sur l’importance des facteurs humains etredonne aux développeurs la place qu’ils avaient peu à peuperdue.
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
A chacun son XP
XP n’est pas une approche dogmatique, elle se fonde sur desvaleurs et quelques principes dont la mise en oeuvre très libreappartient à chaque équipe ;
l’industrialisation du Genie Logiciel, le mouvement pour laqualité, le diktat du management nous avait peu à peu faitoublier qu’il n’y a pas de logiciel sans développeurs ;
XP met l’accent sur l’importance des facteurs humains etredonne aux développeurs la place qu’ils avaient peu à peuperdue.
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
A chacun son XP
XP n’est pas une approche dogmatique, elle se fonde sur desvaleurs et quelques principes dont la mise en oeuvre très libreappartient à chaque équipe ;
l’industrialisation du Genie Logiciel, le mouvement pour laqualité, le diktat du management nous avait peu à peu faitoublier qu’il n’y a pas de logiciel sans développeurs ;
XP met l’accent sur l’importance des facteurs humains etredonne aux développeurs la place qu’ils avaient peu à peuperdue.
Introduction Les processus traditionnels eXtreme Programming Conclusion
Conclusion
Quelques références
Livre-Articles-Web
Bénard-Bossavit-Medina-Williams, Gestion de projet -eXtreme Programming [Eyrolles]
R.Medina, L’extreme programming - processus dedé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, NewOrleans
Sucess Stories
Eclipse "Callisto"
ACE - Adaptive Communication Environment (Siemens)
TAO(TM) A Real Time CORBA (The ACE ORB) (Siemens)