Methodes Agiles powerpont presentation.ppt

Méthodes Agiles
Méthodes Agiles

"La chose la plus dangereuse dans le domaine du logiciel
est l'idée, apparemment presque universelle, que vous
allez spécifier ce qu'il y a à réaliser, puis le réaliser. Voilà
d'où viennent la plupart de nos ennuis. On appelle
réussis les projets qui sont conformes à leurs
spécifications. Mais ces spécifications s'appuient sur
l'ignorance dans laquelle étaient les concepteurs avant de
démarrer le boulot »

1. Rappel méthodes
prédictives

Management Traditionnel TRAMDITIONNEL
5
Opportunité (note cadrage)
Besoin
FAISABILITE
Initialisation
Charte projet ( opportunité,
objectifs et bénéfices attendus,
étude préliminaire des coûts…)
Planification
Plan de projet
périmètre
organigramme des tâches
livrables attendus
délais
budget
qualité
RH
communication
gestion du changementt
Contrôle
Réalisation
Etat d’avancement
Demande changement
Problèmes
Livrable
Actions correctives
Changements validés
Rapports d’avancement
Clôture

Un peu d’histoire
 Années 60 (informatique militaire et scientifique) : des
méthodes de gestion de projets inspirées du BTP et de
l’industrie (Waterfall )
 Années 70 (milieux d’affaires et banques…) : quelques
évolutions
 Cycles en V années 80 : on s’améliore grâce aux tests
 1985: MERISE : méthode conceptuel de données.
 2001: Manifeste Agile : soin porté aux individus, au logiciel, à la
collaboration avec le client et au changement plutôt que le
suivi d’un plan

Modèle cascade TRAMDITIONNEL
7

Modèle en Cascade
AVANTAGES
oFacile à utiliser et à
comprendre
oStructure simple pour une
équipe inexpérimentée
oFonctionne bien quand la
qualité est plus importante
que la durée et le coût
INCOVENIENTS
oFace aux nouveaux
besoins, refaire tout le
procédé
oUne phase ne peut
démarrer que si l ’étape
précédente est terminée
oLe produit n’est visible qu’à
la fin
oLes risques se décalent
vers la fin.
oTrès faible implication du
client
8
Modèle cascade TRAMDITIONNEL

AVANTAGES
oMets l’accent sur les tests
et la validation. Accroît la
qualité
oChaque livrable doit être
testable
oFacile à utiliser et planifier
INCOVENIENTS
oNe gère pas les activités
parallèles
oNe gère pas les
changements de
spécification
oNe contient pas d’activités
d’analyse de risques
10
Modèle V TRAMDITIONNEL

Pourquoi y a-t-il des projets qui
échouent ?
11

Analyse réussite et échec projets
12
L’engagement du Chef de projet est sur le coût, le délai et le périmètre :
32% des projets livrés respectent l’engagement
44% des projets livrés, mais ne respectent pas l’engagement
24% de projets ne sont pas livrés

Analyse réussite et échec projets
13
Facteurs d’échecs
13% exigences
incomplètes
13% manque d’informations
utilisateurs
10% instabilité des
exigences et spécifications
9% manque de ressources
8% manque de soutien du
management
Facteurs de réussite
16% implications
utilisateurs
14% soutien du
management
13% énoncé clair des
exigences
10% planning adéquat
8% demandes réalistes

17
VLS
 Step 1 : VLS, installe une machine à laver robuste à l’arrière d’une
pickup
 Step 2 : Feedback et redéfinition de la stratégie (présence
physique et multiplication des points de présence)
 Step 3 : Kiosques ambulantes devant des supérettes locales.
Succès commercial. Le VLS a aujourd’hui plus de 15 emplacements à
Bangalore, Mumbai et Mysore.
Akshay Mehra

Premiers pas Scrum - cadre léger
 1996 – Article Scrum Ken Schwaber (processus
empirique produits complexes)
 Le processus Scrum définit un cadre léger de
travail :
Sprint et leurs événements
Une équipe avec trois rôles
Un backlog concernant le travail à
faire 18

Premiers pas Scrum – scrum en bref
« Scrum aide les gens à améliorer leur façon availler »
Les gens travaillent en équipe
Le développement est rythmé par des itérations courtes – sprint
Les fonctions du produit sont collectés dans le backlog
Pendant un sprint, des points de synchronisation sont effectués
tous les jours (Daily Scrum)
A la fin de chaque sprint, l’équipe présente l’incrément qu’elle a
ajouté au produit pendant le sprint.
19

Premiers pas Scrum – origine
Scrum n’est pas un acronyme. Le mot Scrum vient du rugby
Au rugby, une mêlée est sifflée lorsque une règle n’est pas respectée
La mêlée permet de repartir sur des bases solides, avec une poussée
synchronisée de tout le pack. L’effort est collectif
La référence au Rugby, vient d’un article de 1986 « The New New Product
Development game » rédigé par des japonais qui aimaient le rugby
[Takeuchi et Nonaka]. Cet article montrait la performance des sociétés
japonaises en adoptant une approche de co-construction pour le
développement de leurs produits
20

En quoi Scrum est différent
APPROCHE EMPIRIQUE
RYTHME.
PRIORITE
AUTO GESTION
TRANSPARENCE. 21

22
Le Mouvement agile – Le Manifeste agile
En 2001, le manifeste Agile Rédigé par 17 experts qui se dressent contre
l'échec des cycles en cascade, Il propose 4 valeurs fondamentales, et 12
principes :
 La Réactivité face au changement plutôt que le suivi d'un plan,
tout change, l’environnement, la technologie et les besoins
les diagrammes se dégradent car des tâches s’ajoutent et
d’autres ne sont plus nécessaires
 L’Interaction avec les personnes plutôt que les processus et les outils,
construire l’équipe est plus important que construire
l’environnement
 Un produit opérationnel plutôt qu’une documentation pléthorique,
 La collaboration avec le client plutôt que la négociation de contrat
Les projets réussis impliquent le client de manière fréquente
et régulière
Le client doit avoir un contact direct avec l’équipe de
développement

23
 Notre première priorité est de satisfaire le client en livrant tôt et
régulièrement des logiciels utiles.
Grâce au développement itératif, chaque livraison
intermédiaire donne lieu à une validation par le client.
 Le changement est accepté, même tardivement dans le
développement.
 Les processus agiles exploitent le changement comme avantage
compétitif pour le client.
 Livrer fréquemment une application fonctionnelle, toutes les deux
semaines à un mois, avec une préférence pour la période la plus
courte
Une version intermédiaire du produit final, visible et testable, satisfait
davantage le client qu’une documentation à valider. Il a, de ce
fait, la preuve que le projet avance présenté.

24
 Le client et l’Equipe doivent collaborer quotidiennement
au projet.
 Bâtissez le projet autour de personnes motivées. Donnez
leur l'environnement et le soutien dont elles ont besoin,
et croyez en leur capacité à faire le travail. Les relations
conflictuelles ne font pas partie de l’esprit agile ; on
préférera des relations collaboratives et de partenariat
basées sur la confiance et le consensus. Le client (ou
son représentant) est accessible et disponible
 La méthode la plus efficace pour transmettre
l'information est une conversation en face à face.

25
 Un logiciel fonctionnel est la meilleure unité
de mesure de la progression du projet
 Les processus agiles promeuvent un rythme
de développement soutenable.
 Une attention continue à l'excellence
technique et à la qualité de la conception
améliore l'agilité.
 La simplicité.
La simplicité garantit l’évolutivité du système..

26
Le Mouvement agile – Pratiques agiles
Des pratiques maintenant qualifiées d’agiles,
existaient avant le Manifeste Agile et avant
même les méthodes agiles :
Cycles courts (itérations) – années 80
La mêlée quotidienne

27
Le Mouvement agile – L’agilité
« L’agilité est la capacité d’une organisation à fournir
tôt et souvent des services impactant ses utilisateurs,
tout en s’adaptant à temps aux changements dans
son environnement »
Scrum est mise en pratique dans de très
nombreuses organisations depuis 20 ans. Parti du
développement, Scrum implique les gens de
plusieurs métiers :
Marketing et commerce
•Numérique
•Hardware

29
Scrum en chiffres
 Scrum est de loin la plus populaire dans la famille des méthodes agiles. Presque ¾ des
répondants disent utiliser Scrum ou des variantes dans leur projet
 Sur un panel d’agilistes :
28% travaillent dans une organisation agile datant plus de 3 ans
38% dans une organisation âgée de 1 à 3 ans
34% dans une organisation datant de moins 1 an.
Une nette augmentation de la mise en place des méthodes agiles dans les organisation
informatiques.
• TYPES
A titre expérimental : 15%
Généralisé : 19%
En cours de généralisation : 22%
Sur un projet pilote stratégique avec mise en production : 25%
Ces chiffres montrent une tendance à la généralisation de la mise en place des méthodes agiles.
Ils démontrent également l’utilisation des méthodes agiles sur des projets stratégiques.
• SPONSORS
55% des DSI
48% des Directions générales
42% du middle management

30
Scrum Bashing
Compte tenu du succès de Scrum, on retrouve des articles
critiques.
Sur le terrain, on commence à voir des déçus qui ne retrouvent
pas les belles promesses de Scrum : client enchanté, ROI, plus vite
sur le marché, plaisir de travailler en équipe….
D’autres voient Scrum que de façon partielle :
des utilisateurs brimés par leur DSI, pensent que Scrum
peut accueillir et favoriser les changements. Ce qui les amène à
penser qu’ils peuvent tout changer tout le temps et à n’importe
quel moment
des managers se disent qu’avec l’agilité, il leur sera plus
facile de demander à leur équipe de traiter une urgence par le
biais d’heures supplémentaires…

31
Scrum n’est pas une méthode tout terrain
Scrum n’est pas la solution pour tous les types de développement.
Et ses échecs sont liés à la culture d’entreprise.
Si vous développez des applications qui ne sont pas complexes.
Scrum n’est pas le meilleur choix
Si votre organisation est dans une culture du contrôle et que vous
n’êtes pas en mesure de promouvoir le changement radical
nécessaire, Scrum n’est pas pour vous
Si vous travaillez dans l’urgence et que vous n’êtes pas en
capacité de réduire les perturbations, vous n’arriverez pas à
focaliser l’équipe sur un sprint sans qu’elle soit perturbée. Dans ce
contexte d’urgence permanent, Scrum n’est pas recommandé

32
Scrum évolue
 Parfois les gens pensent « faire du
scrum », mais leur référence à Scrum
n’est pas la bonne. Ce qui peut
expliquer leur difficulté. Ils ont lu un
manuel, ou suivi une formation, il y a
quelques années….
 SHU – HA - RI

33
BENEFICES PROPOSEES PAR L AGILITE

34
POURQUOI CELA MARCHE
 Priorité à ce qui a le plus de valeur, à ce qui est le
plus important
 Démarche itérative, incrémentale et adaptative
 Des interactions et de la communication
 De la visibilité
 De la motivation et de la satisfaction dans les
équipes
 Un produit opérationnel très tôt Une réactivité face
au changement

35
MAIS CE N’EST PAS
L’ABSENCE DE REGLE
La discipline est indispensable
Les processus sont indispensables
L’ABSENCE DE DOCUMENTATION
Il faut des spécifications
MAGIQUE
Cela ne fonctionne pas dans tous les
contextes
Il n’y a pas de checklist de scrum

LEAN, XP, KABAN, SCRUM
36
LEAN
XP
KANBAN
SCRUM
Pratiques d’Ingénierie logicielle Gestion des production des flux Framework de développement logiciel

EXERCICE « NON/ OUI, ET….. »
40

Réflexions
Pourquoi utilisons nous Scrum, quels problèmes voulons nous
résoudre ?
41

Framework Scrum
43
 Rôles
Dev Team
Product Owner (PO
Scrum Master (SM)
 Cérémoniaux
Sprint Planning
Sprint
Revue de Sprint
Rétrospective de Sprint
 Artefact
Product Backlog
Sprint Backlog
Burdown Chart

Réflexions
Chaque groupe doit discuter des qualités nécessaires pour
assurer d’un des 3 rôles.
44

Acteurs scrum – Importance des gens
46
On privilégie la confiance au contrôle et on favorise
l’auto gestion plutôt que le pouvoir du chef
Scrum est associé à 5 valeurs : focus, ouverture,
respect, courage et engagement.
Le focus, c’est la volonté de se concentrer sur un
sprint. Pendant le sprint, l’équipe a le focus sur
l’objectif qu’elle a défini lors de la planification de
sprint

47
Acteurs Scrum – Intérieur et extérieur
Scrum présente une distinction nette entre ceux qui font et ceux
pour qui c’est fait. Les gens qui font constituent l’équipe Scrum. Les
autres sont appelés des parties prenantes (stakeholders)
Parties prenantes (stakeholders). Le développement d’un produit
est réalisé pour le développement d’une société. On y trouve des
utilisateurs, des clients mais aussi des sponsors, des représentants
des utilisateurs, des marketeurs, commerciaux, des managers….
Equipe. L’Equipe Scrum est composée des personnes qui
contribuent à produire un résultat à chaque sprint. Il y a 3 rôles :
Product Owner (PO), Scrum Master (SM) et le Developement Team
(DT)

49
Development Team – Equipe
 Taille. Pour que Scrum reste efficace, le nombre de
personnes dans une équipe doit rester limité. Max 7
personnes.
 Auto – organisation. C’est l’équipe qui réalise le produit,
en développant un nouvel incrément à chaque sprint.
Elle est investie du pouvoir et de l’autorité pour le faire de
la façon qu’elle estimera la plus efficace.
 Pluridisciplinarité. Scrum doit posséder en son sein toutes
les compétences nécessaires pour finir le travail dans un
sprint. Par exemple, pour le développement de logiciel,
on regroupera des compétences de définition de
produit, d’expérience utilisateur (UX), architecture de
logiciel, de développement et de tests

50
Développement Team – Développeur
 Responsabilité. En tant que membre
d’une équipe auto gérée, le dev est
responsable de ce qu’il fait devant ses
pairs. Ce qu’il fait est décidé en
commun avec ses pairs.
 Sélection. Pour constituer l’équipe, on
prend les personnes les plus qualifiés et
qui acceptent le jeu collectif

51
Development Team – L’Expert
Qui sont ils ? Un expert est une
personne qui aide l’équipe à
produire un résultat. Il dispose de
compétences que l’équipe ne
possède pas. Expert fonctionnel ou
expert technique.

53
Product Owner – Responsabilités du
PO
Le PO agit à la fois sur la stratégie et la tactique. Il prend des
décisions de niveau stratégique qui relève du comité de pilotage.
Partager vision. Le PO doit avoir une bonne vision du produit. Il doit
définir : la raison du produit, l’objectif de la prochaine release, les
impacts attendus sur les acteurs, et liste des fonctionnalités.
Affiner le produit. Le PO définit le contenu du produit. Il définit les
fonctionnalités requises, collectées auprès des parties prenantes et
mise dans une liste, product backlog
Planifier. Le PO définit l’ordre dans lequel les parties du produit seront
développées. Il alimente l’équipe avec les fonctionnalités à
développer, en s’efforçant de maximiser la valeur.

54
Product Owner – Compétences souhaitées
Bonne connaissance métier. Le business ou le cœur
métier. Cela désigne un domaine de connaissances en
relation avec les utilisateurs du produit. Une bonne
connaissance du métier est fondamentale pour le PO.
Maîtrise des techniques de définition du produit. Le PO
doit maîtriser des techniques de collecte des besoins et
de leur transformation en éléments du backlog
Autorité.
Aptitude à la négociation.
Esprit ouvert au changement

55
Product Owner – Choisir le PO d’une équipe
Une personne disponible
Le travail nécessite une participation d’au moins 3 heures
par jour à la disposition de son équipe. Plus la fin d’une
release se rapproche, plus le temps que le PO devrait
consacrer à son équipe augmente.
Exemple : Pour un sprint de deux semaines, le PO :
 réunion de planification de sprint : environ deux
heures
 Mêlées quotidiennes, 2 fois par semaine (minimum)
 Affinage : environ 3 heures
 Revue de sprint et rétrospective : 1 heure chacune
En plus de participer aux réunions, le PO doit
également : affiner seul le backlog, ajuster les
priorités, répondre aux questions produit, conditions
d’acceptation, vérifier terminaison d’une user story

56
Product Owner – Choisir le PO d’une équipe
Collaborer avec l’équipe. S’installer dans le même
lieu que l’équipe pour répondre à ses questions. En
collaborant avec l’équipe, le PO apprend à écouter. Il
comprend mieux leurs préoccupations de délai et de
qualité
S’impliquer dans l’acceptation du fini. Le PO doit
fournir les conditions qui permettent de s’assurer que
ce qu’il demande est terminé. Lors des séances
d’affinage, le PO formule à l’équipe le comportement
qu’elle attend d’une fonctionnalité. Ensemble, ils
identifient les conditions d’acceptation.

58
Scrum master – Responsabilités du scrum
master
Le Scrum master (SM) est une personne dans l’équipe scrum qui
se met à son service, pour faciliter la réalisation des travaux
demandés par le PO, en appliquant Scrum
Servir l’équipe. Une des missions du SM est de motiver l’équipe
pour qu’elle s’auto organise. Il fait tout pour que l’équipe
progresse.
Il se produit toujours des événements imprévus pendant un
développement. Certains sont susceptibles de ralentir ou de
bloquer le travail de l’équipe. Ex : un développeur malade, un po
injoignable, le serveur qui crash etc.. C’est au SM d’éliminer ces
obstacles.
Appliquer Scrum

59
Scrum master – Compétences
souhaitées
Bonne connaissance de Scrum.
Aptitude à comprendre le fonctionnel et la technique. Une expérience dans le
métier permet au SM de mieux communiquer avec le PO. Des bonnes
compétences techniques lui permettent de mieux appréhender les problèmes
rencontrés par son équipe.
Facilité à communiquer. Des talents de communication sont nécessaires car le
SM est amené à discuter fréquemment avec l’équipe et la direction.
Capacité à guider. Il influence l’équipe. C’es un meneur, un guide qui sait créer
les conditions pour que l’équipe soit motivée, pour qu’elle arrive au résultat. Mais
il doit arriver à ses fins par la conviction sans imposer ses décisions.
Talent de médiateur en cas de conflit entre les personnes
Ténacité. Un SM n’abandonne pas à la première adversité. Il se montre opiniâtre,
il poursuit sa quête jusqu’à l’élimination de ce qui freine l’équipe.
Etre au service de l’équipe. Le SM n’est pas un chef, ne commande pas. Il est au
service de l’équipe . Il offre son support. Son humilité consiste à ne pas se mettre
en avant.

Comment ces rôles
travaillent-ils ensemble?
60

Rôles organisationnels
Scrum Team Roles

Le ScrumMaster travaille avec le
Product Owner
62

Le ScrumMaster travaille avec
l’Equipe
63

Le Product Owner travaille avec le
client
64

L’Equipe travaille avec l’utilisateur
final
65

Le ScrumMaster travaille
avec le Manager
66

Le Product Owner a besoin de
connaître ce que le marché
(l’utilisateur final) souhaite.
67

69
Réunion de planification de Sprint

70
Réunion de planification de Sprint – Les
activités
C’est l’équipe qui planifie. Toute l’équipe participe à la
planification
Se mettre dans le contexte du sprint. Le PO rappel les objectifs
du sprint. Il donne la liste des user stories
2 temps. La première partie permet de définir le périmètre et le
but du sprint. Et, la seconde partie est consacrée à l’identification
des tâches nécessaires et à leur estimation. Pour chaque user
story, nous allons vérifier la capacité de l’équipe à la réaliser
pendant le sprint
Lancement du sprint. Ce sont les membres de l’équipe qui
prennent eux-mêmes les tâches, en respectant l’ordre des
stories.

71
Réunion de planification de Sprint – Le résultat
de la planification de sprint
Plan de sprint. Ce plan contient la liste des stories avec les leurs
tâches, sous une forme visible et facilement accessible. Une
tâche est décrite simplement :
- Un nom et de la description du travail à effectuer.
- La personne qui prend la tâche pour la réaliser
PBI : Product Backlog Item

73
Daily Scrum– Réunion quotidienne
Daily scrum meeting en Angleterre ou Daily ou encore mêlée
quotidienne en France.
Pour réussir le sprint. La mêlée est un point de rencontre où
tous les membres de l’équipe répondent à 3 questions simples.
Elle sert à optimiser la probabilité que l’équipe atteigne
l’objectif du sprint. La mêlée est de l’inspection et de
l’adaptation au quotidien.
La mêlée appartient à l’équipe. Toute l’équipe participe à la
réunion, y compris le PO. Le SM s’assure que la réunion a lieu
et que les règles sont respectées.
Un cérémonial balisé : même lieu, même horaire, 15 min

74
Daily Scrum– La mêlée classique
L’Equipe se réunit. Chacun s’exprime à tour de rôle sur les trois
questions : ce qu’il a fait, ce qu’il va faire, et ce qu’il empêche
d’avancer.
Répondre à 3 questions :
Qu’ai-je fait hier ? Il s’agit pour chaque membre de
l’équipe, de parler des tâches sur lesquelles il a travaillé. Il
indique si la tâche est encore en cours ou si elle est finie.
Que vais-je faire aujourd’hui ? Il présente les tâches sur
lesquelles, il prévoit de travailler. Pour chacune d’elles, il
indique en quoi elle consiste et s’il pense la finir dans la journée.
Quels sont les obstacles qui me freinent dans mon travail
?

75
Daily Scrum– La mêlée classique - Tableau

77
Revue Sprint – Les activités de la revue
de sprint
Voici un enchaînement des activités de la réunion :
 Avant la revue, l’équipe prépare tout ce qui est
nécessaire pour que la démo se passe bien
Au début de la réunion, le PO statue par rapport à
l’objectif du sprint
Ensuite, pour chaque story finie, l’équipe effectue une
démo et collecte le feedback sollicité
On profite de la présence des parties prenantes pour
évaluer l’impact obtenu avec le produit et prendre
une décision sur son avenir

79
Rétrospective de sprint Sprint –une pratique
d’amélioration continue
A partir des expériences tirées sur le sprint courant. L’équipe
identifie ce qui marche bien pour elle, ce qui marche moins bien,
et trouve collectivement ce qu’il faut modifier à sa façon de
travailler.
Inspection et adaptation. A la fin d’un sprint , la rétrospective est
le moment où l’équipe se pose des questions sur la façon dont
elle a travaillé. Cela constitue un des piliers de l’approche
empirique. L’inspection conduisant à des adaptations, en
fonction du ressenti sur le sprint qui se termine
Un moment de réflexion collective. Une rétrospective permet de
capitaliser sur les pratiques qui ont marché, d’éviter de refaire les
mêmes erreurs, de partager les différents points de vue et de
s’adapter aux nouvelles avancées


80
Revue Sprint – Les activités de la rétrospective
de sprint
Voici un enchaînement des activités de la réunion
L’animateur, en général le SM, s’assure que l’environnement est
propice à l’expression de tous. Il s’agit de s’assurer que tout le
monde se sent en confiance et pourra s’exprimer librement
pendant la rétro
L ’équipe commence par collecter des informations sur le sprint
passé. Avant de chercher à améliorer les pratiques, il convient
de collecter le ressenti des participants sur ce qui s’est passé
pendant le sprint qui s’achève
Identifier des ides d’amélioration. Une bonne pratique consiste
à collecter les points d’amélioration individuellement, puis les
regrouper.

83
Avant de penser à travailler en sprints, il faut que le Product Backlog
soit “prêt”. C-à-d un juste niveau de granularité, Un Bon product
backlog est DEEP.

EXERCICE SCHEMA
SCRUM
Les équipes vont
représenter tous les
éléments de SCRUM de
manière visuelle
86

EXERCICE PROJET
SCRUM – BALLES
88
OBJECTIF : COMPRENDRE PRINCIPES DE SCRUM

REGLES SCRUM – BALLES 1/2
89
 Chacun est membre d’une équipe
 Entre chaque participant, la balle doit voler (« air-time »)
 Chaque balle doit être touchée par chaque membre de l’équipe
 Vous ne pouvez pas passer la balle à votre voisin ou voisine de
gauche ou de droite
 Chaque cycle de balle doit démarrer et se terminer par la même
personne
 Une balle qui tombe par terre est perdue : elle doit recommencer
 Le cycle Il y aura 5 itérations
 Les seules règles sont celles écrites ci-dessus

PLANNING – BALLES 2/2
90
• Explication des règles
• 2 min Création des équipes
• 2 min Organisation de l’équipe
• 1 min Estimation du temps
• 2 min itération
• 1 min debriefing de l’itération Après les 5 itérations :
• 10 min de debriefing commun

DEBRIEF BALL POINT
91
• PAS DE TEST
• ON PEUT/ON NE PEUT PAS
• ECOUTE < ======> ECOUTE
• ON ESSAIE
• 3 PILIERS : INSPECT/ADAPT/TRANSPARENCE
• PDCA

LE BALL GAME 2/2
92
QUE NOUS APPREND CE JEU ?
• Bâtir sur les idées de tous est plus
motivant pour l’équipe.
• Contraintes
• Pour être le plus efficace : garder un
rythme et éviter les interruptions.

“La difference entre
cinema français et cinema
belge”

Recueillir des besoins -Constat
95
 2 chiffres illustrent les enjeux et la complexité
des besoins :
- le 1er
concerne le taux d’utilisation des
fonctionnalités développées sur les projets. On
constate que plus de 50% des fonctionnalités
livrées sont jamais ou rarement utilisées
- Le second indique, que plus de 56% des défauts
constatés sont liés à la qualité des besoins
recueillis en amont.

Recueillir des besoins – Pourquoi est si difficile ?
96
 Mauvaise communication. Ceux qui demandent le
produit ne sont pas toujours ceux à sui le produit est
destiné
 La nature des relations entre la MOA et le MOE. Les
acteurs se protègent cette répartition de rôles pour ne
pas être montrés du doigt en cas d’échec
 L’illusoire exhaustivité. On demande au client de
décrire la totalité des fonctionnalités du produit. Mais
dans la plupart des cas, le client demande des
modifications
 Défaillance du client. Indisponibilité ou manque de
compétences. La MOE doit définir le besoin.
Dangereux.

Techniques de recueil des besoins
97
L’analyse de l’existant. Il s’agit ici d’examiner les applications existantes
pour en évaluer les forces et les faiblesses, et de mettre au point la
stratégie d’évolution.
L’observation du comportement de l’utilisateur en situation. Ce travail
est efficace pour bien comprendre le comportement des utilisateurs sur
leur poste de travail ou autour du poste de travail. En notant toutes les
astuces qu’u utilisateur trouve pour compenser les manques d’une
application. On prend les mesures de ces limites et des failles qu’il faudra
combler.
Le brainstorming (en amont). Idéal pour « défricher » les besoins encore
flous et mal organisés des utilisateurs lors du démarrage d’un projet.
Le benchmark. Ou l’analyse de la concurrence. C’est un des meilleurs
moyens de découvrir ses propres besoins. Aussi, une analyse des outils du
marché ouvre le champs des fonctionnalités possibles
L’interview

Travailler votre vision produit
98
Construire le bon produit n’est pas facile. Il faut à a fois que le produit apporte de la
valeur réelle à ses utilisateurs et qu’il soit d’une qualité irréprochable.
La vision du produit est la réponse opérationnelle à la stratégie business de
l’entreprise. Elle fait le pont entre cette stratégie et la roadmap du produit (release
planning, story mapping, backlog).
La vision produit est la réponse aux questions suivantes : quel problème essayons
nous de résoudre ? Pour qui résolvons nous ce problème ? Quelle solution apportons
nous ?
Avoir une vision produit claire permet entre autres :
- d’accorder les parties prenantes (marketing, finance, équipes
techniques)
- de garantir la motivation des équipes
- d’anticiper les choix technologiques en fonction de cette vision
Dans une équipe agile, la vision produit est encore plus importante que pour une
équipe classique. Avant chaque sprint ou avant le développement de chaque
fonctionnalité, les membres de l’équipe doivent se demander si leur travail répond
bien au « Product statement ». Si ce n’est pas le cas, c’est que l’énergie est utilisée à
bon escient

Travailler votre vision produit :
Lean Canvas
Qu’est-ce que c’est ?
Trame de 9 cases
Créé par Ash Maurya
(adapté du Business
Model Canvas)
Pour l’entreprise
Objectifs pour une startup
•
Synthétiser le Business
Model en 1 slide
•
Aligner les parties prenantes en
début de projet
•
Identifier les hypothèses les
plus risquées à valider
•
Identifier les hypothèses pour
créer une culture de
l’expérimentation

Risque produit Risque client/marché
Le Lean Canvas
Problème Segment
de clients
Proposition
de valeur
unique
Indicateurs
clés
Solution
Canaux
Avantage
déloyal
Structure de coûts Source de revenus
/gains

Le cas « Réseau Social d’Entreprise »
Le projet de RSE (Réseau Social d’Entreprise)
Exercice pratique
Votre projet
À chaque étape, remplissez la case de votre Lean Canvas

Problème Segments de
clients
• Collaborateurs
de l’entité
• Les experts
• Les managers
• (pas les autres
filiales et les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition
de valeur
unique
Indicateurs
clés
Solution
Canaux
Avantages
concurrentiels
Structure des coûts
Sources de revenus /
gains
1
Pour qui ?
Distinguer les
types : utilisateur
/ payeur /
influenceur
(optionnel) Qui
seraient les plus
faciles à convaincre
au début ?
Affiner le ciblage
Segments client pour un Projet RSE (Réseau Social d’Entreprise).
Les Early adopters sont les premières personnes intéressées par le projet. Et il
faut les convaincre rapidement

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. Etre au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions
de couloir :
aléatoire
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition
de valeur
unique
Indicateurs
clés
Solution
Canaux
Avantage
concurrentiels
gains
2
Pourquoi ?
Les 3 principaux
problèmes que vous
comptez résoudre
Distinguer les
problèmes d’une
cible spécifique
(optionnel)
Alternatives
actuelles et leurs
limites
Dans cette case problème, identifiez les 3 principaux problèmes que vous
voulez résoudre pour vos cibles.
Identifiez ensuite les problèmes des alternatives actuelles. Des concurrents
potentiels, ou des contournements manuels effectués par les utilisateurs.
Ceci est une clé pour formuler des propositions de valeur

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
Des réponses à vos
questions par vos
collègues
Concept de haut
niveau :
« la machine à café
virtuelle du groupe »
Indicateurs
clés
Solution
Canaux
Avantage
cocurrentiel
Structure des
coûts
gains
Proposition de valeur unique
2 1
La promesse de bénéfice
du résultat final
Pourrait être votre slogan
accroche
Se concentrer sur
problème n°1
3
La proposition de valeur est la promesse de bénéfices que vous faites à votre
cible pour les intéresser. Faites abstraction des fonctionnalités.
La proposition de valeur est la clé de voûte de votre projet. A partir de ce point,
passez peu de temps sur les cases restantes, qui risquent d’être remises en
cause au prochain changement de modèle.

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
« la machine à café à
l’échelle du groupe »
Indicateurs
clés
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
Avantage
concurrentiel
gains
Solution
2
1
3
4
Les 3 principales
macro-fonctionnalités
ou services
À remplir après les
3 autres cases
Notez les 3 fonctionnalités ou services clés qui expliquent
comment vous remplirez votre proposition de valeur

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
Avantage
concurrentiel
Sources de revenus / gains
• Capitaliser sur les bonnes pratiques
• Casser les silos entre départements
• Retenir les experts
2 1
3
4
5
Revenus quantitatifs si BtoB ou
BtoC
(distinguer revenus par offre)
Et/ou gains qualitatifs (image,
satisfaction)
Notamment pour BtoE

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
• Intranet
• Communautés de
Pratiques
• Responsables
d’équipes
Avantage
concurrentiel
Canaux
2 1
3
4
5
Canaux par lesquels
•
on vend
•
on fait connaître le produit
•
on récupère le feed-back
6
Listez les canaux de communication dans les 2 sens avec vos
cibles :
Pour acquérir des prospects (on et offline) ;
Pour obtenir du feedback de vos utilisateurs
(fonctionnalités du site, réseau de distribution, support client,
sondages, …).

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
À 12 mois :
• 2.000 lecteurs
actifs (dans la
semaine)
• 200 contributeurs
actifs (dans le
mois)
• Enquête
satisfaction > 3,5/5
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
• Intranet
• Communautés de
Pratiques
• Responsables
d’équipes
Avantage
concurrentiel
Sources de revenus/ gains
Indicateurs clés
2 1
3
4
5
•
Sur les activités utilisa
( « métriques pirates »
•
Sur le succès (résolut
du problème)
6
7
Max 5 indicateurs: ceux q
signalent l’adoption utilisa

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
À 12 mois :
• 2.000 lecteurs
actifs (dans la
semaine)
actifs (dans le
mois)
• Enquête
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
• Intranet
• Communautés de
Pratiques
• Responsables
d’équipes
Avantages
• Intégration avec
SharePoint
• Application
installée sur tous
les postes
Avantage déloyal
2 1
3
4
5
•
Atouts
alternativesdifficilement
copiables que les n’ont
pas
6
7
8
 Pensez aux atouts uniques de votre entreprise qui vous permettent de proposer
une meilleure proposition de valeur que vos concurrents
 Pour une application interne, la « concurrence » sont en fait les outils actuels.
L’avantage « concurrentiel » peut être le réseau des managers, le helpdesk, ou
l’intégration dans des outils existants

Problème
1. Obtenir de l’aide
pertinente
rapidement
2. être au courant/
faire de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives actuelles :
• Mailing lists : trop
fermées
• Mail 1to1 : limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
À 12 mois :
• 2.000 lecteurs actifs (dans la
semaine)
• 200 contributeurs actifs
(dans le mois)
• Enquête satisfaction > 3,5/5
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
• Intranet
• Communautés de
Pratiques
• Responsables
d’équipes
Avantage déloyal
SharePoint
• Application
installée sur tous
les postes
• Build : x k€ (cadrage, conception,
développement, validation, déploiement)
• Run : x k€ / an (hébergement, maintenance,
évolutions, support)
Sources
de
revenus
/
gains
•
Capitaliser
sur
les
bonnes
pratiques
•
Casser
les
silos
entre
départements
•
Retenir
les
experts
2 1
3
4
5
6
7
8
9
•
Coûts fixes
•
Coûts variables
 Assurez vous de la pertinence éco en
évaluan un budget global sous la forme
TCO (Total Cost of Ownership.

Problème
1. Obtenir de
l’aide
pertinente
rapidement
2. être au
courant/ faire
de la veille
3. Trop de mails
4. Experts : être
reconnus
Alternatives
actuelles :
• Mailing lists :
trop fermées
• Mail 1to1 :
limité
• Discussions de
couloir : limité
Segments de
clients
• Collaborateurs
du groupe
(incluant filiales)
• Les experts
• (pas les
externes)
Early adopters :
• Collaborateurs
de la DSI
Proposition de
valeur unique
questions par vos
collègues.
Concept de haut
niveau :
Indicateurs clés
À 12 mois :
• 2.000 lecteurs
actifs (dans la
semaine)
actifs (dans le
mois)
• Enquête
Solution
1. Écrire un post
2. Lire
3. Être notifié
Canaux
• Intranet
• Communautés de
Pratiques
• Responsables
d’équipes
Avantage déloyal
SharePoint
• Application
installée sur tous
les postes
Structure
des
coûts
•
Build
:
x
k€
(cadrage,
conception,
développement,
validation,
déploiement)
•
Run
:
x
k€
/
an
(hébergement,
maintenance,
évolutions,
support)
Sources
de
revenus/
gains
•
Capitaliser
sur
les
bonnes
pratiques
•
Casser
les
silos
entre
départements
•
Retenir
les
experts
Lean canvas
2 1
3
4
5
6
7
8
9
???
???
???
??
??
??
??
??
??
Ce ne sont que des hypothèses à valider !

Atelier Lean Canvas – Projet pour contrer UBER
113
 Préparez une affiche grand format du canvas ;
 Initialisez-le en collant vos propositions sur des notes repositionnables
 Introduisez l’atelier : expliquez l’objectif (être aligné sur une vision
commune initiale, qui pourra s’affiner et évoluer selon les retours
utilisateurs), présentez le canvas ;
 « Pitchez » votre vision : « pour <telle cible> qui a <tels problèmes>, le
projet <XY> propose <telle proposition de valeur> grâce à <telles
fonctionnalités>. Notre avantage clé par rapport à <telles alternatives>
est <tel avantage concurrentiel>. Nous les toucherons par <tels canaux>.
Les gains sont <gains quantitatifs et qualitatifs>. J’estime le budget à
<coûts>. Les indicateurs clés de performance seront <indicateurs> ;

Construisez votre roadmap
114
La roadmap est l’itinéraire entre la ou se trouve votre
produit aujourd’hui et la destination définie dans votre
vision
Il propose une suite d’étapes intermédiaires et les
dates prévisionnelles correspondant au
franchissement de ces étapes
La roadmap comporte principalement des objectifs
chiffrés associés aux moyens à mettre e œuvre pour les
atteindre

Construisez votre roadmap
115
Pour construire votre roadmap, vous
pouvez vous appuyez sur le story
mapping.
Le story mapping permet d’identifier et
de structurer les fonctionnalités suivant 2
axes : un axe horizental découpant le
parcours utilisateur et un axe vertical
détaillant ces étapes en fonctionnalités

Construisez votre roadmap : story mapping
116
Lors de l’atelier de story mapping, il est
nécessaire que toutes les parties prenantes
soient présentes : marketing, design, technique
Il s’agit de bien de bien prendre en compte les
attentes et les contraintes de chacun. Et
d’obtenir un consensus et un engagement sur
votre roadmap

117
 Commencez par réintroduire la vision, les objectifs et les personas
 Puis, initiez la story map en inscrivant ce derniers sur le mur (sous
forme de post it)
Par exemple : pour développer les ventes d’un site en
ligne, nous identifions 3 personas : l’acheteur économe, le fan de
la marque, et l’employé. Chacun de ces acteurs utilise le produit
d’une façon différente. L’enjeu consiste à dégager les étapes clés
de leurs parcours utilisateur et dé réfléchir comment les optimiser
pour influencer positivement l’usage du produit
 Enfin s’ensuite, une phase de discussion sur les fonctionnalités à
mettre en place. A cet instant de l’éxercice, il ne s’agit pas de
reteindre les idées, mais d’envisager toutes les possibilités

118
Dans un deuxième temps, vous pouvez
regrouper les fonctionnalités en MMFs
(Minimum Marketable Features). Puis,
ordonner ces dernières pour définir des
releases. Ce sont des itérations du produit,
apportant chacune une nouvelle valeur
supplémentaire à l’utilisateur et ayant une
cohérence fonctionnelle

119

120
Nous arrivons à la dernière étape, la création de la
roadmap proprement dite à partir de la story map.
En pratique, vous allez extraire cette roadmap de la
story map, chaque MMF correspondant à une ou
plusieurs releases.

121

122
Artistes et Spécificateurs

123
Artistes et spécificateurs – Régles du jeu
1. 5 personnes par équipe (2 spécifieurs et 3
artistes)
2. Les Spécifieurs et les Artistes sont séparés
3. Les Spécifieurs ECRIVENT les instructions aux
Artistes (pas de dessin). Les spécifieurs NE
PEUVENT PAS parler aux artistes
4. Les Artistes peuvent écrire des messages en
retour. Les artistes NE PEUVENT PAS parler aux
spécifieurs.
5. Les spécifieurs peuvent se parler entre eux (hors
présence des artistes).

124
Structurer le Product Backlog – Outil pour
l’équipe
Une liste unique. Un backlog est simplement une liste ordonnée des
choses à faire par l ’équipe. Cette dernière trouve dans le backlog ce
qui est d’ordinaire dispersé dans plusieurs documents ou outils. C’est
un outil de pilotage de projet.
Une liste publique. Le PB est un outil élaboré par le PO, mais c’est
l’outil de toute l’équipe. Ce dernier doit être visible des parties
prenantes. Tout le monde y a accès pour favoriser la transparence,
faciliter le feedback qui se concrétise par l’ajout de nouvelles idées
Une liste ordonnée
Changements permanents. Dans un dev agile, le chgt est possible,
même encouragé. Le backlog n’est pas figé, il n’est jamais complet
tant que le produit vit. Il est élaboré dans une forme initiale pendant le
sprint 0, puis il évolue constamment (ajout, modif, suppression
d’éléments).

125
Structurer le Product Backlog – Hiérarchie des éléments
backlog

126
EN TANT QUE < ROLE>
JE VEUX < FONCTIONNALITE>
AFIN DE < RAISON/ Objectif Business>
Structurer le Product Backlog – La User Story

En tant qu’utilisateur
Je souhaite réserver une place pour
le prochain tournoi de poker
Afin de pouvoir jouer
Je souhaite pouvoir créditer mon
compte en ligne
Afin de pouvoir parier
En tant que joueur adictif
Je souhaite un lien pointant sur un
site d’assistance comportementale
Afin de pouvoir contrôler mes
pulsions
En tant que « High Roller »
(Baleine)
Je souhaite une table ouverte aux
paris > à 10K€
Afin de pouvoir jouer gros
127
Structurer le Product Backlog – La User Stry

Je souhaite réserver une place
pour le prochain tournoi de
poker
En Vérifier qu’un même
utilisateur ne peux pas
réserver plus d’un siège par
tournoi
Vérifier que l’utilisateur peut
annuler sa réservation jusqu’à
l’ouverture du tournoi
Vérifier que l’utilisateur reçoit
RECTO VERSO
128
Structurer le Product Backlog – La User Story –
conditions acceptations

EVITER LES ZONES D’OMBRE
Je souhaite réserver une place
pour le prochain tournoi de
poker
Je souhaite pouvoir réserver une
place pour le prochain tournoi de
poker jusqu’à la dernière minute
Je souhaite recevoir un email de
confirmation
Afin d’être sûr d’être inscrit
129

PROSCRIRE LA TECHNIQUE
En tant que système de paiement
Je souhaite que les échanges
soient effectués en XML
En tant que programmeur
Je souhaite disposer d’une API
pour supprimer les doublons dans
la base de données
Afin de faciliter le développement
Ce type d’informations est à réserver pour le Sprint Backlog
130

131
Structurer le Product Backlog – Workflow
story
5 C de la vie d’une User Story
Un jour, une personne a une idée de story, et la note sur une Carte (ou post it)
Le PO et l’équipe affinent cette story, afin qu’elle puisse être réalisée en un sprint,
au cours d’une Conversation
L’Equipe apporte sa confirmation qu’elle est prête
L’Equipe réalise la story pendant un sprint, en tenant une nouvelle Conversation
avec le PO, sur son acceptation
Le PO apporte sa Confirmation qu’elle est finie
Idée Affinage prête Réalisation finie

Atelier Ecriture Backlog
132
Alternative au taxi, Raid doit être une application qui donne un
accès instantané à un large réseau de voitures avec chauffeurs
(VTC) sur Paris et sa banlieue.
Cible : Voyageurs d’affaires et citadins des grandes villes.
Raid doit permettre la réservation des courses en quelques
clics. Le passager et le chauffeur doivent pouvoir être géo
localisés au moment d’une demande de course par le client.
Le système de paiement doit être sécurisé (PCI DSS) afin de
garantir des transactions sûres. Le client doit connaître à
l’avance le prix et l’itinéraire de sa course. Possibilité de
recevoir les factures par mail.
Raid doit proposer un large éventail de fonctionnalités pour un
usage personnel ou professionnel.
.

Exercice Valeur Métier
Chambre 1
Chambre 2
Salon
Sanitaire
Cuisin
e
Entrée
Véranda
Pièce FISPE
Hall
Cuisine
Salon
Sanitaire
Chambre 1
Chambre 2
134

Exercice Valeur Effort
Chambre 1
Chambre 2
Salon
Sanitaire
Cuisin
e
Entrée
Véranda
Pièce FISPE
Hall
Cuisine
Salon
Sanitaire
Chambre 1
Chambre 2
135

PRODUCT BACKLOG HIERARCHISE
136

Management de projet
Limite du modèle Agile (Scrum)
140
Combinaison normale :
Combinaison envisageable :
140

141
Combinaison envisageable :
141

142
Combinaison à proscrire :
142

Brainstorming
 COMMENT ORGANISER L’AFFINAGE DU BACKLOG ?
 AVANTAGES ET INCONVENIENTS DES OUTILS SOFTWARE ET
MANAGEMENT VISUEL ? LEQUEL CHOISR ?
 COMMENT FAIRE COHABITER SCRUM ET OFFSHORE?
 COMMENT GERER LES BUGS EN SCRUM ?
 DEFINITION OF DONE POUR CHAQUE TACHE D’UN PO
143

145
Outils agiles – Les Post it
 Quand on dispose d’un espace de travail
avec un mur ou un tableau, le post it est
l’outil le plus efficace pour communiquer
 Le Post it est recommandé pour le suivi d’un
sprint
 Les Pos ti permettent également à faciliter le
travail collectif et créatif lors des différents
ateliers du backlog

146
Outils agiles – Les outils
informatiques
 Les tableurs. Selon plusieurs sondages, l’outil
informatique le plus utilisé dans les projets agiles,
reste Excel. (Voir exemple)
 Les bugtrackers. Redmine.
 Les outils agiles. Jira

Transformer les
Organisations
147

148
Transformer les organisations – Pourquoi se
transformer ?
 Transformation agile. On parle de transformation agile, quand
l’organisation prend conscience que, pour obtenir des bénéfices
attendus, elle doit changer de structure, voire changer de culture.
L’agilité est la capacité d’une organisation à fournir tôt et souvent des
services ayant un véritable impact sur ses utilisateurs. La
transformation agile correspond à la démarche que met en œuvre
une organisation pour acquérir cette capacité.
 Origines de la transformation. C’est l’apparition d’obstacles
d’organisation qui va déclencher la transformation.
 Obstacles d’organisation. Les obstacles identifiés par une équipe, qui
la freinent ou le bloquent dans le développement du produit, sont
variés, ils proviennent : pratiques de scrum, pratiques
complémentaires à Scrum, résistance à l’organisation au
changement, type de gouvernance. Pour les 2 premiers, l’équipe
peut trouver des solutions. Et, pour le reste, voir le management. Voir
SHU- HA - RI

149
Transformer les organisations – Pourquoi se
transformer ?
 Un problème de culture. La culture d’entreprise est
souvent négligée par le management. Privilégiant
les objectifs financiers à court terme, les entreprises
ne cherchent pas à devenir des collectifs
organiques, cad des regroupements de personnes
complémentaires, organisés autour d’un sentiment
d’appartenance. La culture d’entreprise est un
paramètre essentiel de la transformation de l’agilité.
 La transformation risque s’être longue et délicate
pour une organisation plus dans la culture du
contrôle, que une davantage focalisée sur la
culture de de la compétence individuelle.

150
Transformer les organisations – Comment se
transformer ?
 Avec qui ? Dans une transformation agile, il est
préférable d’entraîner toutes les personnes qui sont
sur le terrain, et de procéder par invitation pour les
actions concrètes
 Définir l’objectif de la transformation. Qu’est ce qui
pousse l’organisation à adopter à Scrum ? Quel est
son objectif en introduisant l’agilité ?

FORCE ET FAIBLESSES DE SCRUM
152
Forces :
Scrum est axé sur la qualité du livrable.
L’avancement est facilement mesurable et clairement visible.
L’équipe est auto organisée, favorisant la motivation et éliminant la
surcharge de travail
car elle réalise en fonction de ses capacités.
Le risque est détecté très rapidement.
L’équipe peut prendre des décisions.
Suppression de de la notion de hiérarchie pouvant être un frein à certaines
personnes.
• Faiblesses :
Elle nécessite une forte implication du PO.
Elle nécessite un coût de formation non négligeable.
Des relations difficiles peuvent apparaître lors de la présence de bugs.
Le
PO peut ne pas comprendre pourquoi vous l’ajouter au PB.
Le télétravail n’est pas évident.
• Opportunités :
Scrum permet un gain de productivité par la notion de livraison
fréquente. Ce gain
permet notamment de fidéliser les clients et génère beaucoup de
satisfaction.
Scrum favorise la compétitivité.

Methodes Agiles powerpont presentation.ppt

Contenu connexe

Similaire à Methodes Agiles powerpont presentation.ppt

Methodes Agiles powerpont presentation.ppt

Notes de l'éditeur