Yannick

 Prié  
Département  Informatique  –  Faculté  des  Sciences  et  Technologies    
Université  Claude  Bernard  Lyon  1  
2011-­‐2012  
 ¡ 1/3  –  Méthodes  et  processus  
¡ 2/3  –  Processus  unifié  
¡ 3/3  –  Méthodes  Agile  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 2

 ¡ Principes  des  méthodes  Agile  
¡ XP  :  eXtreme  Programming  
¡ Scrum  
¡ Autres  méthodes  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 3

 ¡ Années  90  
§ réaction  contre  les  grosses  méthodes    
§ prise  en  compte  de  facteurs  liés  au  développement  logiciel  
¡ Fin  années  90  
§ méthodes  
▪ d’abord  des  pratiques  liées  à  des  consultants,  puis  des  livres  
▪ XP,  Scrum,  FDD,  Crystal…  
¡ 2001  
§ les  principaux  méthodologues  s’accordent  sur  le  «  Agile  
manifesto  »  
¡ Depuis  
§ projets  Agile  mixent  des  éléments  des  principales  
méthodes  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 4

 ¡ Rien  
§ «  code  and  fix  »  
§ marche  bien  sur  les  petits  projets,  suicidaire  ensuite  
¡ Monumental  
§ méthodes,  processus,  contrats  :  rationalisation  à  tous  les  étages  
§ problèmes  et  échecs  
▪ trop  de  choses  sont  faites  qui  ne  sont  pas  directement  liées  au  produit  
logiciel  à  construire  
▪ planification  trop  rigide  
¡ Agile  
§ trouver  un  compromis  :  le  minimum  de  méthode  permettant  de  
mener  à  bien  les  projets  en  restant  agile  
▪ capacité  de  réponse  rapide  et  souple  au  changement    
▪ orientation  vers  le  code  plutôt  que  la  documentation  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 5

 ¡ Méthodes  adaptatives  (vs.  prédictives)  
§ itérations  courtes  
§ lien  fort  avec  le  client  
§ fixer  les  délai  et  les  coûts,  mais  pas  la  portée  
¡ Insistance  sur  les  hommes    
§ les  programmeurs  sont  des  spécialistes,  et  pas  des  
unités  interchangeables  
§ attention  à  la  communication  humaine  
§ équipes  auto-­‐organisées  
¡ Processus  auto-­‐adaptatif  
§ révision  du  processus  à  chaque  itération  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 6

 ¡ Simplicité  
¡ Légèreté  
¡ Orientées  participants  plutôt  que  plan  
¡ Nombreuses    
§ XP  est  la  plus  connue  
¡ Pas  de  définition  unique  
¡ Mais  un  manifeste  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 7

 ¡ Février  2001,  rencontre  et  accord  sur  un  manifeste  
¡ Mise  en  place  de  la  «  Agile  alliance  »  
§ objectif  :  promouvoir  les  principes  et  méthodes  Agile  
§ http://www.agilealliance.com/    
¡ Les  signataires  privilégient  
§ les  individus  et  les  interactions  davantage  que  les  processus  et  les  
outils  
§ les  logiciels  fonctionnels  davantage  que  l’exhaustivité  et  la  
documentation  
§ la  collaboration  avec  le  client  davantage  que  la  négociation  de  contrat  
§ la  réponse  au  changement  davantage  que  l’application  d’un  plan  
¡ 12  principes  
§ (transparents  suivants)  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 8

 http://agilemanifesto.org/principles.html

1. Our  highest  priority  is  to  satisfy  the  costumer  through  early  and  
continuous  delivery  of  valuable  software.  
2. Welcome  changing  requirements,  even  late  in  development.  
Agile  process  harness  change  for  the  customer´s  competitive  
advantage.    
3. Deliver  working  software  frequently,  from  a  couple  of  weeks  to  a  
couple  of  months,  with  a  preference  to  the  shorter  timescale.  
4. Business  people  and  developers  must  work  together  daily  
throughout  the  project.  
5. Build  projects  around  motivated  individuals.  Give  them  the  
environment  and  support  they  need,  and  trust  them  to  get  the  
job  done.  
6. The  most  efficient  and  effective  method  of  conveying  
information  to  and  within  a  development  team  is  face-­‐to-­‐face  
conversation.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 9

 http://agilemanifesto.org/principles.html

1. Working  software  is  the  primary  measure  of  progress  

2. Agile  processes  promote  sustainable  development.  The  
sponsors,  developers,  and  users  should  be  able  to  
maintain  a  constant  pace  indefinitely  
3. Continuous  attention  to  technical  excellence  and  good  
design  enhances  agility  
4. Simplicity  –  the  art  of  maximizing  the  amount  of  work  
not  done  –  is  essential  
5. The  best  architectures,  requirements,  and  designs  
emerge  from  self-­‐organizing  teams  
6. At  regular  intervals,  the  team  reflects  on  how  to  become  
more  effective,  then  tunes  and  adjusts  its  behavior  
accordingly  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 10

 (Larman 2005, p.36-37)

¡ Utilisation  d’UML  
¡ La  modélisation  vise  avant  tout  à  comprendre  et  
à  communiquer  
¡ Modéliser  pour  les  parties  inhabituelles,  difficiles  
ou  délicates  de  la  conception.    
¡ Rester  à  un  niveau  de  modélisation  
minimalement  suffisant  
¡ Modélisation  en  groupe  
¡ Outils  simples  et  adaptés  aux  groupes  
¡ Les  développeurs  créent  les  modèles  de  
conception  qu’ils  développeront  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 11

 ¡ Principes  des  méthodes  Agile  
¡ XP  :  eXtreme  Programming  
¡ Scrum  
¡ Autres  méthodes  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 12

 ¡ Historique  
§ 1996  :  Ward  Cunningham  et  Kent  Beck    
§ Projet  Chrysler  Comprehensive  Compensation  (C3)  
§ Réorganisation  du  système  de  paie    
§ Propagation  mondiale  grâce  à  Internet  
§ Implantation  lente  en  France  
¡ Dimension  humaine  
§ considérée  comme  déterminante  pour  la  réussite  de  tout  projet  
¡ Principes  
§ Feedback  rapide  et  constant  
§ Compréhension  partagée  
§ Bien-­‐être  de  l  ’équipe  
§ Processus  fluide  et  continu  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 13

 ¡ Caractéristiques  principales  
§ Le  client  (maîtrise  d’ouvrage)  pilote  lui-­‐même  le  projet,  et  ce  de  très  près  grâce  
à  des  cycles  itératifs  extrêmement  courts  (1  ou  2  semaines).  
§ L’équipe  autour  du  projet  livre  très  tôt  dans  le  projet  une  première  version  du  
logiciel,  et  les  livraisons  de  nouvelles  versions  s’enchaînent  ensuite  à  un  
rythme  soutenu  pour  obtenir  un  feedback  maximal  sur  l’avancement  des  
développements.  
§ L’équipe  s’organise  elle-­‐même  pour  atteindre  ses  objectifs,  en  favorisant  une  
collaboration  maximale  entre  ses  membres.  
§ L’équipe  met  en  place  des  tests  automatiques  pour  toutes  les  fonctionnalités  
qu’elle  développe,  ce  qui  garantit  au  produit  un  niveau  de  robustesse  très  
élevé.  
§ Les  développeurs  améliorent  sans  cesse  la  structure  interne  du  logiciel  pour  
que  les  évolutions  y  restent  faciles  et  rapides.  
§ (extrait  de  http://www.design-­‐up.com/methodes/XP/)  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 14

 http://www.swen.uwaterloo.ca/~kostas/ECE355-05/lectures/Lect3-Ch15-Unit2.ppt

toutes les
2 ou 3 semaines
Planning

Écriture des tests

Release Programmation par pairs développement

+ Refactoring piloté par les tests

Test

Integration
chaque jour
(intégration continue)

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 15

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 16
 ¡ Comité  de  pilotage  
§ dirige  les  aspects  stratégiques  du  projet,    
§ définit  les  objectifs    
§ et  alloue  les  moyens  nécessaires  
¡ Client  interlocuteur  :      
§ le  plus  à  même  de  connaître  le  besoin  et  de  l’exprimer  
§ «  Client  interlocuteur  »  =  appui  du  «  sponsor  principal  »  
▪ directeur  des  systèmes  d’information    
▪ ou  porte-­‐parole  officiel  de  l’entreprise  disposant  d’une  autorité  suffisante  pour  
légitimer  le  projet  et  incarner  l’engagement  de  l’entreprise  
¡ En  phase  de  préparation,  il  faut  s’assurer  de:  
§ La  clarté  des  objectifs  du  projet    
§ Leur  compréhension  par  toutes  les  parties  prenantes  
§ Accord  de  l’entreprise  cliente  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 17

 ¡ Pratique  humaniste  favorisant    
§ l'élimination  progressive  des  risques  
§ l’établissement  d’un  rythme  de  travail  régulier,  sans  
heures  supplémentaires    
¡ But    
§ éliminer  le  stress,    
§ éliminer  les  tensions  a  l’intérieur  du  groupe,    
§ éliminer  les  tensions  entre  le  groupe  et  les  donneurs  
d’ordres,  
§ éliminer  le  risque  de  défection.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 18

 ¡ Profils  intervenants  dans  une  équipe  XP  :  
§ Client  
§ Testeur  
§ Manager  
§ Coach  
§ Tracker  
§ Programmeur  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 19

 ¡ Le  client  :  
§ Membre  à  part  entière  de  l’équipe  
§ Présence  physique  imposé  dans  l’équipe  tout  au  long  du  
développement  
§ Spécifie  les  fonctionnalités  à  implémenter  et  tests  fonctionnels  
§ Rôle  pouvant  être  tenu  par  une  ou  plusieurs  personnes  
¡ Le  testeur  :  
§ Assistant  du  client  
§ Un  programmeur    
§ Implémente  (code)  les  tests  de  recette  le  plus  tôt  possible,  valide  le  
fonctionnement  du  code  et  vérifie  la  non  régression  
¡ Le  manager  :  
§ Responsable  de  l’infrastructure  dans  laquelle  l’équipe  travaille  
§ S’assure  la  non  existence  de  problèmes  étrangers  au  projet  ou  
logistiques  (espace  de  travail,  outillage,  documentation,  etc.)  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 20

 ¡ Le  coach  :  
§ S’  assure  de  la  bonne  compréhension  de  la  méthode  XP  et  de  son  application  correcte  
par  les  différents  acteurs  du  projet  
§ Généralement  «  expert  méthode  »  et  bon  communicateur  doublé  d’un  technicien  
crédible  et  respecté  
§ A  pour  objectif  de  se  faire  oublier  
¡ Le  tracker  :  
§ Contrôle  l’avancement  des  tâches  à  l’intérieur  d’une  itération.    
§ S’entretient  fréquemment  avec  chaque  programmeur  pour  s’enquérir  des  difficultés  
rencontrées  et  du  travail  déjà  effectué.    
§ Construit  régulièrement  une  vision  fiable  de  l’avancement  des  tâches  afin  de  détecter  le  
plus  tôt  possible  les  dérives  et  de  lancer  une  nouvelle  phase  si  nécessaire  
¡ Le  programmeur  :  
§ Estime  la  charge  nécessaire  à  l’implémentation  d’un  scénario  dans  le  cadre  du  jeu  de  la  
planification.    
§ Implémente  les  scénarios  en  s’appuyant  sur  l’écriture  de  tests  unitaires  
§ Est  aussi  analyste,  concepteur.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 21

 ¡ Le  «  jeu  de  la  planification  »  
§ regroupement  des  intervenants  pour  planifier  l’itération  
§ les  développeurs  évaluent  les  risques  techniques  et  les  efforts  
prévisibles  liés  à  chaque  fonctionnalité  (user  story,  sortes  de  
scénarios  abrégés)  
§ les  clients  estiment  la  valeur  (l’urgence)  des  fonctionnalités,  et  
décident  du  contenu  de  la  prochaine  itération  
¡ Temps  court  entre  les  releases  
§ au  début  :  le  plus  petit  ensemble  de  fonctionnalités  utiles  
§ puis  :  sorties  régulières  de  prototypes  avec  fonctionnalités  
ajoutées      
¡ Métaphore  
§ chaque  projet  a  une  métaphore  pour  son  organisation,  qui  
fournit  des  conventions  faciles  à  retenir  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 22

 ¡ Conception  simple  
§ toujours  utiliser  la  conception  la  plus  simple  qui  fait  ce  qu’on  
veut    
▪ doit  passer  les  tests    
▪ assez  claire  pour  décrire  les  intentions  du  programmeur  
§ pas  de  généricité  spéculative  
¡ Tests    
§ développement  piloté  par  les  tests  :  on  écrit  d’abord  les  tests,  
puis  on  implémente  les  fonctionnalités  
§ les  programmeurs  s’occupent  des  tests  unitaires  
§ les  clients  s’occupent  des  tests  d’acceptation  (fonctionnels)  
¡ Refactoring    
§ réécriture,  restructuration  et  simplification  permanente  du  code  
§ le  code  doit  toujours  être  propre  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 23

 ¡ Programmation  par  paires  (pair  programming)  
§ tout  le  code  de  production  est  écrit  par  deux  programmeurs  
devant  un  ordinateur    
§ l’un  pense  à  l’implémentation  de  la  méthode  courante,  l’autre  à  
tout  le  système  
§ les  paires  échangent  les  rôles,  les  participants  des  paires  
changent  
§ permet  de    
▪ se  contrôler  mutuellement    
▪ diminuer  les  erreurs  de  conception  
▪ mieux  se  concentraer  sur  le  travail  
▪ éliminer  le  risque  de  dépendance  à  un  développeur  
▪ lisser  les  inégalités  d’expériences  en  associant  «  confirmé  &  débutant  »  
▪ faire  circuler  la  connaissance  à  l’intérieur  du  projet  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 24

 ¡ Propriété  collective  du  code  
§ tout  programmeur  qui  voit  une  opportunité  
d’améliorer  toute  portion  de  code  doit  le  faire,  à  
n’importe  quel  moment  
¡ Intégration  continue  
§ utilisation  d’un  gestionnaire  de  versions  (e.g.,  CVS)  
§ tous  les  changements  sont  intégrés  dans  le  code  de  
base  au  minimum  chaque  jour  :  une  construction  
complète  (build)  minimum  par  jour  
§ 100%  des  tests  doivent  passer  avant  et  après  
l’intégration    
2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 25
 ¡ Semaine  de  40  heures  (35  en  France  ?)  
§ les  programmeurs  rentrent  à  la  maison  à  l’heure  
§ faire  des  heures  supplémentaire  est  signe  de  
problème  
§ moins  d’erreurs  de  fatigue,  meilleure  motivation  
¡ Des  clients  sur  place  
§ l’équipe  de  développement  a  un  accès  permanent  à  un  
vrai  client/utilisateur  (dans  la  pièce  d’à  côté)  
¡ Des  standards  de  codage  
§ tout  le  monde  code  de  la  même  manière    
▪ tout  le  monde  suit  les  règles  qui  ont  été  définies  
▪ il  ne  devrait  pas  être  possible  de  savoir  qui  a  écrit  quoi  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 26

 ¡ Règles  
§ l’équipe  décide  des  règles  qu’elle  suit,  et  peut  les  
changer  à  tout  moment  
¡ Espace  de  travail  
§ tout  le  monde  dans  la  même  pièce  
▪ awareness  
§ tableaux  au  murs  
§ matérialisation  de  la  progression  du  projet  
▪ par  les  histoires  (user  stories)  réalisées  et  à  faire  
▪ papiers  qui  changent  de  position,  sont  réorganisés  
▪ par  les  résultats  des  tests  
▪ …  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 27

 ¡ Formation  
¡ Mise  à  niveau  des  ressources  avant  le  lancement  du  projet  :    
§ Phase  d’apprentissage  théorique  par  un  formateur  professionnel  
§ Mise  en  pratique  dans  le  cadre  d’un  projet  pilote  
¡ Projet  partagé  en  2  phases  :  
§ Phase  coaching,  peu  productive,  avec  pour  objectifs  de    
▪ réaliser  en  situation  le  potentiel  de  chaque  membre  
▪ gérer  les  parcours  individualisé  avec  le  soutien  pédagogique  de  moniteurs  (les  coachs)  
§ Phase  productive  lors  de  la  première  phase  du  vrai  projet  
¡ Montée  en  compétence  de  l’équipe  
¡ Objectifs    
§ Maximiser  la  rentabilité  de  l’investissement  pour  la  montée  en  compétences  
des  ressources  
§ Éviter  l’écueil  80/20  :  l’acquisition  des  20%  de  connaissances  les  plus  pointues  
requiert  80%  des  efforts  (et  de  l’investissement)  en  formation.    
▪ Faire  confiance  au  temps  et  considérer  l’uniformisation  des  compétences  collectives  
2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 28
 ¡ Planning   ¡ Coding  
§ User  stories  are  written.   § The  customer  is  always  available.  
§ Release  planning  creates  the  schedule.   § Code  must  be  written  to  agreed  
§ Make  frequent  small  releases.   standards.  
§ The  Project  Velocity  is  measured.   § Code  the  unit  test  first.  
§ The  project  is  divided  into  iterations.   § All  production  code  is  pair  programmed.  
§ Iteration  planning  starts  each  iteration.   § Only  one  pair  integrates  code  at  a  time.  
§ Move  people  around.   § Integrate  often.  
§ A  stand-­‐up  meeting  starts  each  day.   § Use  collective  code  ownership.  
§ Fix  XP  when  it  breaks.   § Leave  optimization  till  last.  
¡ Designing   § No  overtime.  
§ Simplicity.   ¡ Testing  
§ Choose  a  system  metaphor.   § All  code  must  have  unit  tests.  
§ Use  CRC  cards  for  design  sessions.   § All  code  must  pass  all  unit  tests  before  it  
can  be  released.  
§ Create  spike  solutions  to  reduce  risk.  
§ When  a  bug  is  found  tests  are  created.  
§ No  functionality  is  added  early.  
§ Acceptance  tests  are  run  often  and  the  
§ Refactor  whenever  and  wherever   score  is  published.    
possible.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 29

 ¡ Concept  intégré  et  simples  
¡ Pas  trop  de  management    
§ pas  de  procédures  complexes  
§ pas  de  documentation  à  maintenir  
§ communication  directe  
§ programmation  par  paires  
¡ Gestion  continuelle  du  risque  
¡ Estimation  permanente  des  efforts  à  fournir  
¡ Insistance  sur  les  tests  :  facilite  l’évolution  et  la  
maintenance  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 30

 ¡ Approprié  pour  de  petites  équipes  (pas  plus  
de  10  développeurs),  ne  passe  pas  à  l’échelle  
§ pour  des  groupes  plus  gros,  il  faut  plus  de  
structure  et  de  documentation  (ceremony)  
¡ Risque  d’avoir  un  code  pas  assez  documenté  
§ des  programmeur  qui  n’auraient  pas  fait  partie  de  
l’équipe  de  développement  auront  sans  doute  du  
mal  à  reprendre  le  code  
¡ Pas  de  design  générique    
§ pas  d'anticipation  des  développements  futurs    

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 31

 ¡ Principes  des  méthodes  Agile  
¡ XP  :  eXtreme  Programming  
¡ Scrum  
¡ Autres  méthodes  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 32

 http://web.engr.oregonstate.edu/~cook/classes/cs569.agile.ppt

¡ Scrum  :  mêlée  
¡ Phases  
§ Initiation  /  démarrage  
▪ Planning    
▪ définir  le  système  :  product  Backlog  =  liste  de  fonctionnalités,  
ordonnées  par  ordred  de  priorité  et  d’effort  
▪ Architecture    
▪ conception  de  haut-­‐niveau  
§ Développement  
▪ Cycles  itératifs  (sprints)  :  30j  
▪ amélioration  du  prototype  
§ Clôture  
▪ Gestion  de  la  fin  du  projet  :  livraison…  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 33

 http://fr.wikipedia.org/wiki/Scrum

¡ Isolement  de  l'équipe  de  développement    

§ l'équipe  est  isolée  de  toute  influence  extérieure  qui  
pourrait  lui  nuire.  Seules  l'information  et  les  tâches  reliées  
au  projet  lui  parviennent  :  pas  d’évolution  des  besoins  dans  
chaque  sprint.  
¡ Développement  progressif  
§ afin  de  forcer  l'équipe  à  progresser,  elle  doit  livrer  une  
solution  tous  les  30  jours.  Durant  cette  période  de  
développement  l'équipe  se  doit  de  livrer  une  série  de  
fonctionnalités  qui  devront  être  opérationnelles  à  la  fin  des  
30  jours.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 34

 http://fr.wikipedia.org/wiki/Scrum

¡ Pouvoir  à  l'équipe  
§ l'équipe  reçoit  les  pleins  pouvoirs  pour  réaliser  les  
fonctionnalités.  C'est  elle  qui  détient  la  responsabilité  de  
décider  comment  atteindre  ses  objectifs.  Sa  seule  
contrainte  est  de  livrer  une  solution  qui  convienne  au  client  
dans  un  délai  de  30  jours.  
¡ Contrôle  du  travail  
§ le  travail  est  contrôlé  quotidiennement  pour  savoir  si  tout  
va  bien  pour  les  membres  de  l'équipe  et  à  la  fin  des  30  
jours  de  développement  pour  savoir  si  la  solution  répond  
au  besoin  du  client.  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 35

 http://web.engr.oregonstate.edu/~cook/classes/cs569.agile.ppt

¡ Product  owner    
§ responsable  officiel  du  projet  
¡ Scrum  Master    
§ expert  de  l’application  de  Scrum  
¡ Scrum  Team    
§ équipe  projet.  
¡ Management    
§ prend  les  décisions  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 36

 http://web.engr.oregonstate.edu/~cook/classes/cs569.agile.ppt

¡ Product  Backlog    
§ état  courant  des  tâches  à  accomplir    
¡ Effort  Estimation    
§ permanente,  sur  les  entrées  du  backlog  
¡ Sprint    
§ itération  de  30  jours  
¡ Sprint  Planning  Meeting    
§ réunion  de  décision  des  objectifs  du  prochain  sprint  et  de  la  manière  
de  les  implémenter  
¡ Sprint  Backlog    
§ Product  Backlog  limité  au  sprint  en  cours  
¡ Daily  Scrum  meeting    
§ ce  qui  a  été  fait,  ce  qui  reste  à  faire,  les  problèmes  
¡ Sprint  Review  Meeting    
§ présentation  des  résultats  du  sprint  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 37

 ¡ Principes  des  méthodes  Agile  
¡ XP  :  eXtreme  Programming  
¡ Scrum  
¡ Autres  méthodes  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 38

 ¡ Alistair  Cockburn  (2002).  Agile  Software  
Development.    
Addison  Wesley  
¡ Le  développement  logiciel  vu  comme  un  jeu  
coopératif  de  communication  et  d’invention    
§ des  projets  différents  et  des  méthodes  différentes    
§ le  projet  change  à  mesure  que  les  gens  changent  
¡ Choix  de  la  méthode  en  fonction  de  différents  
facteurs  
§ taille  en  nombre  de  personnes    
§ criticité  pour  le  client  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 39

 (defects cause loss of...)
. . . Prioritized for Legal Liability
air-traffic
Criticality

Prioritized for Productivity & Tolerance

control system Life
(L)
L6 L20 L40 L100 L200 L500 L1000 banking system
Essential
money
(E) E6 E20 E40 E100 E200 E500 E1000

Discretionary
money
(D) D6 D20 D40 D100 D200 D50 D1000

Comfort
medium-sized
small (C)
C6 C20 C40 C100 C200 C500 C1000 productivity tool
utilities 1-6 - 20 - 40 - 100 - 200 - 500 - 1,000
Number of people involved

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 40

 ¡ Familles  conçues  à  partir  de  l'observation  et  des  interviews  
¡ Trouver  à  chaque  fois  la  méthode  la  moins  rigide  qui  réussira  
quand  même  
§ haute  productivité,  haute  tolérance  
§ focus  sur  la  communication  
L6 L20 L40 L80
¡ Exemples  
§ Crystal  Clear  
E6 E20 E40 E80
§ Crystal  Yellow  
§ Crystal  Orange   D6 D20 D40 D80
§ Crystal  Red  
C6 C20 C40 C80
Orange Red
Clear Yellow

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 41

 ¡ LEAN    
§ méthode  de  gestion  de  production  de  chez  Toyota  
§ s’applique  aux  développements  informatiques    
▪ méthode  Agile  
¡ Coders’  dojo  
§ parallèle  arts  martiaux  /  conception-­‐programmation  OO    
▪ il  faut  s’entraîner  à  appliquer  des  «  routines  »  connues  avant  de  pouvoir  
commencer  à  les  utiliser  de  façon  créative,  voire  à  en  inventer  de  
nouvelles  
▪ les  débutant  doivent  apprendre  des  maîtres  
§ un  exemple  de  formation  
▪ http://www.xpday.net/Xpday2005/CodersDojo.html  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 42

 ¡ «  There  is  no  silver  bullet  »  :  le  retour  
§   Même  si  le  développement  incrémental  permet  de  
s’affranchir  de  beaucoup  de  problèmes,  il  y  aura  
quand  même  des  problèmes.  Mais  ceux-­‐ci  seront  
normalement  d’ampleur  plus  faible,  et  mieux  gérés.  
¡ Toute  méthode  est  adaptable  et  doit  être  
adaptée  
§ Mais,    lorsque  l’on  débute,  il  vaut  mieux  ne  pas  trop  
s’écarter  de  la  voie  décrite  pour  bien  comprendre  au  
départ  (cf.  musique)  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 43

 ¡ Gestion  par  aspects  du  code  «  transversal  »      

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 44

 ¡ J.L.  Sourrouille  (INSA  de  Lyon)  :  UP  
¡ Nicolas  Chan  Shin-­‐Yu  (ex.  étudiant  MIAGE)  :  XP  
¡ Sources  
§ http://www.swen.uwaterloo.ca/~kostas/ECE355-­‐05/
lectures/Lect3-­‐Ch15-­‐Unit2.ppt  
§ http://web.engr.oregonstate.edu/~cook/classes/
cs569.agile.ppt  

2011-2012 / Yannick Prié - Université Claude Bernard Lyon 1 45