1. Les méthodes agiles
UM2 –2011-2012
2011 - 2012 Les méthodes agiles – S. Mathon 1

2. 2
Sommaire
Introduction
L’origine des Méthodes Agiles
Le déroulement d’un projet Scrum
Au démarrage d’une version
Au démarrage d’une itération/sprint
Le déroulement d’une itération
La fin d’une itération
Pour aller plus loin : eXtreme Programming
2011 - 2012 Les méthodes agiles – S. Mathon

3. Les ratages et l’informatique
Une Histoire de bug
2011 - 2012 Les méthodes agiles – S. Mathon 3

4. 4
Un projet raté, c’est un produit
qui…
Ne répond pas aux besoins
A été livré trop tard
A coûté trop cher
N’est pas fiable
« Il est incroyablement difficile de
réaliser dans les délais prévus des
logiciels satisfaisant leurs cahiers des
charges »
2011 - 2012 Les méthodes agiles – S. Mathon

5. 5
Un constat alarmant au niveau mondial
Situation en 2002
Résultat des projets
Par le Standish Group CHAOS Report
(http://www.standishgroup.com)
Type 1 :
Projet terminé dans les temps, les budgets et avec les
fonctionnalités prévues
Type 2 :
Projet terminé en retard, hors budget ou avec une limitation de
fonctionnalité
Type 3 :
Projets abandonnés
2011 - 2012 Les méthodes agiles – S. Mathon

6. 6
Résultats 2009 : une nette
amélioration
Projets terminés dans les temps, les budgets
et avec les fonctionnalités prévues : 32%
Projets terminés en retard, hors budget ou
avec une limitation de fonctionnalité : 44%
Projets abandonnés ou livrés mais jamais
utilisés : 24%
2011 - 2012 Les méthodes agiles – S. Mathon

7. 7
Causes d’échec en informatique
selon le Standish Group
Manque de clarté ou mauvaise définition des
besoins
Evolution des spécifications
Manque de réactivité
Priorités non définies
Manque de qualité du logiciel
Conception trop ambitieuse
Evolutions non prévues
Rarement parce que la programmation est
mauvaise
2011 - 2012 Les méthodes agiles – S. Mathon

8. « Le chemin est long du projet à la 8
chose» Molière
2011 - 2012 Les méthodes agiles – S. Mathon

9. 9
L’apparition des méthodes agiles
2011 - 2012 Les méthodes agiles – S. Mathon

10. 10
Manifeste des méthodes agiles
Signé par 17 personnalités
4 valeurs
L'équipe « Personnes et interaction plutôt
que processus et outils »
L'application « Logiciel fonctionnel plutôt que
documentation complète »
La collaboration « Collaboration avec le client
plutôt que négociation de
contrat »
L'acceptation du changement « Réagir au changement plutôt
que suivre un plan »
2011 - 2012 Les méthodes agiles – S. Mathon

11. 11
Méthodes agiles : les 12
principes
Satisfaction client
Changement bienvenu
Livraisons fréquentes
Collaboration quotidienne
Motivation et encouragements
Communication face-à-face
Logiciel sert de mesure
2011 - 2012 Les méthodes agiles – S. Mathon

12. 12
Les 12 principes (suite)
Rythme soutenable
Attention continue à la technique et à la
conception
Simplicité
Auto-organisation
Ajustements continus
2011 - 2012 Les méthodes agiles – S. Mathon

13. 13
Exemples
Scrum
Extreme programming (XP)
Rapid Application Development (RAD)
Adaptive software development (ASD)
Crystal clear
Dynamic software development method
(DSDM)
Feature driven development
2011 - 2012 Les méthodes agiles – S. Mathon

14. Scrum
Le déroulement
2011 - 2012 Les méthodes agiles – S. Mathon 14

15. 15
Scrum
Les racines de Scrum se retrouvent dans la
publication de Takeuchi et Nonaka dans "The
New Product Development Game“
Ken Schwaber et Jeff Sutherland la
formalisent en 1996
SCRUM est un framework de méthodologie
SCRUM est un framework non prescriptif
2011 - 2012 Les méthodes agiles – S. Mathon

16. 16
Les rôles
Scrum Master
Responsable de faire appliquer par l’équipe les valeurs
et les pratiques de Scrum
Facilite la résolution des problèmes
Product Owner
C'est le représentant des clients et des utilisateurs
C'est lui qui donne les fonctionnalités à traiter, et
qui prend les décisions importantes concernant
l'orientation du projet
Il gère le Backlog de Produit et le Release Plan
Team Member
Tous les autres
2011 - 2012 Les méthodes agiles – S. Mathon

17. 17
Pause : le jeu de la balle
Chacun est membre d’une équipe
Entre chaque participant, la balle doit voler (« air-time »)
Chaque balle doit être touchée par chaque membre de l’équipe
Vous ne pouvez pas passer la balle à votre voisin ou voisine de
gauche ou de droite
Chaque cycle de balle doit démarrer et se terminer par la même
personne
Une balle qui tombe par terre est perdue : elle doit
recommencer le cycle
Il y aura 5 itérations
Les seules règles sont celles écrites ci-dessus
2011 - 2012 Les méthodes agiles – S. Mathon

18. 18
Planning
Explication des règles
2 min Création des équipes
2 min Organisation de l’équipe
1 min Estimation du temps
2 min itération
1 min debriefing de l’itération
Après les 5 itérations : 10 min de
debriefing commun
2011 - 2012 Les méthodes agiles – S. Mathon

19. 19
Workflow Agile
2011 - 2012 Les méthodes agiles – S. Mathon

20. 20
Définitions
Sprint : itération dans Scrum – 2 semaines à 1 mois
Scrum : mêlée quotidienne
Product Backlog : cahier des charges initial
User Story : terme eXtreme Programming, qui définit
la manière d ’exprimer les attentes utilisateur
Sprint Backlog : le contenu choisi pour un sprint
Scrum daily meeting : réunion quotidienne de
l’équipe développement
2011 - 2012 Les méthodes agiles – S. Mathon

21. 21
Itératif vs Incrémental
2011 - 2012 Les méthodes agiles – S. Mathon

22. 22
Les règles fondamentales
Les itérations sont courtes : 2 semaines
à 1 mois maximum
Les itérations ne se chevauchent pas
Les itérations ont toujours la même
durée
La date de fin du sprint n’est JAMAIS
repoussée
Les itérations s’enchaînent en général
sans délai
2011 - 2012 Les méthodes agiles – S. Mathon

23. Scrum
Le démarrage d’une version
2011 - 2012 Les méthodes agiles – S. Mathon 23

24. 24
Avoir la vision globale
Comme pour toute méthode de gestion
de projet, comprendre le contexte et les
objectifs du projet.
Déterminer les utilisateurs du projet
Plusieurs approches possibles :
Document de Vision
Modèle Volere
2011 - 2012 Les méthodes agiles – S. Mathon

25. 25
Objectifs du projet
Résumer le projet en une phrase
Quels sont les avantages « business » pour le
client?
Définir comment mesurer le succès du projet
Le projet est-il réaliste/faisable?
Est-ce que toutes les personnes impliquées
l’approuvent?
Quelle est l’importance du projet pour le
client?
2011 - 2012 Les méthodes agiles – S. Mathon

26. 26
Le Product Backlog
Ensemble des évolutions prévues pour la
version, plus ou moins précises
Un Backlog est vivant
Parfois modifications quotidiennes
Surtout en réunions de sprint
Représentation sous forme de liste
Importance de la priorité : donne l’ordre de
réalisation
Le Backlog est partagé
2011 - 2012 Les méthodes agiles – S. Mathon

27. 27
La User Story
Les User Stories sont des « histoires »
Avec :
un acteur
qui effectue une action
dans un objectif donné.
Une User Story doit pouvoir être développée
entièrement pendant une itération.
Un Backlog contient également des Stories
techniques ou méthodologiques (Ex : tests
unitaires)
2011 - 2012 Les méthodes agiles – S. Mathon

28. 28
Exemple de Product Backlog
ID User Story Comment le Valeur Estimation Sprint
démontrer
001 Un <utilisateur> Soit sous forme Importance Effort pour Sprint
fait une <action> de scénario, soit d’un point de implémenter dans
dans un liste des vue la US lequel la
<objectif> donné exigences utilisateur US est
incontournables prise en
compte
2011 - 2012 Les méthodes agiles – S. Mathon

29. 29
Le Plan de Release : pour
garder le cap
Répartition indicative des User Stories dans
les sprints
Prise en compte des dates fatidiques
Fait par toute l’équipe
1- Définir le critère 3- Durée des
de fin sprints
Plan de release
2- Estimer les 5- Planifier la
Backlog stories Backlog release
estimé
4- Estimer la capacité de
l’équipe
2011 - 2012 Les méthodes agiles – S. Mathon

30. 30
Problèmes classiques de
Backlog
Les problèmes classiques de gestion
des exigences :
Stories exprimées sous forme de solution
Stories exprimées sous forme technique
Ambigüité/flou
Manques/doublons/incompatibilité
Product Backlog trop lourd
Stories trop grosses
2011 - 2012 Les méthodes agiles – S. Mathon

31. 31
L’estimation dans Scrum
Estimer la taille/difficulté plutôt que la
durée
Estimation en points = jours/hommes
idéaux
Estimer de façon relative, par rapport à
une story connue
Les estimations sont INDICATIVES
Cf Planning Poker
http://www.planningpoker.com/detail.html
2011 - 2012 Les méthodes agiles – S. Mathon

32. 32
Exercice : la planification
culinaire
Librement inspiré du Doggy Planning
http://tastycupcakes.org/2009/06/dogg
y-planning/
L ’équipe estime le contenu du Backlog
Planning Poker :
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?,
Pause
2011 - 2012 Les méthodes agiles – S. Mathon

33. 33
Backlog
Votre Backlog contient les plats suivants :
Nouilles au beurre
Osso bucco
Gâteau au chocolat
Pizza au thon
Waterzoi
Ikita mashitsu
Vous estimez le temps pour préparer chacun
de ces plats – Unité : le Miam
20 min d’estimation
2011 - 2012 Les méthodes agiles – S. Mathon

34. Scrum : les sprints
Illustration VisualExplainer
2011 - 2012 Les méthodes agiles – S. Mathon 34

35. 35
La durée de sprint
Durée fixe
Consensus entre
le besoin de feedback/la motivation
vs le coût lié au sprint/la disponibilité du
Product Owner
Au minimum 4 sprints par version
2011 - 2012 Les méthodes agiles – S. Mathon

36. 36
La réunion de planification de
sprint
1- Le Product Owner présente l’objectif
du sprint et les Stories candidates
1bis – La colonne « Comment le
démontrer est remplie »
2- L’équipe liste les tâches nécessaires
(<1 jour) et affine l’estimation
3- Accord sur le périmètre du sprint
Consensus entre la capacité, la faisabilité
et l’importance
2011 - 2012 Les méthodes agiles – S. Mathon

37. 37
A préparer avant
Le Product Backlog existe :
Les exigences/User stories sont listées
Le Product Owner a mis l’importance des
stories les plus importantes et sélectionné
ses candidates
Le Scrum Master a calculé la capacité
du sprint (quelle quantité de stories
peut être traitée)
2011 - 2012 Les méthodes agiles – S. Mathon

38. 38
Conditions
Ailleurs que dans le bureau
Tableau blanc
Fixer la durée maximum à respecter : en
général, 2*<durée du sprint (en semaines)>
heures
Ne pas commencer à résoudre les problèmes
techniques, mais faire de la conception
Poser les bonnes questions au Product Owner
Garder du mou
2011 - 2012 Les méthodes agiles – S. Mathon

39. 39
Le tableau blanc
2011 - 2012 Les méthodes agiles – S. Mathon

40. 40
Et les tests?
Prévoir les tests d’acceptation dès la
planification du sprint
Le scénarios de tests permettent :
De comprendre les Stories
De préparer la recette de sprint
Les tests sont effectués en cours de
sprint, pas à la fin
2011 - 2012 Les méthodes agiles – S. Mathon

41. 41
Mise en bouche : jeu du ballon
Mon cahier des charges :
mon ballon
2011 - 2012 Les méthodes agiles – S. Mathon

42. 42
Règle du jeu
Chaque équipe a 2 minutes pour créer
le plus possible de ballons et me les
amener
Résultats et debriefing
2ème itération
2011 - 2012 Les méthodes agiles – S. Mathon

43. Scrum : en cours de sprint
2011 - 2012 Les méthodes agiles – S. Mathon 43

44. 44
Déroulement du sprint
Chaque développeur s’approprie des tâches
des User Stories de l’itération
Premières tâches attribuées à la réunion de sprint
Ensuite, au cours des réunions quotidiennes
Tous les matins, réunion café/standup
meeting/scrum meeting pour débloquer les
problèmes et mesurer l’avancement
Au bout de l’itération, seules les User Stories
complètes sont livrées
2011 - 2012 Les méthodes agiles – S. Mathon

45. 45
Le Scrum Daily Meeting
Faire le point sur les tâches depuis le
dernier Scrum meeting
S’attribuer de nouvelles tâches
Organiser le travail de la journée en cas
d’obstacle (besoin d’expertise, de
travailler à 2, problèmes de serveurs…)
2011 - 2012 Les méthodes agiles – S. Mathon

46. 46
Daily Meeting : les principes
Tous les matins
Pas plus d’1/4 heure
Personne ne dirige la réunion, même si le Scrum
Master peut l’animer
Tout le monde participe
Équipe (y compris Scrum Master)
Product Owner au moins quelques fois par semaine
Utilisation et mise à jour du tableau blanc
L’équipe peut faire appel à des experts
D’autres personnes peuvent y assister mais
n’interviennent pas
2011 - 2012 Les méthodes agiles – S. Mathon

47. 47
La notion de « fini » ou « done »
Définir dès le départ ce que veut dire « fini » :
Les stories :
Est-ce que ça inclut la documentation?
Est-ce que ça inclut des tests unitaires?
Est-ce que ça inclut des tests d’intégration/croisés?
La version
Une story en particulier : chaque story ne nécessite
pas le même travail
Permet d’aborder la notion de « portée »
2011 - 2012 Les méthodes agiles – S. Mathon

48. Scrum : la revue de sprint
2011 - 2012 Les méthodes agiles – S. Mathon 48

49. 49
Les principes
A lieu le dernier jour du sprint
Durée maximum : de 2 à 4 heures
Prend en général la forme d’une
démonstration :
Build avec les stories terminées
Idéalement faite par le Product Owner ou
un membre de l’équipe
2011 - 2012 Les méthodes agiles – S. Mathon

50. 50
La préparation
Tester ou faire tester les stories livrées
Préparer un plan de démonstration basé
sur les Stories livrées
Convier des invités éventuels
Installer sur une plateforme de
test/démonstration, avec des données
significatives
2011 - 2012 Les méthodes agiles – S. Mathon

51. 51
Les participants
Au minimum, toute l’équipe y compris
Product Owner et Scrum Master
Parfois les autres personnes intéressées
Marketing/commercial
Support
Éventuellement clients ou partenaires
2011 - 2012 Les méthodes agiles – S. Mathon

52. 52
Le contenu
Le Product Owner émet des demandes de
modification et recueille les feedbacks des
participants
Il mettra ensuite à jour le Product Backlog et
le Plan de Release, qui serviront à la
planification du sprint suivant
Les demandes de changement et les bugs
sont priorisés et pas forcément pris en
compte dans le sprint suivant
2011 - 2012 Les méthodes agiles – S. Mathon

53. 53
La rétrospective
Revenir sur le déroulement du sprint pour
optimiser l’organisation
Réunion suite à la réunion de fin de sprint
Bilan intermédiaire
Qu’est-ce qui s’est bien passé?
Qu’est-ce qui s’est mal passé?
Comment nous améliorer?
Idéalement, brainstorming
Choisir 1 amélioration pour le sprint à venir
2011 - 2012 Les méthodes agiles – S. Mathon

54. Scrum : résumé des rôles
2011 - 2012 Les méthodes agiles – S. Mathon 54

55. 55
Actions du Scrum Master
Veiller à ce que les pratiques Scrum soient
appliquées
Encourager l’équipe et le Product Owner et
les inciter à devenir autonomes
Protéger l’équipe des obstacles/interférences
en cours de sprint
Organiser et animer les réunions
« Le Scrum Master est au service de
l’équipe »
2011 – 2012 Les méthodes agiles – S. Mathon

56. 56
Le Scrum Master idéal
Bonne connaissance de Scrum
Comprend les aspects techniques
Communication
Bon guide, fait confiance
Médiateur
Tenace
Transparent
Au service de l’équipe
Sait prendre des risques
2011 - 2012 Les méthodes agiles – S. Mathon

57. 57
Questions fréquentes
Peut-on se passer de Scrum Master?
Le Scrum Master doit-il être le Chef de
Projet?
Le Scrum Master peut-il venir en plus
du Chef de Projet?
2011 - 2012 Les méthodes agiles – S. Mathon

58. 58
Actions du Product Owner
Participe aux réunions
De début de sprint
Quotidiennes, parfois
De fin de sprint
À la rétrospective
Est responsable du Backlog de Produit
Répond aux questions sur le produit
Définit les tests d’acceptation
Passe ou fait passer ces tests
2011 - 2012 Les méthodes agiles – S. Mathon

59. 59
Le Product Owner idéal
Bonne connaissance du domaine métier
Maîtrise des techniques de définition de
produit
Capacité à prendre des décisions rapidement
Capacité à détailler quand il le faut
Ouvert au changement…mais sans changer
d’avis tout le temps
Aptitude à la négociation
Disponible pour le rôle
2011 - 2012 Les méthodes agiles – S. Mathon

60. 60
L’équipe
Multi-disciplinaire
Esprit d’équipe
Pas d’élément perturbateur
Mieux vaut un correct niveau moyen
que des stars individuelles
2011 - 2012 Les méthodes agiles – S. Mathon

61. 61
Ne pas oublier
Ce n’est pas parce que les rôles ont l’air
d’être parfaitement définis que vous pouvez
vous passer de les préciser au démarrage et
en cours de projet
Les pratiques ont l’air d’être définies mais
laissent une certaine liberté :
Faire du Scrum, c’est appliquer tous ses
principes, mais réfléchir dès que nécessaire à la
façon de les appliquer
2011 - 2012 Les méthodes agiles – S. Mathon

62. Des pratiques supplémentaires
XP… ou eXtreme Programming
Rien à voir avec Windows
2011 - 2012 Les méthodes agiles – S. Mathon 62

63. 63
XP et la gestion de projet
Séance de Planification (Planning Game)
Livraisons Fréquentes (Frequent Releases)
Rythme Soutenable (Forty-hour Week)
Client sur le Site (On-Site Customer)
2011 - 2012 Les méthodes agiles – Sandrine Mathon

64. 64
XP et les développeurs
Développement conduit par les Tests
Unitaires (Unit Tests, Tests Driven Development)
Conception Simple (Simple Design) et code
maintenable
Re-factorisation de Code pratiquée sans relâche
Tests de Recette (Acceptance Tests)
2011 - 2012 Les méthodes agiles – S. Mathon

65. 65
Les TDD
Ecrire les tests unitaires
Ecrire d’abord les tests unitaires
Processus itératif :
Un test qui produit une erreur
Le code qui résout l’erreur
Un test qui produit une erreur
Le code qui résout l’erreur
…etc…
Les tests unitaires servent d’outil de
conception
2011 - 2012 Les méthodes agiles – S. Mathon

66. 66
Conception simple
Conception architecturale simple
Pas de conception détaillée
Evitez d’anticiper toutes les évolutions
probables : de toute façon, vous vous
trompez
Ne définissez QUE ce dont vous avez
besoin pour l’itération
2011 - 2012 Les méthodes agiles – S. Mathon

67. 67
Refactoring
Remanier le code pour le simplifier
Doit être pratiqué de façon permanente
Pallie à l’absence de conception initiale
Ne pas hésiter à jeter et ré-écrire
Demande un sacré courage
2011 - 2012 Les méthodes agiles – S. Mathon

68. 68
XP et l’équipe développements
Propriété Collective du Code (Collective
Code Ownership)
Convention de Code (Coding Standard)
Programmation En Binôme (Pair
Programming)
Intégration Continue (Continuous
Integration)
Métaphore (Metaphor)
2011 - 2012 Les méthodes agiles – S. Mathon

69. 69
XP et l’équipe développement
2011 - 2012 Les méthodes agiles – S. Mathon

70. 70
Propriété collective du code
Pas de répartition par module
Chaque développeur connaît TOUT le
code
Pas de panique en cas d’absence d’un
développeur
Facilite le refactoring
2011 - 2012 Les méthodes agiles – S. Mathon

71. 71
Convention de code
Parce que le code appartient à tout le
monde
Parce que le code devient l’outil de
communication
Noms de fonctions parlants
Noms de variables clairs
Le coach surveille aussi cette partie-là
2011 - 2012 Les méthodes agiles – S. Mathon

72. 72
Programmation en binôme
Première cause d’échec :
Le travail en binôme mal compris
2 développeurs côte-à-côte, pas toujours les
mêmes
Choisir les moments où le binôme est
nécessaire
Permet une meilleure intégration des
nouveaux
Favorise la propriété collective du code
2011 - 2012 Les méthodes agiles – S. Mathon

73. 73
Intégration continue
Le code est compilé en permanence
Ce qui est mis à l’intégration doit être terminé
Le client a accès au produit en permanence
pour tester
Certaines équipes XP ou Scrum interdisent les
demandes de changement de la part du client au
cours d’une itération
Intégration automatisée
2011 - 2012 Les méthodes agiles – S. Mathon

74. 74
Métaphore
Vous ne développez plus un logiciel,
mais un « bureau » ou une « Ferrari »
ou une « maison »…
Pour la Ferrari, vous vous occupez de
ses roues, de son moteur, de sa
carrosserie…
Crée une complicité autour du produit
2011 - 2012 Les méthodes agiles – S. Mathon

75. Kanban, Lean
Les « nouvelles » tendances
2011 - 2012 Les méthodes agiles – S. Mathon 75

76. 76
Agile = Lean?
Amélioration continue (Kaizen)
Elimination des gaspillages :
production excessive,
attentes,
transport et manutention inutiles,
tâches inutiles,
stocks,
mouvements inutiles
production défectueuse.
2011 - 2012 Les méthodes agiles – S. Mathon

77. 77
Kanban agile
http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire
2011 - 2012 Les méthodes agiles – S. Mathon

78. 78
Kanban agile : les principes
Visualisez le workflow :
Divisez votre travail, décrivez chaque élément sur une fiche et mettez-
la au mur.
Tracez des colonnes, donnez-leur le nom des étapes du workflow et
placez y les éléments de travail.
Limitez le TAF (travail à faire) : fixez des limites précises indiquant
combien d'éléments peuvent être placés dans chaque étape du
workflow.
Mesurez et optimisez le temps de cycle (temps moyen pour
traiter complètement un élément, appelé "lead time" en anglais),
optimisez le processus pour que le temps de cycle soit aussi court et
prévisible que possible.
2011 - 2012 Les méthodes agiles – S. Mathon

79. 79
Les apports de Kanban
Obliger à résoudre les problèmes (sinon
la chaîne se bloque)
Mettre l’accent sur les goulets
d’étranglement et encourager la
collaboration pour les lever
Permet de fluidifier le travail
Mettre en exergue la notion de fini
Est compatible avec Scrum
2011 - 2012 Les méthodes agiles – S. Mathon

80. 80
Les dangers de Kanban
Favoriser la vision à très court terme
Peu de principes définis, il faut donc
réfléchir au reste
Risque de prétexte pour ne rien organiser
Impression de « chômage technique »
en cas de blocage
Et donc risque d’abandon de l’approche
2011 - 2012 Les méthodes agiles – S. Mathon

81. 81
Les idées reçues sur l’Agile
Pas de documentation
Tout est défini, pas besoin de réfléchir à
l’organisation
L’équipe doit être autonome donc il ne
faut pas la diriger
Le client dirige l’équipe
2011 - 2012 Les méthodes agiles – S. Mathon

82. 82
La documentation
Les problèmes de la documentation:
Specs difficiles à maintenir à jour
Coupe la communication
Agile ne veut pas dire « pas de doc »
Oui à la doc comme recueil de
connaissance sur le projet et source
d’amélioration continue
2011 - 2012 Les méthodes agiles – S. Mathon

83. 83
L’Agile dans l’entreprise
2011 - 2012 Les méthodes agiles – S. Mathon

84. 84
Toutes les entreprises peuvent-elles
être agiles?
Je suis une SSII
Je suis un éditeur de logiciel
Je développe mes logiciels internes
2011 - 2012 Les méthodes agiles – S. Mathon

85. 85
La culture d’entreprise
2011 - 2012 Les méthodes agiles – S. Mathon

86. 86
Tous les projets peuvent-ils être
agiles?
Mon produit est un mélange
d’informatique et d’électronique
Petits projets d’une ou 2
personnes
Énormes projets avec des
équipes de plus de 20
personnes : gros projets
OpenSource
Nécessite des concepts objets
forts, une bonne connaissance
technique, au moins 1 très bon
développeur
2011 - 2012 Les méthodes agiles – S. Mathon

87. 87
Causes d’échec
Le laxisme: tout n’est pas pré-mâché
Le fanatisme
Changement d’état d’esprit difficile
Hostilité du management
Le client n’est pas disponible
Agilité ne veut pas dire changement de priorité ou
interruption toutes les 5mn
Il faut trouver le bon coach/scrum master
Technologie pas assez souple (pas d’approche
objet…)
Mauvaise ambiance dans l’équipe
2011 - 2012 Les méthodes agiles – S. Mathon

88. 88
Bénéfices
Chaque développeur est 7 fois plus
productif avec le TDD
Motivation des équipes, augmentation
du niveau
Synergie
Qualité du logiciel lissée
Les retards ou problèmes sont détectés
tôt
2011 - 2012 Les méthodes agiles – S. Mathon

89. 89
Et la documentation?
Idée reçue : Agile = pas de doc
Idée à retenir :
Non à la doc comme « interface » de
communication
Oui à la doc comme recueil de
connaissance sur le projet et source
d’amélioration continue
2011 - 2012 Les méthodes agiles – S. Mathon

90. 90
Les outils
Plateforme Eclipse
Gestion de configuration : SVN, CVS, GIT
Frameworks de Tests Unitaires : Junit,
CPPUnit…
Création de builds et fiches de livraison :
Maven, Hudson
Test de la couche graphique et applis WEB :
Selenium, Squish
Fit : framework de test collaboratif
XPlanner : gestion de projet XP
2011 - 2012 Les méthodes agiles – S. Mathon

91. L’Agile à Montpellier
2011 - 2012 Les méthodes agiles – S. Mathon 91

92. 92
XP et Scrum
Tissu de PMEs/TPEs TIC
Agile = dynamisme et qualité des
versions
eXtreme Programming pour les
entreprises naissantes
SCRUM a le vent en poupe
Agile Tour à Montpellier en 2011 pour la
première fois
2011 - 2012 Les méthodes agiles – S. Mathon

93. 93
Quelques entreprises Agile
IGEOSS - Editeur de progiciel de modélisation
géomécanique – XP
NORMIND - Editeur de logiciel d’aide à la décision –
Scrum, XP
BSD Concept – Editeur de logiciels de généalogie -
Scrum
IOcean - SSII – Scrum
Synapse – SSII – Scrum, XP
La Poste!
2011 - 2012 Les méthodes agiles – S. Mathon

94. 94
L’Agile et les approches qualité
2011 - 2012 Les méthodes agiles – S. Mathon

95. 95
La qualité des produits
Les entreprises mal gérées dépensent 90%
de leurs efforts en qualité dans le traitement
des symptômes
Les entreprises bien gérées dépensent 80%
de leurs efforts en qualité dans la
prévention
Les coûts de prévention sont beaucoup moins
importants que les coûts de détection et de
correction
2011 - 2012 Les méthodes agiles – S. Mathon

96. 96
Les Normes Qualité
ISO 9001:2000 – par ISO
CMMi (Capability Maturity Model
Integration) – par le SEI
Commandé par l’armée américaine
Le SEI est hébergé par la Carnegie Mellon
University
2011 - 2012 Les méthodes agiles – S. Mathon

97. 97
Domaines de processus CMMi
2011 - 2012 Les méthodes agiles – S. Mathon

98. 98
Bénéfices de CMMi niveau2
Compréhension des besoins clients
Bonne préparation des projets
Bon suivi
Réduction des coûts de développement
Réduction des délais de livraison
Amélioration de la qualité du produit
2011 - 2012 Les méthodes agiles – S. Mathon

99. 99
Compatibilité avec l’Agile
Obligation de documentation
Possibilité d’automatiser la production des
documents
Histoires utilisateurs spécifications
Analyse automatique du code conception détaillée
Tests : tout est fait dans XP
Principes fondamentaux semblables
Difficultés
La traçabilité des exigences
Les CR de réunions
PPQA
2011 - 2012 Les méthodes agiles – S. Mathon

100. 100
Références
« Scrum », par Claude Aubry, DUNOD
Gestion de projet eXtreme Programming – Bénard, Bossavit, Medina,
Williams – Eyrolles
eXtreme Programming, La Référence – Kent Beck – Campus Press
http://www.agiletour.org/
Cas pratique : http://henrik-kniberg.developpez.com/livre/scrum-xp/
http://www.scrum.org/
http://www.infoq.com/minibooks/kanban-scrum-minibook
http://blog.octo.com/index.php/2008/01/25/69-pourquoi-les-methodes-
agiles-peinent-elles-a-penetrer-lentreprise
Jeux agiles: http://tastycupcakes.org
2011 - 2012 Les méthodes agiles – S. Mathon