Extreme Programming - XP Une méthode de développement par Kent Beck.

Slides:



Advertisements
Présentations similaires
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Advertisements

Amélioration de la qualité des forfaits
Eléments de Génie Logiciel
La Gestion de la Configuration
Les principes généraux Les objectifs du dispositif Le b2i et les défis sur Internet Une visite concrète.
La Vitesse de la Confiance – Les Compétences
définition L’évaluation :
Le processus unifié UML est un langage de modélisation et n ’impose pas de démarche de développement Le processus unifié : méthodologie de développement.
Rational Unified Process (RUP)
Les Ateliers de Génie Logiciel
L'épreuve - preuve Ou l'indicateur d'acquisition de la compétence
Le cahier de sciences Lieu des écrits pour soi
Filière Informatique et Réseaux
1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.
18/10/2004 P. Van Roy, InfoT4, S5 1 Informatique T4 Solutions au Test du 18 octobre Peter Van Roy Département dIngénierie Informatique, UCL
Cycle de vie dun logiciel Origine des erreurs La spécification 50% 40% 10% Le design Le codage.
MANAGEMENT DU PRODUIT Organisation Technique du Produit (OTP) Objet Arborescence Produits Relation autres domaines Décomposition du système Gestion.
Introduction au Génie Logiciel
Questions/problèmes Contraintes de départ… ressources, plateforme… utilisation de matériel existant –Pas de temps du prof pour préparer des exemples… concrets…
Parcours de formation SIN-7
METHODE AGIL Présenté par : GRIOUI Haykel MILADI Hedi CHARFI Habib
Unite 2 Qui suis je?.
10 ans après… Ma première expérience agile. PLAN mieux vaut un mauvais plan que pas de plan du tout Présentation des acteurs Premier jour : – je suis.
Paul Bories Cyril Enrici Bouzidi Gharoual Kevin Royere
Structures de données IFT Abder Alikacem Gestion des exceptions Département dinformatique et de génie logiciel Édition Septembre 2009.
Pratiques Lean dans le développement
Les styles d'apprentissage
Programme de baccalauréat en informatique Programmation Orientée Objets IFT Thierry EUDE Module 6. Gestion des erreurs et des exceptions : Fonctionnement.
Cycle de vie: « Waterfall » GEF492A Automne 2014 [HvV § 3.1]
Stratégie d’entreprise - Alstom Transport – Marco Férrogalini
Une introduction au eXtreme Programming (XP) GEF492A 2014 Référence: [Jefferies et al ch. 1,2, 7, 9-14] Capt Vincent Roberge Collège Militaire Royal du.
Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3]
GESTION DE PROJET
Compétences relatives à l’employabilité
2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.
Cycles de Vie du Logiciel LFI2 Genie Logiciel/ Gestion de Projets Septembre 2008.
Une nouvelle activité pour le Club L Le Mentorat 8 mars 2010 Sigrid Willame Martine Van den Poel.
Introduction au Génie Logiciel
Les outils de la vérification statiquedynamique unitaires intégration vérificateur de syntaxe vérificateur de syntaxe étenduABAP débogueur inspecteur de.
Comment aider aux Devoirs?
Initiation à la conception des systèmes d'informations
Gestion de projet Cycles de production
MOCK.
Entity/Facet/Pattern Une application qui en a…
Année 2006 – 2007 ENSEA © Emeric Rollin
Quels enjeux Les Nouvelles Technologies sont utilisées sur tous types de projets Applications B2E, B2B, B2C Produits Client-Serveur.
L’enseignement de spécialité SLAM
OPTIMISATION DE LA PLANIFICATION
La famille est un système ouvert :
La planification Rencontre 5.
Présentation du référentiel ITIL v3
D’après une présentation de A. Conti
Conférence 2TUP Stéphane Barthon 03/12/
Test et assurance qualité : Focus Projet Outiz
Présentation de la méthode Merise
Introduction à l’amélioration continue
Pourquoi les gens ont-ils besoins de sécurité économique?
L’entreprise et sa gestion
Chapitre 3: la sécurité Économique
« LA PERFORMANCE DOIT ÊTRE GÉRÉE… ». 2 GÉRER / MESURER ? GÉRER LA PERFORMANCE DES PERSONNES, C’EST BEAUCOUP PLUS QUE LA MESURER. Partager.
LES OUTILS DE GESTION DE PROJET
PRÉSENTATION AGL LES TESTS LOGICIELS LES TEST LOGICIELS 1 Mickael BETTINELLI Brandon OZIOL Gaétan PHILIPPE Simon LUAIRE.
TSTC développement de clientèles 1 Le système d'information mercatique (SIM)
ÉCONOMIE POUR INGÉNIEURS CHAPITRE 1 Les fondements de l’économie d’ingénierie © 2013 Chenelière Éducation inc.
Méthodes Agiles Synthèse. TP 1 : Packaging Réfléchir avec le client aux caractéristiques du produit Permet de rêver et donc de motiver Permet d’avoir.
Un point sur la pédagogie différenciée. Qu’est-ce que la pédagogie différenciée ? La pédagogie différenciée est un type de pédagogie qui prend en compte.
Production de ressources pour le cycle 3 Lycée Diderot le 8 mars 2016
Projet logiciel orienté objets M2 Pro OSAE – P.Didelon, J.F.Rabasse.
Transcription de la présentation:

Extreme Programming - XP Une méthode de développement par Kent Beck

2 Le cycle de vie d’un système …. spécification Design (conception) codage « déboggage » Mise en service maintenance Analyse de besoins Temps t Le modèle de la « chute d’eau » - La vision traditionnelle

3 ….. mais la maintenance coûte ! Coût de modification Age du système La vision traditionnelle: Un système devient plus difficile à modifier avec le temps Confirmé par la bogue de l’an 2000 ?

4 La crise de logiciel u Une courbe exponentielle du coût de la maintenance u Un manque de qualité äLa qualité se définit par la validité, la sécurité, la tolérance aux erreurs, l’extensibilité, … u Une pénurie de bons programmeurs u Les besoins des clients changent pendant le développement äJusqu’à 25% [McConnell] u La plupart des projets sont livrés en retard äS’ils ne sont pas arrêtés avant u Les moyens disponibles pour le projet sont trop peux

5 Extreme Programming - XP u XP est un processus de développement qui a pour but äDe produire du logiciel de qualité äLe développement ne coûte pas cher äLes systèmes ne sont pas livrés en retard u XP consiste en un ensemble des mesures qu’une équipe de développement doit suivre äP.ex: les tests, la programmation en pairs, …. u XP est une discipline u La discipline est extrême dans le sens qu’il faut vraiment suivre toutes les mesures proposées

6 Vers XP u L’adoption d’XP nécessite d’abord une connaissance des risques de développement äLes retards äL’annulation du projet äTrop de bogues äMauvais compréhension de l’aspect Economique  C-à-d: les besoins des clients, l’orientation du marché äChangement dans l’orientation de l’Économique äChangement de personnel dans l’équipe äL’équipe perd l’intérêt dans le système ä« False Feature Rich » - trop d’effort dépensé dans le développement des propriétés qui ne sont pas les plus importantes

7 La philosophie de l’XP u Pour rapidement trouver et corriger les bogues äOn code en pairs, tout le monde est co-propriétaire du code, et on écrit beaucoup de tests u Pour gérer les risques associées à l’Économique äLe design est fait en itérations successives äLes modifications sont testées et puis intégrées rapidement dans le système äOn garde les designs aussi simples que possible äOn est toujours en train de réviser ses propres designs u Pour gérer les problèmes de personnel äTout le monde est co-propriétaire du code

8 XP marche, mais pourquoi ? u Une meilleure prise de connaissance des risques vis-à- vis de l’Économique äOn développe dans l’itération courante ce qui est le plus important (pour le client) actuellement  Pas de paris sur l’évolution de l’Économique u L’effondrement de la courbe de coût de la modification äLa courbe devient linéaire !!! (le coût de modification d’un système ne change pas avec le temps)  À causes des tests  À cause des propriétés de la programmation à objets

9 Les 4 variables du développement 1) Le coût 2) Le temps (la durée) 3) La qualité 4) La portée (de la spécification) u Les variables sont fixées par l’économique, et ont une influence une sur l’autre u XP: La qualité ne doit pas être traitée comme étant une variable u XP: On varie la variable de portée en fonction des variables de coût et de temps

10 Les 4 valeurs du développement 1) La communication äEntre les programmeurs, dans une équipe entre le Développement et l’Économique, entre l’équipe et le clientèle 2) La simplicité äPour la révision de code et le développement rapide, 3) Le feed-back äSur le système (via les tests), mais aussi sur la performance de l’équipe (p.ex. la vélocité du projet) 4) Le courage äIl faut pouvoir jeter un développement s’il ne marche pas avec les tests ou si l’Économique le rend inutile äPour proposer des idées bizarres

11 Quelques principes de l’XP Il faut des principes pour concrétiser les valeurs u Le feed-back rapide äLes programmeurs ont une tendance à oublier leur code avec le temps äComprendre tout de suite les implications d’une modification  XP : les tests, les mesures, l’intégration rapide u Chercher la simplicité äOn code un composant aussi simplement que possible u La modification par incrémentation äUn changement à la fois (dans l’équipe, la spécification, les outils) u Attendre des changements äOn découvre toujours des moyens de mieux faire des choses  XP : la révision du code

12 Quelques principes de l’XP u Qualité äIl faut savoir varier la variable de portée u Apprendre (et noter) u Un investissement initial minimal äIl y a trop d’incertitude au début d’un projet ; donc, on ne dépense pas de ressources avant qu’on en aie vraiment besoin u Jouer offensivement äIl faut créer un cadre et une mentalité où l’équipe peut progresser äP.ex: il est plus important d’écrire des tests que des rapports u Des expériences concrètes äCe sont les tests qui indiquent si le système marche ou pas

13 Quelques principes de l’XP u La communication honnête äSi le code a besoin d’être révisé, alors il faut le dire u Accommoder les intérêts des gens äUn co-équipier n’est pas un valet; il faut qu’il ait un moyen d’avancer (apprendre, contribuer,.. ) u La responsabilité äEst prise, et jamais donnée u Minimum de bagages äOn achète les outils lorsqu’on en a vraiment besoin ….. u Mesures concrètes äIl faut toujours vérifier la vélocité du projet

14 La mise en œuvre de l’XP u La planification äUne équipe comprend une partie Économique et une partie Développement  L’Économique spécifie les besoins  Le Développement fait les estimations de coût et de durée  Puis l’Économique décide sur la portée u Des versions incrémentales äIl vaut mieux avoir une nouvelle version du système tous les 2 ou 3 mois que tous les 6 mois (mais qui comprend plus de modifications)

15 La mise en œuvre de l’XP u Une métaphore äDécrit le rôle (ou la vision) du système. On s’en sert pour guider le développement et pour évaluer son progrès u Un design simple 1.Tous les tests marchent 2.Pas de duplication de code 3.Le nombre minimal de méthodes et des classes u Les tests äLes tests sont écrits par les clients et par les programmeurs äLes tests servent également à préciser le design äXP parie que le temps « perdu » à écrire les tests est largement compensé par les gains en temps de développement

16 La mise en œuvre de l’XP u La révision de code et du design äOn change le code d’un composant dès qu’on voit une manière plus simple de l’implanter  Plus de travail dans le court-terme, mais …. u La programmation en pairs äOn change les pairs fréquemment au sein de l’équipe  On range son bureau pour faciliter l’XP u La propriété commune äTout le monde est co-propriétaire du code du système äDonc, il est au courant du fonctionnement de chaque partie

17 La mise en œuvre de l’XP u Les semaines de 40 heures äIl ne faut pas faire des heures supplémentaires äUne équipe débordée est une équipe dont le processus ne fonctionne pas ! u Intégration rapide äUn nouveau composant est vite intégré est testé  (si les tests ne marchent pas, alors on jette le composant) u Un représentant du client doit être toujours disponible u Les programmeurs doivent adopter des standards de programmation äImportant pour la propriété commune et l’intégration continue

18 Les rôles au sein d’une équipe u Programmeur äIl code et il propose des estimations pour le processus de planification u Client äIl achète et il écrit des tests et il prend des décisions sur la portée u « Testeur » : il écrit et fait tourner les tests u « Traceur » äIl archive les données de performance de l’équipe  P.ex: la vélocité du projet, le nombre de tests u Si la vélocité est trop élevée, alors on ne fait pas suffisamment de révisions de code u Coach : un programmeur qui guide l’application des principes de l’XP

19 Bibliographie u Extreme Programming Explained äKent Beck, publié chez Addison-Wesley u