Une première vue d'ensemble des méthodes agiles

1. B.Vinot
Introduction aux
méthodes agiles

2. Plan du cours
Les projets classiques
Le gantt-Les méthodes d’estimation-Les cycles de développement
Apports des technologies objet-La modélisation UML
Unify Process
L’agilité
Introduction
Le manifeste agile
Le lean
Panorama des méthodes agiles
Les rôles – les cycles
Déroulement d’un projet
Définition des besoins - Méthode de planification agile
les itérations
La modélisation agile -La mêlée scrum ou le stand up meeting XP - Burndown chart- Calcul de
la vélocité de l’équipe
Les outils agiles-TDD
Conclusions
Migration-Avantages-ROI- Les bilans
2

3. Agilité : Définitions
• L’Agilité est l’habilité de créer et de répondre au
changement dans le but d’avoir du succès dans un
environnement d’affaires turbulent. - Jim Highsmith
• Certaines problématiques sont difficiles, certains
individus sont difficiles. Les méthodes Agiles ne sont
pas une garantie de succès. - Craig Larman
• Ce n’est pas la plus forte des espèces qui survit, ni la
plus intelligente, mais celle qui s’adapte le mieux -
Charles Darwin
• Intelligence = (2)Aptitude à s’adapter à une situation, à
choisir en fonction des circonstances… - Larousse
3

4. Etes vous familier avec les cycles de dvp?
Les projets classiques
Le gantt
Les méthodes d’estimation
Les cycles de développement
4

5. Les méthodes prédictives
Et le
client?
Découpe
Planifie
Chef de
projet
Distribue
Discute Equipe1 Equipe2
Réalise Architecte dev1 dev2
5

6. Estimer pour Planifier
• Ne pas faire tout seul
• Méthode des trois experts
• (min + 2 * Moyen + Max) /4
• Méthode des trois wagons
• Faire participer l’équipe
• Tenir compte de la complexité - Fibonacci
• Hiérarchiser les fonctions
• Relativiser : Cocomo
6

7. Planifier avec Fibonacci
F(n) = F(n-2) + F(n-1)
Plus c’est compliqué et plus ça …..
Et si c’est encore plus compliqué
alors ça ….. Encore plus
7

8. Hiérarchiser les fonctions
• Comparer 2 à 2 chaque fonction F2 F3 F4 F5 F6
F1 F2 1 F1 3 F4 2 F5 1 F1 3 6
• A chaque comparaison est associé un poids variant entre 1 et 3 F2 F2 3 F4 2 F2 2 F6 1 6
(1 signifiant peu de différence)
F3 F4 1 F5 1 F3 2 2
F4 F5 1 F4 3 8
• Exemples :
– F2 est plus importante que F1 avec un poids relatif de 1 F5 F5 1 4
– F4 est plus importante que F1 avec un poids relatif de 2 F6 1
27
• Poids de la fonction 5 :
– Somme de toutes les cases orangées (1+1+1+1)
• Poids de toutes les fonctions : F6 3,70%
– Somme de tous les poids de fonction
F3 7,40%
• Poids relatif de la fonction 5 : F5 14,80%
– 4 / 27 = 14,80 %
F2 22,22%
• Hiérarchie des fonctions F1 22,22%
F4 29,66%
No. 8
8

9. Déterminer la valeur des fonctions
• La fonction F6 représente 30 % du
budget du projet pour un poids de 3,7 30%
F6 3,70%
%
– Améliorer le coût de la solution, ou
– Supprimer la fonction du périmètre 10%
F3 7,40%
F5 15%
Coût 14,80%
Poids 20%
F2 22,22%
La fonction F4 représente 5 % du F1 20%
budget pour un poids de 29,66 %
22,22%
Intégrer cette fonction dans le périmètre 5%
n
F4 29,66%
minimal
9

10. Le Gantt
Cocomo
10

11. Les cycles de DVP
Winston Royce
1970
Addison Wesley
1990
1980 : V
1990 : Itératif 11

12. Classique-Agile
12

13. Une arnaque ?
Madame Soleil
« La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch
13

14. UnifyProcess
14

15. La gestion de projet
Classique
Apports des technologies objet-Métriques
La modélisation UML
Unify Process
15

16. Des preuves, des métriques(1)
Des chiffres, oui mais:
Ce qui compte ne peut pas toujours être
• Simples
compté, et ce qui peut être compté ne
• Pas inventés mais mesurés
compte pas forcément - Einstein
• Beaucoup, mais pas trop
• Choisi, pas imposé
16

17. Apports des technologies Objet
Increased
Productivity
5 Cost savings
2
2 Improved
interfaces
6 17
7 11 Software reuse
11
8
14 17 Improved
application
maintenance
Encapsulate
existing
applications
Develop strategic
applications
quickly
Develop
applications as
revenue source 17
Access new OS

18. Des preuves, des métriques(2)
Les métriques de McCabe
C++ C++ C++ C C C
V0 V1 V2 V0 V1 V2
Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11
Min Function LOC 2 1 1 3 3 3
Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56
Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22
Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78
Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56
eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53
eLOC 207 250 268 268 291 353
18

19. Des preuves, des métriques(3)
19

20. Programmation fonctionnelle
20

21. Programmation objet
21

22. Les concepts Objet
• Abstraction : Classe -nom
Personne
-age
• Encapsulation -poids
+Manger()
+Travailler()
+Anniversaire()
• Héritage
Dentiste
Boulanger
• Polymorphisme
-adresseCabinet
+Travailler() +Travailler()
Arracher des dents Faire du pain
// un petit pg // un petit pg (suite)
Personne p p=d
Dentiste d p.Travailler()
Boulanger b p=b
p.Travailler() p.Travailler() For each p in leSac
d.Travailler() p.Travailler()
b.Travailler()
sac<Personne> leSac
22

23. La gestion de projet
Classique
Apports des technologies objet
La modélisation UML
Unify Process
23

24. DOC-PDF UML1.3 = 4,7MB
DOC-PDF UML2.0 = 5.8 MB
UML : La genèse
Nov-97 Sept-97 2000
Janv-97 1.0 1.1 (OMG) 1.4
1.0
Juillet-96
0.9 2003
2.0
Oct-95
0.8
Jacobson (use case - sdl)
Booch-93 Rumbaugh( OMT2)
24

25. Un modèle : Définition
Ce qui sert ou doit servir d’objet d’imitation pour
faire ou reproduire quelque chose (petit robert)
UML Contient
UML est un langage qui contient
• Des éléments de modélisation:
– Des classes
– Des packages
– Des méthodes
– Des Acteurs…..
• Des diagrammes
– Classes, UC, Automate, Activité, …..
Top Model 25

26. Les diagrammes UML
• Diagramme de use case
• Diagramme de classes
• Diagramme de structure
• Diagramme d'objets
• Diagramme dynamique
• Diagramme d'interaction
• Diagramme de séquence
• Diagramme de communication
• Automates
• Diagramme d'activité
• Autres diagrammes
• Composants et Déploiement
26

27. Les diagrammes UML
27

28. Diagramme de Use case
Les acteurs
Un acteur est un rôle d’un ou plusieurs objets
situés à l’extérieur du système et qui interagissent
avec lui pour remplir une fonctionnalité donnée
de ce système.
Un acteur caractérise le rôle joué par un objet à Utilisateur
l’extérieur du système.
• Un acteur parle au système (Acteur principal)
• Le système peut parler à un acteur (Acteur secondaire)
• Un acteur est :
• Un humain (via une IHM)
• Du soft
• Du hard
• Le temps
28

29. Diagramme de Use case
Use Case
Un Cas d’utilisation ( use case ) est une
fonctionnalité remplie par le système et qui se
faire qqchose
manifeste par un ensemble de messages échangés
entre le système et un ou plusieurs acteurs.
Protocole
API
IHM
VerifierBonneMarche
Utilisateur CapteurTemperat
ure
Acteur primaire Une fonctionnalité interne Acteur secondaire
Au système
29

30. Diagramme de Use case
Description d'un Use Case
(3-5 pages)
• Titre et numérotation Ce n ’est pas une
• Résumé description formelle
Mais doit être très détaillé
• Les acteurs
– Acteur principal
– Acteurs secondaires Ceci est l ’usage
• Pré-conditions mais ne fait partie
• Description
de la norme UML
• Exceptions
• Post-conditions
Scenario
30

31. Diagramme de Use Case
Appeler / numéro <<include>>
GSM Envoyer
<<include>>
Utilisateur
Appeler / contact
Antenne HLR
Recevoir appel
Gerer les contacts A1 B3
B2
<<include>> <<include>>
<<include>> <<include>>
Configurateur
A2 A3 B1
Préparer
31

32. Utilisation des Use case
Manger
Descriptions
Distribuer le comportement des fonctionnalités
aux méthodes des objets
32

33. Des mauvais UC
Use cases are wonderful but confusing. People, when asked to write them, do not know
what to include or how to structure them. There is no published theory for them.
This paper introduces a theory based on a small model of communication,
distinguishing "goals" as a key element of use cases. The result is an easily used,
scaleable, recursive model that provides benefits outside requirements gathering:
goals and goal failures can be explicitly discussed and tracked; the goals structure
is useful for project management, project tracking, staffing, and business process
reengineering. The model and techniques described here have been applied and
evaluated on a relatively large (50 work-year, 200 use-case) project.
33

34. Use Case : Exercice
Une société de vente par correspondance vous demande de développer son
système informatique. Ce système doit pouvoir prendre en compte des
commandes passées par la poste et des commandes passées par internet. Il
doit suivre les expéditions qui ne sont effectuées que si le paiement est OK.
Les paiements se font par carte bancaire dans le cas d'internet et par chèque
dans le cas de la poste. Les paiements sont validés par un système bancaire
appartenant à la société et existant. Il faut récupérer ce système. Le
nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article
atteint un seuil minimal, alors il faut passer une nouvelle commande au
fournisseur adéquat. A la réception de la commande, la mise à jour de la
base est faite par un employé. Dans le cas d'un paiement accepté et de stock
disponible, l'expédition est faite par un robot existant au quel il suffit de
passer les coordonnées du client, et la liste des produits achetés. En cas
d'indisponibilité, une lettre doit être envoyé au client.
34

35. Notion de stéréotypes
Un stéréotype est une nouvelle classe d’un élément de
modélisation qui est introduit au moment de la
modélisation. Cela représente une sous classe d’un élément
de modélisation existant avec la même forme, mais avec
une intention différente.
• Les stéréotypes font partie des mécanismes d’extensibilités, prévus
par UML.
• Une interface est un stéréotype
• On peut stéréotyper les classes, les associations, les packages, …..
• On peut associer un nouvel icône pour chaque nouveau stéréotype.
<<nouveauStereotype>>
Z
35

36. Diagramme de classe
Un diagramme de classe montre la structure statique
du modèle, les choses qui existent, leur structure
interne et les relations aux autres choses.
• Statique :
– Ne pas utiliser de verbes d'action pour relier les classes
– Une classe isolée est une classe inutile
– Doit être vrai tout le temps Les choses qui existent
– Représente LE programme Maison
– On ne peut pas tout montrer sur un seul schéma Moto
Garage
Personne
Personne
Tricycle
36

37. Diagramme de classe
Les classes
UneClasse
-attributPrive
+attributPublic
#attributProtected
+attributDeClasse
+attributTypé: int
+attributTypéInit: int = 56
+Operation()
+OperationDeClasse()
+OperationAvecParam(par1: int, par2: boolean): int
+OperationAbstraite()
37

38. L’héritage
Vehicule L’héritage s ’appelle généralisation
+carteGrise en UML
-marque
#nbPassagers
EST UN
Avion Bateau
+ailes +moteurDiesel
+reacteur[2]

39. Les interfaces
Client Client
Une interface permet à un objet (le Client)
De faire faire quelque chose (Fqq) à un
Objet de type A, sans savoir qu’il est un A.
<<interface>> Il sait seulement qu’il est de type FqqAble
FqqAble
FqqAble
+Fqq()
On a remonté le niveau d’abstraction.
On utilise une interface pour imposer à des
Classes différentes d’implémenter une ou
Plusieurs opérations.
A A
+Fqq() +Fqq()
39

40. Les associations
Les associations représentent des relations structurelles
entre classes d’objets. Une association symbolise une
information dont la durée de vie n’est pas négligeable par
rapport à la dynamique générale des objets instances des
classes associées. La plupart des associations sont binaires,
c’est-à-dire qu’elles connectent 2 classes. Certaines sont
refléxives.
+h
Personne
+f
Voiture 4 Roue
40

41. Diagramme de classe : Associations
Est Employée par
Personne Societe Nom d'association
Est Employée par
Personne Societe Nom de rôle
-employe -employeur
1..* 0..1
Personne Societe Cardinalité-Multiplicité
-employe -employeur
Personne Societe
employeur : Societe employe : ListeOfPersonne
1..*
Personne Societe Navigabilité
-employes
Personne Societe
employes : Personne
41

42. Diagramme de classe
Dépendance
Depenser
i = Banque::GetInstance()->DonnerSolde();
Acheter(i);
Voler
b = new Banque();
i = b->DonnerSolde();
Economiser (p : Banque)
p->Deposer(10000);
42

43. Diagramme de classe : Exercice1
Immeuble
Gardemanger
Appartement
Lapin
Personne
Famille Pièce Chien
Mariage
Cuisine CompteBanquaire Nourriture
Animal
Bail
Whisky
Salon acte de propriété
Chat
43

44. Diagramme de classe : Exercice2
44

45. Diagramme dynamique
• Diagrammes d'interaction (Séquence collaboration) servent à
montrer comment les objets parlent les uns aux autres.
Ils montrent le déroulement d'un ou d'une partie d'un Use case
(cas nominal, cas des exceptions, …)
Un objet (l’émetteur) envoi un message à un autre (le récepteur).
Le récepteur doit avoir une opération correspondante au message.
• Automates servent à montrer le comportement d'une classe qui
réagit différemment selon son état.
• Activités montrent le déroulement d'une méthode d'une classe ou
celui d'un Use case
45

46. Diagramme de Séquence
: C1 : C2 : C3
: A1
Oper1()
new : C3
Oper3()
Oper2()
retour
Oper1()
<<create>>
C3()
Oper2()
<<destroy>>
Delete()
46

47. Diagramme de Séquence (UML2.0)
Entreprise Employe
*
+salaire
+CalculerSalaire() -lesEmployes
+CalculerSalaire()
: Commerciaux
: Employe
: Entreprise
Commerciaux
: FinMois +commission
+CalculerCommission()
CalculerSalaire()
loop pour chaque employe
CalculerSalaire()
alt commercial
CalculerCommission()
47

48. Automate
• Un automate est accroché à une classe et est composé d'états et
de transitions. Les transitions permettent de passer d'un état à
un autre …
Off
Arret Marche
On
Casse
Casse
48

49. Automate
État & Transition
Action en entrant dans l'état
Etat
Action en sortant de l'état
entry/ Action1
exit/ Action2 Action déclenchée sur réception de Ev1
on Ev1/ Action2
do/ Activité Activité
Événement qui déclenche la transition
Garde
E1 Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4) E2
Action effectuée sur la transition
Envoie de Ev2 à un objet Cible
Rmq : Le langage d’action (UML1.4) est remplacé par 50 types d’action
49

50. Automate imbriqué
After5
Arret
Off
On
Marche
Ouvrir[ cuve vide ]
Lavage
Essorage
After15
PorteOuverte After10
Rinçage
Fermer H

51. Automate : exercice
E1
ST1 E1 / i++
ST2
E1
entry: i++
entry: i = 0
exit: i++
exit: i++ E3
on E4: i ++
E1
E1 E3
E1
E3[ i == 5 ]
E2
E2
E1
E2
ST4 ST3 E3
on E2: i = i - 2 E1
E3
E3
51

52. La gestion de projet
Classique
Apports des technologies objet
La modélisation UML
Unify Process
52

53. UP : La base
PU est à base de composants
PU utilise UML
PU est piloté par les cas d’utilisation
PU est centré sur l’architecture
PU est itératif et incrémental
53

54. UP & RUP
Unify Process (Énorme process pour tous)
RUP Rational Unify Process
Process customisé à partir du UP
C'est un outil (site web, customisable)
Custom
AirFranceUP XUP
54

55. OpenUP
RUP : Principes
7 rôles (environ 45 pour RUP)
20 artefacts (plus de 80 pour RUP)
18 tâches (plus de 150 pour RUP)
55

56. Les artefacts
• Activité de gestion de projet
– Comptes rendus, planning d’activité, ….
• Résultats
– Modèles
– Code source
– Spécifications
– …..
56

57. Les rôles
• Les analystes (exigences)
• Les développeurs
• Les testeurs
• Les managers (gèrent le processus)
• Le chef de projet
• Les autres (Client, MOA, stakeholder, ….)
57

58. Les activités
• Modélisation métier
• Les Besoins
• Analyse et conception
• Implémentation
• Tests
• Déploiement
• Gestion de configuration Etudié plus tard
• Gestion du projet
• Environnement
58

59. BPM
59

60. Modélisation métier
Stéréotypes UP
Client business use case Fournisseur
Les objets de Les employés
L’entreprise Les process
60

61. Organisation des modèles (UP)
uc1
Définition des besoins
VOPC
Les sources C1 C2
Composant1
Les UC realization (Documentation)
residents
C1
C2
Les composants (physiques et logiques) PC
Les machines components
Composant1 61

62. Exemple d’un workflow
62

63. Processus traditionnel
• Gros classeur sur l’étagère des développeurs
• … Ramasse la poussière …
• Difficile à comprendre et à utiliser, vu comme
une surcharge (gaspillage)
63

64. Motivation
70% 45%
64

65. Les bureaux Google
FaceBook
*****google zurich****** http://www.dailymotion.com/video/x4zlcv_merci-google_lifestyle
65

66. Le processus comme un produit
• Pas un simple livre, pas une autre OOAD
méthode
• Fourni comme un site web (avec les sources)
• Constamment amélioré
• Base de connaissances
– Navigation graphique, moteur de recherche, index
– Guides, templates de documentation, aide à
l’utilisation des outils
66

67. 67

68. RUP : Ses forces
• Cadre générique
• Référentiel de bonnes pratiques;
• Gestion des risques dans les projets;
• Cadre propice à la réutilisation;
• Approche basée sur l’architecture;
• Traçabilité à partir des Uses Cases jusqu’au
déploiement.
Ex : IBM Tivoli ITUP
68

69. RUP : Ses faiblesses
• Coût de personnalisation souvent élevé;
– Autres logiciels propriétaires (Rational)
indispensables;
• Très axé processus :
– peu de place pour le code et la technologie ;
• Vision non évidente ni immédiate
DEVELAY Isabelle
EDORH-A. Semeho
GUIBOUT Nicolas
69

70. RUP : Conclusion
• RUP considéré comme:
– un framework de processus génériques;
– un métaprocessus;
• Démarche itérative
– Réduction des risques;
• Facile à expliquer et à valider (les livrables);
• Finalement pas très populaire…
DEVELAY Isabelle
EDORH-A. Semeho
GUIBOUT Nicolas
70

71. L’Agilité
Introduction
Le lean software dvp
71

72. Une petite vidéo
David Gageot –
Directeur Technique –
Valtech Technology
E:CoursAgilitéVideoValtech) 40mn
72

73. Qu’est ce qu’une méthode agile(1)
Deux caractéristiques fondamentales
– Adaptatives plutôt que prédictive
• Favorables au changement
• Planification plus souple
– Faite par l’équipe et non imposée par le chef
– Orientée vers les personnes plutôt que vers les
processus
• Travailler avec les spécifités de chacun
• Responsabilité, confiance
73

74. Qu’est ce qu’une méthode agile(2)
• Délivrer rapidement et très fréquemment des versions
opérationnelles, pour favoriser un feed-back client
permanent
• Accueillir favorablement le changement
• Assurer une coopération forte entre client et développeurs
• Garder un haut niveau de motivation
• Le fonctionnement de l’application est le premier indicateur
du projet
• Garder un rythme soutenable
• Viser l’excellence technique et la simplicité
• Se remettre en cause régulièrement
• Ecouter le client mais savoir dire non
74

75. Les bureaux agiles
Important - Symbolique
75

76. Nous découvrons de meilleures
façons de développer des
Logiciels en réalisant ce travail
Le manifeste agile
et en aidant les autres à le faire 17 Personnes (2001)
4 Valeurs
12 principes
Kent Beck XP-Junit
Ward Cunningham wiki
Jeff Sutherland scrum
……… 76

77. Manifeste agile : Les valeurs
• L'équipe (« Personnes et interaction plutôt que processus et outils »)
Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens
plutôt qu'une équipe composée d'individualistes, même brillants.
La communication est une notion fondamentale.
• L'application (« Logiciel fonctionnel plutôt que documentation complète »)
La documentation représente une charge de travail importante, mais peut pourtant être néfaste si
elle n'est pas à jour.
Transformer la question : « avez-vous de la documentation ? » en « mais que recherchez-vous
comme information ? »
Commenter abondamment le code lui-même (si besoin)
Transférer les compétences au sein de l'équipe (communication).
• La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)
Le client doit être impliqué dans le développement.
On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes
du client.
Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à
ses attentes.
• L'acceptation du changement (« Réagir au changement plutôt que suivre un plan »)
La planification initiale et la structure du logiciel doivent être flexibles.
Les premières versions du logiciel vont souvent provoquer des demandes d'évolution.
77

78. Manifeste agile : Les 12 principes
1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels
utiles.
2. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles
exploitent le changement comme avantage compétitif pour le client.
3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec
une tendance pour la période la plus courte.
4. Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
5. 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.
6. La méthode la plus efficace de transmettre l'information est une conversation en face à face.
7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires,
développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-
organisent.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste
son comportement dans ce sens.
78

79. Assemblé nationale (30-4-10)
• Ch. Vanneste (député du Nord)
– Etude Sofres : pourquoi travailler?
• Anglais  des sous
• Allemands  Epanouissement
• Français Contacts humains
• Direction HSBC : ce qui manque aux
entreprises françaises:
– Innovation
– Responsabiliser les salariés
79

80. (1950)
L’Agilité
Introduction
Le lean software dvp
80

81. Lean : Philosophie
Le LEAN est principalement une approche managériale pour
optimiser le système de production
– Optimiser la chaîne de création de valeur ajoutée
(sous-traitants compris)
– Eliminer les gaspillages du flux de production
– Push-Pull
– Just in time (pas de code avant que le test le demande)
–Etre discipliné sur les prises de décision (Le plus tard
possible)
– Volonté de perfection à chaque étape (Stopper la chaîne)
– S’appuyer sur les facultés d’adaptation des individus (boite à
idées)
81

82. Kanban
82

83. Lean : Les 7 concepts
– Eliminer les gaspillages
– Améliorer le système
– La qualité de l’intérieur
– Reporter la décision
– Livrer rapidement
– Respecter les personnes
– Créer la connaissance
http://www.youtube.com/watch?v=Dl4dcLbNlgo&f
eature=related
83

84. Lean : Gaspillage
Shigeo Shingo (1950)
1. Stock
2. Surproduction
3. Tâches inutiles
4. Déplacement
5. Transport
6. Attente
7. Défauts
http://www.tv4it.net/jusquou-le-lean-peutil-sappliquer-a-
linformatique--permalink-8907.aspx 84

85. Lean (LSD) : Gaspillage
Shigeo Shingo (1950) LSD : Mary Poppendieck (2003)
1. Stock 1. Travail non terminé
2. Surproduction 2. Sur spécifications
3. Tâches inutiles 3. Processus…
4. Changements de priorité,
4. Déplacement changer de tâche
5. Transport 5. Transmission d’informations
6. Attente 6. Retards
7. Défauts 7. Défauts
85

86. L’Agilité
Panorama des méthodes agiles
86

87. Les méthodes agiles : Panorama
87

88. Taille des projets
1-2 ans & 6-12 personnes  Couper les projets
88

89. Les méthodes agiles : Contraintes
89

90. eXtremPrograming
• KentBeck (1996) Paye de Chrysler
• Les 4 valeurs de XP : CRSC
– Communication
– Retour-FeedBack
– Simplicité
– Courage
90

91. CRSC
• Communication
– Client-Equipe
– Programmeur-Programmeur
– Equipe-Extérieure (indicateurs du projet)
• Retour - Feedback
– Livraison fréquente
– VNR
– Avancements objectifs
– Le client est là
• Simplicité
– pas de sur spécifications
– Code toujours aussi petit et simple que possible
• Courage
– De dire que on s’est trompé
– De revenir en arrière
– De faire du TU
– D’annoncer les soucis
91

92. Les principes de base
• Seul le code source fait foi, il possède une odeur,
appartient à l’équipe, il contient la doc
• L’important c’est le programmeur (ne pas dépasser 40H/S)
• Faire le plus simple possible
• Restructurer dès que nécessaire
• Pratiquer la programmation par paire
• Les spécifications sont des « histoires d’utilisateurs »
• La planification est un jeu
• Livrer fréquemment
• Tester donc intégrer encore, toujours et tout le temps
• Être courageux
B.Vinot

93. Les rôles ds XP(1)
• Développeur (100%)
• travaille en binôme, communique
• doit être autonome
• a une double compétence : développeur – concepteur
• Client (25-75%)
• doit apprendre à exprimer ses besoins sous forme de user stories
• a à la fois le profil de l'utilisateur et une vision plus élevée sur le problème et
l'environnement du business
• doit apprendre à écrire les cas de tests fonctionnels
• est dans la salle
• Testeur (50%-100%)
• a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels
• Tracker – Rapporteur (10-20% = 30 mn par développeur tous les 2 jours + qq réunions)
• aide l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque
user story
• contrôle la conformité de l'avancement au planning
93

94. Les rôles ds XP(2)
• Coach (100% au début, puis 50%, puis 10%)
• recadre le projet
• ajuster les procédures agiles
• doit intervenir de la manière la moins intrusive possible
• ne doit pas s’occuper du projet
• n’est pas là tout le temps
• Consultant – Expert (0-100%)
• n'apporte pas de solution toute faite
• apporte à l'équipe les connaissances nécessaires pour qu'elle résolve elle-même les
problèmes
• doit être un formateur
• Manager (10-25%)
• doit croire à l’agilité
• apporte à l'équipe courage et confiance
• C’est le chef hiérarchique
• Demande des comptes
94

95. 95

96. Combinaison des rôles ds XP
Rmq : si plusieurs clients, Ils doivent parler d’une seule voie
96

97. What is Scrum? Jeff Sutherland
Sutherland
1993
Qu’est ce que Scrum?
• Pas une méthode
• Pas un process
• Pas un ensemble de procédures
• C’est un framework ouvert de dvp
comportant un ensemble de règles
• The rules are constraints on behavior that cause
a complex adaptative system to self organize
into an intelligent state
• Il permet à une équipe moyenne de s’organiser
pour travailler 10 fois mieux
97

98. Scrum : Le cycle de vie
DVP
Tests
UC
Planning
User
game
story
98

99. Scrum : Backlog- BurnDown
99

100. Bob: « Voilà j’ai terminé de
développer ce module,
Scrum : Kanban c’est déployé ! »
Gérard: « Ben je vois
rien…? »
Bob: « Ha en tout cas chez
moi ça marche… »
DoD
100

101. Definition Of Done
Développement Migration des données (structures +
données)
Support IE7 + FF3 Test Seleniums écrits
Support IE6 Test Seleniums passé avec succès
Support “Navigateurs Home Page” Test Unitaires écrits
Déployé sur Staging Test Unitaires passé avec succès
Tests de régression ok (tous les tests Multilingue et traduction ok
passent)
Documentation (dossier Démarches à effectuer auprès de
d’hébergement,…) l’infrastructure (pour la Prod ou autres.
Ex: url, connexion db,ftp,…)
Dépendance avec d’autres acteurs Visualiser sur le mur
Si la définition de « terminé » vous semble confuse Mettez au début un champ
«définition de terminé» pour chaque US.

102. TODO : Exo
• Aujourd’hui je décide de laver ma voiture
• En allant vers le garage, je remarque qu’il y a du courrier sur la table d’entrée
• Je décide de jeter un œil au courrier avant de laver la voiture, il contient des factures et des publicités
• Je jette les publicités dans la corbeille à papier et réalise que la corbeille est pleine
• Je repose les factures sur la table car il faut que je vide la corbeille
• Mais comme la poubelle est proche de la boîte aux lettres, je me dis que je pourrais économiser un trajet
en postant mes factures et je décide donc de préparer d’abord le règlement des factures
• Je prends mon carnet de chèques et trouve sur le bureau la canette que j’avais commencé à boire.
• Je me dis qu’il faut que j’enlève la canette pour ne pas la renverser accidentellement sur mes factures
• Je remarque que la canette est tiède et qu’il vaudrait mieux la remettre au frigo pour la rafraîchir
• En me dirigeant vers la cuisine, le vase sur le comptoir me saute aux yeux : les fleurs manquent d’eau
• En posant la canette sur le comptoir, je manque d’écraser mes lunettes que je cherchais depuis ce matin
• Je me dis que je devrais ranger mes lunettes … mais avant, j’ai le temps de donner à boire aux fleurs
• Je repose mes lunettes sur le comptoir, remplis un pichet d’eau et soudain, j’aperçois la télécommande qui
traîne sur la table de la cuisine
• Je me dis que ce soir je vais la chercher partout et que je ne me souviendrais plus qu’elle est dans la
cuisine
• Je décide donc de la ranger au salon … mais avant, je vais donner à boire aux fleurs
• Je remplis le vase au tiers car malheureusement je renverse beaucoup d’eau sur le sol
• En allant chercher une serpillère, je remets la télécommande sur la table de la cuisine
• Je nettoie le sol puis range la serpillère
• De retour dans l’entrée … je me demande ce que j’avais l’intention de faire
• Cela va ma revenir, en attendant, je vais lire mes mails
• Mais avant je …
102

103. Todo – encours - fini
TODO-> DoD : Exo
Faire qq chose
------------------------
Comment tester
Le résultat
------------------------
Valeur = 0 - 5O
Urgent = 0 – 5
Estimation = 0-40
103

104. Planning Game
Faire qq chose
------------------------
Comment tester
Le résultat
------------------------
Valeur = 0 - 5O
Urgent = 0 – 5
Estimation = 0-40
104
Et Maintenant Estimer

105. Kanban & US & DoD
Laver voiture Vider corbeil Régler facture Canette frigo
------------------------ ------------------------ ------------------------ ------------------------
Ma femme dit: Corbeil vide Chèques débités Canette froide
« elle est propre » Rien par terre
------------------------ ------------------------ ------------------------ ------------------------
Val= 50 Urg=2 E=25 Val= 2 Urg=2 E= 2 Val= 5 Urg=1 E=40 Val= 2 Urg=5 E= 5
Arroser fleurs Ranger telecom. Ranger lunettes Lire mail
------------------------ ------------------------ ------------------------ ------------------------
Le vase est plein d’ La telecom. est sur Les lunettes sont
eau La table du salon Dans la chambre
------------------------ ------------------------ ------------------------ ------------------------
Val= 3 Urg=4 E=3 Val= 5 Urg=4 E=1 Val= 1 Urg=2 E=1 Val= 2 Urg=2 E= 15
105
Et Maintenant Planifier

106. Planification
Laver voiture Vider corbeil Régler facture Canette frigo
------------------------ ------------------------ ------------------------ ------------------------
Ma femme dit: Corbeil vide Chèques débités Canette froide
« elle est propre » Rien par terre
------------------------ ------------------------ ------------------------ ------------------------
Val= 50 Urg=2 E=25 Val= 2 Urg=2 E= 2 Val= 5 Urg=1 E=40 Val= 2 Urg=5 E= 5
50/25 = 2 2/2 = 1 5/40 = 0,125 2/5 = 0,4
Arroser fleurs Ranger telecom. Ranger lunettes Lire mail
------------------------ ------------------------ ------------------------ ------------------------
Le vase est plein d’ La telecom. est sur Les lunettes sont
eau La table du salon Dans la chambre
------------------------ ------------------------ ------------------------ ------------------------
Val= 3 Urg=4 E=3 Val= 5 Urg=4 E=1 Val= 1 Urg=2 E=1 Val= 2 Urg=2 E= 15
3/3= 1 5/1 = 5 1/1 = 1 106
2/15 = 0,13

107. Les rôles dans Scrum(1)
Directeur de produit : Client
• Le Directeur de produit, ou Product Owner en anglais, représente les clients et les
utilisateurs. Ses responsabilités se bornent à l'établissement des limites du projets et de
chaque itération.
• Il définit les fonctionnalités du produit. Voici une liste de ses responsabilités :
– Choisit la date et le contenu de la release
– Responsable du retour sur investissement
– Définit les priorités dans le backlog en fonction de la valeur « métier »
– Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire
SCRUM Master : Coach + Manager + tracker
• Le SCRUM Master représente le management du projet. Il interviens dans le cas ou une
situation ou un événement peut empêcher ou retarder la progression du travail prévu. Ce
n’est pas un maître.
• Voici quelques unes de ces caractéristiques :
– Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum
– Résout des problèmes, remédier aux imprévus
– S'assure que l'équipe est complètement fonctionnelle et productive
– Facilite une coopération poussée entre tous les rôles et fonctions
– Protège l'équipe des interférences extérieures 107

108. Les rôles dans Scrum(2)
Equipe SCRUM / SCRUM Team
• Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10
personnes. L'échange est un atout primordial dans l'utilisation de SCRUM, il faut
donc garder l'aspect dialogue au sein de son équipe de développement.
• Les caractéristiques d'une bonne équipe :
– Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste
IHM, testeur, etc.
– A plein temps sur le projet, de préférence
– Exceptions possibles (administrateur, …)‫‏‬
– Organisation autonome
– Equipe cross-fonctionnelle
• La composition de l’équipe est fixe pendant un sprint
Il n’y a pas de chef de projet
• Le chef = PO + Equipe
108

109. Scrum : Une release
Durée planif sprint: Time Boxing
2*N (N = nb de semaines du sprint)
• Un sprint n’est pas un sprint
• Sprint de début de release
• Sprint de stabilisation
• Le PO doit anticiper le sprint suivant
• Un sprint = 40 tâches
• Une tâche = 1-2 jours max
• Un backlog = 50 US
109

110. Scrum : sprint
http://www.axosoft.com/ontime/videos/scrum
110

111. Le test Nokia
% des personnes ayant trouvé une des
Q 1 : Itération
deux meilleures réponses
Q 2 : Pratique des tests 84
Q 3 : Spécifications 64 67
57,5
Q 4 : Product Owner
Q 5 : Backlog de produit 37,5
27,5
Q 6 : Estimation 24,5
18
14
Q 7 : Sprint Burdown Chart
Q 8 : Dérangement de l'équipe Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9
Q 9 : Équipe
Q 1 : Itération
1. Pas d'itération
2. Itération > 6 semaines
Bas Vode 3. Durée variable < 6 semaines
Jeff Sutherland 4. Itération de durée fixe 6 semaines
5. Itération de durée fixe 5 semaines
6. Itération de durée fixe 4 semaines ou moins
test nokia-ScrumBut
111

112. Comparaison XP-Scrum
XP (programmation) Scrum (process)
Client est ds la salle Oui Non
Représenté par le product
Owner
Techniques de programmation Oui (Prog Objet) Peu
 Junit Test
 XP est le roi  Refactoring Génération automatique,
 Binôme graphique, C , Javascript,….
 Simple
Gestion de projet Peu Oui
Tracker  Velocité
 Scrum est le roi  Planing game BurnDown chart
Durée des itérations Autour de 2 semaines Autour d’un mois (En baisse)
Adaptable Pas pendant les 3 premières Oui
H itérations
XP SCR Mélanger les deux
112
O RUP P Un scrum meeting

113. Feature Driven Development
5 processes
Inventée par Peter Coad
113

114. FDD : Les rôles
Principaux rôles
Autres rôles
• Project manager
Release manager
• Chief architect Language guru
Build engineer
• Domain experts Tool smith
• Dev. manager System admin
Testers
• Chief Deployers
programmers Tech writers
• Class owners
114

115. DSDM : Les principes
• implication active des utilisateurs
• équipes autorisées à prendre des décisions
• produit rendu tangible aussi souvent que possible
• L'adéquation au besoin métier est le critère essentiel
pour l'acceptation des fournitures
• Un développement itératif et incrémental permet de
converger vers une solution appropriée
• Toute modification pendant la réalisation est réversible
• besoins définis à un niveau de synthèse
• tests intégrés pendant tout le cycle de vie
• esprit de coopération entre tous
115

116. DSDM : Le cycle de vie
116

117. Les rôles ds DSDM
Sponsor exécutif : Manager
Visionnaire : Manager
Utilisateur ambassadeur : Client
Utilisateur conseiller : Client-Tracker
Chef de projet : Manager
Coordinateur technique : consultant - expert
Chef d’équipe : Manager
Développeur
Facilitateur : Coach
Rapporteur : Tracker
117

118. Crystal
Méthodes créées par Alistair Cockburn (Expert UC)
• Importance de la Communication et du feed-back client
• Releases fréquentes
• Deux grandes phases
• Conception et planning
• Itérations
• Clear crystal : Adaptée à des équipes
de 6-8 personnes maximum
118

119. Le chef de projet Agile
la qualité essentielle du leader sera le charisme plus que l’autorité.
119

120. Le cycle de l’agilité
Les 3 rythmes :
• Le rythme du projet
• Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.
• Le rythme journalier, qui montre la progression au sein de l’itération.
Ces rythmes suivent la même progression :
• préparation,
• Une idée claire (sinon précise) de l’objectif à atteindre.
• Une façon de vérifier que la réalisation atteint l’objectif.
• réalisation (laisser faire l’équipe)
• retour d’expérience ,
• adaptation.
120

121. Mise en place du process
• Version
– Temps fixe : 2-6mois (Préféré)contenu à définir
– Contenu fixe durée à définir
• Itérations-Durée : fixe 1-6 semaines
– Taille de l’équipe fixe
• Choix des indicateurs
• Méthode
– Tests automatisés, Intégration continue
– Moins de code, qualité, binôme, refactoring
– Itérations courtes, commencer par 4 semaines, puis finir par 2
– Implication du client , sur place à 25 ou 50%, représentant de la MOA
• local, personnes, outils,…
• Ce processus évoluera dans le futur (adaptable par l’équipe à la fin de chaque
itération)
Chaque équipe a un process différent  plus de process d’entreprise
Exemple : Une équipe de 5 personnes, des itérations de 10 jours, 5 itérations par Version
121

122. L’Agilité – Déroulement d’un
projet
Définition des besoins
UC-User Story
Planification
122

123. Un Problème sur deux!
Client
Utilisateurs
Client
MOA
(chefs)
MOAD
MOE
Analystes (Chef de projet)
Architectes
Dev Experts Dev
Programmeurs
testeurs
123

124. Une révolution
Ne pas tout étudier, mais commencer le plus
vite possible
Faut-il toujours prendre un billet A-R?
40% à 70% des infos suffisent pour se lancer
• François 1° (Androuet du cerceau)
• Napoléon
• Colin Powell
124

125. Définitions des besoins - DVP
Besoin global (10%) : Liste des UC ou US + Planification
Détail du 1° tiers : Scénario des UC – Discussion des US
Réalisation du 1° tiers
It1
It2
Détail du 2° tiers
Réalisation du 2° tiers
Intégration continue It3
VNR
Détail du 3° tiers
Réalisation et Fin
Bilan
Définition des besoins Réalisation : les itérations
125

126. Principe : une version
• Le client (ou PO) est dans la salle
– Il propose une liste de fonctionnalités (Backlog)
• UC (sans donner les scénarios) ou User Story
• Chaque US ou UC a une priorité donnée par le client
• Les programmeurs affectent un poids (en pt) à chacune des US (Backlog du
produit)
– Estimation des US en équipe (planning game)
– Si estimation impossible, découper la US, ou bien discuter avec le client
– Le client refait une passe sur les priorités
• On fait une découpe de la version en itérations
• Démarrage de l’itération
– Ecriture des scénarios ou détails des user story
– Découpe en tâches des US (Backlog du sprint)
– Estimation des tâches en heure
– Tests + Dvp + Tests
– Bilan + Demo
• Maj du Backlog pour itération suivante
126

127. User story
le client L’équipe de dvp
• Phase de Définition des besoins
• Taille : carte postale
•Discussion avec le client
• Affecte un ID automatique
• Affectation d’un coût
• Ecrite par le client
• si estimation impossible
• N’est qu’un résumé
• Rediscuter avec le client
• Le reste est verbal
• la décomposer en n US
• Affectation d’une priorité (une valeur)
• la décomposer en tâches et estimer les
• Affectation sur une itération (voir partiel)
tâches (Voir la suite)
• Ecriture des tests finaux (TR)
• Phase de DVP (Iterations)
• Découpage en tâches er estimation (H)
Les 3C • Prise de responsabilité d’un développeur
• Card : une ou deux phrases pour une tâche
• Réalisation en binôme
• Conversation : verbale • Ecritures des TU
• Confirmation : test • Réalisation
• Passage des TU
• Passage des tests finaux (TR) 127

128. US : Recto
128

129. US : Verso
129

130. Planification d’une version
• Calculer la vélocité de l’équipe
– Prendre une moyenne des derniers sprints
– Pour la première fois :
• commencer l’estimation du sprint (ce qui nous donnera un nb de pt faisables en un sprint
– voir plus loin)
• Méthode des 3 experts
• Pif
• Répartir les US ds les sprints en commençant par les plus prioritaires
• Ajustement des fins de sprint
• Rajouter du mou
– 10% pour erreur d’estimation
– 15% pour Bug, FeedBack des utilisateurs
• Tenir compte du calendrier (prévisible)
• Tenir compte des changements des effectifs de l’équipe si prévu à l’avance
• Prendre en compte les points de synchro avec d’autres équipes
• Planning orienté utilisateur, sans garantie car il va être remanié
130

131. BackLog de produit(1)
D’après la velocité : Une itération = 50 points  5 Itérations (sans engagement)
131

132. BackLog de produit(2)
132

133. BackLog de produit(3)
Méthode classique 
• RAF = Temps estimé – temps passé
Agilité
• RAF = Réestimation de la tâche
• Simplement utiliser les états
(en cours-fini-…)
Beurdone - burndown
133

134. Ice Scrum 2
Excel
Un planning de version
•Une version
•3 Itérations
•Chaque itération contient
des US
Rmq : on ne voit pas les
priorités (dommage)
134

135. Une variante : Feature
135

136. L’Agilité – Déroulement d’un
projet
Les itérations
136

137. Une itération
• Découpe en tâches (Planning horizontal)
• Estimation des tâches en heure
• Planification du sprint (2-4H) : Equipe + PO
• Rajouter du Mou (30%)
• Affectation des tâches – Fabrication des binômes
• 1-2 jours de modélisation (toute l’équipe)
• DVP
– Préparation des tests
– Coder en binôme et améliorer
– Tester
– Une réunion par jour (suivre ce que font les autres, …)
• Acceptation par le client
• Un bilan Améliorer le process
Rmq : à la fin de la réunion de la planification du sprint, on doit avoir : Un but pour le sprint,
Une liste des membres d'équipe (et de leur niveau d'engagement , si ce n'est pas 100%),
Un backlog de sprint , une date bien pour la démonstration et uUne heure et un lieu bien
137
définis pour la mêlée quotidienne.

138. Les principes
• Modéliser agile ensemble
• Se mettre en binôme
• Ecrire les cas tests
• Tester (NOK)
• Coder
– Faire simple
– Suivre l’avancement
• Tester (OK)
• Une personne est responsable d’une tâche
• Le code appartient à tout le monde
138

139. La modélisation agile
• Il faut modéliser (1 jour sur 10)
• Les modèles sont faux
• Un modèle agile est une peinture, pas une
photographie
• Modéliser à plusieurs, jamais seul
• Moins de diagrammes de classe et plus de diagrammes
d’interaction (et en //)
• Ne pas passer trop de temps avec les outils, faire du
reverse après coup
• Modéliser pour soi même, pas pour faire de la
documentation
139

140. Développement (1)
• Faire le plus simple possible
• Pas de conception  Conception émergeante
• Pas de Doc uniquement pour satisfaire le
process
• 1-2 jour de modélisation sur 10
• Binômes
• Personne n’est propriétaire du code  Equipe
• CR journalier + le tracker
140

141. Binômes
• Il y en a un qui fait le code pendant que l ’autre fait les
tests
• Il y en a un qui code pendant que l’autre le surveille
• Il y en a un qui code pendant que l’autre se repose
• Il y en a un qui tient la souris, l ’autre a le clavier...
• Cela coûte forcément deux fois plus cher
• J ’ai mes habitudes de codage...
• J ’aime travailler tout seul
• Binômer, c’est multiplier les couts
par 2
141

142. 142

143. Binômes
• Deux personnes travaillant ensemble pour concevoir, tester, coder...
• Une seule machine (standardisée)
– un conducteur: manipule la machine, réalise le travail
– un observateur: propose, conseille, vérifie, et réfléchi à la stratégie globale
• Changements de conducteur fréquents
• Changements de binôme fréquents
• Travail dense, exigeant, productif et efficace
• L’un regarde le clavier, l’autre l’écran, et on discute
• Celui qui ne sait pas faire, fait, l’autre lui apprend
• TDD (l’un écrit un cas de test puis l’autre le programme, programmation
ping-pong)
• La programmation en binôme est épuisante et ne devrait pas être
pratiquée toute la journée
• Utiliser pour la montée en compétence des nouveaux entrants et pour les
développements pointus
143

144. Qualités d’ ½ binôme
Ouverture d'esprit et remise en question
Courage (de se mettre à nu)
Communication active (pas de rétention d'information)
Respect de l'autre et de son travail
Capacité à tourner (tâches, fonctionnalités, personnes...)
A se rendre non indispensable
Durée d’un binôme = 1 jour, 1 tâche (pas toujours)
Travailler à deux
Savoir partager la gloire... Et les erreurs
il est « plus facile de former un débutant (à l'agilité) que de
déformer un gourou ».
144

145. Cycle de vie d’un binôme
145

146. Développement (2)
• Faire le plus simplement possible
– Faire simple mais pas simpliste
– Pas de savants
• Ne pas prendre d’expert
• Se méfier des architectes
– Problème des design patterns
– Homogénéité de l’équipe avant tout
– Les cimetières sont remplis de gens indispensables
– Faire de la réorganisation de code
• Revue (binômes)
• Une seule fois (DP Template method)
• Refactoring (séparation des idées)
• Interdit si pas de tests automatisés
• Quand?
146

147. Faire le plus simple possible (1)
• Ne pas faire de conception
(la bourseMauvaise spéculation)
• Ecrire les tests d’abord
• Ne pas faire de sur spécification, mais penser à demain
• Ne pas choisir tout de suite une architecture
– Cela permet d’en tester plusieurs
– Mais, ne pas la choisir trop tard!!!
• Ne pas mettre de commentaires, ni de lignes blanches de séparation
mais couper en n parties
• Compliquer le code (ex DP)
– Former, convaincre sinon ne pas faire
– Nivèlement par le bas, mais tout le monde comprend
• Commencer simplement
• Ecrire la solution la plus simple possible pour résoudre ce cas et que ce cas
« La vérité, ce n’est point ce qui démontre, mais ce qui simplifie »— Saint Exupéry.
147

148. Faire le plus simple possible (2)
If (n == 0) return 0;
If (n == 1) return 1; Cas 0 et 1
----------------------------------------------
return n; Cas 0 et 1 remanié
-----------------------------------------------
If (n<=1) return n;
Return 1; Cas 0, 1, 2
-----------------------------------------------
If (n<=1) return n; Cas 0, 1, 2 remanié
Return F (n-2) + F (n-1); …Cas général…
-----------------------------------------------
If (n < 0) erreur (TBD)
If (n<=1) return n; Solution finale
Return F(n-2) + F(n-1);
148

149. Conception émergeante
Le Refactoring : la solution agile pour conserver un code évolutif
Exemple de conception émergeante sur un projet XP démarré en 2002, dans le cadre d’un grand
projet télécom.
Lancé au départ avec une équipe de trois développeurs, il occupait en 2005 plus
d’une vingtaine de développeurs, avec une application qui représentait quelques centaines
de milliers de lignes de code, des milliers de classes, et environ 20.000 tests.
En 2003, nous avons extrait une partie “plateforme” gérée par une équipe dédiée ……
La plateforme continue d’évoluer, et le nombre d’équipes utilisatrices augmente.
Après six ans d’évolution, le code de l’application est toujours jugé propre.
Des blocs de code  des fonctions,
des fonctions  classes,
des classes  modules,
 des interfaces sont apparues pour découpler des modules,
Certaines portions du code  “poussées” dans des fichiers de configuration, etc.
le meilleur moyen pour trouver ces erreurs est d’arrêter de penser au logiciel au niveau théorique
de l’analyse et de la conception, mais plutôt de se lancer, de se salir les mains, et de
149
commencer à construire le produit. Mike Cohn

150. Stand up meeting
• Tous les jours 15 mn
• Toute l’équipe
• Chacun doit dire (15/6 = 2mn30s)
• Les problèmes qu’il a eu la veille si ils ne sont pas résolus
• Ce qu’il pense pouvoir faire aujourd’hui
• Les problèmes rencontrés
• On est pas là pour résoudre les pb, mais
• pour les faire connaitre, Les noter
• prendre un RV ds la journée avec le sauveur
• si il n’y a pas de sauveur, il faudra réestimer la tâche  US.
• Mise à jour du planning journalier (Sprint) et de la liste des PB
• Si plusieurs équipes scrum de scrum
150

151. Stand up meeting : Objectifs
• Evaluer l'avancement du travail
• Identifier les obstacles(problèmes) nuisant à la
progression: Quelque chose qui génère une perte
de temps ou un gaspillage de ressources
• Garder l'équipe concentrée sur l'objectif du sprint
• Améliorer l'esprit d'équipe (cette réunion donne
le sentiment commun de l’engagement)
• Permettre une communication objective sur
l'avancement
151

152. Stand up meeting : Les erreurs
• La réunion n'a pas lieu tous les jours
• la réunion commence en retard
• Tout le monde ne s'exprime pas
• Des personnes bavardent en aparté
• Une personne interrompt les autres
• On s'adresse uniquement au ScrumMaster
• On parle de choses sans rapport avec les tâches
du sprint
• Essayer de résoudre un pb compliqué
152

153. Les tâches à faire (le radiateur)
153

154. Ice scrum : Kanban
154

155. Cycle de vie d’une User Story
Dvp Client
Phrase+Priorité
Discussion
Estimation
ProductBacklog/iteration SprintBacklog
Definition Test
Découpe en Tâches
Ecriture du test
Affectation des tâches Affectation des tâches [NOK]
Réalisation tâches Réalisation tâches
TU TU
TI [OK]
155

156. Déroulement du Sprint (Iter1)
Rmq :
Total priorité = 42
Le premier jour on a de disponible 5/42
(10% du projet)
Le 6° Jour on a de dispo 10/42
(25% du projet)
156

157. Vélocité
Vélocité = nb de points (estimation des US) réalisés pendant une itération
157

158. BurnDown de Sprint (Iter1)
Vélocité = 48-34
=14 !!!
158

159. Burndown du produit après Iter1
Beurdone - burndown
Vélocité = 14 !!!
Faire une démonstration au client de ce qui fonctionne (25% du projet)
Faire un bilan de l’itération (Voir plus loin)
159

160. Iteration2
Vélocité = 50
Beurdone - burndown
180
Supposition :
Pas de pb sur iter2 (50 points)
Gain priorité pour le client = 4+3*3 = 13
Total 10(iter1) + 13 = 23/42 (La moitié du projet)
et on avance de 9 points sur la US10
(reste 16-9= 7 points pour la finir)
160
Gain total de l’iter2 = 50 points (RAF = 230-50 = 180)

161. Iteration3
Ré estimation
Supposition : Iter3
US11 est terminée (4 points cout de 55)
US10 est enfin OK (5 points cout 34)
mais pas propre!!!
En avance us15 OK (4 points cout 21)
Velocité = 55 + 34 + 21 = 110
Total point 23(iter2) + 4 + 5 + 4= 36/42
161
Total RAF 180 – (55 + 34 + 21) = 70

162. Fin du projet
Vélocité moyenne = 41
Faire un bilan de fin de Version ou de fin de projet : IDEM (Voir plus loin) 162

163. Graphe : BurnDown & velocité
raf velocite
300
80
250
200 60
150
40
raf
100 velocite
50 20
0 0
1 2 3 4 5 1 2 3 4
300 Rmq : Techn Story : Attention à garder le
250
Backlog orienté métier (ex : Indexer une table)
200
rafInitial rafTotal
150 rafTotal
244 0
100 rafInitial
136 30
50 85 30
0 50 50
1 2 3 4 5
0 50
163

164. Les indicateurs
• Feature et US (UC) : Estimation taille en points et Utilité (Valeur, priorité) en points ou en €
• Tâches : Estimation en heures
• Vélocité : nb de points réalisés en un sprint
• Mesures quotidiennes
– Nb d’heures RAF pour les tâches du sprint non finies
– Nb de tâches et de US restant à finir pour ce sprint
– Nb de points de US restant à finir pour ce sprint
• Mesures à chaque sprint
– Capacité estimée au début du sprint
– Vélocité réelle du sprint
– L’utilité ajoutée pendant le sprint
– Le Nb de US restant à faire ds le backlog (selon les états des US)
– La taille (en point) du restant à faire ds le backlog. Pour la release seulement
– Le nombre de points total ds le backlog, y compris ce qui est fini
– Les tests (nombre, OK, Echec, Ecrits mais pas encore passés, ….)
• Mesure de fin de release
– Idem mesure de sprint, en en faisant la somme
• Autres mesures
– Nombre d’obstacle (trouvé, résolus, …)
– Ressources consommées par le sprint
– Qualité du code
164

165. Montrer des diagrammes simples (1)
165

166. Montrer des diagrammes simples (2)
166

167. Cycle scrum : résumé
• http://vimeo.com/4587652 scrum vivant
• Bruxellesmobilite
http://www.bruxellesmobilite.irisnet.be/
167

168. Les bilans
• Bilan itération : Réunion des questions QQ (2-4H , Toute l’équipe + des
muets)
– Préparée par le scrum master
– Qu’est ce qui a bien marché ?
– Qu’est ce qui n’a pas marché ?
– A-t-on besoin de qq chose ?
– Que faut-il ne plus faire ?
– Comment ça va-t-il bien (Le moral)?
– Comment peut-on améliorer qq chose ?
– Qu’est ce que vous gardez sur le cœur ?
• Bilan de release : Réunion CC (1-2 Jours , Toute l’équipe + hiérarchie)
– Préparée par tous (montrer l’esprit d’équipe-ROI)
– IdemQQ + pompeuse Demo
– mais à la Campagne + Champagne
– Faire cette réunion même en cas d’échec du projet (sans champagne)
168

169. XP-Game
Un projet
• User story
• Planning game
• Product backlog
• Itérations
– Sprint backlog
– Stand up meeting
– Calcul de la vélocité
– Calcul de la satisfaction client
• Bilan
169

170. L’Agilité
Les tests
TDD
170

171. TDD Client Programmeur
Tester pour vérifier n’est pas judicieux!!!
Tester pour spécifier Ecrire un Test
Spécifications executables
Programmation par contrat
Ecrire un scénario
(Bertrand Meyer)
Un test comprend plusieurs scénarios [OK] Passer le test Ecrire le pg
Cas nominal, cas aux limites,….
[NOK]
Le test remplace la documentation
[OK]
Passer le test [NOK]
TU (Programmeur+Outils+Tracker)
TR (Client + programmeur)
L’acceptation n’est faite que par le client
[OK]
Tous les tests sont archivés et automatisés
Remanier le code
[NOK]
Passer le test
171

172. Qu’avez-vous testé aujourd’hui?
Valtech-Test (14mn)
BOF Yahoo!!!
Tester pour corriger Tester pour spécifier
Organiser des campagnes de Tester en permanence IC
test
Spécialiser les métiers du test Partager les responsabilités
des tests
172

173. Les tests Automatisés
• TU1
TU
• TU2
• TU3
• TU4
• TU5
OK/NOK
• tr1
TestSuite
TR
• tr2
• tr3
• tr4
173

174. Les types de tests
• Tests unitaires (X-UNIT)
– AAA : Acteurs, Action, Assertions (5-20 pour un scénario)
– Ecrire le programme de test (cas par cas)
– Générer les classes et les méthodes nécessaires
– Lancer le programme de test  Echec
– Ecrire le programme
– Lancer le test jusqu’au  Succès
– Archiver le test ( TestSuite )
– Ecrits par le programmeur
• Tests de recette
– Des outils
– IHM Textuelles (automatique)
– Outils de test
– Ecrits par le client (test de comportement, spécification exécutable)
• Tests d’IHM
• Tests de charge, Tests temps réel,….
RMQ : Ecrire et tester le programme avant de l’écrire (TTD)
174