1.
Méthodes et Processus
Agiles
Ecole Informatique IN2P3 2008

2.
Agile ?
• Une méthode agile est une approche
itérative et incrémentale, qui est
menée dans un esprit collaboratif avec
juste ce qu’il faut de formalisme
• Elle génère un produit de haute qualité
tout en tenant compte de l’évolution
des besoins client

3.
Agile ?
• Modèle de développement à l’opposé du
modèle en cascade ou du modèle
en V, généralement basés sur le forfait

4.
Agile ?
• Beaucoup de méthodes et techniques dites
agiles existent !
• XP, Scrum, RAD, DSDM, ASD, FDD,
Crystal Clear, PUMA, AUP, etc.

5.
Agile ?
• Courant issu du Manifeste Agile
• L’interaction avec les personnes plutôt que les
processus et les outils
• Une production opérationnelle plutôt
qu’une documentation pléthorique
• La négociation avec le client plutôt que le
respect d’un contrat
• La collaboration au changement plutôt que le
suivi du plan

6.
Agile Manifesto

7.
• Notre première priorité est de satisfaire le
client en livrant tôt et régulièrement
des logiciels utiles.

8.
• Le changement est accepté, même
tardivement dans le développement. Les
processus agiles exploitent le changement
comme avantage compétitif pour le client.

9.
• Livrer fréquemment une application
fonctionnelle, toutes les deux semaines
à deux mois, avec une tendance pour la
période la plus courte.

10.
• Les gens de l'art et les développeurs
doivent collaborer quotidiennement
au projet.

11.
• Bâtissez le projet autour de personnes
motivées. Donnez leur
l'environnement et le soutien dont
elles ont besoin, et croyez en leur capacité
à faire le travail.

12.
• La méthode la plus efficace de transmettre
l'information est une conversation en
face à face.

13.
• Un logiciel fonctionnel est la meilleure
unité de mesure de la progression du
projet.

14.
• Les processus agiles promeuvent un
rythme de développement
soutenable. Commanditaires,
développeurs et utilisateurs devraient
pouvoir maintenir le rythme indéfiniment.

15.
• Une attention continue à l'excellence
technique et à la qualité de la
conception améliore l'agilité.

16.
• La simplicité - l'art de maximiser la
quantité de travail à ne pas faire - est
essentielle.

17.
• Les meilleures architectures, spécifications
et conceptions sont issues d'équipes qui
s'auto-organisent.

18.
• À intervalle régulier, l'équipe réfléchit
aux moyens de devenir plus efficace,
puis accorde et ajuste son
comportement dans ce sens.

19.
Méthodologie XP

20.
eXtreme Programming
• Réconcilier l´humain avec la productivité
• Voie d'amélioration
• Style de développement
• Discipline de développement d´applications
informatiques

21.
Objectif Principal
Réduire les coûts du
changement

22.
• Revues de code permanentes

23.
• Développement pilotés par les tests

24.
• Conception au cours du projet
(refactoring)

25.
• Privilégier systématiquement la méthode la
plus simple

26.
• Utiliser des métaphores pour faciliter la
communication

27.
• L’intégration des modifications se fait
quotidiennement, voire plusieurs fois
par jour

28.
• Les cycles de développement seront
réduits au plus court

29.
Cycles XP
Livraison &
Exploration Client feed-back
Attribution de
Tâches Développement
Création de Tests
Fonctionnels

30.
Programmation par
Paire
• Deux développeurs échangent et corrigent
mutuellement leur code
• Variante: l’un implémente les fonctionnalités
pendant que l’autre code les tests
nécessaires
• Qualité optimale !

31.
Tests unitaires et
fonctionnels
• Développement piloté par les tests (TDD)
• Etablir un contrat fonctionnel pour
l’application d’abord
• Développer ensuite

32.
Intégration Continue
• Garant de l’intégrité des développements
au cours des itérations
• Favorise la réactivité
• Instaure un contrôle continu de la qualité

33.
Cas Défavorables de
mise en œuvre d’XP
• Blocage culturel
• Grandes équipes de développement
• Feedback long et difficile à obtenir
• Impossibilité de fonctionner en binômes

34.
Méthodologie Scrum

35.
Scrum ?
• Méthodologie de gestion de projet
• Issue du terme “mêlée” (Rugby) en anglais
• Avancer ensemble vers un but commun
• Pas fondamentalement liée au
développement logiciel
• Bon complément à XP

36.
Objectifs de Scrum
• Focaliser l’équipe sur la réalisation
d’objectifs dans un cycle itératif
• Itérations de 30 jours appelées Sprint,
chacune possédant son un périmètre
fonctionnel délimité
• Comme avec XP, la participation du
client est prépondérante

37.
Idées Clé
• Le client est au cœur du projet
• Esprit d’équipe
• La communication est la clé
• Simplicité, Efficacité, et Qualité
• Flexibilité aux changements
• Avancement basé sur le concret

38.
Rôles
• Product Owner (ou Directeur Produit)
C’est le représentant des clients et des
utilisateurs
• Scrum Master
Est chargé de protéger l'équipe de tous les
éléments perturbateurs extérieurs à
l'équipe et de résoudre ses problèmes non
techniques

39.
Rôles
• Equipe
Auto-gérée, elle s'adresse directement au
Directeur de produit.
• Intervenants (Stakeholders)
Personnes qui souhaitent avoir une vue sur
le projet sans réellement s'investir dedans
(experts, agents de direction)

40.
Processus
Intervenants
Clients extérieurs
Directeur de Produit
Eléments
perturbateurs Equipe étendue
Master
Scrum
Equipe

41.
Planification
Projet
Release Release
Sprint Sprint Sprint Sprint Sprint Sprint Sprint
...
Produit partiel, testé Version Produit partiel, testé
et utilisable finalisée et utilisable

42.
Le Sprint
• 30 jours calendaires (~2 à 4 semaines en
réalité)
• Associé à un but, matérialisé par la
réalisation d’un certain nombre d’items
du backlog produit

43.
Backlog Produit
• Liste des éléments fonctionnels à
implémenter
• Chaque élément du backlog est noté deux
fois en termes d’importance :
• Le Product Owner lui attribue une
valeur client
• Une estimation en points arbitraires
est faire par l’équipe (ex. Fibonacci)

44.
Backlog Produit
• Les items du backlog de produit peuvent
être réordonnés, ajoutés ou
supprimés d’un sprint - si les conditions
l’exigent et après concertation de
l’Equipe Etendue

45.
Backlog Produit

46.
Backlog de Sprint
• L’équipe sélectionne les items du
backlog produit à prendre en charge
pour le sprint
• Chaque item est décomposé en tâches
dont la durée ne doit jamais excéder deux
jours
• Chaque tâche traitée donne lieu à une
mise à jour du backlog de sprint

47.
Backlog de Sprint

48.
Sprint Burndown Chart
• C’est la somme des heures des items du
backlog de sprint, soit le reste à faire total
du sprint
• Il montre le reste à faire au fur et à
mesure de l’avancement du sprint

49.
Vélocité
• Une fois un sprint terminé, on peut calculer
la vélocité de l’équipe, et estimer la
charge des prochains sprint d’une façon de
plus en plus fiable

50.
Daily Scrum
• C’est une réunion quotidienne de 15
minutes maximum destinée à faire un
point sur l’avancement du sprint
• Chaque membre répond à 3 questions :
• Qu'est-ce que j'ai fait hier ?
• Qu'est-ce que je compte faire aujourd'hui ?
• Quelles difficultés est-ce que je rencontre ?

51.
Revue de Sprint
• A la fin d’un sprint, c’est une réunion de
quelques heures destinée à comprendre
ce qui n’a pas marché quand c’est le
cas
• Il faut en tirer des axes d’amélioration
pour les sprints suivants, et adapter le
backlog produit en conséquence

52.
Eléments Déterminants
• Travailler dans la même pièce
• Equipe idéale constituée de 4 développeurs
• Tableau blanc, post-its
• Calme

53.
Questions ?