SlideShare une entreprise Scribd logo
1  sur  43
Vulgarisation des 
méthodes Agiles 
expérimentées au SED 
de Sophia
PLAN 
Les méthodes agiles et notre contexte 
SCRUM : Les acteurs et entités manipulés 
SCRUM : Le sprint 0 
SCRUM : La planification de sprint 
SCRUM : Les mêlées pour s’adapter 
XP : Les outils d’ingénierie 
SCRUM : La démo et rétrospective de sprint 
Conclusion, ouverture 
Esnault Jerome - INRIA SED DREAM - 2
CLIENT 
BESOINS 
CONTRAT 
REACTIVITE AUX 
Méthodes AGILES 
INTERACTIONS CHANGEMENTS 
LEAN 
KANBAN 
SCRUM XP 
• Amélioration continue 
• Augmenter la productivité 
• Optimiser la qualité 
T 
H 
E 
O 
R 
I 
E 
EQUIPE 
Esnault Jerome - INRIA SED DREAM - 3 
SCIENTIFIQUE 
Les méthodes agiles et notre contexte
Les méthodes agiles et notre contexte 
BESOINS VISIBILITE 
PRODUIT / PROJET 
FEEDBACK 
Valeurs agiles 
Personnes et 
interactions 
Logiciel qui 
fonctionne 
Collaboration 
continue avec le 
client 
Adaptation au 
changement 
http://agilemanifesto.org/ 
T 
H 
E 
O 
R 
I 
E 
RELEASE 
ITERATIONS 
STORIES 
LIVRABLES 
Esnault Jerome - INRIA SED DREAM - 4 
Valeurs 
traditionnelles 
Processus et 
outils 
Documentation 
exhaustive 
Négociation du 
contrat 
Suivi d’un plan 
STORY : Ensemble des tâches permettant de réaliser un cas d’utilisation
Les méthodes agiles et notre contexte 
Et notre point de départ ? 
± 4 projets (isiVR, SOFAVR, MixedReality, VCORE) 
± 3 personnes (mais forte interactions externes) 
1 salle (mais interventions extérieur) 
1 wiki (PmWiki centralise toutes sortes d’infos) 
Forte interaction entre les projets (interdépendances) 
Projets qui n’ont pas la même ampleur : 
(portée réduite à l’équipe  portée européenne) 
Néophyte / «Newbie» SCRUM : 
On apprend l’agilité en même temps qu’on la pratique 
P 
R 
A 
T 
I 
Q 
U 
E 
Esnault Jerome - INRIA SED DREAM - 5
Les méthodes agiles et notre contexte 
Et l’évolution de notre méthode? 
1er étape : issues tracking system avec PmWiki 
P 
R 
A 
T 
I 
Q 
U 
E 
Centralisation √ 
Tracker les issues √ 
Dépendances entre projets ≈ 
Planification X 
Simplicité √ 
Esnault Jerome - INRIA SED DREAM - 6
Les méthodes agiles et notre contexte 
Et l’évolution de notre méthode? 
2ème étape : AgileFant 
P 
R 
A 
T 
I 
Q 
U 
E 
Centralisation √ 
Tracker les issues √ 
Dépendances entre projets √ 
Planification √ 
Simplicité ≈ 
Esnault Jerome - INRIA SED DREAM - 7
P 
R 
A 
T 
I 
Q 
U 
E 
Les méthodes agiles et notre contexte 
Et l’évolution de notre méthode? 
3ème étape : IceScrum + BugZilla 
Centralisation ≈ 
Tracker les issues √ 
Dépendances entre projets √ 
Planification √ 
Simplicité √ 
Esnault Jerome - INRIA SED DREAM - 8
SCRUM : Les acteurs et entités manipulés 
Acteurs Scrum 
CLIENT 
Le SCRUM master 
Equipe multidisciplinaire 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
Responsable 
Scientifique EPI 
Responsable technique 
Esnault Jerome - INRIA SED DREAM - 9 
Le product owner 
P 
R 
A 
T 
I 
Q 
U 
E 
Roulement ? 
Membres de l’EPI
SCRUM : Les acteurs et entités manipulés 
« Entités » manipulées dans SCRUM 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
CLIENT / RESPONSABLE SCIENTIFIQUE 
B 
A 
FEATURE 
C 
K 
L 
O 
G 
S => TACHES 
Esnault Jerome - INRIA SED DREAM - 10 
STORY 
STORY 
STORY 
FEATURE 
STORY 
STORY 
STORY 
EQUIPE DE DEV
PLANNIFICATION 
Thèmes 
Features 
SCRUM : Le sprint 0 
Esnault Jerome - INRIA SED DREAM - 11
SCRUM : Le sprint 0 
REUNION : SPRINT 0 
≈4h 
Story Story Story 
NECESSAIRE Story Story Story Story Release 1 
IMPOR TA N C E 
Thème 1 Thème 2 Thème 3 
Story Story Story 
Story Story 
FEATURES 
FEATURES Release 2 
FEATURES 
Schéma visuel prototypique 
CLIENT 
PRODUCT OWNER 
BUT CLIENT : 
perspectives utilisateurs 
OBJECTIFS EQUIPE : 
Spécifications fonctionnelles 
DOMAINES FONCTIONNELS INDEPENDANTS 
BACKLOG 
PRODUIT 
FEATURES FEATURES Release 3 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
Esnault Jerome - INRIA SED DREAM - 12
SCRUM : Le sprint 0 
REUNION : SPRINT 0 
CLIENT 
PRODUCT OWNER 
BUT CLIENT : 
≈4h 
perspectives utilisateurs 
OBJECTIFS EQUIPE : 
Spécifications fonctionnelles 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
1ère ESTIMATION GLOBALE (JALONNAGE) 
Esnault Jerome - INRIA SED DREAM - 13 
Sprint 1.1 
temps 
Release 1 Release 2 Release 3 
Sprint 
1.N 
Sprint 2.1 
Sprint 
2.N 
Sprint 3.1 
Sprint 
3.N
SCRUM : Le sprint 0 
Et notre sprint 0 ? 
P 
R 
A 
T 
I 
Q 
U 
E 
CE QU’ON A FAIT CONSEQUENCES 
Pas de sprint 0 avec agileFant 
Pas de backlog de départ et 
mauvaise prise en main de 
l’outil 
Sprint « -1 » avec IceScrum 
(démarrage avec un backlog 
produit suffisant pour le 
Esnault Jerome - INRIA SED DREAM - 14 
sprint) 
Première prise en main plus 
accessible et rapide 
(sprint de test) 
Sprint 0 d’une demi journée 
avec une vision sur 5 mois 
(release 1) => définition des 
features + stories associées 
Backlog détaillé et concentré 
sur la release 1. Pas de vision 
sur les releases suivante.
PLANNIFICATION 
Thèmes / EPIC 
Features 
DECOMPOSITION 
Stories 
SCRUM : 
La planification de sprint 
Esnault Jerome - INRIA SED DREAM - 15
SCRUM : La planification de sprint 
REUNION : Planification de sprint 
≈2h 
TRIE BRAINSTORMING CHOISISSENT 
BACKLOG PRODUIT BACKLOG SPRINT N 
TO DO RESERVED DONE 
PRODUCT OWNER 
Sprint N : 
• But + Durée 
• Membre équipe (engagement %) 
• Horaire de mêlée quotidienne 
• Date démo/rétrospective 
• Liste des stories (priorisées/estimées) 
SCRUM MASTER 
EQUIPE DE DEV 
Story 
Story 
Story 
Story 
Story 
Story 
Story 
Story 
Story 
Story 
Story 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
SELECTION 
Esnault Jerome - INRIA SED DREAM - 16
IMPORTANCE : Permet de prioriser (trier) les stories les 
Propriétés 
d’une story 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
unes par rapport aux autres. 
VELOCITE ESTIMEE : 
Temps en points d’histoire, nécessaire à la 
réalisation de la story. 
POKER PLANNING 
Esnault Jerome - INRIA SED DREAM - 17 
PORTEE 
Définit la qualité 
externe attendue 
de cette story. 
SCRUM : La planification de sprint
SCRUM : La planification de sprint 
REUNION : Planification de sprint / Durée 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
Définir la durée du sprint (idéalement 2 à 4 semaines) : 
CLIENT + 
PRODUCT OWNER 
CLIENT + 
Vélocité disponible 
Sprint N 
VELOCITE ESTIMEE 
EQUIPE 
Combien de stories nous pouvons faire avec la 
vélocité de notre sprint ? 
Esnault Jerome - INRIA SED DREAM - 18 
SPRINT N 
= X Résultats 
sprint N-1 
Comment estimer notre vélocité pour ce sprint ? 
PRODUCT OWNER 
EQUIPE 
• Trop court = 
• Trop long =
Sprint 1 (exemple) : 
• 3 personnes à 100% + 1 personne à 50% 
• Durée du sprint de 2 semaines ouvrées 
• Résultats sprint 1-1 …?!... prenons 70% pour commencer 
• Vélocité estimée du sprint : (2 x 5jrs x 3pers + 5jrs x 1 pers) x 70% = 
24 points d’histoire 
Story 1 
7pt 
Story 2 
5pt 
Story 6pt 
Story 4 
6pt 
Et notre planification de sprint ? 
BACKLOG DE FIN DU SPRINT 1 : 
TO DO RESERVED DONE 
P 
R 
A 
T 
I 
Q 
U 
E 
Esnault Jerome - INRIA SED DREAM - 19 
3 
Story 2 
5pt 
Story 4 
6pt 
Story 1 
7pt 
Story 5 
4pt 
Story 3 
6pt 
24 pts à 
utiliser 
12 pts 
réelle 
accomplis 
Résultats: 
50% 
BACKLOG PRODUIT : 
SCRUM : La planification de sprint
P 
R 
A 
T 
I 
Q 
U 
E 
SCRUM : La planification de sprint 
Et notre planification de sprint ? 
CE QU’ON A FAIT CONSEQUENCES 
On rempli le bac à sable d’IceScrum 
en attente de validation 
Pas d’influence, libre à tous et 
accessible tout le temps 
Brainstorming autour d’IceScrum 
(1machine) pour discuter des 
stories à valider dans le backlog 
Esnault Jerome - INRIA SED DREAM - 20 
produit 
Backlog produit cohérent avec la 
vision de l’équipe à l’instant t… 
On met à jour le backlog de sprint 
en fonction de notre but et 
estimation de sprint puis on met à 
jour le tableau physique (post-it) 
…surestimation, pas de discutions 
autour de l’importance, la portée 
(pas de redécoupage), ni 
d’interaction autour du tableau lors 
des mêlées
ADAPTATION 
PLANNIFICATION 
DECOMPOSITION 
Taches 
Esnault Jerome - INRIA SED DREAM - 21 
Thèmes / EPIC 
Features 
Stories 
≈ 15jrs ≈24h 
≈5mois 
releases 
sprints 
mêlées 
SCRUM : 
Les mêlées pour s’adapter
SCRUM : Les mêlées pour s’adapter 
Stand up : Adaptation / Mêlée 
IMPOR TA N C E 
Sérialisations 
Parallélisations 
Story t t 
t 
Story 
t t 
t t 
Story 
Story 
t t 
t t 
t 
Story 
t t 
t t 
t = Taches 
TO DO RESERVED DONE 
≈15 
min 
But : 
… 
INDICATEURS 
Non planifiés : 
… 
Suivant : 
… 
SCRUM MASTER 
Mêlée jour N : 
• Ou en est on ? 
• Gestion du temps : Tâches urgentes/récurrentes 
• Gestion du personnel : Décomposition des 
stories en taches et attribution … 
• Gestion de problèmes (obstacles) : 
stories techniques… 
EQUIPE DE DEV 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
Esnault Jerome - INRIA SED DREAM - 22
P 
R 
A 
T 
I 
Q 
U 
E 
SCRUM : Les mêlées pour s’adapter 
Communication sur les sprints 
100 
50 
0 
Day 
1 
Day 
3 
Day 
5 
Day 
7 
surcharge 
Day 
9 
Day 
11 
Day 
13 
Day 
15 
100 
50 
0 
Day 
1 
Day 
3 
Day 
5 
Day 
7 
Day 
9 
Day 
11 
Day 
13 
Day 
15 
équilibré 
BURN DOWN CHART : Vélocité estimée (pts) 
par rapport à la durée du sprint 
BAC A SABLE 
INFOS 
SPRINT 
-1 
INDICATEURS 
Limiter les obstacles 
Préparer la suite 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
- 23 
Sous estimation 
Esnault Jerome - INRIA SED DREAM 
100 
50 
0 
Day 
1 
Day 
3 
Day 
5 
Day 
7 
Day 
9 
Day 
11 
Day 
13 
Day 
15
ADAPTATION 
PLANNIFICATION 
DECOMPOSITION 
Taches 
Tests 
Esnault Jerome - INRIA SED DREAM - 24 
Thèmes / EPIC 
Features 
Stories 
≈ 15jrs ≈24h 
≈5mois 
releases 
sprints 
mêlées 
XP: 
Les outils d’ingénierie
P 
R 
A 
T 
I 
Q 
U 
E 
XP : Les outils d’ingénierie 
eXtreme Programming : outils 
• Normes de développement 
• Conception simple 
• Programmation en binôme 
• Refactoring 
• Responsabilité collective du code 
• Intégration continue 
• Livraisons fréquentes 
• Planification itérative 
• Tests unitaires 
• Tests de recette 
• Documentation 
 Coding rules dispo sur notre WIKI 
 Design pattern (BOUML, Yuml pour WIKI) 
 Implication des débutants, revues de code 
 SCM GIT avec workflow 
 BugZilla 
 Jenkins et CMake 
 Demos, packaging avec CPack 
 IceScrum 
 TODO : CTest ? 
 Tests d’acceptations 
 Doxygen 
T 
H 
E 
O 
R 
I 
E 
X 
P 
Esnault Jerome - INRIA SED DREAM - 25
XP : Les outils d’ingénierie 
Pratiques eXtrem Programming : nos outils 
Dépôts SCM 
GIT / SVN 
PmWiki 
Jabber 
Chat 
API Doc 
HowTo Doc 
Continuous build 
From #id-Bug msg commit 
See sofa model : 
http://www.sofa-framework.org/SOFA%20day%20-%20Dec%202011%20-%20software%20engineering.pdf 
P 
R 
A 
T 
I 
Q 
U 
E 
Esnault Jerome - INRIA SED DREAM - 26 
Doxygen 
Jenkins Status build 
Mailling 
Planifications 
Features / stories 
Mailling 
IceScrum 
BugTracker 
Features request 
Mailling 
BugZilla 
? 
CMake / QMake
PLANNIFICATION 
DECOMPOSITION 
≈ 15jrs 
DEMO 
RETROSPECTIVE 
ADAPTATION 
mêlées ≈24h 
releases 
sprints 
≈5mois 
Esnault Jerome - INRIA SED DREAM - 27 
Thèmes / EPIC 
Features 
Stories Taches 
Tests
SCRUM : La démo et rétrospective de sprint 
REUNION : Démo / rétrospective 
PRODUCT OWNER 
Démo / Rétrospective sprint N : 
≈1h 
• Invitation libre à une demo du livrable obtenu 
par le sprint (scénario utilisateur simple) 
• Comment c’était? 
• Ou on en est (point de vue release) ? 
• Améliorations par rapport au sprint - 1 ? 
• Analyse des indicateurs : identification des 
freins, report de stories non finies 
• Analyse des activités non prévus (finis ou 
non) : modification du backlog ? 
• Points à améliorer au prochain sprint 
SCRUM MASTER 
EQUIPE DE DEV 
INVITES 
RETOUR CLIENT SUR LE LIVRABLE (affinage de la vision du projet) 
La boucle est bouclée 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
Esnault Jerome - INRIA SED DREAM - 28
ADAPTATION 
releases 
PLANNIFICATION 
DECOMPOSITION 
sprints 
mêlées 
≈ 15jrs 
DEMO 
RETROSPECTIVE 
≈24h 
≈5mois 
Esnault Jerome - INRIA SED DREAM - 29 
Thèmes / EPIC 
Features 
Stories Taches 
Tests
P 
R 
A 
T 
I 
Q 
U 
E 
Conclusion 
Notre contexte : 
• Plus de projets que de personnel expérimentant l’agilité 
• Disponibilité et niveau d’engagement sur les projets très variables 
• Projets de différentes ampleurs (collaborations internes/externes) et interdépendants 
C’est notre besoin qui formate l’outils et pas l’outils qui formate notre besoin ! 
L’évolution de notre méthode et de nos outils : 
• Expérimentation « stricte » de SCRUM (méthode et outils) et couplage à des outils XP 
• Pour notre contexte : 
BESOIN D’ADAPTER NOTRE MANIERE DE TRAVAILLER 
MOINS NORMATIVE ET PLUS AAPTATIVE 
• Pas de rôles bien définis 
• Tableau physique peu utilisé 
• Capacité pas encore stabilisée 
• Pas de démos (que lorsque nécessaire) 
• Rétrospectives ne sont pas encore prises en compte dans les sprints suivants 
• Pas de lien entre notre outil de gestion de bug et notre outil de planification 
Il n’existe pas une unique bonne manière de travailler, 
il faut expérimenter en fonction du contexte 
Esnault Jerome - INRIA SED DREAM - 30
Réflexion autour du stress 
Définition : 
Ensemble des réactions non spécifiques d'un organisme, 
biologiques ou psychologiques, lorsque cet organisme est soumis 
à un nouveau stimulus. [granddictionnaire.com] 
Performance 
Stress optimal = challenge 
Stress positif Stress négatif 
Niveau de stress 
- 31 
Esnault Jerome - INRIA SED DREAM
Références 
• pdf: SCRUM depuis les tranchées - Henrik Kniberg traduit par Claude Aubry 
• ppt: Agile tour Toulouse 2011 : Agilité à grande échelle – Claude Aubry 
• ppt: Agile tour Lille 2011 : L’agilité situationnelle – Claude Aubry 
• pdf: KANBAN & SCRUM tirer le meilleur des deux – Henrik Kniberg, Mattias Skarin et traduit 
par Claude Aubry, Antoine Vernois, Fabrice Aimetti 
• pdf: Lean depuis les tranchées – Henrik Kniberg et traduit par Claude Aubry, Sylvain Fraissé, 
Nicolas Mereaux, Antoine Vernois et Fabrice Aimetti 
• book: SCRUM le guide pratique de la méthode agile la plus populaire – Claude Aubry 
• blog : www.openagile.net 
• bolg : bootstrapping an agile project in the cloud 
• site : www.IceScrum.org 
• site : www.aubryconseil.com 
• site : www.qualitystreet.fr 
• site : http://referentiel.institut-agile.fr/kanban.html 
• pdf : 10 kanban boards and their context 
• ppt : Management 3.0 : Leading Agile Developers, developing Agile Leaders – Jurgen Appelo 
• book: Management de Projet fondamentaux, méthodes, outils – Jean-Claude Corbel 
Esnault Jerome - INRIA SED DREAM - 32
MERCI
Méthodes traditionnelles 
Analyse / Etude 
Codage 
Recette 
Spécification 
Conception Test 
Validation 
Ces phases ne s’enchainent pas vraiment séquentiellement (sans réel retour) 
Portées et délais fixes pour chaque phase (généralement non respectées) 
Pas de critère de complétion des phases (deadLine = finie) 
Non implication du client dans le projet 
Mécontentement généralisé 
T 
H 
E 
O 
R 
I 
E 
Esnault Jerome - INRIA SED DREAM - 35
• Optimiser la qualité ? 
« Un produit ou service de qualité est un produit dont les 
caractéristiques lui permettent de satisfaire les besoins exprimés 
ou implicites des consommateurs". 
l’AFNOR (Association Française de NORmalisation) 
Affinage régulier de la « zone de satisfaction du client » 
et de la direction de l’équipe 
N critères de satisfaction client = univers du projet à N dimensions 
objectif fixe 
T 
H 
E 
O 
R 
I 
E 
délais 
Esnault Jerome - INRIA SED DREAM - 36 
perf 
coût 
t0 
t1
“Une méthode agile est une approche itérative et incrémentale, 
qui est menée dans un esprit collaboratif avec juste ce qu’il faut 
de formalisme. Elle génère un produit de haute qualité tout en 
prenant en compte l’évolution des besoins des clients” 
Veronique Messager Rota - Gestion de projet : Vers les méthodes agiles 
Valeurs 
traditionnelles 
Processus et 
outils 
Documentation 
exhaustive 
Négociation du 
contrat 
Suivi d’un plan 
BESOINS VISIBILITE 
FEEDBACK 
Valeurs agiles 
Personnes et 
interactions 
Logiciel qui 
fonctionne 
Collaboration 
continue avec le 
client 
Adaptation au 
changement 
http://agilemanifesto.org/ 
T 
H 
E 
O 
R 
I 
E 
PRODUIT / PROJET 
RELEASE 
ITERATIONS 
STORIES 
LIVRABLES 
Esnault Jerome - INRIA SED DREAM - 37
« Entités » manipulées dans SCRUM 
client 
équipe 
finies dans une release 
FEATURES 
STORIES 
TASKS 
finies dans un sprint 
Product Backlog : 
Detailed 
Estimated 
Evolutionary 
Prioritized 
User Story (objectif du client) / Technical Story (objectifs de l’équipe) : 
En tant que « Utilisateur », je veux « fonction », dans le but de 
Sprint Backlog : 
Splitted stories 
Health indicators 
S TOR I E S 
Obstacles gestion 
Regular revieview 
Testable tasks 
« résultat attendu ». 
T 
H 
E 
O 
R 
I 
E 
S 
C 
R 
U 
M 
• Le backlog produit contient tous les éléments (définies ou à 
venir) du projet . 
• Chaque backlog de sprint contient toutes les stories 
(sélectionnées depuis le backlog produit) à finir dans un sprint. 
Esnault Jerome - INRIA SED DREAM - 38
Agile et outsourcing 
Logiciel de méthodes agiles via plateforme internet (iceScrum-AgileFant) 
Efficacité de la communication 
Conversation face à face avec 
support (tableau) + cafè? 
Visio conférence Conversation face à face 
Echange de mails Chat écrit 
Papier 
Enregistrement video 
Documentation 
en ligne 
Enregistrement 
audio 
Chat audio 
Richesse de la communication 
static dynamique 
Risques : 
• meeting plus long et moins interactif 
• barrière de la culture et de la langue 
T 
H 
E 
O 
R 
I 
E 
Esnault Jerome - INRIA SED DREAM - 39
Conclusion 
cela permet d'éviter 
« l'effet tunnel » 
Les points positifs : 
• Méthode à flux tirés et non poussés 
• Méthode itérative et incrémentielle 
• Méthode participative et adaptative (flexible) 
T • Communication et coopération efficace et riche 
H 
E 
Les risques : 
• Si taille de l'équipe > 10 et dispatchée 
O 
R 
I 
E 
=> organisation difficile (cohésion de groupe, qualité de comm…) ? 
=> besoin de décomposer en scrum de scrum (équipes de 7-10 max) 
• Réticence à l’évolutivité, réactions aux changements (Procrastination) 
=> appréhension à faire évoluer (refactoring) un code qui marche déjà 
=> besoin d’outils XP (coding rules, SCM, intégration continue, tests…) 
• Le turnover 
=> impact directement la capacité / stabilité de l’équipe 
Esnault Jerome - INRIA SED DREAM - 40
Nos ouvertures : KANBAN 
Passage à une méthode moins normative et plus adaptative : KANBAN 
• Ne pas imposer de rôle précis ni de livrable quotidien, planifier le TAF (Travail A Faire) 
au fur et à mesure et ne livrer que lorsque c’est demandé. 
• Utiliser un tableau KANBAN pour toute la durée du projet plutôt que d’avoir un tableau 
de sprint par itération. 
=> impliquerait d’avoir un découpage régulier ( ± même taille) des éléments à faire. 
• Limiter le TAF (Travail A Faire) de chaque étape du workflow plutôt que de chaque 
itération permettra d’identifier plus rapidement les goulets d’étranglements et de réagir 
plus vite. 
• Autoriser les changements au court d’une itération (en respectant la règle ci-dessus) 
plutôt que d’essayer de fixer une itération (avec des stories non modifiables). 
• Utiliser le burndown chart le temps d’un jalon/release plutôt que pour une itération 
ET / OU le diagramme de flux cumulés (pour modifier les capacités). 
Continuer d’adapter, d’expérimenter et de faire évoluer vers notre propre méthode ! 
Esnault Jerome - INRIA SED DREAM - 41 
T 
H 
E 
O 
R 
I 
E 
K 
A 
N 
B 
A 
N
KANBAN : exemple 
Exemple de diagramme de flux cumulé 
Backlog Dev Test/Déploiement Prod 
Capacité 
moyenne : 
1 item/jour 
6 jours dont 3 en test 
Esnault Jerome - INRIA SED DREAM - 42 
T 
H 
E 
O 
R 
I 
E 
K 
A 
N 
B 
A 
N 
30 
25 
20 
15 
10 
5 
0 
9 items 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
Nombre 
d’items (TAF) 
Jours 
Objectif : 
Lisser le flux et limiter le travail à la capacité « disponible » : 
minimiser le nombre d’éléments séjournant dans les files.
Limiter la phase de TEST/DEPLOIEMENT à 2 éléments : 
BACKLOG RESERVED TEST/DEP 
A 
Esnault Jerome - INRIA SED DREAM - 43 
T 
H 
E 
O 
R 
I 
E 
K 
A 
N 
B 
A 
N 
DEV 
WIP DONE 
PROD 
C B 
D 
E 
F 
H 
3 4 
L M 
N 
O P 
I dépend de G 
et 
On a besoin de 
J et K 
J 
E et F sont 
terminés, 
on prend G 
C ne compile 
pas et D 
dépend de C, 
on est bloqué 
2 
H est terminé, on ne 
peut pas commencer 
un autre item 
(limite à 4) 
On vient en 
renfort ! 
I 
Protection 
contre les 
perturbations 
K 
G

Contenu connexe

Tendances

Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrumPierre E. NEIS
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsPierre E. NEIS
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPNicolas Perriault
 
Introduction à Scrum Par La Pratique
Introduction à Scrum Par La PratiqueIntroduction à Scrum Par La Pratique
Introduction à Scrum Par La PratiqueFou Cha
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: ScrumChaymaMghazli
 
Guide des bonnes pratiques de la méthode Scrum – AT Internet
Guide des bonnes pratiques de la méthode Scrum – AT Internet Guide des bonnes pratiques de la méthode Scrum – AT Internet
Guide des bonnes pratiques de la méthode Scrum – AT Internet AT Internet
 
Présentation des principes Scrum
Présentation des principes ScrumPrésentation des principes Scrum
Présentation des principes Scrummsmpp-nantes
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Blackbird
 
Formation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product OwnerFormation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product OwnerNovUp
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionTremeur Balbous
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slidesNicolas Deverge
 

Tendances (20)

Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrum
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
Introduction à Scrum Par La Pratique
Introduction à Scrum Par La PratiqueIntroduction à Scrum Par La Pratique
Introduction à Scrum Par La Pratique
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 
Scrum
ScrumScrum
Scrum
 
Guide des bonnes pratiques de la méthode Scrum – AT Internet
Guide des bonnes pratiques de la méthode Scrum – AT Internet Guide des bonnes pratiques de la méthode Scrum – AT Internet
Guide des bonnes pratiques de la méthode Scrum – AT Internet
 
Présentation des principes Scrum
Présentation des principes ScrumPrésentation des principes Scrum
Présentation des principes Scrum
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Scrum xp
Scrum xpScrum xp
Scrum xp
 
Formation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product OwnerFormation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product Owner
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
Guide scrum
Guide scrumGuide scrum
Guide scrum
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 

Similaire à DevExp 2012 methodes agiles SCRUM jesnault

Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012agnes_crepet
 
Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]almerys
 
Betaleadership - ima digitalday - Digitalisation et méthodes collaboratives
Betaleadership - ima digitalday - Digitalisation et méthodes collaborativesBetaleadership - ima digitalday - Digitalisation et méthodes collaboratives
Betaleadership - ima digitalday - Digitalisation et méthodes collaborativesSylvain Loubradou
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011Christophe NEY
 
Team Backlogs & Priorisation MOSCOW
Team Backlogs & Priorisation MOSCOWTeam Backlogs & Priorisation MOSCOW
Team Backlogs & Priorisation MOSCOWPierre E. NEIS
 
Présentation projetcqp dnt2013-k
Présentation projetcqp dnt2013-kPrésentation projetcqp dnt2013-k
Présentation projetcqp dnt2013-kMarc Cotté
 
Smartview - Construire et piloter votre roadmap produits
Smartview - Construire et piloter votre roadmap produitsSmartview - Construire et piloter votre roadmap produits
Smartview - Construire et piloter votre roadmap produitsYassine Zakaria
 
Web-conference | DDMRP et flux tirés
Web-conference | DDMRP et flux tirésWeb-conference | DDMRP et flux tirés
Web-conference | DDMRP et flux tirésXL Groupe
 
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)Couthaïer FARFRA
 
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013Artusamak
 
La programmation par contraintes avec Choco3 (Java)
La programmation par contraintes avec Choco3 (Java)La programmation par contraintes avec Choco3 (Java)
La programmation par contraintes avec Choco3 (Java)Aline Figoureux
 
Jeu gestion de projets distanciel
Jeu gestion de projets distancielJeu gestion de projets distanciel
Jeu gestion de projets distancielNadia Gharbi
 
Les Outils de l'Agile
Les Outils de l'AgileLes Outils de l'Agile
Les Outils de l'Agilearagot1
 
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Oeil de Coach
 
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...Association Agile Nantes
 
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBan
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBanFKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBan
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBanFrench Kanban User Group
 

Similaire à DevExp 2012 methodes agiles SCRUM jesnault (20)

Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012
 
Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]Retour Experience Atchik Sigma T9 200903[1]
Retour Experience Atchik Sigma T9 200903[1]
 
Betaleadership - ima digitalday - Digitalisation et méthodes collaboratives
Betaleadership - ima digitalday - Digitalisation et méthodes collaborativesBetaleadership - ima digitalday - Digitalisation et méthodes collaboratives
Betaleadership - ima digitalday - Digitalisation et méthodes collaboratives
 
SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011SCRUM et KANBAN - Agile Grenoble 2011
SCRUM et KANBAN - Agile Grenoble 2011
 
Team Backlogs & Priorisation MOSCOW
Team Backlogs & Priorisation MOSCOWTeam Backlogs & Priorisation MOSCOW
Team Backlogs & Priorisation MOSCOW
 
Présentation projetcqp dnt2013-k
Présentation projetcqp dnt2013-kPrésentation projetcqp dnt2013-k
Présentation projetcqp dnt2013-k
 
Smartview - Construire et piloter votre roadmap produits
Smartview - Construire et piloter votre roadmap produitsSmartview - Construire et piloter votre roadmap produits
Smartview - Construire et piloter votre roadmap produits
 
PresentationMéthodologie SCRUM-2021.pptx
PresentationMéthodologie SCRUM-2021.pptxPresentationMéthodologie SCRUM-2021.pptx
PresentationMéthodologie SCRUM-2021.pptx
 
Web-conference | DDMRP et flux tirés
Web-conference | DDMRP et flux tirésWeb-conference | DDMRP et flux tirés
Web-conference | DDMRP et flux tirés
 
Agile
AgileAgile
Agile
 
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
REX Kanban dans plusieurs contextes, par Couthaïer Farfra (Agile4Me)
 
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013Drupal, scrum et l'agilité - Drupalcamp Paris 2013
Drupal, scrum et l'agilité - Drupalcamp Paris 2013
 
Introduction à Agile Lean
Introduction à Agile LeanIntroduction à Agile Lean
Introduction à Agile Lean
 
La programmation par contraintes avec Choco3 (Java)
La programmation par contraintes avec Choco3 (Java)La programmation par contraintes avec Choco3 (Java)
La programmation par contraintes avec Choco3 (Java)
 
Jeu gestion de projets distanciel
Jeu gestion de projets distancielJeu gestion de projets distanciel
Jeu gestion de projets distanciel
 
Les Outils de l'Agile
Les Outils de l'AgileLes Outils de l'Agile
Les Outils de l'Agile
 
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
 
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...
Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilit...
 
At nancy10 scrumv2.0
At nancy10 scrumv2.0At nancy10 scrumv2.0
At nancy10 scrumv2.0
 
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBan
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBanFKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBan
FKUG - Meetup du 12 mai 2015 : REX projet pilote ScrumBan
 

Dernier

BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLidelewebmestre
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en Franceidelewebmestre
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvreidelewebmestre
 
BOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairBOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairidelewebmestre
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinidelewebmestre
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcsidelewebmestre
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...idelewebmestre
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsidelewebmestre
 
Cours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesCours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesPierreFournier32
 
BOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsBOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsidelewebmestre
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineidelewebmestre
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresidelewebmestre
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...idelewebmestre
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airidelewebmestre
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresidelewebmestre
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresidelewebmestre
 
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...idelewebmestre
 
anas transcript 111111111111111111111111
anas transcript 111111111111111111111111anas transcript 111111111111111111111111
anas transcript 111111111111111111111111zaidtaim1214
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...idelewebmestre
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasidelewebmestre
 

Dernier (20)

BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en France
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
 
BOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairBOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chair
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcin
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
 
Cours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesCours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pages
 
BOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsBOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminants
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitières
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein air
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
 
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
 
anas transcript 111111111111111111111111
anas transcript 111111111111111111111111anas transcript 111111111111111111111111
anas transcript 111111111111111111111111
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
 

DevExp 2012 methodes agiles SCRUM jesnault

  • 1. Vulgarisation des méthodes Agiles expérimentées au SED de Sophia
  • 2. PLAN Les méthodes agiles et notre contexte SCRUM : Les acteurs et entités manipulés SCRUM : Le sprint 0 SCRUM : La planification de sprint SCRUM : Les mêlées pour s’adapter XP : Les outils d’ingénierie SCRUM : La démo et rétrospective de sprint Conclusion, ouverture Esnault Jerome - INRIA SED DREAM - 2
  • 3. CLIENT BESOINS CONTRAT REACTIVITE AUX Méthodes AGILES INTERACTIONS CHANGEMENTS LEAN KANBAN SCRUM XP • Amélioration continue • Augmenter la productivité • Optimiser la qualité T H E O R I E EQUIPE Esnault Jerome - INRIA SED DREAM - 3 SCIENTIFIQUE Les méthodes agiles et notre contexte
  • 4. Les méthodes agiles et notre contexte BESOINS VISIBILITE PRODUIT / PROJET FEEDBACK Valeurs agiles Personnes et interactions Logiciel qui fonctionne Collaboration continue avec le client Adaptation au changement http://agilemanifesto.org/ T H E O R I E RELEASE ITERATIONS STORIES LIVRABLES Esnault Jerome - INRIA SED DREAM - 4 Valeurs traditionnelles Processus et outils Documentation exhaustive Négociation du contrat Suivi d’un plan STORY : Ensemble des tâches permettant de réaliser un cas d’utilisation
  • 5. Les méthodes agiles et notre contexte Et notre point de départ ? ± 4 projets (isiVR, SOFAVR, MixedReality, VCORE) ± 3 personnes (mais forte interactions externes) 1 salle (mais interventions extérieur) 1 wiki (PmWiki centralise toutes sortes d’infos) Forte interaction entre les projets (interdépendances) Projets qui n’ont pas la même ampleur : (portée réduite à l’équipe  portée européenne) Néophyte / «Newbie» SCRUM : On apprend l’agilité en même temps qu’on la pratique P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 5
  • 6. Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 1er étape : issues tracking system avec PmWiki P R A T I Q U E Centralisation √ Tracker les issues √ Dépendances entre projets ≈ Planification X Simplicité √ Esnault Jerome - INRIA SED DREAM - 6
  • 7. Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 2ème étape : AgileFant P R A T I Q U E Centralisation √ Tracker les issues √ Dépendances entre projets √ Planification √ Simplicité ≈ Esnault Jerome - INRIA SED DREAM - 7
  • 8. P R A T I Q U E Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 3ème étape : IceScrum + BugZilla Centralisation ≈ Tracker les issues √ Dépendances entre projets √ Planification √ Simplicité √ Esnault Jerome - INRIA SED DREAM - 8
  • 9. SCRUM : Les acteurs et entités manipulés Acteurs Scrum CLIENT Le SCRUM master Equipe multidisciplinaire T H E O R I E S C R U M Responsable Scientifique EPI Responsable technique Esnault Jerome - INRIA SED DREAM - 9 Le product owner P R A T I Q U E Roulement ? Membres de l’EPI
  • 10. SCRUM : Les acteurs et entités manipulés « Entités » manipulées dans SCRUM T H E O R I E S C R U M CLIENT / RESPONSABLE SCIENTIFIQUE B A FEATURE C K L O G S => TACHES Esnault Jerome - INRIA SED DREAM - 10 STORY STORY STORY FEATURE STORY STORY STORY EQUIPE DE DEV
  • 11. PLANNIFICATION Thèmes Features SCRUM : Le sprint 0 Esnault Jerome - INRIA SED DREAM - 11
  • 12. SCRUM : Le sprint 0 REUNION : SPRINT 0 ≈4h Story Story Story NECESSAIRE Story Story Story Story Release 1 IMPOR TA N C E Thème 1 Thème 2 Thème 3 Story Story Story Story Story FEATURES FEATURES Release 2 FEATURES Schéma visuel prototypique CLIENT PRODUCT OWNER BUT CLIENT : perspectives utilisateurs OBJECTIFS EQUIPE : Spécifications fonctionnelles DOMAINES FONCTIONNELS INDEPENDANTS BACKLOG PRODUIT FEATURES FEATURES Release 3 T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 12
  • 13. SCRUM : Le sprint 0 REUNION : SPRINT 0 CLIENT PRODUCT OWNER BUT CLIENT : ≈4h perspectives utilisateurs OBJECTIFS EQUIPE : Spécifications fonctionnelles T H E O R I E S C R U M 1ère ESTIMATION GLOBALE (JALONNAGE) Esnault Jerome - INRIA SED DREAM - 13 Sprint 1.1 temps Release 1 Release 2 Release 3 Sprint 1.N Sprint 2.1 Sprint 2.N Sprint 3.1 Sprint 3.N
  • 14. SCRUM : Le sprint 0 Et notre sprint 0 ? P R A T I Q U E CE QU’ON A FAIT CONSEQUENCES Pas de sprint 0 avec agileFant Pas de backlog de départ et mauvaise prise en main de l’outil Sprint « -1 » avec IceScrum (démarrage avec un backlog produit suffisant pour le Esnault Jerome - INRIA SED DREAM - 14 sprint) Première prise en main plus accessible et rapide (sprint de test) Sprint 0 d’une demi journée avec une vision sur 5 mois (release 1) => définition des features + stories associées Backlog détaillé et concentré sur la release 1. Pas de vision sur les releases suivante.
  • 15. PLANNIFICATION Thèmes / EPIC Features DECOMPOSITION Stories SCRUM : La planification de sprint Esnault Jerome - INRIA SED DREAM - 15
  • 16. SCRUM : La planification de sprint REUNION : Planification de sprint ≈2h TRIE BRAINSTORMING CHOISISSENT BACKLOG PRODUIT BACKLOG SPRINT N TO DO RESERVED DONE PRODUCT OWNER Sprint N : • But + Durée • Membre équipe (engagement %) • Horaire de mêlée quotidienne • Date démo/rétrospective • Liste des stories (priorisées/estimées) SCRUM MASTER EQUIPE DE DEV Story Story Story Story Story Story Story Story Story Story Story T H E O R I E S C R U M SELECTION Esnault Jerome - INRIA SED DREAM - 16
  • 17. IMPORTANCE : Permet de prioriser (trier) les stories les Propriétés d’une story T H E O R I E S C R U M unes par rapport aux autres. VELOCITE ESTIMEE : Temps en points d’histoire, nécessaire à la réalisation de la story. POKER PLANNING Esnault Jerome - INRIA SED DREAM - 17 PORTEE Définit la qualité externe attendue de cette story. SCRUM : La planification de sprint
  • 18. SCRUM : La planification de sprint REUNION : Planification de sprint / Durée T H E O R I E S C R U M Définir la durée du sprint (idéalement 2 à 4 semaines) : CLIENT + PRODUCT OWNER CLIENT + Vélocité disponible Sprint N VELOCITE ESTIMEE EQUIPE Combien de stories nous pouvons faire avec la vélocité de notre sprint ? Esnault Jerome - INRIA SED DREAM - 18 SPRINT N = X Résultats sprint N-1 Comment estimer notre vélocité pour ce sprint ? PRODUCT OWNER EQUIPE • Trop court = • Trop long =
  • 19. Sprint 1 (exemple) : • 3 personnes à 100% + 1 personne à 50% • Durée du sprint de 2 semaines ouvrées • Résultats sprint 1-1 …?!... prenons 70% pour commencer • Vélocité estimée du sprint : (2 x 5jrs x 3pers + 5jrs x 1 pers) x 70% = 24 points d’histoire Story 1 7pt Story 2 5pt Story 6pt Story 4 6pt Et notre planification de sprint ? BACKLOG DE FIN DU SPRINT 1 : TO DO RESERVED DONE P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 19 3 Story 2 5pt Story 4 6pt Story 1 7pt Story 5 4pt Story 3 6pt 24 pts à utiliser 12 pts réelle accomplis Résultats: 50% BACKLOG PRODUIT : SCRUM : La planification de sprint
  • 20. P R A T I Q U E SCRUM : La planification de sprint Et notre planification de sprint ? CE QU’ON A FAIT CONSEQUENCES On rempli le bac à sable d’IceScrum en attente de validation Pas d’influence, libre à tous et accessible tout le temps Brainstorming autour d’IceScrum (1machine) pour discuter des stories à valider dans le backlog Esnault Jerome - INRIA SED DREAM - 20 produit Backlog produit cohérent avec la vision de l’équipe à l’instant t… On met à jour le backlog de sprint en fonction de notre but et estimation de sprint puis on met à jour le tableau physique (post-it) …surestimation, pas de discutions autour de l’importance, la portée (pas de redécoupage), ni d’interaction autour du tableau lors des mêlées
  • 21. ADAPTATION PLANNIFICATION DECOMPOSITION Taches Esnault Jerome - INRIA SED DREAM - 21 Thèmes / EPIC Features Stories ≈ 15jrs ≈24h ≈5mois releases sprints mêlées SCRUM : Les mêlées pour s’adapter
  • 22. SCRUM : Les mêlées pour s’adapter Stand up : Adaptation / Mêlée IMPOR TA N C E Sérialisations Parallélisations Story t t t Story t t t t Story Story t t t t t Story t t t t t = Taches TO DO RESERVED DONE ≈15 min But : … INDICATEURS Non planifiés : … Suivant : … SCRUM MASTER Mêlée jour N : • Ou en est on ? • Gestion du temps : Tâches urgentes/récurrentes • Gestion du personnel : Décomposition des stories en taches et attribution … • Gestion de problèmes (obstacles) : stories techniques… EQUIPE DE DEV T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 22
  • 23. P R A T I Q U E SCRUM : Les mêlées pour s’adapter Communication sur les sprints 100 50 0 Day 1 Day 3 Day 5 Day 7 surcharge Day 9 Day 11 Day 13 Day 15 100 50 0 Day 1 Day 3 Day 5 Day 7 Day 9 Day 11 Day 13 Day 15 équilibré BURN DOWN CHART : Vélocité estimée (pts) par rapport à la durée du sprint BAC A SABLE INFOS SPRINT -1 INDICATEURS Limiter les obstacles Préparer la suite T H E O R I E S C R U M - 23 Sous estimation Esnault Jerome - INRIA SED DREAM 100 50 0 Day 1 Day 3 Day 5 Day 7 Day 9 Day 11 Day 13 Day 15
  • 24. ADAPTATION PLANNIFICATION DECOMPOSITION Taches Tests Esnault Jerome - INRIA SED DREAM - 24 Thèmes / EPIC Features Stories ≈ 15jrs ≈24h ≈5mois releases sprints mêlées XP: Les outils d’ingénierie
  • 25. P R A T I Q U E XP : Les outils d’ingénierie eXtreme Programming : outils • Normes de développement • Conception simple • Programmation en binôme • Refactoring • Responsabilité collective du code • Intégration continue • Livraisons fréquentes • Planification itérative • Tests unitaires • Tests de recette • Documentation  Coding rules dispo sur notre WIKI  Design pattern (BOUML, Yuml pour WIKI)  Implication des débutants, revues de code  SCM GIT avec workflow  BugZilla  Jenkins et CMake  Demos, packaging avec CPack  IceScrum  TODO : CTest ?  Tests d’acceptations  Doxygen T H E O R I E X P Esnault Jerome - INRIA SED DREAM - 25
  • 26. XP : Les outils d’ingénierie Pratiques eXtrem Programming : nos outils Dépôts SCM GIT / SVN PmWiki Jabber Chat API Doc HowTo Doc Continuous build From #id-Bug msg commit See sofa model : http://www.sofa-framework.org/SOFA%20day%20-%20Dec%202011%20-%20software%20engineering.pdf P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 26 Doxygen Jenkins Status build Mailling Planifications Features / stories Mailling IceScrum BugTracker Features request Mailling BugZilla ? CMake / QMake
  • 27. PLANNIFICATION DECOMPOSITION ≈ 15jrs DEMO RETROSPECTIVE ADAPTATION mêlées ≈24h releases sprints ≈5mois Esnault Jerome - INRIA SED DREAM - 27 Thèmes / EPIC Features Stories Taches Tests
  • 28. SCRUM : La démo et rétrospective de sprint REUNION : Démo / rétrospective PRODUCT OWNER Démo / Rétrospective sprint N : ≈1h • Invitation libre à une demo du livrable obtenu par le sprint (scénario utilisateur simple) • Comment c’était? • Ou on en est (point de vue release) ? • Améliorations par rapport au sprint - 1 ? • Analyse des indicateurs : identification des freins, report de stories non finies • Analyse des activités non prévus (finis ou non) : modification du backlog ? • Points à améliorer au prochain sprint SCRUM MASTER EQUIPE DE DEV INVITES RETOUR CLIENT SUR LE LIVRABLE (affinage de la vision du projet) La boucle est bouclée T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 28
  • 29. ADAPTATION releases PLANNIFICATION DECOMPOSITION sprints mêlées ≈ 15jrs DEMO RETROSPECTIVE ≈24h ≈5mois Esnault Jerome - INRIA SED DREAM - 29 Thèmes / EPIC Features Stories Taches Tests
  • 30. P R A T I Q U E Conclusion Notre contexte : • Plus de projets que de personnel expérimentant l’agilité • Disponibilité et niveau d’engagement sur les projets très variables • Projets de différentes ampleurs (collaborations internes/externes) et interdépendants C’est notre besoin qui formate l’outils et pas l’outils qui formate notre besoin ! L’évolution de notre méthode et de nos outils : • Expérimentation « stricte » de SCRUM (méthode et outils) et couplage à des outils XP • Pour notre contexte : BESOIN D’ADAPTER NOTRE MANIERE DE TRAVAILLER MOINS NORMATIVE ET PLUS AAPTATIVE • Pas de rôles bien définis • Tableau physique peu utilisé • Capacité pas encore stabilisée • Pas de démos (que lorsque nécessaire) • Rétrospectives ne sont pas encore prises en compte dans les sprints suivants • Pas de lien entre notre outil de gestion de bug et notre outil de planification Il n’existe pas une unique bonne manière de travailler, il faut expérimenter en fonction du contexte Esnault Jerome - INRIA SED DREAM - 30
  • 31. Réflexion autour du stress Définition : Ensemble des réactions non spécifiques d'un organisme, biologiques ou psychologiques, lorsque cet organisme est soumis à un nouveau stimulus. [granddictionnaire.com] Performance Stress optimal = challenge Stress positif Stress négatif Niveau de stress - 31 Esnault Jerome - INRIA SED DREAM
  • 32. Références • pdf: SCRUM depuis les tranchées - Henrik Kniberg traduit par Claude Aubry • ppt: Agile tour Toulouse 2011 : Agilité à grande échelle – Claude Aubry • ppt: Agile tour Lille 2011 : L’agilité situationnelle – Claude Aubry • pdf: KANBAN & SCRUM tirer le meilleur des deux – Henrik Kniberg, Mattias Skarin et traduit par Claude Aubry, Antoine Vernois, Fabrice Aimetti • pdf: Lean depuis les tranchées – Henrik Kniberg et traduit par Claude Aubry, Sylvain Fraissé, Nicolas Mereaux, Antoine Vernois et Fabrice Aimetti • book: SCRUM le guide pratique de la méthode agile la plus populaire – Claude Aubry • blog : www.openagile.net • bolg : bootstrapping an agile project in the cloud • site : www.IceScrum.org • site : www.aubryconseil.com • site : www.qualitystreet.fr • site : http://referentiel.institut-agile.fr/kanban.html • pdf : 10 kanban boards and their context • ppt : Management 3.0 : Leading Agile Developers, developing Agile Leaders – Jurgen Appelo • book: Management de Projet fondamentaux, méthodes, outils – Jean-Claude Corbel Esnault Jerome - INRIA SED DREAM - 32
  • 33. MERCI
  • 34.
  • 35. Méthodes traditionnelles Analyse / Etude Codage Recette Spécification Conception Test Validation Ces phases ne s’enchainent pas vraiment séquentiellement (sans réel retour) Portées et délais fixes pour chaque phase (généralement non respectées) Pas de critère de complétion des phases (deadLine = finie) Non implication du client dans le projet Mécontentement généralisé T H E O R I E Esnault Jerome - INRIA SED DREAM - 35
  • 36. • Optimiser la qualité ? « Un produit ou service de qualité est un produit dont les caractéristiques lui permettent de satisfaire les besoins exprimés ou implicites des consommateurs". l’AFNOR (Association Française de NORmalisation) Affinage régulier de la « zone de satisfaction du client » et de la direction de l’équipe N critères de satisfaction client = univers du projet à N dimensions objectif fixe T H E O R I E délais Esnault Jerome - INRIA SED DREAM - 36 perf coût t0 t1
  • 37. “Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients” Veronique Messager Rota - Gestion de projet : Vers les méthodes agiles Valeurs traditionnelles Processus et outils Documentation exhaustive Négociation du contrat Suivi d’un plan BESOINS VISIBILITE FEEDBACK Valeurs agiles Personnes et interactions Logiciel qui fonctionne Collaboration continue avec le client Adaptation au changement http://agilemanifesto.org/ T H E O R I E PRODUIT / PROJET RELEASE ITERATIONS STORIES LIVRABLES Esnault Jerome - INRIA SED DREAM - 37
  • 38. « Entités » manipulées dans SCRUM client équipe finies dans une release FEATURES STORIES TASKS finies dans un sprint Product Backlog : Detailed Estimated Evolutionary Prioritized User Story (objectif du client) / Technical Story (objectifs de l’équipe) : En tant que « Utilisateur », je veux « fonction », dans le but de Sprint Backlog : Splitted stories Health indicators S TOR I E S Obstacles gestion Regular revieview Testable tasks « résultat attendu ». T H E O R I E S C R U M • Le backlog produit contient tous les éléments (définies ou à venir) du projet . • Chaque backlog de sprint contient toutes les stories (sélectionnées depuis le backlog produit) à finir dans un sprint. Esnault Jerome - INRIA SED DREAM - 38
  • 39. Agile et outsourcing Logiciel de méthodes agiles via plateforme internet (iceScrum-AgileFant) Efficacité de la communication Conversation face à face avec support (tableau) + cafè? Visio conférence Conversation face à face Echange de mails Chat écrit Papier Enregistrement video Documentation en ligne Enregistrement audio Chat audio Richesse de la communication static dynamique Risques : • meeting plus long et moins interactif • barrière de la culture et de la langue T H E O R I E Esnault Jerome - INRIA SED DREAM - 39
  • 40. Conclusion cela permet d'éviter « l'effet tunnel » Les points positifs : • Méthode à flux tirés et non poussés • Méthode itérative et incrémentielle • Méthode participative et adaptative (flexible) T • Communication et coopération efficace et riche H E Les risques : • Si taille de l'équipe > 10 et dispatchée O R I E => organisation difficile (cohésion de groupe, qualité de comm…) ? => besoin de décomposer en scrum de scrum (équipes de 7-10 max) • Réticence à l’évolutivité, réactions aux changements (Procrastination) => appréhension à faire évoluer (refactoring) un code qui marche déjà => besoin d’outils XP (coding rules, SCM, intégration continue, tests…) • Le turnover => impact directement la capacité / stabilité de l’équipe Esnault Jerome - INRIA SED DREAM - 40
  • 41. Nos ouvertures : KANBAN Passage à une méthode moins normative et plus adaptative : KANBAN • Ne pas imposer de rôle précis ni de livrable quotidien, planifier le TAF (Travail A Faire) au fur et à mesure et ne livrer que lorsque c’est demandé. • Utiliser un tableau KANBAN pour toute la durée du projet plutôt que d’avoir un tableau de sprint par itération. => impliquerait d’avoir un découpage régulier ( ± même taille) des éléments à faire. • Limiter le TAF (Travail A Faire) de chaque étape du workflow plutôt que de chaque itération permettra d’identifier plus rapidement les goulets d’étranglements et de réagir plus vite. • Autoriser les changements au court d’une itération (en respectant la règle ci-dessus) plutôt que d’essayer de fixer une itération (avec des stories non modifiables). • Utiliser le burndown chart le temps d’un jalon/release plutôt que pour une itération ET / OU le diagramme de flux cumulés (pour modifier les capacités). Continuer d’adapter, d’expérimenter et de faire évoluer vers notre propre méthode ! Esnault Jerome - INRIA SED DREAM - 41 T H E O R I E K A N B A N
  • 42. KANBAN : exemple Exemple de diagramme de flux cumulé Backlog Dev Test/Déploiement Prod Capacité moyenne : 1 item/jour 6 jours dont 3 en test Esnault Jerome - INRIA SED DREAM - 42 T H E O R I E K A N B A N 30 25 20 15 10 5 0 9 items 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Nombre d’items (TAF) Jours Objectif : Lisser le flux et limiter le travail à la capacité « disponible » : minimiser le nombre d’éléments séjournant dans les files.
  • 43. Limiter la phase de TEST/DEPLOIEMENT à 2 éléments : BACKLOG RESERVED TEST/DEP A Esnault Jerome - INRIA SED DREAM - 43 T H E O R I E K A N B A N DEV WIP DONE PROD C B D E F H 3 4 L M N O P I dépend de G et On a besoin de J et K J E et F sont terminés, on prend G C ne compile pas et D dépend de C, on est bloqué 2 H est terminé, on ne peut pas commencer un autre item (limite à 4) On vient en renfort ! I Protection contre les perturbations K G

Notes de l'éditeur

  1. LEAN n’est donc pas en soi une méthode de gestion de projet. Il s’agit plus certainement d’un cadre de travail, regroupant des méthodes telles que RAD (rapid development software), Scrum et XP, KANBAN… mais surtout des valeurs. Cependant nous noterons que ces méthodes ont des points en commun tels que les cycles de développement itératif, incrémental et adaptatif. La grande idée derrière Agile est de concevoir un produit qui satisfait le client et ses besoins au lieu de satisfaire les termes d’un contrat. Cela implique une plus grande interaction avec le client afin d’obtenir une grande réactivité face à des demandes. Agile permet donc d’obtenir des logiciels de meilleur qualité et adaptés au besoin réel. L’accent est donc mis sur la réactivité au changement et l’interaction entre les individus. Dès lors MOE (maitre d’œuvre – chargé de projet) et MOA (maitre d’ouvrage – propriétaire/commanditaire) sont en phase pour arriver ensemble à un objectif commun, avec un travail d’équipe. Notez que si Agile est essentiellement appliquée à la conception de logiciels, on notera cependant une tendance à l’appliquer dans le cadre général de management agile, qui met l’accent sur l’amélioration continue de la qualité (MTQS - Managerial Technical Qualifications ou Lean - http://www.logistiqueconseil.org/Articles/Logistique/Lean-management.htm). LEAN: S’applicant pour tous domaines/secteurs d’activités. Le Lean management est de ce fait une technique de gestion essentiellement concentrée vers la réduction des pertes générés à l’intérieur d’une organisation, pour une production et un rendement plus justes (apparu dans les année 70 avec l’entreprise Toyota). réduire la durée des cycles de production, diminuer les stocks, augmenter la productivité, optimiser la qualité. Le Lean management repose sur le facteur humain. Il suggère que le personnel travaille dans un état d’esprit orienté vers la diminution du gaspillage et des pertes (de temps, de matières, d’argent …). La motivation et les comportements des hommes sont nécessaires pour une application efficace. (5M, PDCA, QQOQCP…) Le Lean ne vous donne pas un ensemble spécifique de techniques pour gérer le travail, mais plutôt un ensemble de principes destinés à vous aider à décider comment livrer le plus de valeur avec le moindre effort, et comment continuer à améliorer vos techniques actuelles. Les principes du Lean englobent donc l'utilisation de Scrum et Kanban ainsi que d'autres méthodes de gestion du travail. Parfois, les gens sont frustrés parce que le Lean ne fournit pas un ensemble de règles sur la façon de faire les choses, mais plutôt un ensemble d'outils de réflexion (principes). Pour ces personnes, Scrum et/ou Kanban constituent de très bons points de départ. Mais le Lean fera que chaque entreprise mettre d'abord en oeuvre ces techniques, les améliorera constamment, et après quelques années, Scrum et Kanban auront évolué et changé en quelque chose de très différent de ce qu'il y avait au départ. KANBAN: (définition brut) : Kanban : Terme japonais qui signifie étiquette, fiche ou carte. Méthode de gestion des réapprovisionnements d'origine japonaise consistant à créer un circuit d'étiquettes, les unes accompagnant les conteneurs des produits gérés, les autres s'accumulant sur un tableau jusqu'au déclenchement du réapprovisionnement. Le Kanban permet de gérer visuellement les flux de matériel et l'ordonnancement des cellules de travail. Basé sur le principe de production à flux tiré (la production à déjà commencée avant la réception de commande de manière à spécialiser le produit plus rapidement sur la base des précédant travaux; à l’inverse de la production à flux poussé => prévision de vente et on produit ensuite tout d’un coup suivant un cycle séquentiel), le kanban permet d'optimiser les stocks en cours et de diminuer la taille des lots. Le tableau de KANBAN est unique durant toute la durée du projet et chaque colone du tableau (TO DO, SELECTED, IN PROGRESS, DONE, DEPLOY) limite le nombre d’entrées. Principe du flux continue limité : Un exemple de mesures de sous-optimisation est le fait de s'assurer dans certaines entreprises que tout le monde est occupé tout le temps ; et généralement cela se fait en demandant aux gens de travailler sur plusieurs choses en même temps. Pourtant, cette stratégie entraîne un énorme gaspillage car un taux d'utilisation élevé crée l'équivalent des embouteillages et ralentit tout au fur et à mesure que le temps dépensé pour passer d'une tâche à une autre augmente. SCRUM : Scrum est une méthode de développement agile orientée gestion de projet informatique (« haut niveau ») dont les ressources sont régulièrement actualisées. La méthode Scrum tire son nom du monde du rugby, scrum = mêlée. Le principe de base étant d'être toujours prêt à réorienter le projet au fil de son avancement. C'est une approche dynamique et participative de la conduite du projet. Scrum est essentiellement une méthode permettant d'accomplir un travail cadencé par itérations. Kanban est une méthode permettant d'accomplir un travail en limitant les travaux en cours et en gérant les flux. Certains travaux (en particulier créatifs) sont plus efficacement traités avec des itérations, alors que d'autres travaux (en particulier naturellement séquentiels) sont plus naturellement gérés avec Kanban. En règle générale, vous devez utiliser l'une ou l'autre de ces techniques, mais pas les deux en même temps pour le même travail. Déterminer la meilleure technique de gestion du travail dans un contexte donné devrait être réalisé en menant des expériences et en mesurant les résultats aux différents niveaux d'un système. XP: 'Extreme Programming (XP) est une méthode de développement logiciel (« bas niveau »), c'est-à-dire un ensemble de pratiques/outils destinées à organiser le travail d'une équipe de développement (orienté équipe de dev). Ces pratiques se focalisent sur la construction proprement dite du logiciel, en aval des phases préparatoires d'études d'opportunité ou de faisabilité (cf. lean). L'heure est à l'économie et à l'efficacité. XP propose un ensemble de pratiques organisées autour des principes suivants : Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines). L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements. L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres. L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé. Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides. Source : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/04/09/Entretien-avec-Mary-Poppendieck-sur-le-Lean-Scrum-Kanban-et-le-Leadership
  2. “Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients” Veronique Messager Rota - Gestion de projet : Vers les méthodes agiles L’agilité, c’est d’abord des Valeurs (4) et des PRINCIPES (12)… * Les individus et les interactions plutôt que les processus et les outils * Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive * Collaboration avec le client plutôt que la contractualisation des relations * Acceptation du changement plutôt que la conformité aux plans * Satisfaire le client est la priorité * Accueillir les demandes de changement « à bras ouverts » * Livrer le plus souvent possible des versions opérationnelles de l’application * Assurer une coopération permanente entre Client et Equipe projet * Construire des projets autour d’individus motivés * Privilégier la conversation en face à face * Mesurer l’avancement du projet en termes de fonctionnalités de l’application * Faire avancer le projet à un rythme soutenable et constant * Porter une attention continue à l’excellence technique et à la conception * Favoriser la simplicité * Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. * Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace Source : http://www.qualitystreet.fr/2009/06/21/agile-et-lean-booster-dinnovation/ source: http://www.qualitystreet.fr/2007/11/20/methodes-agiles-un-belle-definition/ STORY exemple : En tant qu’internaute, je veux pouvoir me loguer sur le wiki de l’équipe afin d’y ajouter des informations. TACHES exemple: Créer un formulaire et une interface utilisateur; enregistrer les utilisateurs dans une base de donnée, autoriser la lecteur et l’écriture sur le wiki.
  3. Interventions dans différents projets Personnel qui varie régulièrement entre les personnes à engagement variable (50%) et les invités Cœur de l’équipe dans une salle mais collaborations externe régulières
  4. Suffi pas d’un point de vue visibilité => plannification Peu de fonctionnalités :pas d’évolution de l’outils possible (ou besoin de dev derrière)
  5. Les + : Les - :
  6. La méthode SCRUM est planifiée selon 3 niveaux. Le fait qu’il n’y ait pas beaucoup de niveaux permet de simplifier la planification et son organisation. Les 3 niveaux différents sont le projet, les release (version du projet) et les sprints (moment de travail). Le directeur de produit Le directeur de produit est la personne qui représente le client à l’intérieur même de l’équipe : c’est lui qui définit l’ordre et la priorité de chaque fonctionnalité. En cas de besoin d’orientation du projet, c’est à lui que revient cette responsabilité. Une fois encore, le terme de directeur n’est pas à associer au sens hiérarchique du terme : il travaille en étroite collaboration avec l’équipe. Le SCRUM master Il collabore avec le directeur de produit. Il veille au respect des valeurs de la méthode SCRUM. Il protège l’équipe des « éléments perturbateurs ». Equipe : D'une taille allant de 4 à 10 personnes idéalement multidisciplinaire pour favoriser le partage de connaissance (l'équipe regroupe tous les rôles habituellement nécessaires à un projet, à savoir l'architecte, le concepteur, le développeur, le testeur, etc.) L'équipe s'organise elle-même et elle reste inchangée pendant toute la durée d'un sprint. Membre de l’EPI mais peu varier d’un sprint à l’autre Source: http://www.pentalog.fr/offre/methodologie_agile_scrum.htm
  7. L’abreviation pour définir le backlog : DEEP [source: http://www.qualitystreet.fr/2010/02/05/dans-scrum-mon-backlog-de-produit-est-deep/] Autres sources : http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/ Exemple de user story : http://www.mountaingoatsoftware.com/scrum/sprint-backlog Feature L'élaboration de la vision du produit passe par l'identification des features. Le terme features est abondamment utilisé dans le domaine de l'ingénierie des exigences [2]. Il y a même une méthode agile qui l'utilise dans son nom : Feature driven development ou FDD. Elles apportent suffisamment de valeurs pour être release (finie dans une release). Theme Un theme est une collection de stories, et peu donc regrouper plusieurs features. L'intérêt des themes est évident quand il s'agit de définir les priorités : c'est bien plus facile à faire sur 5 à 10 themes que sur des dizaines de stories. Epic Une epic est une grosse story. Elle est en attente de décomposition en stories "normales". L'intérêt d'avoir des epics est qu'il ne sert à rien de décomposer trop tôt : il est préférable de le faire au dernier moment raisonnable. On pourrait dire épopée ? épisode ? Activités => taches techniques => matière brute de travail 1 Activity = N tasks : “Read an email message” is a task, “Managing email” is an activity.
  8. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  9. Le(s) Objectif(s) (le « Quoi ? ») => La valeur ajoutée, les spécifications fonctionnelles Le but (le « Pourquoi ?») => Les perspectives utilisateurs Plus l’importance est forte et plus le niveau de détail des stories/EPICS sont élevés (éventuellement découpées). PROCEDURE : identifier les themes, en regroupant éventuellement des features pour en obtenir de 5 à 10 et en les consolidant de façon à constituer des domaines fonctionnels indépendants. Les themes seront utilisés dans le backlog comme attribut des stories. décider des priorités entre les themes, par une session de priority poker ou un autre moyen comme la sélection de themes basée sur des critères de satisfaction[4]. pour les 1 ou 2 themes les plus prioritaires, décomposer en stories détaillées (normales), en pratiquant par exemple un story workshop. Les stories, avec leur theme, sont placées dans le backlog. pour les autres themes, la ou les features correspondant deviennent des epics, ordonnés en utilisant les priorités définies sur les themes. Source: http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories http://www.openagile.net/?page_id=52
  10. Le(s) Objectif(s) (le « Quoi ? ») => La valeur ajoutée, les spécifications fonctionnelles Le but (le « Pourquoi ?») => Les perspectives utilisateurs Plus l’importance est forte et plus le niveau de détail des stories/EPICS sont élevés (éventuellement découpées). PROCEDURE : identifier les themes, en regroupant éventuellement des features pour en obtenir de 5 à 10 et en les consolidant de façon à constituer des domaines fonctionnels indépendants. Les themes seront utilisés dans le backlog comme attribut des stories. décider des priorités entre les themes, par une session de priority poker ou un autre moyen comme la sélection de themes basée sur des critères de satisfaction[4]. pour les 1 ou 2 themes les plus prioritaires, décomposer en stories détaillées (normales), en pratiquant par exemple un story workshop. Les stories, avec leur theme, sont placées dans le backlog. pour les autres themes, la ou les features correspondant deviennent des epics, ordonnés en utilisant les priorités définies sur les themes. Source: http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories http://www.openagile.net/?page_id=52
  11. On apprend en même temps qu’on pratique. 1- On savait pas qu’il y avait une grosse réunion de planification prévisionnel pour définir et estimer les jalons du projet. 2- IceScrum est plus accessible est intuitif à utiliser (moins de paramètres à régler mais plus de contraintes SCRUM à respecter) 3- Lancement de nos premiers sprints avec IceScrum en commençant par le sprint 0
  12. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  13. BACKLOG PRODUIT (TO DO for FEATURES) BACKLOG SPRINT N (TO DO for SPRINT) Source : http://www.openagile.net/?page_id=52
  14. Portée : Qualité externe => est ce qui est perçu par les utilisateurs du système (une interface utilisateur lente et pas intuitive est un exemple de mauvaise qualité externe). product owner peut diminuer la portée ou la écouper en 2 stories pour influencer les choix de l’équipe. Qualité interne => non négociable => fait référence à des points qui habituellement ne sont pas visibles par l’utilisateur, mais qui ont un profond effet sur la maintenabilité du système. La cohérence de la conception, la couverture de test, la lisibilité du code, les remaniements (refactoring)… Estimation : 1er Facteur de focalisation pour commencer environ 70% Importance : product owner peut influencer l’équipe en changeant l’ordre de priorité des sorties Selection pour prochain sprint : Valeur métier (quelles fonctionnalités seraient le plus appréciées par le client) Connaissance (quelles fonctionnalités apporteront de la connaissance et par conséquent, réduiront les risques) Utilisation des ressources (équilibrer les domaines fonctionnels pour donner du travail à tout le monde) Dépendances (quelles fonctionnalités sont à construire les unes par rapport aux autres) Testabilité (quelles fonctionnalités devraient être développées ensemble pour un test logique) VELOCITE: Mesure permettant d’estimer la capacité. CAPACITE : Quantité d’éléments livrés par sprint.
  15. Trop court = client + product owner content (visu/affinage du produit ) équipe plus bridée (plus de meeting/livrables, moins de résolution de problèmes, stress) Trop long = client + product owner bridée (intervention moins régulière/confiance) équipe plus libre (monté en puissance de l’équipe, meilleur qualité de support) En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt, c'est qu'on a une vision de plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'aménager les items de backlog du produit en cours de route.
  16. Facteur de focalisation pour sprint 2 = 12/24 = 50%
  17. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  18. http://www.aubryconseil.com/post/Scrum-et-les-taches-urgentes http://www.openagile.net/?page_id=52
  19. Planifier et mesurer l’avancement : Gantt VS Burn down Chart Les personnes habituées aux méthodes en cascades et autres cycles en V peuvent désormais se demander de quelle manière on peut mesurer et se rendre compte de l’avancement d’un projet Agile. En effet vous noterez l’absence jusqu’à présent de tout diagramme de Gantt, Pert ou assimilé. En effet un diagramme de Gantt n’est pas approprié car il est généralement conçut en début de projet. Puis une personne est chargée de l’annoter avec l’état d’avancement et la mesure des écarts (généralement le chef de projet). Enfin, une fois le projet terminé, il est temps de rendre compte des erreurs d’appréciations dans l’évaluation et la planification préliminaire. On note donc trois moments dévoreurs de la ressource temps : création du diagramme de Gantt maintenance et suivie du diagramme de Gantt rendre comptes des erreurs et des écarts Ce diagramme de Gantt doit être maintenu grâce à un logiciel, et est très souvent visible uniquement par le chef de projet, qui devra par ailleurs aller chercher les informations sur l’avancement auprès des développeurs. Ces derniers seront très certainement réticents à prendre du temps pour mesurer leur progression. Pour eux, cette tâche n’apporte pas de valeur au produit (et ils n’ont pas complètement tort). Nous avons vu que la méthode Scrum implique une planification courte, par Sprints de 1 à 3 semaines, qui se répètent de manière itérative (pas de planification à moyen ou long terme). Au sein de ces sprints, chaque développeur est maître de son temps, et effectue lui-même l’étude de l’avancée de ses travaux. Il n’existe pas d’outil imposé pour le suivi d’un projet Scrum. Cependant, on peut utiliser un élément très visuel, et surtout visible par tous, tels qu’un tableau d’avancement de sprint associé à un burn down chart. Les fonctionnalités à implémenter sont classés dans ce tableau d’avancement selon trois colonnes : à faire, en cours, fait. Quand au burn down chart, il s’agit d’une courbe qui donne une indication de l’avancée par rapport au temps. Source : http://blog.vincentbrouillet.com/post/2010/05/30/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-2/3%29
  20. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  21. http://www.aubryconseil.com/post/2007/01/11/154-discussion-sur-les-merites-du-pair-programming http://seanron.free.fr/index.php?article7/la-methode-agile-scrum-et-extreme-programming http://www.slideshare.net/jcgrosjean/methodes-agiles-scrum-et-xp-pdjsqli-presentation?type=powerpoint http://www.regismedina.com/articles/fr/extreme-programming Réductionnisme : http://www.merriam-webster.com/dictionary/reductionism
  22. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  23. Quelques post-it : - arrêter la réunion du matin - réunion du matin trop tard (9h30) - réunion du matin à faire sous timer (chronométrage ! ) [dure actuellement entre 15 et 25 min] - faire la réunion tous les 2 jours - faire une réunion par semaine - ralentir le rythme des réunions - estimation des taches incorrecte - tests insuffisamment définis sur les tâches de conception, de programmation - à confirmer : les réunions de revues avec les clients, l'aide sur les tâches annexes - des oublis de tâches au tableau de sprint
  24. Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
  25. Les points positifs : Méthode à flux tirés et non poussés Méthode itérative et incrémentielle  Méthode participative et adaptative (flexible) Communication et coopération efficace et riche Cela permet d'éviter « l'effet tunnel » Les risques : Si taille de l'équipe > 10 et dispatchée => organisation difficile (cohésion de groupe, qualité de comm…) ? => besoin de décomposer en scrum de scrum (équipes de 7-10 max) Réticence à l’évolutivité, réactions aux changements (Procrastination) => appréhension à faire évoluer (refactoring) un code qui marche déjà => besoin d’outils XP (coding rules, SCM, intégration continue, tests…) Le turnover => impact directement la capacité / stabilité de l’équipe Projets: isiVR, SOFA, SOFAVR, MR, VCORE, CMAKETOOLS, NIEVE, DogPhobia… Dispo très variables : beaucoup de CP, interventions dans d’autres projets, réunions non prévisibles… A vouloir trop utiliser le formalisme SCRUM, la méthode et les outils nous ont formaté alors qu’il ne correspond pas tout à fait notre contexte. FINAL: Garder une methode souple au début, puis l’adapter à notre contexte. Attention: C’est notre besoin qui formate l’outils et pas l’outils qui formate notre besoin ! Tableau physique peu utilisé : (communication indirecte par les interactions dans IceScrum) Capacité pas encore stabilisée (sur-estimation lors des planifications de sprint)
  26. AGILE: Ca nous aide Ca nous organise Mais ca prend u temps Il faut que l’équipe complète s’investisse Peu engendrer du stress négatif (conflit sur la manière de bosser, conflit de perssone, conflits hierarchique, pression (trop de travail)? http://sebastienboyer.wordpress.com/2012/03/18/ http://www.granddictionnaire.com/btml/fra/r_motclef/index800_1.asp http://www.lfsm.org/IMG/pdf/intervention_Patrick_Legeron.pdf http://www.travailler-mieux.gouv.fr/IMG/pdf/livreblancstress.pdf LES STRESSEURS LIÉS AU CONTENU DU TRAVAIL Pénibilité physique Pénibilité mentale Charge de travail Responsabilités LES STRESSEURS LIÉS AU CONTEXTE DE TRAVAIL Changements Incertitudes Organisation de l’entreprise Conflits de valeurs LES STRESSEURS LIÉS À L’INDIVIDU Non adéquation des compétences au poste Frustrations matérielles Frustrations psychologiques Absence d’intérêt LES STRESSEURS LIÉS AUX DIFFICULTÉS RELATIONNELLES Avec la hiérarchie Avec les pairs Avec les individus sous sa responsabilité Avec le public et/ou les clients
  27. Source : http://dchaffiol.free.fr/info/chefprj/art_xp_t.htm Autres : http://dchaffiol.free.fr/info/blagues/art_bg_cycleEnV.htm http://blog.vincentbrouillet.com/post/2011/01/30/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-1/3%29 http://www.aubryconseil.com/post/2007/01/23/162-le-cycle-de-vie-en-v-n-existe-pas
  28. La qualité est donc une notion relative basée sur le besoin. On doit en général rechercher davantage une qualité optimum, qu’une qualité maximum. "la qualité, c'est la conformité aux exigences". « les exigences de qui ? », « Ce qui est apprécié d’une personne », mais comment ce manifeste ce sentiment chez cette personne? Pour répondre aux critères de qualité, il faut donc tester auprès du client : - si les résultats obtenus lui sont satisfaisant , - ce que l'on veut définir ou redéfinir comme résultat à atteindre. Il faut également se demander, une fois ses "intentions" précisées, si l'on sait comment s'y diriger, pour satisfaire ses intentions. On ne va pas vers un objectif fixe, on se dirige vers un ou plusieurs buts qui forment la "zone de satisfaction du client", zone sans cesse affinée avec lui (le client). Parce que la satisfaction du client dépend de critères multiples, définissant chacune une "dimension". On en connaît, les plus classiques : le coût et les délais. Mais il y en a plein d'autres : la qualité de service (performance, temps d'indisponibilité minimal, etc...). Définir une solution unique qui répond du premier coup à tout ces critères revient à vouloir définir un point et un chemin précis dans un univers (ou hypercube) à n-dimensions : c'est très compliqué. Il est plus simple de se mettre d'accord sur une "zone" générale de ce même hypercube (dont chacune des dimensions représente un axe binaire de critère de satisfaction client), et de viser cette zone en se définissant un « vecteur » dont on affinera régulièrement la direction. Pour mettre en place une tel qualité il faut communiquer avec le client, avoir le courage de prendre une direction générale pour aller simplement vers cette zone et vérifier régulièrement auprès du client si l'on va toujours dans le sens qu'il souhaite. De cette dernière phrase découlent les 4 valeurs fondamentales : la communication, le courage, la simplicité et le feedback. Oui, la qualité revient donc à placer en objectif prioritaire le fait que quelqu'un apprécie son travail. Cette appréciation est mise dans un mécanisme de feedback, sachant que le contenu même du travail reste libre : on fait ce que l'on veut pourvu que l'on ait un retour régulier et une appréciation positive. Si l'appréciation n'est pas positive, il ne faut pas avoir peur du changement. Plus simplement, on brise le mythe de conception qui définirait la solution atteignable que via un "process balistique" (on vise, on tire... et on espère atteindre l'objectif initialement visé!)  : XP voit la qualité comme un process de pilotage "à tête chercheuse". Source : http://dchaffiol.free.fr/info/chefprj/art_xp_t.htm
  29. L’agilité, c’est d’abord des Valeurs (4) et des PRINCIPES (12)… * Les individus et les interactions plutôt que les processus et les outils * Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive * Collaboration avec le client plutôt que la contractualisation des relations * Acceptation du changement plutôt que la conformité aux plans * Satisfaire le client est la priorité * Accueillir les demandes de changement « à bras ouverts » * Livrer le plus souvent possible des versions opérationnelles de l’application * Assurer une coopération permanente entre Client et Equipe projet * Construire des projets autour d’individus motivés * Privilégier la conversation en face à face * Mesurer l’avancement du projet en termes de fonctionnalités de l’application * Faire avancer le projet à un rythme soutenable et constant * Porter une attention continue à l’excellence technique et à la conception * Favoriser la simplicité * Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. * Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace Source : http://www.qualitystreet.fr/2009/06/21/agile-et-lean-booster-dinnovation/ source: http://www.qualitystreet.fr/2007/11/20/methodes-agiles-un-belle-definition/
  30. L’abreviation pour définir le backlog : DEEP [source: http://www.qualitystreet.fr/2010/02/05/dans-scrum-mon-backlog-de-produit-est-deep/] Autres sources : http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/ Exemple de user story : http://www.mountaingoatsoftware.com/scrum/sprint-backlog Feature L'élaboration de la vision du produit passe par l'identification des features. Le terme features est abondamment utilisé dans le domaine de l'ingénierie des exigences [2]. Il y a même une méthode agile qui l'utilise dans son nom : Feature driven development ou FDD. Elles apportent suffisamment de valeurs pour être release (finie dans une release). Theme Un theme est une collection de stories, et peu donc regrouper plusieurs features. L'intérêt des themes est évident quand il s'agit de définir les priorités : c'est bien plus facile à faire sur 5 à 10 themes que sur des dizaines de stories. Epic Une epic est une grosse story. Elle est en attente de décomposition en stories "normales". L'intérêt d'avoir des epics est qu'il ne sert à rien de décomposer trop tôt : il est préférable de le faire au dernier moment raisonnable. On pourrait dire épopée ? épisode ? Activités => taches techniques => matière brute de travail 1 Activity = N tasks : “Read an email message” is a task, “Managing email” is an activity.
  31. Agile et outsourcing L’outsourcing consiste externaliser la partie développement, c'est-à-dire l’écriture du code. Le plus souvent on outsource vers des pays à faible coûts tels que l’Inde, la Chine ou même la Russie, ou encore l’Argentine. Ces pays ont à disposition une main d’ouvre compétente pour effectuer le développement. D’une manière générale, le management du projet, l’étude et l’analyse des besoins et la conception sont effectués sur place. L’écriture du code est réalisée par une équipe « outsourcée ». Ce mode de fonctionnement est "plus facile" à concevoir lorsque le projet est très spécifié. Il "suffit" alors de remettre à l’équipe de développement toute la documentation qui a été produite, et il ne leur reste plus qu’à implémenter et valider les résultats. Que le résultat soit en adéquation avec les specifications est un autre debat (voir Partie 1: Défauts des méthodes traditionnelles). Cependant, le challenge est tout autre avec une méthode Agile. Agile c’est la capacité à s’adapter et à réagir rapidement face au changement. Dès lors, on a une contradiction : comment communiquer au quotidien efficacement entre deux équipes distantes, issus de différentes cultures? Comment, par exemple, mener à bien une réunion de type « daily standup meeting » (littéralement réunion journalière où on se tient debout) ? La solution est de se reposer sur les technologies de communication et les outils de travail collaboratif à distance. La plupart des réunions peuvent être réalisées en utilisant des outils de visioconférence. En fait un simple micro-casque et un logiciel comme Skype permettent déjà de franchir beaucoup d’obstacles liés à la distance. De plus on peut utiliser des outils tels que IceScrum ou AgileFant qui permettent de gérer des projets Agile via une plateforme Internet. Chaque membre de l’équipe est invité à se connecter quotidiennement sur la plateforme afin de communiquer sur sa progression et d’estimer le temps nécessaire pour les tâches qui lui sont allouées. Bien sûr les personnes n’ont aucun visu, ce qui constitue un frein à l’interaction et donc à la coordination. Les meetings sont aussi souvent plus longs car il faut nécessairement être beaucoup plus descriptif. Deux problèmes majeurs surviennent souvent : la médiocre qualité des communications et la barrière de la langue. En Inde, par exemple, se pose le problème de la qualité des connexions Internet (et aussi électriques) qui viennent interrompre fréquemment les communications. En chine, le problème de la langue se pose. Les développeurs chinois parlent peu ou mal l’anglais. Souvent, les communications orales ne sont pas possibles et il est nécessaire de les remplacer par l’écrit, qui est beaucoup moins efficace. Enfin, le plus gros problème auquel on fait face en outsourcing est l’incompréhension due à des différences culturelles (le fameux « oui » respectueux Indien qui n’a pas la valeur du oui occidental).  Source : http://blog.vincentbrouillet.com/post/2010/06/06/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-3/3%29
  32. Valeurs scrum : Confiance Courage Transparence Humilité Congruence En psychothérapie, congruence est le terme employé par Carl Rogers pour indiquer une correspondance exacte entre l'expérience et la prise de conscience Avantages Scrum se différencie des autres méthodes de développement par ses avantages qui font de ce procédé une réponse pragmatique aux contraintes actuelles des chefs de produits : Méthode itérative et incrémentielle : cela permet d'éviter "l'effet tunnel", c'est-à-dire le fait de ne voir le résultat qu'à la livraison finale et rien ou presque rien pendant toute la phase de développement, si fréquent dans les développements avec le cycle en V. Adaptabilité maximale pour du développement de produits et d'applications : la composition séquentielle du contenu des sprints permet d'ajouter une modification ou une fonctionnalité qui n'était pas prévue au départ. C'est principalement cela qui rend cette méthode "agile". Méthode participative : chaque membre de l'équipe est invité à s'exprimer et il peut participer à toutes les décisions prises sur le projet. Il est donc plus impliqué et plus motivé. Augmentation de la communication : en travaillant dans la même salle de développement, ou en étant connecté avec différents moyens de communication, l'équipe peut communiquer facilement et échanger sur les obstacles afin de les supprimer au plus tôt. Maximisation de la coopération : les échanges quotidiens entre le client et l'équipe permettent un rapprochement et une entraide se met logiquement en place. Augmentation de la productivité : en supprimant certaines "contraintes" des méthodes classiques comme la documentation ou la formalisation exagérée, SCRUM permet d'augmenter la productivité de l'équipe. En ajoutant à cela la qualification de chaque module permettant d'en déterminer un chiffrage, chacun peut se positionner par rapport à la productivité moyenne de l'équipe. Risques et solutions La méthodologie SCRUM n'est pas une réponse miracle à tous les problèmes inhérents au développement de logiciels informatiques. Il faut rester vigilant sur les risques ci-dessous, risques qui possèdent néanmoins, une réponse systématique puisée dans l'extrapolation de la méthode : Taille de l'équipe : généralement limitée à 7 ou 10 personnes, la taille de l'équipe peut devenir un obstacle si elle dépasse ces préconisations. L'organisation des réunions devient alors impossible et les fondements mêmes de la méthode sont alors mises à mal.  La solution consiste à réaliser des Scrum de Scrum. Il s'agit ici de constituer de scinder le projet en équipes de taille recommandée et d'ajouter une instance de niveau supérieure regroupant les ScrumMaster de chaque Scrum. Qualité des développements : Plus le nombre d'équipes augmente, plus la qualité est difficile à maîtriser. Ce postulat est d'autant plus vrai dès lors que le projet est réparti sur plusieurs sites. Les risques sont particulièrement liés à la qualité du code et au nombre de défauts répertoriés au moment de l'intégration. Pour cela, il est important d'avoir une politique qualité rigoureuse et un plan qualité projet qui définit précisément les règles du projet. Des audits de code fréquents et la mise en place d'indicateurs mesurant la performance des développeurs permettent de minimiser ce risque. Concludion: http://www.aubryconseil.com/post/Les-valeurs-de-l-agilite http://www.pentalog.fr/offre/methodologie_agile_scrum.htm
  33. 1 - plus de réunion de sprint mais mêlées quotidienne importantes 2 - 3 – Si un problème persiste ou si plusieurs elements sont en attente de traitement pour la prochaine étape du workFlow : cela permet de mobiliser ses troupe pour les terminer et passer à autre chose (minimiser les pertes (de temps, d’argents tout en étant capable de livrer des éléments en production) et maximiser le rendement)
  34. Sur 15 jours la capacité de l’équipe est de 15 éléments soit en moyenne 1 élément par jour (Courbe violette de prod). Le 4ème jour les 9 premiers items ont mis 6 jours pour passer du backlog à la prod dont 50% du temps en phase de test/deploiement… On pourrait limiter le TAF en phase de test/deploiement pour fluidifier (lisser) le flux et concentrer les efforts dans cette phase pour dépiler plus rapidement les items et les passer en prod.
  35. Estimations peuvent être XS, S, M, XL, XXL … Pourquoi une limite de 4 dans la colonne DEV ? Supposons qu’il y ai 3 éléments dans la colonne DONE (et donc 1 élément dans la colonne Work In Progress), il y à donc une capacité excédentaire (des développeurs qui pourraient commencer de nouveaux éléments), mais qui ne peuvent pas à cause de la limite KANBAN. Cela les incitent donc fortement à aider à livrer des choses en production en vidant les colonnes DONE et TEST/DEPLOIEMENT et à maximiser le flux (effet positif et progressif). Limite KANBAN trop faible => les gens sont inoccupés => mauvaise productivité Limite KANBAN trop elevé => taches non traitées => mauvais temps de cycle Principe du flux continue limité : Un exemple de mesures de sous-optimisation est le fait de s'assurer dans certaines entreprises que tout le monde est occupé tout le temps ; et généralement cela se fait en demandant aux gens de travailler sur plusieurs choses en même temps. Pourtant, cette stratégie entraîne un énorme gaspillage car un taux d'utilisation élevé crée l'équivalent des embouteillages et ralentit tout au fur et à mesure que le temps dépensé pour passer d'une tâche à une autre augmente.