Introduction dun Procd Agile dans la Maintenance de Logiciel Par: Carl Bessette

1
Introduction dun Procédé Agiledans la
Maintenancede LogicielPar Carl Bessette
2
Déroulement

• Pésentation de létude
• Présentation du procédé Agile
• Présentation de limplantation
• des pratiques
• Résultats
• Conclusion

3

• ETUDE
• But
• Application des pratiques basées
• sur la programmation extrême
• Projet
• - Maintenance de type corrective, adaptative
• et perfective sur un projet de grande taille
• préalablement livré au client
• Période
• Huit mois.
• Points importants
• Fiabilité
• Gestion des erreurs

4
Procédé Agile
5
Procédé Agile
6
Procédé Agile
Sans XP
Avec XP
7
Procédé Agile

• Agents de motivation
• à ladoption du procédé Agile
• Le fonctionnement nest pas critique
• Développeurs expérimentés
• Petit groupe de travail
• Changements fréquents des exigences

8
ProgrammationExtrême (XP)
9
Programmation Extrême4 pratiques importantes

• Retours tôt et concrets Tests effectués en
  continue Planification incrémentale
  Client sur place Programmation par paires

10
Tests effectués en continue

• Définition Une procédure de tests est écrite
  à chaque fois quune partie de code doit
  être ajoutée au programme.

11
Tests effectués en continue Implantation
Avant Plusieurs formes de tests qui sont
effectuées fréquemment de manière non
structurée.Après Des tests sont effectués
fréquemment et de manière structurée.Différence
avec XP classiqueLes tests effectués ne
couvrent paslensemble du système
12
Programmation Extrême4 pratiques importantes

• Retours tôt et concrets Tests effectués en
  continue Planification incrémentale
  Client sur place Programmation par paires

13
Planification incrémentale

• Planification incrémentale Planification de
  livrables Planification ditérations

14
Planification incrémentale
Planification de livrables Phase
dexploration - Déterminer avec le client ses
exigences Phase dengagement -
Déterminer les fonctionnalités qui seront
développées et les échéanciers Phase
dajustement - Ajustements au plan
15
Planification incrémentale
Planification ditérations Phase
dexploration - Chacune des exigences est
transformée en tâche. Phase
dengagement - Chacune des tâches est assignée
à un programmeur et les échéanciers
sont fixés Phase dajustement - Les tâches
sont effectuées
16
Planification incrémentale Implantation
Avant - Planification détaillée inexistante
- Assignation quotidienne des tâches effectuées
par un chef déquipe - Les échéanciers sont
fixés par le personnel à lextérieur de
léquipe - Aucune vue densemble sur
lévolution du projet
17
Planification incrémentale Implantation
Après - Planification détaillée sur une
période de 2 semaines - Assignation quotidienne
des tâches effectuées par lensemble des
développeurs - Léquipe fixe ses échéanciers
- Vue densemble sur lévolution du
projetDifférence avec XP classique- Le
client nest pas présent.- Aucune planification
de livrable
18
Programmation Extrême4 pratiques importantes

• Retours tôt et concrets Tests effectués en
  continue Planification incrémentale
  Client sur place Programmation par paires

19
Client sur place

• Définition Le client devrait être disponible à
  tous moments pour répondre aux divers
  questions

20
Client sur place Implantation
Avant Le client nest pas disponible.Après
Un représentant est présent une fois au deux
semaines.Différence avec XP classique Le
client est remplacé par un représentant Il ne
fait pas partie de léquipe
21
Programmation Extrême4 pratiques importantes

• Retours tôt et concrets Tests effectués en
  continue Planification incrémentale
  Client sur place Programmation par paires

22
Programmation par paires

• Définition Deux programmeurs pour une tâche et
  un poste de travail.

23
Programmation par paires Implantation

• Avant Inexistant, contact entre les
  programmeurs lorsquun problème est
  rencontré.Après Rencontre deux fois par tâche
  pour discuter du problème et pour présenter la
  solution.Différence avec XP classique Travail
  constamment fait en paire

24
Programmation Extrême4 pratiques importantes

• Développement en continue Intégration en
  continue Raffinements Petits livrables

25
Intégration en continue

• Définition Intégration du code dès quil est
  validé pour découvrir des erreurs de
  conception ou de compatibilité rapidement.

26
Intégration en continue Implantation
Avant Impossible vu la complexité et le temps
requis pour lexécuter. Lintégration se fait une
fois par semaine.Après Aucun
changement.Différence avec XP classique Doit
être fait au moins une fois par jour.
27
Programmation Extrême4 pratiques importantes

• Développement en continue Intégration en
  continue Raffinements Petits livrables

28
Raffinements

• Définition Réécrire le code pour en améliorer
  la clarté et la structure sans toutefois en
  changer le comportement.

29
Raffinements Implantation
Aucun changement Impossible vu la quantité de
code et les défauts que cela pourrait
occasionner.
30
Programmation Extrême4 pratiques importantes

• Développement en continue Intégration en
  continue Raffinements Petits livrables

31
Petits livrables Implantation
Avant Léquipe produit déjà des livrables 1 à 2
fois par semaine.Après Aucun changement.
32
Programmation Extrême4 pratiques importantes

• Compréhension collective Conception simple
  Métaphores Appartenance collective du code
  Convention de codage

33
Conception simple

• Définition Rechercher la solution la plus
  simple possible en ne se préoccupant que des
  exigences immédiates.

34
Conception simpleImplantation
Avant - Effort pour réduire la complexité.-
Conception en prévision dapplications
futursAprès Aucun changement.Différence
avec XP classiqueNe répond pas seulement aux
besoins présents.
35
Programmation Extrême4 pratiques importantes

• Compréhension collective Conception simple
  Métaphores Appartenance collective du code
  Convention de codage

36
Métaphores

• Définition Choisir les noms des classes et
  des fonctions dans le but de faciliter la
  compréhension du programme et de ses
  abstractions.

37
Métaphores Implantation
Aucun changement La description de
larchitecture du programme est déjà bien
documentée.
38
Programmation Extrême4 pratiques importantes

• Compréhension collective Conception simple
  Métaphores Appartenance collective du code
  Convention de codage

39
Appartenance collective du code

• Définition tous les membres de léquipe
  connaissent bien le code et peuvent effectuer
  des changements à ce dernier.

40
Appartenance collective du code Implantation
Avant - Chaque membre est encouragé à
effectuer des changements au code.- Le membre
maîtrisant le mieux la partie du code changée,
fait la révision.Après Renforcement des
pratiques utilisées.
41
Programmation Extrême4 pratiques importantes

• Compréhension collective Conception simple
  Métaphores Appartenance collective du code
  Convention de codage

42
Convention de codage

• Définition Établir une convention qui
  sappliquera à lécriture de tous nouveaux
  codes.

43
Convention de codage Implantation
Avant - Léquipe travaille sur plusieurs
systèmes différents qui ont chacun des
standards différents.- Aucune documentation
sur les standardsAprès - Documentation
44
Programmation Extrême4 pratiques importantes

• Bien-être des programmeurs 40 heures/semaine

45
40 heures/semaine

• Définition Établir un maximum de 40 heures
  par semaine de travail pour maximiser la
  productivité et conserver la motivation à un
  haut niveau.

46
40 heures/semaine Implantation
Aucun changement Dans le but de garder les
clients heureux, les développeurs ont à faire
plus de 40 heures si cela est nécessaire pour
respecter les échéanciers.
47
Résultats
48
Résultats
49
Résultats
50
Conclusion
Facilite la communication des informations La
planification incrémentale permet une meilleure
gestion de projet Besoin de devoir faire la
maintenance sur plusieurs différents systèmes
favorisé par Programmation structurée.
- Les 3 pratiques les plus positives sont
reliée au code. - Elles sont les plus
difficiles à introduire.
51
Conclusion
- Adapter les pratiques pour bien répondre
aux besoins et pour conserver la motivation
des participants
52
Questions
53
Références
H. Svensson et M. Host. Introducing an Agile
Process in a Software Maintenance and Evolution
Organization. IEEE Software, 2005.