Presentation in French of Agile methodologies: SCRUM and eXtreme Programming

1. Introduction à eXtreme
Programming et Scrum

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. Histoire des méthodes de
développement de projet

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. 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. eXtreme Programming :
Diagramme général

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. eXtreme Programming : Diagramme
Projet

27. eXtreme Programming : Diagramme
Itération

28. eXtreme Programming : Diagramme
Développement

29. eXtreme Programming : Diagramme
Code appartient au groupe

30. eXtreme Programming :
cas pratique

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. Scrum : Diagramme

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. 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. 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. 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. 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. 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. 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. 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. Scrum : Rétrospective du Sprint
● Analyse par l'équipe des problèmes
rencontrés
● Réflexion sur les solutions aux problèmes

42. Scrum :
cas pratique

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