Download - Introduction à l'Agilité
Introduction aux méthodes agiles
B.Vinot
Plan du coursLes 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é
IntroductionLe manifeste agile
Le lean
Panorama des méthodes agiles
Les rôles – les cycles
Déroulement d’un projetDé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
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
Les projets classiques
Le gantt
Les méthodes d’estimation
Les cycles de développement
4
Etes vous familier avec les cycles de dvp?
Les méthodes prédictives
Réalise
Discute
Découpe
Planifie
Distribue
Chef de projet
Equipe1
Architecte dev1
Equipe2
dev2
Et le client?
5
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
Planifier avec Fibonacci
Plus c’est compliqué et plus ça …..Et si c’est encore plus compliquéalors ça ….. Encore plus
F(n) = F(n-2) + F(n-1)
7
No. 8
• Comparer 2 à 2 chaque fonction
• A chaque comparaison est associé un poids variant entre 1 et 3 (1 signifiant peu de différence)
• Exemples :– F2 est plus importante que F1 avec un poids relatif de 1
– F4 est plus importante que F1 avec un poids relatif de 2
• Poids de la fonction 5 : – Somme de toutes les cases orangées (1+1+1+1)
• Poids de toutes les fonctions :
– Somme de tous les poids de fonction
• Poids relatif de la fonction 5 : – 4 / 27 = 14,80 %
• Hiérarchie des fonctions
F2 F3 F4 F5 F6
F1 F2 1 F1 3 F4 2 F5 1 F1 3 6
F2 F2 3 F4 2 F2 2 F6 1 6
F3 F4 1 F5 1 F3 2 2
F4 F5 1 F4 3 8
F5 F5 1 4
F6 1
27
29,66%
22,22%
22,22%
14,80%
7,40%
3,70%
F4
F1
F2
F5
F3
F6
Hiérarchiser les fonctions
8
29,66%
22,22%
22,22%
14,80%
7,40%
3,70%
5%
20%
20%
15%
10%
30%
F4
F1
F2
F5
F3
F6
Coût
Poids
La fonction F4 représente 5 % du budget pour un poids de 29,66 %
n Intégrer cette fonction dans le périmètre minimal
• La fonction F6 représente 30 % du budget du projet pour un poids de 3,7 %
– Améliorer le coût de la solution, ou
– Supprimer la fonction du périmètre
Déterminer la valeur des fonctions
9
Le Gantt
10
Cocomo
Les cycles de DVP
Winston Royce1970
Addison Wesley1990
11
1980 : V1990 : Itératif
Classique-Agile
12
Une arnaque ?
1313
« La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch
Madame Soleil
UnifyProcess
14
La gestion de projetClassique
Apports des technologies objet-Métriques
La modélisation UML
Unify Process
15
Des preuves, des métriques(1)
16
Des chiffres, oui mais:• Simples• Pas inventés mais mesurés• Beaucoup, mais pas trop• Choisi, pas imposé
Ce qui compte ne peut pas toujours êtrecompté, et ce qui peut être compté necompte pas forcément - Einstein
Apports des technologies Objet
17
17
11
81714
11
7
6
2
2
5
IncreasedProductivity
Cost savings
Improvedinterfaces
Software reuse
Improvedapplicationmaintenance
Encapsulateexistingapplications
Develop strategicapplicationsquickly
Developapplications asrevenue source
Access new OSand tools
Des preuves, des métriques(2)Les métriques de McCabe
18
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
Des preuves, des métriques(3)
19
Programmation fonctionnelle
20
Programmation objet
21
Les concepts Objet
• Abstraction : Classe
• Encapsulation
• Héritage
• Polymorphisme
22
Personne
-nom-age-poids
+Manger()+Travailler()+Anniversaire()
Dentiste
-adresseCabinet
+Travailler()
Boulanger
+Travailler()
Arracher des dents Faire du pain
// un petit pgPersonne pDentiste dBoulanger bp.Travailler()d.Travailler()b.Travailler()
// un petit pg (suite)p = dp.Travailler()p = bp.Travailler()
sac<Personne> leSac
For each p in leSacp.Travailler()
La gestion de projetClassique
Apports des technologies objet
La modélisation UML
Unify Process
23
UML : La genèse
Booch-93 Rumbaugh( OMT2)
Oct-950.8
Jacobson (use case - sdl)
Juillet-960.9
Janv-971.0
Nov-971.0
Sept-971.1 (OMG)
20001.4
DOC-PDF UML1.3 = 4,7MBDOC-PDF UML2.0 = 5.8 MB
20032.0
24
Un modèle : Définition
Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose (petit robert)
Top Model 25
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é, …..
Les diagrammes UML
26
• 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
Les diagrammes UML
27
Diagramme de Use caseLes acteurs
Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.
Uti lisateur
• 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
Diagramme de Use caseUse Case
Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.
UtilisateurVerifierBonneMarche
CapteurTemperat
ure
29
faire qqchose
Acteur primaire Acteur secondaire
IHM
ProtocoleAPI
Une fonctionnalité interneAu système
Diagramme de Use caseDescription d'un Use Case
• Titre et numérotation
• Résumé
• Les acteurs
– Acteur principal
– Acteurs secondaires
• Pré-conditions
• Description
• Exceptions
• Post-conditions
(3-5 pages)Ce n ’est pas une
description formelleMais doit être très détaillé
Ceci est l ’usagemais ne fait partiede la norme UML
30
Scenario
Diagramme de Use Case
31
Utilisateur
Appeler / numéro
Appeler / contact
Gerer les contacts
Préparer
Recevoir appel
Antenne HLR
Configurateur
GSM Envoyer<<include>>
A1
A2 A3
<<include>> <<include>>
B1
B2 B3
<<include>> <<include>>
<<include>>
Utilisation des Use caseManger
Descriptions
Distribuer le comportement des fonctionnalitésaux méthodes des objets
32
33
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.
Des mauvais UC
Use Case : Exercice
34
Une société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit 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èquedans le cas de la poste. Les paiements sont validés par un système bancaireappartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de labase est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En casd'indisponibilité, une lettre doit être envoyé au client.
Notion de stéréotypesUn 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émentde modélisation existant avec la même forme, mais avecune 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.
Z
<<nouveauStereotype>>
35
Diagramme de classe
• 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
– Représente LE programme
– On ne peut pas tout montrer sur un seul schéma
Un diagramme de classe montre la structure statiquedu modèle, les choses qui existent, leur structureinterne et les relations aux autres choses.
36
Les choses qui existent
Maison
GaragePersonne
Personne
Moto
Tricycle
Diagramme de classeLes classes
37
UneClasse
-attributPrive+attributPublic#attributProtected+attributDeClasse+attributTypé: int+attributTypéInit: int = 56
+Operation()+OperationDeClasse()+OperationAvecParam(par1: int, par2: boolean): int+OperationAbstraite()
L’héritage
Vehicule
+carteGrise-marque#nbPassagers
Avion
+ailes+reacteur[2]
Bateau
+moteurDiesel
L’héritage s ’appelle généralisation en UML
EST UN
Les interfaces
39
FqqAble<<interface>>
+Fqq()
A
+Fqq()
Client
FqqAble
A
+Fqq()
Client
Une interface permet à un objet (le Client)De faire faire quelque chose (Fqq) à unObjet de type A, sans savoir qu’il est un A.Il sait seulement qu’il est de type FqqAble
On a remonté le niveau d’abstraction.On utilise une interface pour imposer à desClasses différentes d’implémenter une ouPlusieurs opérations.
Les associationsLes 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.
40
Personne
+f
+h
Voiture Roue4
Diagramme de classe : Associations Personne Societe
Est Employée par
Nom d'association
Personne SocieteEst Employée par
-employeur-employe
Nom de rôle
SocietePersonne1..* 0..1
-employe -employeur
1..* 0..1Cardinalité-Multiplicité
Personne
employeur : Societe
Societe
employe : ListeOfPersonne
NavigabilitéSocietePersonne1..*
-employes
1..*
Societe
employes : Personne
Personne
41
Diagramme de classeDépendance
Depenseri = Banque::GetInstance()->DonnerSolde();Acheter(i);Volerb = new Banque();i = b->DonnerSolde();Economiser (p : Banque)p->Deposer(10000);
42
Diagramme de classe : Exercice1
Immeuble
Famille
Appartement
Pièce
Cuisine
Salon
Gardemanger
Chien
Chat
Animal
Bail
acte de propriété
Nourriture
Lapin
Whisky
Mariage
CompteBanquaire
Personne
43
Diagramme de classe : Exercice2
44
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 oucelui d'un Use case
45
Diagramme de Séquence
46
: A1
: C1 : C2 : C3
new : C3Oper1()
Oper3()
Oper2()
Oper1()
C3()
<<create>>
Oper2()
Delete()
<<destroy>>
retour
Diagramme de Séquence (UML2.0)
47
pour chaque employeloop
commercialalt
: FinMois
: Entreprise : Employe
: Commerciaux
CalculerSalaire()
CalculerSalaire()
CalculerCommission()
Entreprise
+CalculerSalaire()
Employe
+salaire
+CalculerSalaire()
Commerciaux
+commission
+CalculerCommission()
-lesEmployes
*
Automate• Un automate est accroché à une classe et est composé d'états etde transitions. Les transitions permettent de passer d'un état àun autre …
Arret Marche
On
Off
Casse
Casse
48
AutomateÉtat & Transition
Etat
entry/ Action1
exit/ Action2
on Ev1/ Action2
do/ Activité
E1 E2Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4)
Événement qui déclenche la transition
Garde
Action effectuée sur la transition
Envoie de Ev2 à un objet Cible
Action en entrant dans l'état
Action en sortant de l'état
Action déclenchée sur réception de Ev1
Activité
49Rmq : Le langage d’action (UML1.4) est remplacé par 50 types d’action
Automate imbriqué
Arret
Marche
Lavage
Rinçage
Essorage
H
On
Lavage
Rinçage
Essorage
After15
After10
After5
PorteOuverte
HFermer
Off
Ouvrir[ cuve vide ]
Automate : exercice
E1
ST1
entry: i = 0exit: i++
ST2
entry: i++exit: i++on E4: i ++
E1 / i++
ST3ST4
on E2: i = i - 2
E3[ i == 5 ]
E2
E1
E1
E3
E3
E1E3E1E3E1E2E1E2
E3
51
La gestion de projetClassique
Apports des technologies objet
La modélisation UML
Unify Process
52
UP : La base
PU est à base de composantsPU utilise UMLPU est piloté par les cas d’utilisationPU est centré sur l’architecturePU est itératif et incrémental
53
UP & RUP
Unify Process (Énorme process pour tous)
RUP Rational Unify Process Process customisé à partir du UPC'est un outil (site web, customisable)
Custom
AirFranceUP
54
XUP
RUP : Principes
55
OpenUP7 rôles (environ 45 pour RUP)20 artefacts (plus de 80 pour RUP)18 tâches (plus de 150 pour RUP)
Les artefacts
• Activité de gestion de projet
– Comptes rendus, planning d’activité, ….
• Résultats
– Modèles
– Code source
– Spécifications
– …..
56
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
Les activités
• Modélisation métier• Les Besoins• Analyse et conception• Implémentation• Tests• Déploiement• Gestion de configuration• Gestion du projet• Environnement
Etudié plus tard
58
BPM
59
Modélisation métierStéréotypes UP
Fournisseur
Les processLes objets de L’entreprise
Client
Les employés
business use case
60
Organisation des modèles (UP)
61
Les sources
Les UC realization (Documentation)
Les composants (physiques et logiques)Les machines
Définition des besoins
PC
Composant1components
Composant1
C1C2
residents
C1 C2
VOPC
uc1
Exemple d’un workflow
62
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
Motivation
64
70% 45%
Les bureaux Google
65*****google zurich****** http://www.dailymotion.com/video/x4zlcv_merci-google_lifestyle
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
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.
68
Ex : IBM Tivoli ITUP
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 IsabelleEDORH-A. SemehoGUIBOUT Nicolas
69
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 IsabelleEDORH-A. SemehoGUIBOUT Nicolas
70
L’Agilité
Introduction
Le lean software dvp
71
Une petite vidéo
72
David Gageot –Directeur Technique –Valtech Technology
E:\Cours\Agilité\Video\Valtech) 40mn
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
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
Les bureaux agiles
75
Important - Symbolique
Le manifeste agile
76
Kent Beck XP-JunitWard Cunningham wikiJeff Sutherland scrum………
17 Personnes (2001)4 Valeurs12 principes
Nous découvrons de meilleuresfaçons de développer des
Logiciels en réalisant ce travail et en aidant les autres à le faire
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
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
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
L’Agilité
Introduction
Le lean software dvp
80
(1950)
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
Kanban
82
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&feature=related
83
Lean : Gaspillage
Shigeo Shingo (1950)
1. Stock
2. Surproduction
3. Tâches inutiles
4. Déplacement
5. Transport
6. Attente
7. Défautshttp://www.tv4it.net/jusquou-le-lean-peutil-sappliquer-a-
linformatique--permalink-8907.aspx84
Lean (LSD) : Gaspillage
Shigeo Shingo (1950)
1. Stock
2. Surproduction
3. Tâches inutiles
4. Déplacement
5. Transport
6. Attente
7. Défauts85
LSD : Mary Poppendieck (2003)
1. Travail non terminé2. Sur spécifications3. Processus…4. Changements de priorité,
changer de tâche5. Transmission d’informations6. Retards7. Défauts
L’Agilité
Panorama des méthodes agiles
86
Les méthodes agiles : Panorama
87
Taille des projets
1-2 ans & 6-12 personnes Couper les projets
88
Les méthodes agiles : Contraintes
89
eXtremPrograming
• KentBeck (1996) Paye de Chrysler
• Les 4 valeurs de XP : CRSC
– Communication
– Retour-FeedBack
– Simplicité
– Courage
90
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
B.Vinot
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
Les rôles ds XP(1)
93
• 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
Les rôles ds XP(2)
94
• 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
95
Combinaison des rôles ds XP
96
Rmq : si plusieurs clients, Ils doivent parler d’une seule voie
What is Scrum? Jeff Sutherland
97
Qu’est ce que Scrum?• Pas une méthode• Pas un process• Pas un ensemble de procédures
• C’est un framework ouvert de dvpcomportant un ensemble de règles
• The rules are constraints on behavior that causea complex adaptative system to self organizeinto an intelligent state
• Il permet à une équipe moyenne de s’organiserpour travailler 10 fois mieux
Sutherland1993
Scrum : Le cycle de vie
98
UCUser story
Planninggame
DVPTests
Scrum : Backlog- BurnDown
99
Scrum : Kanban
100
DoD
Bob: « Voilà j’ai terminé de développer ce module, c’est déployé ! »Gérard: « Ben je vois rien…? »Bob: « Ha en tout cas chez moi ça marche… »
Definition Of DoneDé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 passent)
Multilingue et traduction ok
Documentation (dossier d’hébergement,…)
Démarches à effectuer auprès de 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.
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
TODO-> DoD : Exo
103
Faire qq chose------------------------Comment testerLe résultat------------------------Valeur = 0 - 5OUrgent = 0 – 5Estimation = 0-40
Todo – encours - fini
Planning Game
104
Faire qq chose------------------------Comment testerLe résultat------------------------Valeur = 0 - 5OUrgent = 0 – 5Estimation = 0-40
Et Maintenant Estimer
Kanban & US & DoD
105
Laver voiture------------------------Ma femme dit:« elle est propre »------------------------Val= 50 Urg=2 E=25
Vider corbeil------------------------Corbeil videRien par terre------------------------Val= 2 Urg=2 E= 2
Régler facture------------------------Chèques débités
------------------------Val= 5 Urg=1 E=40
Canette frigo------------------------Canette froide
------------------------Val= 2 Urg=5 E= 5
Arroser fleurs------------------------Le vase est plein d’
eau------------------------Val= 3 Urg=4 E=3
Ranger telecom.------------------------La telecom. est surLa table du salon------------------------Val= 5 Urg=4 E=1
Ranger lunettes------------------------Les lunettes sontDans la chambre------------------------Val= 1 Urg=2 E=1
Lire mail------------------------
------------------------Val= 2 Urg=2 E= 15
Et Maintenant Planifier
Planification
106
Laver voiture------------------------Ma femme dit:« elle est propre »------------------------Val= 50 Urg=2 E=25
Vider corbeil------------------------Corbeil videRien par terre------------------------Val= 2 Urg=2 E= 2
Régler facture------------------------Chèques débités
------------------------Val= 5 Urg=1 E=40
Canette frigo------------------------Canette froide
------------------------Val= 2 Urg=5 E= 5
Arroser fleurs------------------------Le vase est plein d’
eau------------------------Val= 3 Urg=4 E=3
Ranger telecom.------------------------La telecom. est surLa table du salon------------------------Val= 5 Urg=4 E=1
Ranger lunettes------------------------Les lunettes sontDans la chambre------------------------Val= 1 Urg=2 E=1
Lire mail------------------------
------------------------Val= 2 Urg=2 E= 15
50/25 = 2 2/2 = 1 5/40 = 0,125 2/5 = 0,4
3/3= 1 5/1 = 5 1/1 = 1 2/15 = 0,13
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
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
Scrum : Une release
109
Time Boxing
• 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
Durée planif sprint:2*N (N = nb de semaines du sprint)
Scrum : sprint
110http://www.axosoft.com/ontime/videos/scrum
Le test Nokia
111
84
27,5
37,5
24,518
6457,5
67
14
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9
% des personnes ayant trouvé une des deux meilleures réponses
test nokia-ScrumBut
Q 1 : ItérationQ 2 : Pratique des testsQ 3 : SpécificationsQ 4 : Product OwnerQ 5 : Backlog de produitQ 6 : EstimationQ 7 : Sprint Burdown ChartQ 8 : Dérangement de l'équipeQ 9 : Équipe
Q 1 : Itération1. Pas d'itération2. Itération > 6 semaines3. Durée variable < 6 semaines4. Itération de durée fixe 6 semaines5. Itération de durée fixe 5 semaines6. Itération de durée fixe 4 semaines ou moins
Bas VodeJeff Sutherland
Comparaison XP-ScrumXP (programmation) Scrum (process)
Client est ds la salle Oui NonReprésenté par le productOwner
Techniques de programmation
XP est le roi
Oui (Prog Objet) Junit Refactoring Binôme Simple
PeuTestGénération automatique, graphique, C , Javascript,….
Gestion de projet
Scrum est le roi
PeuTracker Planing game
Oui VelocitéBurnDown chart
Durée des itérations Autour de 2 semaines Autour d’un mois (En baisse)
Adaptable Pas pendant les 3 premières itérations
Oui
112Mélanger les deuxUn scrum meeting
H
PO
SCR
RUP
XP
Feature Driven Development5 processes
113
Inventée par Peter Coad
FDD : Les rôles
114
Principaux rôles
• Project manager
• Chief architect
• Domain experts
• Dev. manager
• Chief programmers
• Class owners
Autres rôlesRelease manager
Language guru
Build engineer
Tool smith
System admin
Testers
Deployers
Tech writers
DSDM : Les principes
115
• 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
DSDM : Le cycle de vie
116
Les rôles ds DSDM
117
Sponsor exécutif : ManagerVisionnaire : ManagerUtilisateur ambassadeur : ClientUtilisateur conseiller : Client-TrackerChef de projet : ManagerCoordinateur technique : consultant - expertChef d’équipe : ManagerDéveloppeurFacilitateur : CoachRapporteur : Tracker
Crystal
118
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
Le chef de projet Agile
119la qualité essentielle du leader sera le charisme plus que l’autorité.
Le cycle de l’agilité
120
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.
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
121
Exemple : Une équipe de 5 personnes, des itérations de 10 jours, 5 itérations par Version
L’Agilité – Déroulement d’un projet
Définition des besoins
UC-User Story
Planification
122
MOE(Chef de projet)
Un Problème sur deux!
123
Client
Dev
Client
Dev
MOA(chefs)
Utilisateurs
AnalystesArchitectes
ExpertsProgrammeurs
testeurs
MOAD
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
Définitions des besoins - DVP
125
Besoin global (10%) : Liste des UC ou US + Planification
Détail du 1° tiers : Scénario des UC – Discussion des USRéalisation du 1° tiers
Définition des besoins Réalisation : les itérations
It1
It2
It3
Détail du 2° tiersRéalisation du 2° tiersIntégration continueVNR
Détail du 3° tiersRéalisation et FinBilan
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
User story
127
• Taille : carte postale• Affecte un ID automatique• Ecrite par le client• N’est qu’un résumé• Le reste est verbal• Affectation d’une priorité (une valeur)• Affectation sur une itération (voir partiel)• Ecriture des tests finaux (TR)
le client L’équipe de dvp
• Phase de Définition des besoins •Discussion avec le client• Affectation d’un coût• si estimation impossible
• Rediscuter avec le client• la décomposer en n US• la décomposer en tâches et estimer les tâches (Voir la suite)
• Phase de DVP (Iterations)• Découpage en tâches er estimation (H)• Prise de responsabilité d’un développeur pour une tâche• Réalisation en binôme• Ecritures des TU• Réalisation• Passage des TU• Passage des tests finaux (TR)
Les 3C• Card : une ou deux phrases• Conversation : verbale• Confirmation : test
US : Recto
128
US : Verso
129
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
BackLog de produit(1)
131
D’après la velocité : Une itération = 50 points 5 Itérations (sans engagement)
BackLog de produit(2)
132
BackLog de produit(3)
133
Beurdone - burndown
Méthode classique • RAF = Temps estimé – temps passéAgilité• RAF = Réestimation de la tâche• Simplement utiliser les états
(en cours-fini-…)
Ice Scrum 2Excel
134
Un planning de version•Une version•3 Itérations•Chaque itération contient
des US
Rmq : on ne voit pas lespriorités (dommage)
Une variante : Feature
135
L’Agilité – Déroulement d’un projet
Les itérations
136
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
137
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 définis pour la mêlée quotidienne.
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
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
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
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
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
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
Cycle de vie d’un binôme
145
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
Faire le plus simple possible (1)
• Ne pas faire de conception (la bourseMauvaise 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
Faire le plus simple possible (2)
If (n == 0) return 0;If (n == 1) return 1;----------------------------------------------return n;-----------------------------------------------If (n<=1) return n;Return 1;-----------------------------------------------If (n<=1) return n;Return F (n-2) + F (n-1);-----------------------------------------------If (n < 0) erreur (TBD)If (n<=1) return n;Return F(n-2) + F(n-1);
148
Cas 0 et 1
Cas 0 et 1 remanié
Cas 0, 1, 2
Cas 0, 1, 2 remanié…Cas général…
Solution finale
Conception émergeante
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 commencer à construire le produit. Mike Cohn
149
Le Refactoring : la solution agile pour conserver un code évolutif
Stand up meeting
150
• 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
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
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
Les tâches à faire (le radiateur)
153
Ice scrum : Kanban
154
Cycle de vie d’une User Story
155
Dvp Client
Phrase+Priorité
Discussion
Estimation
ProductBacklog/iteration SprintBacklog
Definition Test
Ecriture du test
Découpe en Tâches
Affectation des tâches
Réalisation tâches
TU
Affectation des tâches
Réalisation tâches
TU
TI [OK]
[NOK]
Déroulement du Sprint (Iter1)
156
Rmq : Total priorité = 42Le premier jour on a de disponible 5/42
(10% du projet) Le 6° Jour on a de dispo 10/42
(25% du projet)
Vélocité
157
Vélocité = nb de points (estimation des US) réalisés pendant une itération
BurnDown de Sprint (Iter1)
158
Vélocité = 48-34 =14 !!!
Burndown du produit après Iter1
159
Vélocité = 14 !!!
Beurdone - burndown
Faire une démonstration au client de ce qui fonctionne (25% du projet)Faire un bilan de l’itération (Voir plus loin)
Iteration2
160
Supposition : Pas de pb sur iter2 (50 points)Gain priorité pour le client = 4+3*3 = 13Total 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)
Gain total de l’iter2 = 50 points (RAF = 230-50 = 180)
180
Vélocité = 50
Beurdone - burndown
Iteration3
161
Supposition : Iter3US11 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 = 110Total point 23(iter2) + 4 + 5 + 4= 36/42 Total RAF 180 – (55 + 34 + 21) = 70
Ré estimation
Fin du projet
162
Vélocité moyenne = 41
Faire un bilan de fin de Version ou de fin de projet : IDEM (Voir plus loin)
Graphe : BurnDown & velocité
163
0
50
100
150
200
250
300
1 2 3 4 5
rafTotal
rafInitial
0
50
100
150
200
250
300
1 2 3 4 5
raf
raf
rafInitial rafTotal
244 0
136 30
85 30
50 50
0 50
0
20
40
60
80
1 2 3 4
velocite
velocite
Rmq : Techn Story : Attention à garder le Backlog orienté métier (ex : Indexer une table)
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
Montrer des diagrammes simples (1)
165
Montrer des diagrammes simples (2)
166
Cycle scrum : résumé
• http://vimeo.com/4587652 scrum vivant
• Bruxellesmobilitehttp://www.bruxellesmobilite.irisnet.be/
167
Les bilans
168
• 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)
XP-GameUn 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
L’Agilité
Les tests
TDD
170
TDDTester pour vérifier n’est pas judicieux!!!
Tester pour spécifierSpécifications executablesProgrammation par contrat
(Bertrand Meyer)
Un test comprend plusieurs scénariosCas nominal, cas aux limites,….Le test remplace la documentation
TU (Programmeur+Outils+Tracker) TR (Client + programmeur)L’acceptation n’est faite que par le client
Tous les tests sont archivés et automatisés
171
Client Programmeur
Ecrire un scénario
Passer le test Ecrire le pg
[NOK]
[OK]
Passer le test [NOK]
Remanier le code
[OK]
Passer le test
[NOK]
[OK]
Ecrire un Test
Qu’avez-vous testé aujourd’hui?
Valtech-Test (14mn)
172
BOF Yahoo!!!
Tester pour corriger Tester pour spécifier
Organiser des campagnes de test
Tester en permanenceIC
Spécialiser les métiers du test Partager les responsabilités des tests
Les tests Automatisés
• TU1
• TU2
• TU3
• TU4
• TU5
TU
• tr1
• tr2
• tr3
• tr4TR
173
TestSuite OK/NOK
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,….
174RMQ : Ecrire et tester le programme avant de l’écrire (TTD)
Junit : Ecriture du TestDOC
175
import junit.framework.TestCase;
public class TestFib extends TestCase {
private Calculette c ;
protected void setUp() throws Exception {c = new Calculette(); //Acteur}public void testFibNominal(){try{int i = c.Fib(0); //ActionassertTrue(i == 0); //Assertioni = c.Fib(1);assertEquals (i, 1);i = c.Fib(2);assertEquals (i, 1);i = c.Fib(21);assertEquals (i, 10946);}catch(Exception excpt){fail();}• }
public void testFibLimites(){try{c.Fib(-1);fail();}catch(Exception excpt){assertTrue (excpt.getMessage().equals
("Nb négatif interdit"));}try{c.Fib(51);fail();}catch(Exception excpt){assertTrue (excpt.getMessage().equals
("Nb superieur à 50 interdit"));}}
Calculette
+Fib(nb: int): int
Généré par JunitAvec un return 0;
Rmq : un test peut avoir 5-20 Assertions et une dizaine de cas de tests
Junit : Passer le testNOK
176
Rmq :Le cas de test s’arrête au premier assert en échec.
Mais les autres tests sontexécutés
Junit : Ecrire le programme
177
public class Calculette {
public int Fib(int n) throws Exception {if (n<0) throw new Exception("Nb négatifinterdit");if (n>50) throw new Exception("Nb superieurà 50 interdit");if (n <= 1) return n;return Fib(n-2) + Fib(n-1);
}}
RMQ : Commencer simplement (return 0, return 1, return n, ……)
Junit : Passer le testOK
178
Junit : TestSuite(1)
179
Calculette
+Fib(nb: int): int+SommeN(n: int): int
import junit.framework.TestCase;
import org.junit.Before;
public class TestSomme extends TestCase {private Calculette c ;@Beforepublic void setUp() throws Exception {c = new Calculette();}
public void testSommeNPremierNombre(){int i = c.SommeNPremierNombre(3);assertEquals (i, 6);i = c.SommeNPremierNombre(-10);assertEquals (i, -1);}
Junit : TestSuite(2)
180
TU : Bouchons & inversion des dépendances
181
A
+Fqq(b: B)
B
+Fac()
IB<<interface>>
+Fac()
PA-IB
B
+Fac()
A
+Fqq(b: B)
B
+Fac()
IB<<interface>>
+Fac()
Bouchon-TU
+Fac()
A
+Fqq(b: B)
B
+Fac()
: A b : B
Fqq(b): void
Fac(): void
IHM DOS
182
CTRL
BlalalGfgdgghdghds
E1<<entity>>
E2<<entity>>
IHM
Test IHM Web : Selenium
183Selenium.mov (2mn)
Outil de test Temps réelChess
184TestTpsReel.wmv (5mn)
Visual Studio 2010 (Vidéo 1H)
185
L’Agilité
Les outils agiles
Voyager léger
186
Les outils
• Gestion de la configuration
• Script de fabrication
• Des outils de DVP – avec du refactoring
– TU
• Des outils de tests (Selenium, Chess, visualStudio)
• UML (reverse)
• Gestion des changements
• Gestion de projet
187
Ne pas se faire ralentir par des outils. Jetez les
Script de fabrication
• Makeall : executable
executable : file1.o file2.o
gcc -o executable file1.o file2.o
file1.o : file1.c file1.h
gcc -c file1.c
file2.o : file2.c file1.h file2.h
gcc -c file2.c
clean : rm file1.o file2.o executable core
• Ant http://wiki.apache.org/ant/FrontPage -
188
Gestion de Configuration
DVP
Test
Intégration
Check inCheck out
189
Mode :• lock• merge
Gestion conf : arborescence
190
S1 S2
S1.VF S1.VO
S1.VF.1
S1.VF.2
S1.VF.3
S2.1
S1
S2
R1.1
R1.2
R2
R1
Gestion conf : Méthode de travail
191
: binomeA : binomeB
: System gest Conf
1 : CheckOut de la BD V1.0()
2 : Travail en local() 3 [mode != lock] : CheckOut de la BD V1.0()
4 : Travail en local()5 : Consolidation()
6 : CheckIn de la BD V1.1()
7 : Consolidation()
8 : Integration du travail de A()
9 : CheckIn V1.2()
V1.2 = V1.0 + WA + WB
V1.2 = V1.1 + WB
Refactoring
100 fois sur le métier remettez votre ouvrage
192
Solution trop lourde
Architecture complexe
•Réparer avant de continuer•Faire le ménage tous les jours, puis faire un nettoyage de printemps.•Ne pas le faire si il n’y a pas de tests automatisés OK
Refactoring• Supprimer le code mort (mettre en commentaire dans un 1° temps)• Rechercher les doublons (Equipe de base)
– Regrouper du code dans des fonctions– Transformer les fonctions en méthodes de classe– Regrouper les méthodes par héritage ou agrégation– Faites des classes génériques (Template)
• Remonter le niveau d’abstraction (classe abstraite et interface)• Utiliser les DP (Equipe moyenne)
– Regrouper les classes dans des packages et encapsuler (Façade)– Regrouper du code dans des fonctions (Template méthode)– Supprimer les variables globales (Singleton)– Supprimer les Switchs (State-Stratégie-….)– Surveiller le couplage (Mediateur)– Garder tout private (Memento, Commande, Visiteur, ….)– Utiliser le configurateur (Fabrique)
• Généraliser par fichier de configuration (.ini, XML)• Mais, Ne rien faire si pas de tests automatisés et complets OK
– Ne pas toucher aux TR– Mais Il va falloir réécrire, modifier des TU, ne pas le faire tant que les TR ne passent pas.
• Faites des mesures de la qualité (avant et après). Affichez les résultats• Passer à la programmation orientée aspect (Equipe de course)
193
Refactoring
194
Gestion des changements (1)
195
Utilisateur
Admin
Developpeur
Testeur
Login
Configurer
Liste des utilisateurs
Gerer un PB
Corriger un PB S'approprier un PB
Enregistrer un PB
Rechercher un PB
Gestion des changements (2)
196
MySQL
Serveur Web
Client
Developpeur
Admin
Bug
Produit
DM
Avec XP, il n’y a plus de Bug !!!!!!
Les Bugs
• Un bug est un défaut• Les défauts sont rares en XP !!!• Il peut provenir:
– Du client– Du programmeur
• Mais il manque un test– Ecrire le test avant de corriger le défaut– Si nécessaire en faire une US (priorité urgente) pour le
product backlog– …… Corriger le défaut
• Et surtout, chercher l’origine de l’origine du défaut, puis y remédier.
197
Gestion des changementsBugzilla : Etats des DM
198Doit être intégré à la gestion de conf, doit contenir ce qu’il faut pour reproduire le Bug
Gestion de projet
199
http://www.extremeplanner.com/tour/
Ice scrum
Excel/Gapps (gratuit)IceScrum (gratuit)ScrumWorks (version gratuite et pro payante)GreenHopper - plugin JIRA (payant)Agilo (version gratuite et pro payante)Pivotal Tracker (payant)Mingle (Payant)Banana Scrum (Saas payant)TargetProcess (payant)VersionOne (payant)Confluence ?E Scum de Microsoft ?
L’Agilité
ConclusionsApplicabilité
ROIMigration
Forfait
200
Applicabilité de l’agilité
201
Agilité : Les avantages
202
Retours d’expérience(1)
203
Chrysler (la paye)Métro de NewcastlePostes de supervision TGV Madrid-Barcelone
Qui
204http://blog.xebia.fr/2008/03/31/scrum-entretien-avec-jeff-sutherland-a-paris/
Microsoft
205
Visual studio 2010 – Agile•2500 ingénieurs• 4 ans• 1.500.000 fichiers-lignes sources• 61H pour Fabriquer le produit• Equipes de 10-20 personnes• Point de synchro toutes les 6 semaines Jeff Beehler : VisualS tudio Chief of Staff
Qui : Et les systèmes critiques?
• Un nouveau projet :Air Data Inertial Reference Unit. Ce dernier est un composant essentiel du système d'information (ADIRS), qui équipera les avions de la gamme A350 XWB.
• Partenaire de longue date du groupe Thales, AdaCoreaffirme dans un communiqué que ce nouveau projet « doit permettre des avancées dans le domaine du développement de systèmes critiques à travers un certain nombre d'innovations, dont l'utilisation de méthodes de développement agiles et de techniques de programmation orientée objet. »
206
Retours d’expérience (2)
Gains sensibles :
• Diminution du volume de la documentation,
• Diminution des coûts de pilotage du projet,
• Diminution des efforts de validation des composants,
• Une plus grande productivité,
• Une capacité à intégrer beaucoup plus tardivement les changements demandés par la maîtrise d'ouvrage, et donc de livrer un produit plus proche du besoin du client.
Michel Perron, responsable du SI .
207
Enquête(1)
L’enquête de VersionOne (2008 sur 2319 entreprises dans 80 pays), 7 points d’amélioration conséquent :
• Le changement est facilité• La productivité augmente• Les ressources humaines sont motivées• La qualité s’améliore• Les risques diminuent• Le « Time to market » se réduit• Cohérence entre développeur et utilisateur
208
Enquête(2)
L’enquête du cabinet Forrester (2007, sur 70 entreprises ) 4 améliorations conséquentes:
• 49% d’entre elles ont constaté une diminution des coûts d’opération
• 83% d’entre elles ont constaté une amélioration de la satisfaction du client
• 88% d’entre elles ont constaté une augmentation du niveau de qualité
• 93% d’entre elles ont constaté une hausse de la productivité
209
Googlism (1)
• 10 Choses que Google trouve vrai:
– 1 : S’occuper des utilisateurs et le reste viendra
• L’interface est claire et simple
• Chargement instantané des pages
• L’ordre des résultats n’est jamais vendu à personne
• Les publicités doivent aider le client et ne pas lui être désagréable
– 2: …….
210
Scrum AScrum BScrum C
Googlism (2)
• Les gens ne doivent pas utiliser leur position hiérarchique pour obtenir ce qu’ils veulent. Ils doivent avoir de meilleurs arguments, basés sur des chiffres et l’expérience. La hiérarchie doit être utilisée en dernier ressort.
• Nous détestons la bureaucratie dans toutes ses formes. Un process peut être une bonne chose, mais il doit accélérer les choses, si ce n’est pas le cas jeter le.– Dire Oui
– Essayer
– Si mauvais, refuser
• 20% pour réfléchir, innover, ….
• Petites équipes peuvent faire de grandes choses
• Pas de polémiques, utiliser des chiffres
• Mesurer tout
• Un problème : ne pas se plaindre, mais le résoudre
• Ne faites pas qq chose de mauvais parce que vous êtes pressé. Si vous pensez gagner du temps en faisant du moins bon, arrêtez vous (Que du bon!!!)
211
Googlism (3)
212
• Affecter des priorités
• Faire simple
• Dire non
• Ne pas propager : Ne créez pas des tâches, réunions ou email si ils vont couter aux autres plus que ce qu’ils valent (1000 personnes reçoivent 1 mail * 5 mn = ½ h*m)
• Soyez concret rapidement (Commencez petit, Itérez souvent)
• Don’t just kill project : learn from them
• Travaillez ensemble
• Soyez à l’écoute de ce qui se passe dans la compagnie (Zoogler)
• Partagez toutes vos informations ( Idées, projets, délais, ….)
• Les projets doivent être petits (4-6 personnes)
• Personne ne travaille tout seul. Les solitaires sont rarement très productifs ni heureux.
• Le plein temps est bien meilleur que le temps partiel.
Communication
213
Ex : Comment communiquer sur un Wiki ou Zoogler
Que du bon !!!
214
• Le syndrome de la décharge (idem pour le code)– ne pas commencer– ne pas continuer– Si qq commence, nettoyer tout de suite
• Un bon code :1. passe ses tests avec succès2. ne peut être mal utilisé (code détrompé)
• Programmation par contrat• LSD : Gestion préventive des défauts et Stop the line
3. ne contient pas de redondance4. exprime clairement l'intention5. est aussi court que possible (en dernier)
Retour d’expérienceMigration
215
Migration vers agilité
• La migration dure
• La migration douce
• La micro migration
216
Prendre un coachEtudier l’existantS’appuyer sur les rôlesSi nécessaire faire un trie dans les pratiquesAffecter les personnes aux rôlesDémarrer un projet piloteMonter en charge progressivement(une équipe de 4, puis rajouter un binôme…)S’adapterAugmenter le nb de projets
Niveau 0 : Script de fabrication et gestion de configuration_______________________________________________Niveau 1 : Tests automatisésNiveau 2 : Intégration continueNiveau 3 : Moins de codeNiveau 4 : Itérations courtesNiveau 5 : Implication du client
Migration : Projet Scrum de transition
Créer un projet Scrum de transition (sans Product Owner):
• Les participants:– PDG (ou un dirigeant)
– Des experts méthodes et processus
– Le scrum master du premier projet pilote
– Un ou plusieurs consultants externes experts de ces transitions
• Les actions– Evaluer le contexte : Pourquoi faire du scrum (Vision)
– Faire un Backlog d’amélioration des pratiques
– Les prendre en compte, puis itérativement : Lever les obstacles:• Sur les pratiques scrum
• Venant des personnes
• Venant de l’organisation et de la gouvernance
• Outil et matériel
217
Evaluer le contexte
Préparer l’application
de scrum
Exécuter projet pilote
Diffuser dsl’organisation
Evaluer le niveau atteint
Les 2 projets en //
Projet pilote
Projet
Migration
Evaluer le
contexte
Planifier
Release
Préparer
Sprint1
Sprint1
Sprint2
Sprint2
Sprint3
Sprint3
Dernier
Sprint
Sprint4 Diffuser
218
Spécificité française
• Culture des organisations– Langue– Esprit cartésien– Peur de l'incertitude
• Gouvernance : séparation MOA/MOE• Modèle économique : grosses SSII sur des contrats au
forfait• Puissance de la hiérarchie et des diplômes--------------------------- MAIS ---------------------------------• Capacité des équipes : formation, esprit d'initiative,
aime la discussion et les contacts
219
Agilité & Forfait(Livre blanc Valtech)
220http://www.tv4it.net/contractualiser-les-projets-agiles-la-quadrature-du-cercle--permalink-4232.aspx
Contre
Pour
Bibliographie (livres)
221
Bibliographie (www)
222
• http://www.extremeprogramming.org/example/stories.html
• UML Laurent Audiber
• http://www.agilealliance.org/
• http://www.aubryconseil.com/pages/Scrum
• http://ayeba.fr/2010/04/09/les-methodes-agiles-ou-la-methode-agile/
Cinéma
223
OffshoreTDDEst ce que cela marche en France ?TDRArchitecture orientée service (SOA)Résumé scrum (1H15)
Conclusion
224
225
http://www.agiliste.fr/Home/bien-demarrer-avec-scrum