Pratiques agiles

PRATIQUES AGILES
MOSTEFAI MOHAMMED AMINE | 2018

PRATQUES AGILES
PLAN DU COURS
2
Vue d’Ensemble Organisation Collaboration
Livraison Planification Développement

PRATIQUES AGILES
SECTION 1 : VUE D’ENSEMBLE
MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018 3

SECTION1:VUED’ENSEMBLE
PRATIQUES AGILES
PRATIQUES XP
Organisation
Programmation
par binômes
Travail énergisé
Espace de travail
informatif
Analyse de cause
racine
Rétrospective
Collaboration
Confiance
S’assoir ensemble
Implication du
client
Langage universel
Réunion debout
Standard de codage
Démo d’itération
Rapports
Livraison
Définition du Fait
Pas de bugs
Contrôle de version
Génération de 10
minutes
Intégration
Continue
Propriété
Collective
Documentation
Planification
Planification Agile
Vision
Plan de livraison
Jeu de planning
Gestion des risques
Planification de
l’itération
Relâchement
Estimation
Développement
Exigences
Incrémentales
Tests d’acceptation
TDD
Refactoring
Conception Simple
Conception et
Architecture
Incrémentales
Solutions de Pointe
Tests Exploratoire
Revues de Code

SECTION2:PRATIQUESD’ORGANISATION
PRATIQUES AGILES
SECTION 2 : PRATIQUES D’ORGANISATION

PRATIQUES AGILES
PROGRAMMATION PAR PAIRES

PRATIQUES AGILES
PROGRAMMATION PAR PAIRES
Deux
programmeurs
partagent le
même poste
Une personne
code « le
conducteur »,
l’autre appelée
« navigateur »
observe et
réfléchit
Le conducteur
se concentre
sur le code
tandis que le
navigateur sur
une vision plus
globale
Le travail en
binôme ne se
retreint pas au
codage, mais
peut s’étendre
aux tests
Il est
recommandé de
changer les
binômes à
travers les
journées
Il est
recommandé de
réfléchir à
haute voix
Le navigateur
doit privilégier
la réflexion à
l’interruption
Le navigateur
et le
conducteurs
doivent
échanger leur
rôles
fréquemment

PRATIQUES AGILES
PROGRAMMATION PAR PAIRES - RECOMMANDATIONS
S’organiser en binôme pour tout
Les binômes se choisissent d’eux-mêmes, éviter les affectations
Quand les choses n’avancent pas, changer de binôme
Éviter de faire binôme avec la même personne plus d’une journée
Échanger fréquemment les rôles
Le navigateur doit collaborer, pas critiquer
Faire attention au style de communication

PRATIQUES AGILES
TRAVAIL ÉNERGISÉ

PRATIQUES AGILES
TRAVAIL ÉNERGISÉ
L’un des facteurs
de productivité,
est la forme
Un développeur
ne doit pas « se
noyer » dans le
projet et doit
avoir d’autres
activités
personnelles et
sociales
L’une des façons
de pratiquer le
travail énergisé
est le mode 40H
par semaine (pas
d’heure sup)
Le coach doit
rappeler aux
développeurs de
rentrer chez eux
S’habituer à des
pauses
Le CdP Essaye
de se
déprogrammer
des réunions
facultatives
Pendant les
heures de
travail, se
concentrer sur le
projet : pas de
mail ni
téléphone
Construire une
équipe soudée
aide à la
productivité
Si un travail
supplémentaire
est inévitable, ne
pas en abuser

PRATIQUES AGILES
ESPACE DE TRAVAIL INFORMATIF

PRATIQUES AGILES
Un espace de travail
informatif fait circuler
l’information d’une
manière optimale
L’état d’avancement du
projet peut être facilement
obtenu en marchant dans
la salle
Tableaux blancs, des
mures d’affichage, des
schémas dessinés à la
main
Utiliser les photos avec les
personnes distantes

PRATIQUES AGILES

PRATIQUES AGILES
EXEMPLE D’ESPACE DE TRAVAIL
www.jamesshore.com

PRATIQUES AGILES
EXEMPLE D’ESPACE DE TRAVAIL - 2
Source : www.jamesshore.com

PRATIQUES AGILES
ANALYSE DE LA CAUSE RACINE

PRATIQUES AGILES
ANALYSE DE LA CAUSE RACINE
Au lieu de se
restreindre à
corriger un bug,
identifier les causes
Une des techniques
est de poser
« pourquoi » cinq fois
Les rétrospectives
sont le moment idéal
de discuter des
causes racines
L’analyse peut se
faire
individuellement,
par binôme ou par
équipe
Le but de RCA est de
corriger les
problèmes, pas de
blâmer les gens

PRATIQUES AGILES
QU’EST-CE QU’UNE RÉTROSPECTIVE ?
Une réunion impliquant l’équipe qui se tient à la fin du projet ou d’une étape du projet.
Cette réunion discute des éléments qui ont bien fonctionné et des possibilités
d’amélioration du processus de travail.
Source : https://www.gov.uk/service-manual/agile/running-retrospectives.html

PRATIQUES AGILES
QU’EST-CE QU’UNE RÉTROSPECTIVE ?
MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018 19http://nomad8.com/personal-kanban-at-work/

PRATIQUES AGILES
TYPES DE RÉTROSPECTIVES
Itération Livraison Projet
Surprise

PRATIQUES AGILES
RÉTROSPECTIVES - DÉTAILS
Tout le monde
doit participer
Les éléments
externes à
l’équipe ne
doivent pas
assister
Donne
l’occasion à
tout le monde
d’améliorer le
procédé
Il est
obligatoire de
cadrer la
rétrospective
Utiliser des
techniques
comme les
questions,
brainstorming
ou les cinq
pourquoi
Ne pas utiliser
les
rétrospectives
pour attaquer
ou blâmer
Les
rétrospectives
ont besoin d’un
facilitateur
(par exemple
chef de projet)
Le plan
d’action à
sortir doit être
réalisable à
court terme
Les
rétrospectives
sont
cohérentes
entre elles
Privilégier les
post-it

PRATIQUES AGILES
LE FACILITATEUR
Planifier la
rétrospective
Donne la chance
à tout le monde
de s’exprimer
Contrôle la
rétrospective
S’assure que des
actions sont
prises et
affectées

PRATIQUES AGILES
RÉTROSPECTIVES - PROCESSUS
Discours
Ecrire les
points
positifs
Discuter des
points
positifs
Ecrire les
points
négatifs
Discuter des
points
négatifs
Plan d’action

PRATIQUES AGILES
RÉTROSPECTIVES - TABLEAU
MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018 24Source : https://www.gov.uk/service-manual/agile/running-retrospectives.html

PRATIQUES AGILES
SECTION 3 :
PRATIQUES DE
COLLABORATION
25MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018

SECTION2:PRATIQUESDECOLLABORATION
COURS 5 : PRATIQUES AGILES
CYCLE DE VIE D’UNE ÉQUIPE
26
Constitution
•Découverte
•Rôle du leader
•Fédération
autour d’un
objectif
•Instauration d’un
climat de
confiance
Tensions
•Divergences /
Confrontations
•Rôle du leader
•Ecoute /
Régulation
•Instauration du
leadership
Normalisation
•Structuration
•Rôle du leader
•Règles partagées
•Célébrer les
premiers succès
Production
•Coopération /
Coordination
•Rôle du leader
•Motivation
•Encouragement
Dissolution
•Deuil / Départ /
Reconstitutions
•Rôle du leader
•Reconnaissance
•Encouragement
MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018

CONFIANCE

CONFIANCE
28
Il faut du temps aux
membres de l’équipe
pour se connaître
Une équipe qui
s’entend bien est une
équipe qui devrait
être plus productive
Les membres de
l’équipe doivent
compter l’un sur
l’autre
La responsabilité
collective et la
propriété collective
sont une des clés du
succès
Remplacer la
mentalité « c’est
eux » par « c’est
nous »
Créer un climat de
confiance entre
clients et
développeurs

CLÉS DE LA CONFIANCE
29
Je ne dois pas être pénalisé par ce que je consacre du
temps à aider les autres
Je ne dois pas être sanctionné ou mal vu lorsque je
demande de l’aide
Le Top Management doit faire confiance aux équipes

CONSTRUIRE LA CONFIANCE
30
Coaching Rétrospectives
S’asseoir
ensemble
Manger
ensemble
Faire d’autres
activités
Continuité de
l’équipe
Satisfaire
l’organisation

S’ASSEOIR ENSEMBLE
31
Les
communications
face à face sont
les plus efficaces
Les
communications
indirectes sont
plus sujettes aux
ambiguïtés et
aux malentendus
Il faut éviter aux
collaborateurs de
« deviner » les
réponses
Dans une équipe
XP, dans un
espace ouvert,
quand on a une
question, on la
pose directement
La
communication
directe augmente
la propriété
collective et
anticipe les
questions
L’espace de
travail doit
accommoder
l’équipe XP mais
ne pas déranger
les autres
employés

IMPLICATION DU CLIENT

IMPLICATION DU CLIENT
33
Si le client est bien
choisi, son impact
est extraordinaire
Si le projet est
interne, prendre une
personne
compétente, motivée
et influente
Si intégrer un client
est difficile,
multiplier les
réunions et les
visites
Utiliser les outils de
communication
Inviter des
utilisateurs pour des
versions « béta »

LANGAGE UNIVERSEL

LANGAGE UNIVERSEL
35
Les développeurs ne
sont généralement pas
qualifiés pour le
domaine cible et les
clients ne sont pas
techniquement qualifiés
Les développeurs et les
clients doivent parler un
langage unique
Respecter au maximum
la terminologie du client
Le langage universel
doit se répercuter sur le
code

RÉUNION DEBOUT

RÉUNION DEBOUT
37
Se fait chaque
jour, la même
heure
Chaque membre
partage ce que les
autres doivent
savoir sur le projet
Les échanges
doivent être brefs
et cadrés

SCRUM QUOTIDIEN
38
De préférence
en début de
journée
Qu’est-ce que
j’ai fait hier ?
Qu’est-ce que je
vais faire
aujourd’hui ?
Quels sont les
problèmes qui
m’empêchent de
progresser ?

RÉUNION DEBOUT
39
Source : en.wikipedia.org

STANDARDS DE CODAGE

STANDARDS DE CODAGE
41
Il est dans l’intérêt de l’équipe d’avoir un style unique
XP suggère la création de standards auxquels l’équipe doit adhérer
Les standards incluent :
•Les pratiques de développement
•Le style de conception
•La manière de générer les produits
•La manière avec laquelle créer des tests unitaires
•Les logs et l’infrastructure
•Outils
•…
Les standards sont établis en consensus aux débuts de l’itération
La présence d’un coach technique est hautement recommandée
Choisir les standards les plus consensuels

DÉMO DE L’ITÉRATION

DÉMO DE L’ITÉRATION
43
Faire chaque
itération,
idéalement à la
fin
Présente ce qui a
été fait pendant
l’itération
Inviter d’autres
clients que ceux
sur site
Collecter le
feedback et
réorganiser les
idées et les récits

REPORTING

REPORTING
45
Les rapports
permettent aux
personnes
concernées d’être
informées sur le
projet
Il existe plusieurs
types de rapports
Les rapports
affichent la
progression du
projet

RAPPORTS DE PROGRESSION
46
Plan d’itération et le
livraison
•Donne des indications
sur le progrès
Rapport de
Progression Globale
(Burn-up Chart)
•Avance globale du projet
Feuille de Route
•Direction du Projet
Tableau de bord des
défaillances
•Suit et mesure les
défaillances
Utilisation du temps
•Temps accordé par
l’équipe aux différentes
activités
Suivi de Vélocité
•Capacité de l’équipe à
produire

BURN-UP CHART - EXEMPLE
47
Source : pm.stackexchange.com

BURN-UP CHART – EXEMPLE 2
48
Source : help.rallydev.com

BURN-UP CHART AVEC VÉLOCITÉ
49Source : help.rallydev.comMÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018

SUIVI DES DÉFAILLANCES– EXEMPLE
50
Source : help.scrumalliance.org

PRATIQUES AGILES
SECTION 4 : PRATIQUES DE LIVRAISON

PLAN DE LIVRAISON EXEMPLE
52
Source : scalingsoftwareagilityblog.com

PLAN DE LIVRAISON EXEMPLE 2
53
Source : betterprojects.net

PLAN D’ITÉRATION - EXEMPLE
54
Source : jazz.net

SECTION4:PRATIQUESDELIVRAISON
COURS 5 : PRATIQUER XP
DÉFINITION DU FAIT !

DÉFINITION DU FAIT ! (DEFINITION OF DONE, DOD)
56
Quand est-ce qu’un
récit est
« effectivement » fini ?
Les récits
partiellement finis ont
un potentiel néfaste
sur le projet (coûts,
bugs, désagréments)
Il faut définir les
critères permettant de
dire qu’un récit est fait

CRITÈRES POSSIBLES
57
Testé
•Intégration
•Acceptation
•Unitaire
Codé
Conçu
•La structure et
l’architecture est
satisfaisante
Intégré
•Fonctionne en end to
end
Compilable
Installable
Révisé
•Validé par les clients
Migré
•Scripts de BDD
•Fichiers
•Clés registre
Réparé
•Éliminé les bugs
Accepté
Performant Documenté

COMMENT RÉUSSIR LE DOD ?
58
TDD Bien planifier
S’assurer qu’un
récit est fait
avant de passer
à l’autre
Intégration
Continue
Les récits
doivent être
assez petits

ABSENCE DE BUGS

ABSENCE DE BUGS
60
Toutes les pratiques
de XP tendent à
réduire le nombre de
bugs
Se baser sur le TDD
Faire les tests très
tôt dans le process
Prioriser le
règlement de bugs
Améliorer le
processus de façon à
toujours réduire le
nombre de
défaillances

CONTRÔLE DE VERSION

CONTRÔLE DE VERSION
62
L’équipe a besoin
d’un référentiel
centralisé pour le
code et d’autres
éléments
Plusieurs systèmes
supporte le contrôle
de version (svn,
TFS,…)
Le contrôle de
version permet une
résolution des
conflits et une plus
grande sécurité
Le contrôle de
version est
indispensable à
l’intégration
continue

GÉNÉRATION DE 10 MINUTES

GÉNÉRATION DE 10 MINUTES
64
Préférer les outils
automatisant la
compilation
Ajoutez d’autres tâches
à la génération : mise à
jour du schéma, clés,
fichiers,…
Structurez le projet de
façon à minimiser la
compilation
Évitez les projets
monolithiques
Cloisonnez le travail de
façon à ce que pendant
une itération, peu de
développeurs
travaillent sur
plusieurs sous-projets
Allégez les tests
unitaires
Utilisez les générations
rapides et les
générations poussées
(lorsqu’il y a beaucoup
de tests)

INTÉGRATION CONTINUE

INTÉGRATION CONTINUE
66
L’intégration continue
consiste à intégrer tous
les travaux des
développeurs en un code
centralisé et compilable
L’équipe doit intégrer
fréquemment
Le contrôle de version
est la base de
l’intégration continue
Exemple d’Outils :
Bamboo, TeamCity,
Apache Continuum
Deux types
d’intégration: synchrone
et asynchrone

PROPRIÉTÉ COLLECTIVE

PROPRIÉTÉ COLLECTIVE
68
La Propriété
Collective lègue la
responsabilité de
maintenir le code à
TOUTE l’équipe
Répond à des
risques connus:
absence, maladie,
démission,…
S’il y a y a un
problème avec le
code, toute l’équipe
devrait être
responsable

DOCUMENTATION

DOCUMENTATION
70
L’agilité réduit la
documentation mais
ne l’élimine pas
La meilleure
documentation sur le
code est le code lui-
même
documentation
automatique tels que
Doxygen ou JavaDoc
Les tâches de
documentation
doivent être
considérés comme
récits et planifiées
Privilégier
l’utilisation des
wikis

PRATIQUES AGILES
SECTION 5 : PRATIQUES DE PLANIFICATION

SECTION5:PRATIQUESDEPLANIFICATION
ENCHAÎNEMENTS
72
Constitution
• Identification
des rôles
Découverte
• Constitution
des backlogs
• Vision
Exécution
• Itérations
• Transformation
créative

CONSTITUTION
73
Leader Client Equipe
Partie Prenante

DÉCOUVERTE
74
Qu’est-ce
que le
produit ?
Où va-t-on
Quelle est la
vision ?
Backlog
Initial

LIVRAISON
75
R0
R1
R2
R3
Rx
Valeur

RÉCIT / ELEMENT
Fonctionnalité
d’un produit
Moins
granulaire que
l’épopée ou la
fonctionnalité
Caractérisé par
un poids
(points) et une
priorité

R0
RÉCITS
77
R1
Rx

RÉCIT ?
78
Source : agilemodeling.com

RÉCIT ?
79
Source : agilemarketing.net

ORGANISATION DES RÉCITS
80
Epopée 1
Fonctionnalité
1
Récit 1 Récit 2
Fonctionnalité
2
Récit 3 Récit 4 Récit 5
Epopée N
Fonctionnalité
X
Récit N Récit N+1

EXÉCUTION
81
R0
I1 I2 I3 I3 I4 I5 I6 I7 I8 I9
I1
0
R1
I1
1
I24 I25 I26 I27 I28
Rx
Infrastructure
Itération
Normale
Itération
Qualité

ITÉRATIONS
82
Planification
IngénierieDémonstration
Rétrospective

LES RÉCITS
83
Les récits sont des fonctionnalités décrites en une ou deux lignes
Elles sont utilisées pour la planification
Les récits sont orientées métier et utilise la terminologie du client
La réalisation d’un récit doit être mesurable
Utiliser des cartes en papier et les tableaux blancs pour afficher les récits
Les récits peuvent être fusionnés ou scindés pour s’adapter aux contraintes de planification
Certains récits « spéciaux » peuvent être ajoutés :
•Infrastructure
•Non-fonctionnel
•Bugs
•Documentation
•PoC
Les récits ne remplacent pas les spécifications

LES RÉCITS - EXEMPLE
84
Source : agilemodeling.com

LES RÉCITS - EXEMPLE
85

LES RÉCITS – EXEMPLE TFS
86
Source : microsoft.com

LES RÉCITS – EXEMPLE
87

ANATOMIE D’UN RÉCIT
88
Epopée 1
Fonctionnalité
1
Récit 1
Élément de
travail
Élément de
travail
Élément de
travail
Récit 2
Fonctionnalité
2
Récit 3 Récit 4 Récit 5

ÉLÉMENT DE TRAVAIL
89
Élément
de
travail
Tâche
Bug
Amélioration
Exécution de
test
….

ÉLÉMENT DE TRAVAIL VS RÉCIT
90
Élément de travail
• Estimé par le temps
• Monolithique
• Sur une itération
• Généralement affecté à une
personne
• Technique
Récit
• Estimé par l’effort
• Composite
• Peut s’étaler sur plusieurs itérations
• Généralement pris en charge par
plusieurs personnes
• Fonctionnel

PRINCIPES DE PLANIFICATION
91
Planifier
Court
Cadrage Contraintes
Dettes
Techniques
Granularité Poker
Calcul de
Vélocité

92
Semaine
Heur
e
Dim Lun Mar Mer Jeu
Journée
9H-10H
10H-
11H
11H-
12H
13H-
14H
14H-
15H
15H-
16H
16H-
17H
17H-
18H
Planification
Ingénierie
Relâchement
Rétrospective &
Démo
PLANIFICATION

EXÉCUTION
Ingénierie
Développement
Tests
Conception
Relâchement
Dette
Technique
Recherche
Documentation
Planification
Poker
Négociation
Auto-
Organisation

PLANIFICATION
Récits
Tâches

PLANIFICATION - SUITE

CONTRAINTE DÉVELOPPEMENT
«recette + dev»
Analyse Fonctionnelle
Récit
«equipe»
Planification
«dev»
Implémentation
Tâche
«recette»
RédactionCas de Test
«recette»
Test
Rapport de
Test
«dev»
Rectification
Bug
Clôture
présence de bugs

CONTRAINTE TEST
«recette»
Test Exploratoire Rapport de
Test
«dev»
Rectification
Bug
«dev»
Implémentation
Tâche
Test
Clôture
RAS
défaillance
defaillance
amélioration

TRANSFORMATION CRÉATIVE
Tâches

LA VISION

LA VISION
100
La vision est très
importante car elle
définit une sorte
d’identité pour le
projet
La vision est portée
par le
« visionnaire »
Il faut que l’équipe
comprenne dans
quel contexte elle
est
Il faut que la vision
soit unique
L’idéal est que la
vision soit portée et
promue par le chef
de produit
Si l’équipe comporte
plusieurs
visionnaires, il faut
qu’ils consolident
leur vision
Il est recommandé
que la vision soit
formalisée
La vision doit être
omniprésente
La vision aide à
structurer le projet
et à prioriser les
récits

FORMALISER LA VISION
101
Projet
Qu’est-ce
qu’il
accomplit
Quelle est
sa valeur ?
Quels sont
les critères
de succès ?

PLAN DE LIVRAISON

QU’EST-CE QU’UN PLAN DE LIVRAISON ?
103
Un plan de livraison est un ensemble
de récits quantifiés et priorisé
déterminant la portée fonctionnelle
d’une ou plusieurs livraisons.

PLANIFIER LA LIVRAISON
104
Planifier un seul
projet en même
temps
Essayer de prioriser
les récits de façon à
créer une première
version qui crée de
la valeur
Livrer tôt Livrer fréquemment
Réduire le nombre
de récits par
livraison pour
inclure le nombre
des livraisons
Adapter le plan en
intégrant les récits
provenant des
feedbacks des
utilisateurs
Les dates de
livraisons sont
souvent fixées par
des entités externes

LIVRAISON FRÉQUENTE – EXEMPLE, TODO LIST

MÉTHODES DE CRÉER UN PLAN DE LIVRAISON
106
Cadré par les
fonctionnalités
•Fonctions Connues
•Date de Livraison Inconnue
Cadré par le temps
•Fonctions Inconnues
•Temps Connu

MÉTHODES DE CRÉER UN PLAN DE LIVRAISON
107
Produit
Livraison 1
Livraison N
Itération 1
Itération 2
Itération 3
Itération P
Itération
P+1MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018

PROCESSUS DE LA PLANIFICATION DE LIVRAISON
108
Identification
des fonctions
Estimation Priorisation
Répartir les
récits sur les
livraisons

FACTEURS IMPACTANT LA PLANIFICATION DE LIVRAISON
109
Vision
Stratégie
Coût des
récits
Valeur des
récits
Complexité

EXEMPLE

LE JEU DE PLANNING

LE JEU DE PLANNING
112
Une approche
permettant de
construire
convivialement le
meilleur planning
possible
Les clients sont les plus
informés sur la valeur
 priorité
Les développeurs sont
les plus informés sur le
coût  estimation
La planification
optimale maximise la
valeur en réduisant les
coûts

DÉROULEMENT DU JEU
113
Des récits
sont
proposés
Les
développeurs
estiment les
récits
Les clients
classent les
récits selon
leur priorité

LE POKER DE PLANNING
114
Un jeu permettant
d’obtenir un
consensus des
estimations
Chaque estimateur a
des cartes de
0,1,2,3,5,8,13,20,40 et
100 points
Le client ou le chef de
produit présente un
récit
Les estimateurs
posent des questions
Chaque estimateur
présente une carte
Si les estimations
convergent,
l’estimation est
adoptée
Si les estimations
divergent, on pose la
question à la plus
grande et la plus
petite estimation
Redemander
l’estimation en cas de
divergence

LES RISQUES

LES RISQUES
116
Les risques est un
évènement qui peut
avoir lieu
Un risque a un
impact négatif sur le
triangle
portée/qualité, coût,
temps
Avant de pouvoir
gérer les risques, il
faut les recenser et
prédire leur impact
Un risque est mesuré
en combinant sa
fréquence et sa
probabilité
d’occurrence
La réunion pessimiste
est une technique de
recensement des
risques

EXEMPLES DE RISQUES
117
Absence Départ
Nouveaux
besoins à
impacts
Problème
techniques
Changement
Stratégie
Budget
inadéquat

COMMENT RÉAGIR À UN RISQUE ?
118
L’éviter Dans la mesure du possible
L’intégrer L’intégrer au planning
Le passer Le passer aux autres (par exemple, top
management)

ESTIMATION & VÉLOCITÉ

ESTIMATION & VÉLOCITÉ
120
Il est quasiment
impossible d’avoir une
estimation précise
Prédire en terme
d’effort au lieu en
temps
Utiliser les jours
idéaux d’ingénierie : le
nombre de jours à
réaliser un récit sans
interruption
Convertir les jours en
points
La vélocité est
l’ensemble des points
qu’on peut réaliser
pendant une itération
La vélocité est utilisée
pour la planification,
pas pour mesurer la
productivité
La vélocité prend
quelques itérations
pour se stabiliser
Des pratiques comme
le poker aident à
rendre les estimations
plus précises à travers
le temps

LE PLANNING DES ITÉRATIONS
121
Une itération est par
définition très courte
Une itération se fixe
l’objectif de réaliser
des récits
sélectionnés sur la
base de priorités
Chaque récit est
composé en tâches
qui sont mesurées en
heure
Les tâches
composant un récit
sont les tâches
d’ingénierie
De préférence, faire
coïncider les
itérations avec les
semaines de travail
L’identification des
tâches d’ingénierie
est un travail de
conception

PROCESSUS DE L’ITÉRATION
122
Mesurer la
vélocité de
l’itération
précédente
Sélectionner
les récits à
partir du
plan de
livraison
Développer
les Récits
Préparer la
Livraison
Démo
d’itération
Rétrospective

PRINCIPES DE BONNE PLANIFICATION
123
La vélocité doit se faire
uniquement sur les
récits « faits faits »
Un récit doit être
réalisable sur une
itération
Un récit doit être
décomposé en un nombre
raisonnable de tâches
Une tâche doit durer
quelques heures
seulement (par exemple
max 6). Si cette tâche là
dépasse, la décomposer
Dérouler les tâches à la
fin pour identifier les
doublons ou les erreurs
Comparer le total
horaire de l’itération à
celui de l’itération
précédente
Demander une
réorganisation si on
constate que le planning
obtenu est irréalisable
Demander plus de récits
si on constate que le
planning se termine
avant la fin de l’itération
La planification doit
durer d’une demi heure à
quatre heures

RÉAGIR AUX IMPRÉVUS
124
Si un problème général
saborde l’’itération, cette
itération est déclarée
ratée
Ne pas de baser sur la
vélocité des itérations
ratées
Si le phénomène
d’itérations ratées est
fréquent, il y a alors un
problème de planning
Rien n’empêche, en cas
d’imprévus, d’ajuster le
planning de l’itération
On peut remplacer les
récits en cours d’itération
à condition qu’il soient
du même poids et qu’ils
ne soient pas encore
commencés

LE RELÂCHEMENT
125
Les heures de
relâchement sont des
heures qui peuvent être
utilisées pour répondre à
des risques critiques sur
l’itération
Le relâchement donne
une marge de manœuvre
pendant l’itération
Il permet de réagir aux
imprévus sans perdre
l’itération
Une autre approche est
de planifier des tâches
de dette technique
Accorder des heures de
recherche à l’équipe
Augmenter le
relâchement lorsque les
besoins sont très
instables ou lorsqu’on ne
maîtrise pas très bien les
technologies

PRATIQUES AGILES
SECTION 6 : PRATIQUES DE
DÉVELOPPEMENT

SECTION6:PRATIQUESDEDÉVELOPPEMEBNT
EXIGENCES INCRÉMENTALES

EXIGENCES INCRÉMENTALES
128
Dans le développement
agile, il n’y pas une
phase dédiée aux
exigences
Les clients sur site sont
des exigences vivantes
XP n’élimine pas les
documents de
spécifications mais les
réduit et s’ouvre à leur
évolution
Lors des discussions
avec les clients, prendre
des notes, faire des
schémas, des
affichages,…
bureautique et/ou les
wikis
Utiliser le système de
gestion de version (ou
un autre système
équivalent) pour le
versionnement des
documents

EXIGENCES INCRÉMENTALES – QUE DOIT FAIRE LE
CLIENT ?
129
Comprendre et
faire comprendre
les récits
Éviter le blocage et
maximiser le
parallélisme des
développeurs
Comprendre le
langage et le mode
de réflexion des
programmeurs
Anticiper la
question
S’approprier la
vision
Déterminer le
« fait fait » d’un
récit
Concevoir avec
précision les tests
d’acceptation
Faire réviser les
récits

LES TEST CLIENT - ACCEPTATION

LES TEST CLIENT - ACCEPTATION
131
Les tests clients
décrivent et valident les
fonctionnalités qui ont
besoin d’explication
Les tests aident à
l’équipe à comprendre le
domaine et les règles du
métier
Les tes d’acceptation
sont créés à partir des
récits
Un récit peut être validé
par un ou plusieurs tests
d’acceptation
Les tests doivent
impliquer le minimum de
travail. Il est très
recommandé
d’automatiser les tests
d’acceptation
Un récit n’est complet
que s’il passe ses tests
d’ acceptation
Les tests sont aussi
utilisés pour vérifier la
non-régression
De préférence utiliser les
tableaux qui sont
parlants
Les scores de tests sont
publiés et discutés

TDD

TDD
133
Le TDD est un cycle rapide de tests, codage et refactoring
Le TDD consiste à écrire des tests d’une fonction avant de
l’implémenter
L’impact du TDD est la réduction de bugs et
l’augmentation de la qualité de l’architecture

TDD - CYCLE
134
Réfléchir
Faillir
Réussir
Refactoring

TDD - RÉFLÉCHIR
135
Imaginer que le
code est finalisé,
que serait le
résultat ?
Réfléchir à un test
efficace et aux
conséquences sur le
code qui doit suivre
La programmation
par paires aide
dans ce processus
Ne s’intéresser qu’à
la façade des
modules ou des
classes

TDD - FAILLIR
136
Le premier échec est
l’échec de compilation
Souvent on écrit des
tests sur des méthodes
qui n’existent pas ou qui
sont structurellement
différentes du test
Réfléchir en tant
qu’utilisateur de la
classe, pas en tant que
son concepteur
Plusieurs formes d’échec
: la compilation ou un
échec différent à l’échec
attendu

TDD - RÉUSSIR
137
Ecrire le code
qui permet de
passer les tests
Ne pas se
soucier de la
qualité du code
pour le moment
Vérifier que les
tests passent

TDD - REFACTORING
138
Réécrire le code de façon à le rendre
meilleur sur le plan structurel
Repasser les tests et vérifier

REFACTORING

REFACTORING
140
Le Refactoring est le processus de changer le code sans
changer son comportement
L’objectif primaire est d’améliorer l’architecture du code
Plusieurs motivations : non respects des principes SOLID,
non conformité aux patrons de conception,…

EXEMPLES DE REFACTORING
141
Changement
des Noms
Classe
Méthode
Variable
...
Structure
Encapsulation
Extraction de
méthodes, classes et
interfaces
…
Nettoyage
Code mort
Code sale
…
…
…

ARCHITECTURE INCRÉMENTALE

ARCHITECTURE INCRÉMENTALE
143
Le facteur « Time-To-
Market » exige des
livraisons rapides
Pas le temps pour des
fondations complètes et
complexes
L’architecture
incrémentale consiste à
construire
l’infrastructure
technique d’une
manière incrémentale
Eviter d’identifier les
abstractions à partir des
premières utilisations
d’un élément
Utiliser les abstractions
à partir de la deuxième
utilisation d’un élément

CONCEPTION SIMPLE

CONCEPTION SIMPLE
145
Privilégier toujours les approches simples
Simplicité n’est pas forcément contraire à évolutivité
Adopter une fondation minimale lors des premières
itérations

SOLUTION DE POINTE

SOLUTION DE POINTE
147
Aussi appelée PoC
(Proof of Concept)
Des petites solutions
à périmètre très
réduit
Permet de découvrir
un nouvel aspect
technologique ou du
domaine
Des projets à part,
non intégrés au
projet principal
Doivent être intégrés
au planning
Éventuellement
prévoir des
démonstrations

TESTS EXPLORATOIRES

TESTS EXPLORATOIRES
149
L’objectif du
développement agile
n’est pas de corriger
les bugs mais de ne
pas en produire
Le testeur choisit un
test au hasard
ensuite à partir des
résultats du test
conçoit d’autres tests
Se font
généralement
lorsque une partie
considérable du
logiciel est prête
Parmi les tâches, les
testeurs poussent le
logiciel à des
conditions étranges
ou extrêmes
Les sessions
prennent quelques
heures
Utiliser des
techniques telles que
l’observation ou les
heuristiques

TESTS EXPLORATOIRES - HEURISTIQUES
150
Privilèges
Super
Utilisateur
Pas de
privilège
Peu de
Privilège
Taille
Trop petit Trop gros
Normal
Position
Début Fin
Milieu
Nombre
0 Plusieurs
1
CRUD
Read Update
Delete Create
Type et
Frontières
< MIN > MAX
Mauvais
Type

REVUE DE CODE

REVUE DE CODE
152
Des revues de code
régulières
Faites par les
membres avec le
plus d’expérience ou
des personnes
externes
Les résultats de la
revue sont discutés
avec toute l’équipe
Ne pas utiliser pour
sanctionner
Combiner avec
l’analyse de la cause
racine
Utiliser le
relâchement pour les
revues de code

PRATIQUES AGILES
BIBLIOGRAPHIE

PRATQUES AGILES
BIBLIOGRAPHIE
154
• The Art of Agile Development, 2007, James Shore and Shane Warden,
O’Reilly
• XP Practice: Energized Work, 2007, Artem Marchenko,
http://agilesoftwaredevelopment.com/xp/practices/energized-work
• What’s an Agile Retrospective and Why Would You Do It?, 2013, Ben
Linders, http://www.benlinders.com/2013/whats-an-agile-retrospective-
and-why-would-you-do-it/
• Running Retrospectives, 2014, https://www.gov.uk/service-
manual/agile/running-retrospectives.html, Government Service Design
Manual,
• VERSIONONE, 2014, Release Planning, http://www.versionone.com/agile-
101/agile-development-release-planning/MÉTHODES AGILES | MOSTEFAI MOHAMMED AMINE | © 2018

PRATQUES AGILES
BIBLIOGRAPHIE
155
• What is a Planning Poker ? 2014, Moutain Goat Software,
http://www.mountaingoatsoftware.com/agile/planning-poker
• Acceptance Tests,
http://www.extremeprogramming.org/rules/functionaltests.html
• Three Main Types of Refactoring, 2012, Peter Kaptein ,
http://patterns.instantinterfaces.nl/current/Refactoring-and-Design-
Patterns-RFCT-ELM-3ELM.html

Pratiques agiles

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Pratiques agiles

Semelhante a Pratiques agiles (20)

Mais de Mohammed Amine Mostefai

Mais de Mohammed Amine Mostefai (20)

Pratiques agiles