Introduction Les processus traditionnels eXtreme Programming Conclusion

eXtreme Programmingvers plus d’agilité

F. Miller

francois.miller@inpg.fr

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

Des questions ?

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)