[ENGLISH BELLOW]
Les journees DevExp sont comme nos DreamTech meetings a Sophia Antipolis (Le partage d'expériences), mais couvrant l'ensemble des centres de l'INRIA (à travers tout le pays). Les ingénieurs se rencontrent une fois par an pendant 2/3 jours pour présenter, discuter et partager leurs travaux/experiences/point de vue. Dans mon cas (de l'INRIA Sophia Antipolis), je ai présenté notre expérimentation de la méthode agile Scrum et comment nous avons appris à l'utiliser et à l'adapter à notre contexte (SOFAVR + les autres projets en relations).
[ENGLISH]
DevExp are like our INRIA DreamTech (share engineer experiences) but covering the whole INRIA centers (through all the country). Engineers meet 1 time a year during 2/3 days to present, share and discuss about their actual works. In my case (from INRIA Sophia Antipolis) I presented our experimentation of the SCRUM agile method and how we learnt to use it and to adapt it to our context (SOFAVR and all the others related projects).
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
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
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
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
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
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
“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.
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
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)
Les + :
Les - :
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
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.
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
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
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
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
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
BACKLOG PRODUIT (TO DO for FEATURES)
BACKLOG SPRINT N (TO DO for SPRINT)
Source : http://www.openagile.net/?page_id=52
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.
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.
Facteur de focalisation pour sprint 2 = 12/24 = 50%
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
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
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
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
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
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
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)
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
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
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
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/
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.
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
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
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)
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.
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.