1. Formation
Initiation à l’agile
Mathieu Gandin

2. Agilité
Think BIG
Start small
Deliver Quickly
© OCTO 2012 2

3. L'histoire
Nouvelles approches
du développement logiciel 3

4. Manifeste pour le développement agile
« Nous découvrons comment mieux développer des logiciels par la
pratique et en aidant les autres à le faire. Ces expériences nous ont
amenés à valoriser :
 Les individus et leurs interactions plus que les processus et les outils
 Des logiciels opérationnels plus qu’une documentation exhaustive
 La collaboration avec les clients plus que la négociation contractuelle
 L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments mais privilégions
les premiers ».
Manifeste Agile 2001,
http://agilemanifesto.org/iso/fr/ 4

5. Qu'est-ce qu'une méthode agile ?
Itératif et
Incrémental 5

6. Qu'est-ce qu'une méthode agile ?
Adaptation au
changement 6

7. Qu'est-ce qu'une méthode agile ?
Plus pragmatique
Engagement sur les résultats 7

8. Qu'est-ce qu'une méthode agile ?
Implique fortement le client
Dialogue sur les exigences 8

9. Exigences
Que fait-on durant une itération ?
Conception
Test
Développement
Plutôt que toute une discipline d’un coup
Un peu de tout à la fois 9

10. A quoi reconnaît-on un projet agile ?
Livraisons fréquentes
Auto-amélioration
Communication proche
Concentration focus
Sécurité personnelle
Accès facile aux experts
Environnement technique robuste
Alistair Cockburn 10

11. Les rôles dans le projet agile
Product Owner Développeurs
assure le pilotage implémentent le logiciel
fonctionnel du projet dans les standards de
(exigences et validation) qualité
Utilisateurs Coach
expriment aide l’équipe à
les besoins métier s’approprier la
et évaluent méthode et à
l’utilisation du logiciel s’améliorer
11

12. Le cycle de développement agile
10 j. 2 semaines 6 mois
Cadrage Planning Démo, Mise en
version d’itération Bilan Prod.
d’itération Version
12

13. Artefacts agiles
Les scénarios utilisateur
Les tests de recette
Le backlog
13

14. Suivi et pilotage
Le burndown permet de voir le reste à faire mais ne permet pas de voir
simplement les ajouts de user stories en cours d’une release. Pour pallier à
cette limitation, des alternatives ont été proposées
14

15. La vélocité
15

16. Intégration continue
UDD
Source code
+ tests Tests de dév. Référentiel de Référentiel de
automatisés tâches / bug documentation
Développeur
Exécution des
Gestionnaire des Gestionnaire de contrôles
sources build qualité
Source code
+ tests
Développeur
Référentiel des Tests de recette Livraison de
Dépendances artefacts automatisés l’incrément
pour la démo /
l’intégration
automatiquement 16

17. Développement pilotés par les tests
Tests
d’IHM
Tests
de recette
Tests unitaires
et d’intégration
17

18. TDD
Acteurs / Actions / Assertions
Avancer pas à pas avec les cas
TEST
aux limites puis les cas
nominaux (0, 1, N)
Nommage clair qui exprime
l’intention du code
© OCTO 2011 18

19. TDD
« YAGNI »
« Fake It ’til you make it»
Qui marche !
CODE
Acteurs / Actions / Assertions
Avancer pas à pas avec les cas
TEST
aux limites puis les cas
nominaux (0, 1, N)
Nommage clair, exprime
l’intention, API de vos rêves
© OCTO 2011 19

20. TDD
« YAGNI »
« Fake It ’til you make it»
Qui marche !
CODE Supprimer le code mort
Acteurs / Actions / Assertions
ou inutile
Avancer pas à pas avec les cas Réduire la duplication
TEST REFACTOR
aux limites puis les cas « DRY »
nominaux (0, 1, N)
Simplifier (« KISS »)
Nommage clair, exprime Fierté du design
l’intention, API de vos rêves Objet !
© OCTO 2011 20

21. Management visuel
21

22. Critères d’éligibilité
Projet stratégique (enjeux important et vision partagée MOA, MOE et Métier)
Time-to-market fort (retour rapide et réactivité importante de la part des clients)
Projet co-localisé
Projet internalisé
Projets faiblement couplé avec des progiciels nécessitant un paramétrage long et complexe
Equipe de 10 personnes
Budget à 500 j/h max
Besoins métiers faiblement spécifiés
Contrainte de date de livraison forte
© OCTO 2011 22

23. Un seule condition pour démarrer …
Avoir envie
d’essayer …
© OCTO 2011 23

24. Glossaire
 Backlog
 Liste ordonnée de toutes les choses à faire. On parle de:
• Backlog de produit qui énumère toutes exigence souhaitées du
produit final
• Backlog de sprint qui contient les tâches de l'équipe
• Backlog de problème (voir Rétrospective de sprint)
 Diagramme d’avancement (burndown chart)
 Représentation graphique du reste à faire dans une
période, actualisé aussi souvent que possible et permettant de
montrer une tendance de l'avancement
 Release
 Une release correspond à la livraison d'une version. Par
habitude, on parle de release pour considérer la période de
temps qui va du début du travail sur cette version jusqu'à sa
livraison et qui passe par une série de sprints successifs
 Rétrospective d’itération
 Bilan d’équipe en fin de sprint, qui débouche sur un Backlog de
problèmes à résoudre
© OCTO 2011 24

25. Glossaire
 Responsable Produit (Product Owner)
 Le représentant du client. C’est lui qui porte la vison
métier et construit le Backlog initial
 Revue d’itération
 La revue de sprint correspond à la démonstration réalisée
par l’équipe en fin de sprint
 Revue de Backlog
 Actualisation régulière et formelle du Backlog de Produit.
S’organise généralement en fin de sprint
 Scrum
 C’est la méthode mais c'est aussi le nom usuel de la
réunion quotidienne limitée à un quart d'heure
© OCTO 2011 25

26. Glossaire
 Scrum Master
 Animateur, facilitateur d'une équipe Scrum
 Itération
 Bloc de temps, cycle aboutissant à créer un incrément du
produit potentiellement livrable. C'est le terme utilisé dans
Scrum pour itération. Dure de 1 à 4 semaines. De préférence
les sprints sont planifiés à l’avance et d’une durée égale
 Tâche élémentaire
 Découpage d’une User Story en tout type d’action dont le
temps de réalisation est précisément estimé par l’équipe et
qui sert de base de calcul à la vélocité de l’équipe
 User Story
 Décrit, selon un formalisme précis, une action élémentaire
de l’utilisateur à travers le produit
© OCTO 2011 26