Introduction à eXtreme
Programming et Scrum
eXtreme Programming
● Méthode Agile de gestion de projet
● Utilisé la première fois en 1996
● Publié pour la première fois...
Histoire des méthodes de
développement de projet
Le manifeste des méthodes Agile
We are uncovering better ways of developing software by
doing it and helping others do it....
eXtreme Programming : la théorie
L'Équipe
Planification
Petite
Livraison
Retour Client
Norme
de code
Rythme
endurant
Visio...
eXtreme Programming :
Diagramme général
eXtreme Programming : la théorie
Les 12 points (1)
● L'Équipe
● Planification
● Scénario utilisateur et jeu de test
● Peti...
eXtreme Programming : la théorie
Les 12 points (2)
● Développement piloté par les tests (TDD)
● Factorisation
● Intégratio...
eXtreme Programming : la théorie
l'Équipe
● Se rassemble autour du Client
● Rassemble des développeurs généraux ayant
des ...
eXtreme Programming : la théorie
Les rôles (1)
● Client
– Définit les scénarios et les tests fonctionnels
● Développeur
– ...
eXtreme Programming : la théorie
Les rôles (2)
● Coach
– Regarde tout
– Envoi des signaux obscures à l'équipe
– Pilote cha...
eXtreme Programming : la théorie
Les rôles (3)
● Messager de l'Apocalypse
– Faire en sorte que tout le monde comprenne les...
eXtreme Programming : la théorie
Planification
Réponds à deux questions clefs :
– Quelles fonctionnalités seront présentes...
eXtreme Programming : la théorie
Planification
2 types de plannings distincts :
– Planning de Livraison
Jeu de fonctionnal...
eXtreme Programming : la théorie
Planning Game
Pièces : les scénarios utilisateurs sous forme de cartes à jouer
But : Mett...
eXtreme Programming : la théorie
Programmation par paire
● Deux personnes par station de travail
● Les paires ne sont pas ...
eXtreme Programming : la théorie
Développement pilotés par les tests
1.Pensez à ce que vous devez faire
2.Pensez comment v...
eXtreme Programming : la théorie
Scénario Utilisateur
● Écrit par le Client
● Décrive le comportement de l'application
● P...
eXtreme Programming : la théorie
Petite Livraison
● Après chaque itération
● Montre l'évolution au Client
● Permet le test...
eXtreme Programming : la théorie
Design Simple
● Définition de Simple
Pas ou peu de temps à développer
● Mesure de la simp...
eXtreme Programming : la théorie
Factorisation
● Faire évoluer le design
● Supprimer les doublons
● Augmenter la cohérence...
eXtreme Programming : la théorie
Intégration en continue
● Intégrer les différents modules
● Reconstruire le projet
Quotid...
eXtreme Programming : la théorie
Code appartient au groupe
● Évite un mauvais placement des
fonctionnalités
● Toute l'équi...
eXtreme Programming : la théorie
Norme de code
● Impose des règles d'écriture stricte de code à
l'équipe
➔Baisse du sentim...
eXtreme Programming : la théorie
Vision simple et Rythme endurant
● Utilisation du même vocabulaire entre les
membres de l...
eXtreme Programming : Diagramme
Projet
eXtreme Programming : Diagramme
Itération
eXtreme Programming : Diagramme
Développement
eXtreme Programming : Diagramme
Code appartient au groupe
eXtreme Programming :
cas pratique
Scrum
● Apparaît en 1995
● Ensemble de règles de management
● Méthodologie itérative & incrémentale
● Ne couvre pas la par...
Scrum : Diagramme
Scrum
● 3 rôles principaux :
– Propriétaire du Produit
– Équipe de Développement
– Scrum Master
● 4 étapes
– Planification...
Scrum : Sprint
● Durée d'un mois maximum
● Cette durée reste constante tout au long du projet
● Possède un but et une list...
Scrum : Le Propriétaire du Produit
– Responsable de la maximisation du ROI (Retour sur 
Investissement) du développement
–...
Scrum : L'équipe de développement
– Transverse (testeurs, architecte, analyste,...)
– Autogérer sans rôles extérieurs
– Né...
Scrum : Le Scrum Master
– Facilite le processus
– Aide à la résolution des obstacles
– Créé un environnement aidant l'équi...
Scrum : Planification du Sprint 
● Lieu au début de chaque nouveau sprint
● Entre le Propriétaire du Produit et l'équipe
●...
Scrum : Mêlée Quotidienne
Répondre à trois questions : 
– Qu'ai je réalisé hier?
– Que vais-je faire aujourd'hui?
– Quel p...
Scrum : Revue de sprint
● Présentation de ce qui a été réalisé pendant le 
sprint
● Validation par le Propriétaire du Prod...
Scrum : Rétrospective du Sprint
● Analyse par l'équipe des problèmes 
rencontrés
● Réflexion sur les solutions aux problèm...
Scrum : 
cas pratique
Forces et Faiblesse des méthodes 
Agiles
✔ Productivité
✔ Qualité
✔ Souplesse
✔ Environnement 
✗ Échelle des équipes
✗ Équ...
Prochain SlideShare
Chargement dans…5
×

Agile Methodologies

500 vues

Publié le

Presentation in French of Agile methodologies: SCRUM and eXtreme Programming

Publié dans : Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
500
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
21
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Historiquement le modèle appliqué était le cycle en V (1957 au plus vieux) Le modèle en spirale est issu des travaux de Barry Boehm en 1986. Parallèlement à ses travaux, Hirotaka Takeuchi et Ikujiro Nonaka publient le « New New Product Development Game » En 1991 avec la méthode Rapid Application Development (RAD) on commence à voir l'émergence de cycle semi itératif ainsi qu'une constante validation par le Client du produit livré. Des évolutions (RAD2 et Dynamic System Development Method) apparaissent en 1994.
  • En février 2001, 17 développeurs se sont retrouvés à Snowbird dans l'Utah pour discuter des méthodes de développement. On y retrouve des hautes figures dans le monde du développement tel que : Ward Cunningham (inventeur du WiKi) Kent Beck (XP + xUnit) Ken Schwaber et Jeff Sutherland (Scrum) Ils établissent alors le manifeste suivant qui repose sur les valeurs suivantes : L'équipe – organisation personnelle et motivation ainsi que les interactions dans l'équipe sont importantes L'application – arrivé devant le client avec un produit fonctionnel plutôt que des pages et des pages de documentation La collaboration – les desiderata ne peuvent être tous découvert au début du projet, donc il suffit d'inclure le client continuellement dans le projet. L'acceptation du changement – développer continuellement et répondre vite aux changement, tel est le point principale d'une méthode Agile.
  • Une équipe se forme autour d'un Client. Ce Client deviens partie intégrante de l'équipe. S'ensuit la réalisation d'une planification simple permettant de savoir les modules à faire et leurs priorités respectives et d'établir la date de fin du projet. La production elle se fera dans l'ordre de priorité en une série de petit module intégré et passant les tests définis par le Client. Les développeurs travaillent par paire en générant des designs simples et testés de bout en bout. On améliore le design (sans le complexifié) pour qu'il corresponde toujours aux besoins courants. L'intégration est faite en continue tout en gardant le système en ligne. Tout le code de production est réalisé par des pairs de développeurs. Le code est écrit de sorte que n'importe quel membre de l'équipe puisse le comprendre et l'améliorer. L'équipe partage une vision simple de l'application en travaillant à un rythme pouvant être maintenu indéfiniment.
  • La planification des tâches dans la méthode XP se fait sous la forme d'un jeu avec son but, ses joueurs, ses règles. On le fait ainsi afin de créer une distance émotionnelle entre les acteurs et la planification.
  • Les cartes sont souvent représentées sous la forme de cartes CRC (Class – Responsabilities – Collaboration) - Class : pour le nom de la classe / fonctionnalité - Responsabilities : ce qu'elle doit réaliser - Collaboration : les liens avec les autres classes / fonctionnalités Chacune des cartes à aussi deux valeurs : la priorité (ou valeur) le coût de celle-ci (en temps idéal) Description des coups : Écrire Histoire : Ajouter des informations sur la cartes (dans le descriptif) / sa priorité Estimer Histoire : Assigner un coût en temps idéal de développement. Si le coût est > au temps d'une itération, le Business divise la tâche. Si le coût est < 1, on combine la tâche avec d'autre petite tâche pour obtenir une unité de temps idéal Introduire Histoire : Ajoute une nouvelle carte dans le jeu S'engager : Phase principale du jeu, où l'on agence les différentes fonctionnalités pour la livraison. On distingue généralement deux méthodes : Pilotage par les fonctionnalités : le Business pose les fonctionnalités une par une sur la table, le Développement calcule et annonce la date de livraison Pilotage par la date : le Business choisit une date de livraison, le Développement calcule le coût total faisable d'ici la date (en unité de temps idéal). Ensuite le Business choisit les fonctionnalités selon leur coût. Enfin le Développement ordonnance les cartes choisis selon un des deux ordres suivants : Par ordre de valeur décroissante (les plus prioritaires d'abord) Par ordre de risque décroissant (les plus risqués d'abord) Revenir sur un engagement : Le Développement révise son engagement de X sur Y unités (Y < X) entre le temps T et la deadline. Le Développement annonce ceci le plus vite possible, le Business dès lors choisit les Y unités à garder déférant le reste pour une itération suivante. Changer Valeur : Redéfinir la priorité d'une carte Pic : Le Business peut mobiliser toute l'équipe pour combattre un feu ou réaliser un PoC. Si ce pic est plus qu'un patch temporaire, le Business doit créer une nouvelle Histoire. Cette histoire sera ordonnancer comme les autres. Ré-estimation : Le Développement reprend toutes les cartes de la pire et ré-évalue celle-ci. Cette action peut provoquer un Retour sur engagement.
  • Les cartes sont souvent représentées sous la forme de cartes CRC (Class – Responsabilities – Collaboration) - Class : pour le nom de la classe / fonctionnalité - Responsabilities : ce qu'elle doit réaliser - Collaboration : les liens avec les autres classes / fonctionnalités Chacune des cartes à aussi deux valeurs : la priorité (ou valeur) le coût de celle-ci (en temps idéal) Description des coups : Écrire Histoire : Ajouter des informations sur la cartes (dans le descriptif) / sa priorité Estimer Histoire : Assigner un coût en temps idéal de développement. Si le coût est > au temps d'une itération, le Business divise la tâche. Si le coût est < 1, on combine la tâche avec d'autre petite tâche pour obtenir une unité de temps idéal Introduire Histoire : Ajoute une nouvelle carte dans le jeu S'engager : Phase principale du jeu, où l'on agence les différentes fonctionnalités pour la livraison. On distingue généralement deux méthodes : Pilotage par les fonctionnalités : le Business pose les fonctionnalités une par une sur la table, le Développement calcule et annonce la date de livraison Pilotage par la date : le Business choisit une date de livraison, le Développement calcule le coût total faisable d'ici la date (en unité de temps idéal). Ensuite le Business choisit les fonctionnalités selon leur coût. Enfin le Développement ordonnance les cartes choisis selon un des deux ordres suivants : Par ordre de valeur décroissante (les plus prioritaires d'abord) Par ordre de risque décroissant (les plus risqués d'abord) Revenir sur un engagement : Le Développement révise son engagement de X sur Y unités (Y < X) entre le temps T et la deadline. Le Développement annonce ceci le plus vite possible, le Business dès lors choisit les Y unités à garder déférant le reste pour une itération suivante. Changer Valeur : Redéfinir la priorité d'une carte Pic : Le Business peut mobiliser toute l'équipe pour combattre un feu ou réaliser un PoC. Si ce pic est plus qu'un patch temporaire, le Business doit créer une nouvelle Histoire. Cette histoire sera ordonnancer comme les autres. Ré-estimation : Le Développement reprend toutes les cartes de la pire et ré-évalue celle-ci. Cette action peut provoquer un Retour sur engagement.
  • La méthode TUBE (Testable – Understandable – Browsable – Explainable) demande que le design possède 4 qualités : - Possibilité d'écrire des tests unitaires et de validation - Tous les membres de l'équipe le comprenne - Facilité à trouver des éléments dedans - Facile de montrer à une nouvelle personne comment il fonctionne Selon Beck un design est simple si : - il passe les tests - répond aux attentes - il n'y a pas de duplication de code - nombre minimal de composants et de méthodes
  • Agile Methodologies

    1. 1. Introduction à eXtreme Programming et Scrum
    2. 2. eXtreme Programming ● Méthode Agile de gestion de projet ● Utilisé la première fois en 1996 ● Publié pour la première fois en 1999 par Kent Beck
    3. 3. Histoire des méthodes de développement de projet
    4. 4. Le manifeste des méthodes Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ● Individuals and interactions over processes and tools ● Working software over comprehensive documentation ● Customer collaboration over contract negotiation ● Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
    5. 5. eXtreme Programming : la théorie L'Équipe Planification Petite Livraison Retour Client Norme de code Rythme endurant Vision Simple Intégration en continue Code appartient à l'équipe TDD Programmation par paire Factorisation Design Simple
    6. 6. eXtreme Programming : Diagramme général
    7. 7. eXtreme Programming : la théorie Les 12 points (1) ● L'Équipe ● Planification ● Scénario utilisateur et jeu de test ● Petite livraison régulière ● Design Simple ● Programmation par paire
    8. 8. eXtreme Programming : la théorie Les 12 points (2) ● Développement piloté par les tests (TDD) ● Factorisation ● Intégration en continue ● Code appartient au groupe ● Norme de Code ● Vision commune et Rythme endurant
    9. 9. eXtreme Programming : la théorie l'Équipe ● Se rassemble autour du Client ● Rassemble des développeurs généraux ayant des compétences spécifiques ● Tous ont un ou plusieurs rôles dans l'équipe avec des fonctions précises ● Environnement de travail favorisant la communication
    10. 10. eXtreme Programming : la théorie Les rôles (1) ● Client – Définit les scénarios et les tests fonctionnels ● Développeur – Estime les scénarios – Produit le code et les tests unitaires – Définit les tâches
    11. 11. eXtreme Programming : la théorie Les rôles (2) ● Coach – Regarde tout – Envoi des signaux obscures à l'équipe – Pilote chaque membre – Remet sur les rails du projet ceux qui s'en éloigne (cas extrême se sépare d'elle) – Gère les problèmes d'ego ● Testeur – Implémente et exécute les tests fonctionnels – Dans certains cas aide le Client à définir les tests
    12. 12. eXtreme Programming : la théorie Les rôles (3) ● Messager de l'Apocalypse – Faire en sorte que tout le monde comprenne les risques – Faire en sorte que les mauvaises nouvelles ne soient pas masquées ou écartées – Faire en sorte que les mauvaises nouvelles ne prennent pas trop de proportions ● Manager – Organise les réunions – S'assure du bon déroulement de celles-ci – Renvoie les comptes rendus – Ne dicte pas : ● Ce qu'il faut faire (Client) ● Quand il faut le faire (planning des itérations)
    13. 13. eXtreme Programming : la théorie Planification Réponds à deux questions clefs : – Quelles fonctionnalités seront présentes à la livraison ? – Que fait-on ensuite ? Dirige le projet au lieu d'avoir une prédiction exacte de ce qu'il faut et du temps.
    14. 14. eXtreme Programming : la théorie Planification 2 types de plannings distincts : – Planning de Livraison Jeu de fonctionnalités totales présentes à la fin du projet – Planning des itérations Jeu de fonctionnalités présentes à la fin de l'itération
    15. 15. eXtreme Programming : la théorie Planning Game Pièces : les scénarios utilisateurs sous forme de cartes à jouer But : Mettre le maximum de valeur dans le produit sur la durée du jeu Joueurs : les membres de l'équipe Business (Client, Manager) face aux Développeurs Coups : ● Écrire Histoire (Business) ● Estimer Histoire (Développeurs) ● Introduire Histoire (Business) ● S'engager - Création de la liste d'Histoire - Ordonnancement ● Revenir sur un engagement ● Changer Valeur (Business) ● Pic (Business) ● Ré-estimation (Développeurs)
    16. 16. eXtreme Programming : la théorie Programmation par paire ● Deux personnes par station de travail ● Les paires ne sont pas statiques ● Dans une paire les deux personnes sont actifs ● Difficile à mettre en place ● Le temps de développement augmente de 15 % environ ● Peux générer des problèmes d'ego ● Il ne faut pas tomber dans des relations maître / étudiant ● La qualité du code augmente ● Les connaissances sur les points sont mieux réparties ● Le code est revue par l'ensemble de l'équipe Problèmes Avantages
    17. 17. eXtreme Programming : la théorie Développement pilotés par les tests 1.Pensez à ce que vous devez faire 2.Pensez comment vous allez le tester 3.Écrire un petit test, pensez aux API requises 4.Écrire un code qui ne passera pas le test 5.Voir le test raté 6.Écrire un code qui passe le test 7.Voir le test réussir 8.Logique doublée ? Code incompréhensible → factorisation 9.Relancer tout les tests Pour chaque nouveau test imaginé. Reprendre le cycle complet
    18. 18. eXtreme Programming : la théorie Scénario Utilisateur ● Écrit par le Client ● Décrive le comportement de l'application ● Permet une évaluation raisonnable du temps de développement ● Servent à établir le Planning de Livraison ● Servent de base pour les scénarios de tests
    19. 19. eXtreme Programming : la théorie Petite Livraison ● Après chaque itération ● Montre l'évolution au Client ● Permet le test par le Client Final ● Assure des remontées rapides.
    20. 20. eXtreme Programming : la théorie Design Simple ● Définition de Simple Pas ou peu de temps à développer ● Mesure de la simplicité ? – TUBE (Testable – Understandable – Browsable – Explainable) – Beck
    21. 21. eXtreme Programming : la théorie Factorisation ● Faire évoluer le design ● Supprimer les doublons ● Augmenter la cohérence ● Réduire les liens forts ● Retester l'ensemble
    22. 22. eXtreme Programming : la théorie Intégration en continue ● Intégrer les différents modules ● Reconstruire le projet Quotidiennement ➔Évite les problèmes d'intégration en fin de projet ➔Évite les gels du code trop long }
    23. 23. eXtreme Programming : la théorie Code appartient au groupe ● Évite un mauvais placement des fonctionnalités ● Toute l'équipe de développement participe aux composants (via la Programmation par Paire) ● Code constamment relu et améliorer ● Un bon code est un code où aucun développeur peut dire « c'est moi qui est fait cette fonctionnalité »
    24. 24. eXtreme Programming : la théorie Norme de code ● Impose des règles d'écriture stricte de code à l'équipe ➔Baisse du sentiment d'appropriation du code ➔Augmente la cohérence du code ➔Augmente la qualité de celui-ci ➔Facile la compréhension de celui-ci
    25. 25. eXtreme Programming : la théorie Vision simple et Rythme endurant ● Utilisation du même vocabulaire entre les membres de l'équipe ➔ Meilleur communication interne Toute l'équipe œuvre pour la finalisation du projet. Ils ne sont pas là pour se tuer à la tâche. Source : Extreme Programming Explained – 2nd Edition
    26. 26. eXtreme Programming : Diagramme Projet
    27. 27. eXtreme Programming : Diagramme Itération
    28. 28. eXtreme Programming : Diagramme Développement
    29. 29. eXtreme Programming : Diagramme Code appartient au groupe
    30. 30. eXtreme Programming : cas pratique
    31. 31. Scrum ● Apparaît en 1995 ● Ensemble de règles de management ● Méthodologie itérative & incrémentale ● Ne couvre pas la partie technique d'ingénierie du logiciel
    32. 32. Scrum : Diagramme
    33. 33. Scrum ● 3 rôles principaux : – Propriétaire du Produit – Équipe de Développement – Scrum Master ● 4 étapes – Planification du Sprint – Mêlée quotidienne – Revue de Sprint – Rétrospective du Sprint
    34. 34. Scrum : Sprint ● Durée d'un mois maximum ● Cette durée reste constante tout au long du projet ● Possède un but et une liste de fonctionnalités ● Pendant un sprint – Le but est inaltérable – L'Équipe doit être constante – La qualité est non négociable – Les fonctionnalités sont sujettes à négociations
    35. 35. Scrum : Le Propriétaire du Produit – Responsable de la maximisation du ROI (Retour sur  Investissement) du développement – Responsable de Vision du produit – Priorise constamment les fonctionnalités du produit – Ajuste sur le long terme les attentes – Décisionnaire sur les pré requis – Accepte/Rejette les livraisons aux itérations – Décide de la livraison – Décide la continuité des développements
    36. 36. Scrum : L'équipe de développement – Transverse (testeurs, architecte, analyste,...) – Autogérer sans rôles extérieurs – Négocie les développements avec le Product  Owner, une itération à la fois – Autonome sur la réalisation – Collaborative – Équipe de 7 personnes environs
    37. 37. Scrum : Le Scrum Master – Facilite le processus – Aide à la résolution des obstacles – Créé un environnement aidant l'équipe à s'autogérer – Protège l'équipe des interférences extérieurs – Assure le respect des temps – Promeut et améliore des pratiques d'ingénierie – N'a aucune autorité sur l'équipe
    38. 38. Scrum : Planification du Sprint  ● Lieu au début de chaque nouveau sprint ● Entre le Propriétaire du Produit et l'équipe ● Définit le but du sprint ● Choisit les fonctionnalités à réaliser ● Découpe les fonctionnalités en tâches à  réaliser
    39. 39. Scrum : Mêlée Quotidienne Répondre à trois questions :  – Qu'ai je réalisé hier? – Que vais-je faire aujourd'hui? – Quel problème ai-je eu? ➔ Permet de déceler les nouvelles tâches à  réaliser pour finir le Sprint
    40. 40. Scrum : Revue de sprint ● Présentation de ce qui a été réalisé pendant le  sprint ● Validation par le Propriétaire du Produit ● Revue de la liste des fonctionnalités restantes
    41. 41. Scrum : Rétrospective du Sprint ● Analyse par l'équipe des problèmes  rencontrés ● Réflexion sur les solutions aux problèmes
    42. 42. Scrum :  cas pratique
    43. 43. Forces et Faiblesse des méthodes  Agiles ✔ Productivité ✔ Qualité ✔ Souplesse ✔ Environnement  ✗ Échelle des équipes ✗ Équipe expérimenté ✗ Non applicable à tout  les projets ✗ Coûts variables

    ×