MANAGEMENT DE
PROJET (MdP)
david.vallat@univ-lyon1.fr @DavidVALLAT
david.vallat@univ-lyon1.fr
2
david.vallat@univ-lyon1.fr
3
Definition
• Project management is the process and activity of planning,
organizing, motivating, and controlling resources, procedures
and protocols to achieve specific goals in scientific or daily
problems.
• A project is a temporary endeavor designed to produce a
unique product, service or result with a defined beginning and
end (usually time-constrained, and often constrained by
funding or deliverables), undertaken to meet unique goals and
objectives, typically to bring about beneficial change or added
value.
• The temporary nature of projects stands in contrast with
business as usual (or operations), which are repetitive,
permanent, or semi-permanent functional activities to produce
products or services. In practice, the management of these two
systems is often quite different, and as such requires the
development of distinct technical skills and management
strategies. http://en.wikipedia.org/wiki/Project_management
david.vallat@univ-lyon1.fr
4
Un peu d’histoire…
david.vallat@univ-lyon1.fr
5
Approche disciplinaire récente
FW Taylor
H Fayol
H Gantt
david.vallat@univ-lyon1.fr
6
Pourquoi gérer un projet ? (1)
• Besoin d’une méthode (poursuite ou recherche d’une
voie) car l’organisation spontanée ne fonctionne pas
(=>The Resistance)
• Planifier pour maximiser l’utilisation des ressources -
matérielles, humaines, financières (=>Ile interdite)
david.vallat@univ-lyon1.fr
7
Pourquoi gérer un projet ? (2)
Les pièges organisationnels
Levitt, B. and March, J. (1988), « Organizational Learning », Annual
Review of Sociology, vol 14, pp. 319–40.
• Knowledge in Organization = Routines
• Competency Trap
• The Innovator’s Dilemma (C. Christensen)
http://www.forbes.com/sites/stevedenning/2012/04/05/clayt
on-christensen-and-the-innovators-smackdown/
http://www.youtube.com/watch?v=35z03U3wugs
• Surpersticious Learning
http://blogs.hbr.org/2011/07/superstitious-learning/
• = GOD
COMPLEXhttp://www.youtube.com/watch?v=K5wCfYujRdE
david.vallat@univ-lyon1.fr
8
Scientific Management
david.vallat@univ-lyon1.fr
9
L’échelle d’inférence
david.vallat@univ-lyon1.fr
10
Building shared vision
• « When there is a genuine vision (as opposed to the all-to-familiar
‘vision statement’), people excel and learn, not because they are told to,
but because they want to. But many leaders have personal visions that
never get translated into shared visions that galvanize an organization…
What has been lacking is a discipline for translating vision into shared
vision – not a ‘cookbook’ but a set of principles and guiding practices.
The practice of shared vision involves the skills of unearthing shared
‘pictures of the future’ that foster genuine commitment and enrolment
rather than compliance. In mastering this discipline, leaders learn the
counter-productiveness of trying to dictate a vision, no matter how
heartfelt » (P. Senge 1990: 9).
• interview with P. Senge:
http://www.mutualresponsibility.org/science/what-is-systems-
thinking-peter-senge-explains-systems-thinking-approach-and-
principles
david.vallat@univ-lyon1.fr
11
Les phases du MdP (1)
http://en.wikipedia.org/wiki/Project_management
david.vallat@univ-lyon1.fr
12
Les phases du MdP (2)
http://en.wikipedia.org/wiki/PDCAdavid.vallat@univ-lyon1.fr
13
david.vallat@univ-lyon1.fr
14
Créativité
david.vallat@univ-lyon1.fr
15
david.vallat@univ-lyon1.fr
16
Brainstorming
david.vallat@univ-lyon1.fr
17
Mind Mapping
david.vallat@univ-lyon1.fr
18
DO
CHECK
ACT
david.vallat@univ-lyon1.fr
19
Do-Check-Act
david.vallat@univ-lyon1.fr
20
Deux applications
complémentaires du PDCA
david.vallat@univ-lyon1.fr
21
david.vallat@univ-lyon1.fr
22
Pourquoi gérer
en mode Agile ?
• An imperative for survival in a VUCA world.
• Business agility is the ability of a business to adapt rapidly and
cost efficiently in response to changes in the business
environment.
• Une présentation vidéo
:https://www.youtube.com/watch?v=OJflDE6OaSc
• History: http://agilemanifesto.org
david.vallat@univ-lyon1.fr
23
Pourquoi gérer en mode
Agile ?
http://www.venveo.com/articles/agile-vs-waterfall-project-managementdavid.vallat@univ-lyon1.fr
24
Agility = people
• All about people…
• Theory X and Y:
http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y
• Freedom Inc. http://www.amazon.com/Freedom-Inc-
Employees-Business-Productivity/dp/0307409384
• SEMCO: http://en.wikipedia.org/wiki/Maverick_(book)
• GORE:
http://en.wikipedia.org/wiki/W._L._Gore_and_Associates
• IDEO: http://en.wikipedia.org/wiki/IDEO
david.vallat@univ-lyon1.fr
25
Les valeurs du projet Agile
• Les méthodes agiles prônent 4 valeurs fondamentales (entre parenthèses, les citations du
manifeste)4 :
• L'équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans
l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle)
ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui
communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une
équipe composée d'experts fonctionnant chacun de manière isolée. La communication est
une notion fondamentale.
• L'application (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il
est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est
une aide précieuse mais non un but en soi. Une documentation précise est utile comme
moyen de communication. La documentation représente une charge de travail importante,
mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter
abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe
(on en revient à l'importance de la communication).
• La collaboration (« La collaboration avec les clients, plus que la négociation
contractuelle ») : le client doit être impliqué dans le développement. On ne peut se contenter
de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client
doit collaborer avec l'équipe et fournir un compte rendu continu sur l'adéquation du logiciel
avec ses attentes.
• L'acceptation du changement (« L'adaptation au changement, plus que le suivi d'un
plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de
permettre l'évolution de la demande du client tout au long du projet. Les premières livraisons
du logiciel vont souvent provoquer des demandes d'évolution.
• http://fr.wikipedia.org/wiki/Méthode_agile david.vallat@univ-lyon1.fr
26
Les principes du projet Agile• Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :
• La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des
fonctionnalités à forte valeur ajoutée.
• Le changement est accepté, même tardivement dans le développement, car les processus
agiles exploitent le changement comme avantage concurrentiel pour le client.
• La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux
mois, avec une préférence pour la période la plus courte.
• Le métier et les développeurs doivent collaborer régulièrement et de préférence
quotidiennement au projet.
• Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien
dont elles ont besoin et faites leur confiance quant au respect des objectifs.
• La méthode la plus efficace de transmettre l'information est une conversation en face à face.
• L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de
comptabiliser les fonctions non formellement achevées).
• Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la
non qualité découlant de la fatigue).
• Les processus agiles recommandent une attention continue à l'excellence technique et à la
qualité de la conception.
• La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes
essentiels.
• Les équipes s'auto-organisent afin de faire émerger les meilleures architectures,
spécifications et conceptions.
• À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et
ajuste son processus de travail en conséquence.. Les premières livraisons du logiciel vont
souvent provoquer des demandes d'évolution.
• http://fr.wikipedia.org/wiki/Méthode_agile
david.vallat@univ-lyon1.fr
27
Comment gérer un projet en
mode Agile (SCRUM) ? (1)
• Méthode de management agile en gestion de projet : SCRUM
http://fr.wikipedia.org/wiki/Scrum_(méthode)
• « Le terme Scrum est emprunté au rugby à XV et signifie mêlée.
• La méthode Scrum a été conçue lors de projets de développement de
logiciels.
• Le principe de base de Scrum est de focaliser l'équipe sur une partie
limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se
réalisent successivement lors de périodes de durée fixe de une à
quatre semaines, appelées sprints. Chaque sprint possède,
préalablement à son exécution, un but à atteindre, défini par le
propriétaire du produit, à partir duquel sont choisies les
fonctionnalités à implémenter dans cet incrément. Un sprint aboutit
toujours à la livraison d'un produit partiel fonctionnel. Pendant ce
temps, le ScrumMaster a la charge de former le directeur de produit,
l'équipe et l'organisation entière à la méthode Scrum. »
david.vallat@univ-lyon1.fr
28
Comment gérer un projet en
mode Agile (SCRUM) ? (2)
• « Un principe fort des méthodes Agiles est la
participation active du client.
• Cela permet de choisir plus finement les fonctionnalités
réalisées à chaque incrément. Le directeur de produit peut
à tout moment compléter ou modifier la liste des
fonctionnalités à produire pour les prochains sprints.
• Chaque sprint constitue donc un incrément, facilitant le
pilotage du projet. La notion d'itération couvre
l'adaptabilité au quotidien. »
david.vallat@univ-lyon1.fr
29
Les trois piliers de SCRUM
• « La transparence - Scrum met l'accent sur le fait d'avoir un
langage commun entre l'équipe et le management. Ce langage
commun doit permettre à tout observateur d'obtenir rapidement
une bonne compréhension du projet.
• L'inspection - À intervalle régulier, Scrum propose de faire le
point sur les différents artéfacts produits, afin de détecter toute
variation indésirable. Ces inspections ne doivent pas être faites
trop fréquemment, ou par un inspecteur mal formé : cela
nuirait à l'avancement du projet.
• L'adaptation - Si une dérive est constatée pendant
l'inspection, le processus doit alors être adapté. Scrum fournit
des rituels, durant lesquels cette adaptation est possible. Il
s'agit de la réunion de planification de sprint, de la mêlée
quotidienne, de la revue de sprint ainsi que de la rétrospective
de sprint. »
david.vallat@univ-lyon1.fr
30
Les Rôles dans SCRUM
• « Scrum définit trois rôles : le Propriétaire du produit
(Product Owner), le ScrumMaster et le Développeur. Il est à
noter que le rôle de développeur couvre plusieurs métiers d'une
organisation traditionnelle.
• Le Propriétaire du produit (Product Owner) est le
représentant des clients et des utilisateurs. Son objectif est de
maximiser la valeur du produit développé. De ce fait, cet
acteur se charge de différents rôles et responsabilités.
• Le ScrumMaster est responsable de la méthode. Il doit
s'assurer que celle-ci est comprise, et bien mise en application.
Ce n'est pas un chef de projet, ni un intermédiaire de
communication avec les clients.
• Développeur. L'équipe ne comporte pas de rôles
prédéfinis, elle est auto-organisée et pluridisciplinaire. »
david.vallat@univ-lyon1.fr
31
Evènements dans SCRUM
• « Le sprint est une période d'un mois au maximum, au
bout de laquelle l'équipe délivre un incrément du produit,
potentiellement livrable.
• Au quotidien, une réunion, la mêlée quotidienne (Daily
Scrum), permet aux développeurs de faire un point de
coordination sur les tâches en cours et sur les difficultés
rencontrées. Cette réunion dure 15 minutes au maximum.
Le Scrum Master s'assure que la réunion ait lieu à heure
fixe. »
david.vallat@univ-lyon1.fr
32
Artefacts de SCRUM
• « Carnet de produit (Product Backlog). Scrum utilise une
approche fonctionnelle pour récolter les besoins des
utilisateurs. L'objectif est d'établir une liste de fonctionnalités à
réaliser, que l'on appelle carnet du produit.
• À chaque élément du carnet sont associés trois attributs : une
description (User Story), une estimation (souvent exprimée en
points arbitraires) et un ordre, qui est défini par le directeur
de produit.
• Carnet de sprint (Sprint Backlog). En début de sprint, un but
est décidé. Pour atteindre cet objectif, l'équipe choisit quels
éléments du carnet de produit seront réalisés. Ces éléments
sont alors groupés dans un carnet de sprint.
• Graphique d'avancement (Burndown Chart)
• Graphique qui représente l'évolution du reste à faire total de
jour en jour (pour les sprints) ou de sprint en sprint (pour les
releases). »
david.vallat@univ-lyon1.fr
33
SCRUM en image
david.vallat@univ-lyon1.fr
34
SCRUM en image
david.vallat@univ-lyon1.fr
35
SCRUM en image
david.vallat@univ-lyon1.fr
36
SCRUM en image
david.vallat@univ-lyon1.fr
37
SCRUM en image
david.vallat@univ-lyon1.fr
38
SCRUM en image
david.vallat@univ-lyon1.fr
39
david.vallat@univ-lyon1.fr
40
What is design thinking?
1. Design Thinking is human-centered
2. Design Thinking is an iterative learning process
3. Design Thinking projects consist of diverging and
converging phases
4. Design Thinking is prototyping
david.vallat@univ-lyon1.fr
41
... human-centered
david.vallat@univ-lyon1.fr
42
an iterative learning process
david.vallat@univ-lyon1.fr
43
… diverging and converging
phases
david.vallat@univ-lyon1.fr
44
… prototyping
david.vallat@univ-lyon1.fr
45
david.vallat@univ-lyon1.fr
46
Pour aller plus loin
• Les fondamentaux du management de projet - cours en vidéo :
http://rb.ec-lille.fr/l/Projets/v1/Projet_les_fondamentaux_video.html
• SCRUM : http://www.codeproject.com/Articles/704720/SCRUM-
explained
• Design thinking : http://frenchweb.fr/le-design-thinking-un-nouvel-
avantage-competitif/122936
• Outils :
• https://trello.com
• http://kanbanize.com
david.vallat@univ-lyon1.fr
47
david.vallat@univ-lyon1.fr
48
Initiation à SCRUM
• Comprendre la méthode SCRUM par la pratique
• Objectif : gérer un projet consistant à construire un
quartier… en Lego.
david.vallat@univ-lyon1.fr
49
Programme
• Tout est là : http://www.lego4scrum.com
• Etape 1 : Organisation des équipes et de l’espace de
travail
• Etape 2 : Définition du projet (en tant que Product
Owner/Client)
• Etape 3 : Construction du Backlog
• Etape 4 : Estimation (Swimlanes Wall)
• Etape 5 : Action
• Planification du Sprint 1 (Planning Wall)
• Sprint 1
• Revue du Sprint 1 (rétroaction/feed back)
• …
• Etape 6 : Debriefing
david.vallat@univ-lyon1.fr
50
Construction du Backlog
david.vallat@univ-lyon1.fr
51
• 6 x Bâtiments sans étage
• 4 x Bâtiments avec étage
• 1 x Ecole
• 1 x Eglise
• 1 x Mairie annexe
• 1 x Epicerie
• 1 x Arrêt de bus
• 1 x Pont
• 1 x Rivière
• 1 x Intersection routière
• 1 x Jardin public
Estimations
david.vallat@univ-lyon1.fr
52
Planification Sprint 1
david.vallat@univ-lyon1.fr
53
Planification Sprint 1
david.vallat@univ-lyon1.fr
54
Sprint !
david.vallat@univ-lyon1.fr
55
http://www.online-
stopwatch.com/countdown/
Actualisation de la Burndown
chart
david.vallat@univ-lyon1.fr
56
http://en.wikipedia.org/wiki/Burn_down_chart
Debriefing
david.vallat@univ-lyon1.fr
57
So what ?

Management de projet (agilité et design thinking)

  • 1.
  • 2.
  • 3.
  • 4.
    Definition • Project managementis the process and activity of planning, organizing, motivating, and controlling resources, procedures and protocols to achieve specific goals in scientific or daily problems. • A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. • The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the management of these two systems is often quite different, and as such requires the development of distinct technical skills and management strategies. http://en.wikipedia.org/wiki/Project_management david.vallat@univ-lyon1.fr 4
  • 5.
  • 6.
    Approche disciplinaire récente FWTaylor H Fayol H Gantt david.vallat@univ-lyon1.fr 6
  • 7.
    Pourquoi gérer unprojet ? (1) • Besoin d’une méthode (poursuite ou recherche d’une voie) car l’organisation spontanée ne fonctionne pas (=>The Resistance) • Planifier pour maximiser l’utilisation des ressources - matérielles, humaines, financières (=>Ile interdite) david.vallat@univ-lyon1.fr 7
  • 8.
    Pourquoi gérer unprojet ? (2) Les pièges organisationnels Levitt, B. and March, J. (1988), « Organizational Learning », Annual Review of Sociology, vol 14, pp. 319–40. • Knowledge in Organization = Routines • Competency Trap • The Innovator’s Dilemma (C. Christensen) http://www.forbes.com/sites/stevedenning/2012/04/05/clayt on-christensen-and-the-innovators-smackdown/ http://www.youtube.com/watch?v=35z03U3wugs • Surpersticious Learning http://blogs.hbr.org/2011/07/superstitious-learning/ • = GOD COMPLEXhttp://www.youtube.com/watch?v=K5wCfYujRdE david.vallat@univ-lyon1.fr 8
  • 9.
  • 10.
  • 11.
    Building shared vision •« When there is a genuine vision (as opposed to the all-to-familiar ‘vision statement’), people excel and learn, not because they are told to, but because they want to. But many leaders have personal visions that never get translated into shared visions that galvanize an organization… What has been lacking is a discipline for translating vision into shared vision – not a ‘cookbook’ but a set of principles and guiding practices. The practice of shared vision involves the skills of unearthing shared ‘pictures of the future’ that foster genuine commitment and enrolment rather than compliance. In mastering this discipline, leaders learn the counter-productiveness of trying to dictate a vision, no matter how heartfelt » (P. Senge 1990: 9). • interview with P. Senge: http://www.mutualresponsibility.org/science/what-is-systems- thinking-peter-senge-explains-systems-thinking-approach-and- principles david.vallat@univ-lyon1.fr 11
  • 12.
    Les phases duMdP (1) http://en.wikipedia.org/wiki/Project_management david.vallat@univ-lyon1.fr 12
  • 13.
    Les phases duMdP (2) http://en.wikipedia.org/wiki/PDCAdavid.vallat@univ-lyon1.fr 13
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
    Deux applications complémentaires duPDCA david.vallat@univ-lyon1.fr 21
  • 22.
  • 23.
    Pourquoi gérer en modeAgile ? • An imperative for survival in a VUCA world. • Business agility is the ability of a business to adapt rapidly and cost efficiently in response to changes in the business environment. • Une présentation vidéo :https://www.youtube.com/watch?v=OJflDE6OaSc • History: http://agilemanifesto.org david.vallat@univ-lyon1.fr 23
  • 24.
    Pourquoi gérer enmode Agile ? http://www.venveo.com/articles/agile-vs-waterfall-project-managementdavid.vallat@univ-lyon1.fr 24
  • 25.
    Agility = people •All about people… • Theory X and Y: http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y • Freedom Inc. http://www.amazon.com/Freedom-Inc- Employees-Business-Productivity/dp/0307409384 • SEMCO: http://en.wikipedia.org/wiki/Maverick_(book) • GORE: http://en.wikipedia.org/wiki/W._L._Gore_and_Associates • IDEO: http://en.wikipedia.org/wiki/IDEO david.vallat@univ-lyon1.fr 25
  • 26.
    Les valeurs duprojet Agile • Les méthodes agiles prônent 4 valeurs fondamentales (entre parenthèses, les citations du manifeste)4 : • L'équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale. • L'application (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication). • La collaboration (« La collaboration avec les clients, plus que la négociation contractuelle ») : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un compte rendu continu sur l'adéquation du logiciel avec ses attentes. • L'acceptation du changement (« L'adaptation au changement, plus que le suivi d'un plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent provoquer des demandes d'évolution. • http://fr.wikipedia.org/wiki/Méthode_agile david.vallat@univ-lyon1.fr 26
  • 27.
    Les principes duprojet Agile• Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles : • La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée. • Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client. • La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte. • Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet. • Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs. • La méthode la plus efficace de transmettre l'information est une conversation en face à face. • L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées). • Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue). • Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception. • La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels. • Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions. • À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.. Les premières livraisons du logiciel vont souvent provoquer des demandes d'évolution. • http://fr.wikipedia.org/wiki/Méthode_agile david.vallat@univ-lyon1.fr 27
  • 28.
    Comment gérer unprojet en mode Agile (SCRUM) ? (1) • Méthode de management agile en gestion de projet : SCRUM http://fr.wikipedia.org/wiki/Scrum_(méthode) • « Le terme Scrum est emprunté au rugby à XV et signifie mêlée. • La méthode Scrum a été conçue lors de projets de développement de logiciels. • Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le propriétaire du produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de former le directeur de produit, l'équipe et l'organisation entière à la méthode Scrum. » david.vallat@univ-lyon1.fr 28
  • 29.
    Comment gérer unprojet en mode Agile (SCRUM) ? (2) • « Un principe fort des méthodes Agiles est la participation active du client. • Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément. Le directeur de produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. • Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d'itération couvre l'adaptabilité au quotidien. » david.vallat@univ-lyon1.fr 29
  • 30.
    Les trois piliersde SCRUM • « La transparence - Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le management. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet. • L'inspection - À intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable. Ces inspections ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela nuirait à l'avancement du projet. • L'adaptation - Si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint. » david.vallat@univ-lyon1.fr 30
  • 31.
    Les Rôles dansSCRUM • « Scrum définit trois rôles : le Propriétaire du produit (Product Owner), le ScrumMaster et le Développeur. Il est à noter que le rôle de développeur couvre plusieurs métiers d'une organisation traditionnelle. • Le Propriétaire du produit (Product Owner) est le représentant des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit développé. De ce fait, cet acteur se charge de différents rôles et responsabilités. • Le ScrumMaster est responsable de la méthode. Il doit s'assurer que celle-ci est comprise, et bien mise en application. Ce n'est pas un chef de projet, ni un intermédiaire de communication avec les clients. • Développeur. L'équipe ne comporte pas de rôles prédéfinis, elle est auto-organisée et pluridisciplinaire. » david.vallat@univ-lyon1.fr 31
  • 32.
    Evènements dans SCRUM •« Le sprint est une période d'un mois au maximum, au bout de laquelle l'équipe délivre un incrément du produit, potentiellement livrable. • Au quotidien, une réunion, la mêlée quotidienne (Daily Scrum), permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées. Cette réunion dure 15 minutes au maximum. Le Scrum Master s'assure que la réunion ait lieu à heure fixe. » david.vallat@univ-lyon1.fr 32
  • 33.
    Artefacts de SCRUM •« Carnet de produit (Product Backlog). Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle carnet du produit. • À chaque élément du carnet sont associés trois attributs : une description (User Story), une estimation (souvent exprimée en points arbitraires) et un ordre, qui est défini par le directeur de produit. • Carnet de sprint (Sprint Backlog). En début de sprint, un but est décidé. Pour atteindre cet objectif, l'équipe choisit quels éléments du carnet de produit seront réalisés. Ces éléments sont alors groupés dans un carnet de sprint. • Graphique d'avancement (Burndown Chart) • Graphique qui représente l'évolution du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les releases). » david.vallat@univ-lyon1.fr 33
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
    What is designthinking? 1. Design Thinking is human-centered 2. Design Thinking is an iterative learning process 3. Design Thinking projects consist of diverging and converging phases 4. Design Thinking is prototyping david.vallat@univ-lyon1.fr 41
  • 42.
  • 43.
    an iterative learningprocess david.vallat@univ-lyon1.fr 43
  • 44.
    … diverging andconverging phases david.vallat@univ-lyon1.fr 44
  • 45.
  • 46.
  • 47.
    Pour aller plusloin • Les fondamentaux du management de projet - cours en vidéo : http://rb.ec-lille.fr/l/Projets/v1/Projet_les_fondamentaux_video.html • SCRUM : http://www.codeproject.com/Articles/704720/SCRUM- explained • Design thinking : http://frenchweb.fr/le-design-thinking-un-nouvel- avantage-competitif/122936 • Outils : • https://trello.com • http://kanbanize.com david.vallat@univ-lyon1.fr 47
  • 48.
  • 49.
    Initiation à SCRUM •Comprendre la méthode SCRUM par la pratique • Objectif : gérer un projet consistant à construire un quartier… en Lego. david.vallat@univ-lyon1.fr 49
  • 50.
    Programme • Tout estlà : http://www.lego4scrum.com • Etape 1 : Organisation des équipes et de l’espace de travail • Etape 2 : Définition du projet (en tant que Product Owner/Client) • Etape 3 : Construction du Backlog • Etape 4 : Estimation (Swimlanes Wall) • Etape 5 : Action • Planification du Sprint 1 (Planning Wall) • Sprint 1 • Revue du Sprint 1 (rétroaction/feed back) • … • Etape 6 : Debriefing david.vallat@univ-lyon1.fr 50
  • 51.
    Construction du Backlog david.vallat@univ-lyon1.fr 51 •6 x Bâtiments sans étage • 4 x Bâtiments avec étage • 1 x Ecole • 1 x Eglise • 1 x Mairie annexe • 1 x Epicerie • 1 x Arrêt de bus • 1 x Pont • 1 x Rivière • 1 x Intersection routière • 1 x Jardin public
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
    Actualisation de laBurndown chart david.vallat@univ-lyon1.fr 56 http://en.wikipedia.org/wiki/Burn_down_chart
  • 57.