Journée Agilité à Ei.Cesi (17 avril 2013)

Gestion de

projet Agile

CESI MS RACPI 05 18 avril 2013

Fabrice AIMETTI [email protected]

« L'agilité est l'habileté à changer la position de son corps. » « Dans le sport, l'agilité est décrite comme le temps de réponse contre un adversaire ou une cible qui bouge. »

Etude de cas

Xavier,

Directeur des Etudes Informatiques

« Démontrons la

Valeur Métier ! »

Xavier a 43 ans. Depuis 3 ans, il est Directeur des Etudes Informatiques au sein d’une société

bordelaise de 1000 salariés. Ancien Directeur de projets dans une SSII de 10000 personnes, il a été

recruté pour répondre aux forts enjeux d’innovation définis par la Direction des Systèmes

d’Information (DSI) et des Directions Métiers. Aujourd’hui, les projets de transformation du système

d’information n’ont pas démontré leur adéquation aux besoins : effet tunnel, obsolescence de la

solution, dépassement des délais de 200% sans parler des coûts de développement. L’ambiance

est morose depuis un certain temps. Son Directeur des Ressources Humaines lui a remonté un

turnover en hausse (+5%) dans ses équipes. Le département informatique est régulièrement montré

du doigt lors des comités trimestriels d’activités. Même son DSI commence à lui lancer des piques. Il

a besoin de gagner en crédibilité, en fiabilisant le pilotage et le fonctionnement de l’activité. On lui

a conseillé de forfaitiser et externaliser ses projets mais il pense que cela ne règlera pas le

problème.

Récemment, il a participé à une sensibilisation

d’une journée au Lean Management. Certains

concepts l’ont interpellé (chaîne de valeur,

management visuel, standardisation, …) et

semblent transposables dans le monde du SI. Il s’est

renseigné et a décidé de faire appel à un

Consultant spécialisé dans l’Amélioration Continue

et la Performance Industrielle. C’est un pari.

L’entretien avec ce Consultant a été

planifié au jeudi 18 avril 2013. Il a prévu d’y

consacrer deux heures et a préparé

quelques documents : l’organigramme de

la DSI, le cycle de développement

documenté par la Cellule Méthodes, des

indicateurs visuels…

DSI

DSI

Adjoint Urbanisation

Etudes Production Support

utilisateurs

Administratif

et Financier

Système

Réseau

Domaines

fonctionnels Finances

RH

Xavier

Exploitation

CESI MS RACPI 05 - 18 avril 2013

Agilarium® Fabrice Aimetti

Visibilité Adaptabilité

Valeur Métier Risque

Existant Attendu


Agilarium® Fabrice Aimetti Equipe Christian

Equipe Sophie

Equipe Zoé


Agilarium® Fabrice Aimetti Recueil des problèmes

Objectifs

Proposition

d’intervention

Origines de Scrum

1986 Université

Hitotsubashi

de Tokyo

Hirotaka

Takeuchi

Ikujiro

Nonaka

… spécialistes des organisations apprenantes

Origines de Scrum



DEKRA Automotive Solutions

… publient un article de douze pages dans la Harvard Business Review

Origines de Scrum



L’environnement d'une entreprise a complètement changé

ces dernières années…

Profits générés

1970 1980

1/3 Source : sondage réalisé en 1981 sur 700 entreprises aux États-Unis

Augmenter la Qualité Baisser les coûts Se différencier

+ Rapidité

+ Souplesse

Produits Standards

Nouveaux Produits 1/5

Constat



Ce dont nous avons besoin aujourd'hui, c'est d'innover constamment dans un monde en constant changement ...

Nous avons donc besoin d'un processus dynamique basé sur la tolérance aux essais/erreurs et l'apprentissage sur le terrain ...

Comment exceller sur le marché compétitif ?



La réussite de l'équipe dépend de l'enchaînement de séquence d'efforts individuels :

Pendant qu'un coureur réalise un effort, ses coéquipiers ne peuvent quasiment rien faire …

Il y a toujours un risque lors du passage du témoin …

Arrêtez le relais 4 x 100



Le processus de développement d'un produit est le fruit de la constante interaction des membres pluridisciplinaires d'une équipe, qui travaillent ensemble du début à la fin :

L'effort collaboratif est global : le ballon passe de main en main dans l'équipe pendant qu'elle parcourt comme un seul homme la distance le séparant de l'objectif.

L'avancement se fait par petites itérations et les membres de l'équipe doivent s'accorder pour réussir ensemble dans un intervalle de temps limité.

Jouez… au rugby


Agilarium® Fabrice Aimetti Vision

holistique

Six facteurs clés novateurs qui s'emboîtent comme dans un puzzle, formant un processus très souple pour le développement d'un nouveau produit :

1°Instabilité intrinsèque 2°Équipes auto-organisées

3°Recouvrement des différentes phases du cycle de développement

4°Apprentissage global et multiple

5°Contrôle subtil

6°Transfert de la connaissance dans

l'organisation

Cadre de travail Scrum



2°Vision holistique

3°Pluridisciplinarité

4°Améliorer en permanence le niveau de l'équipe

5°Récompenser la performance du groupe

Cette nouvelle approche peut en outre agir comme un agent du changement … dans toute l'organisation.

1°Instabilité intrinsèque

2°Équipes auto-organisées

3°Recouvrement des différentes phases du cycle de développement

4°Apprentissage global et multiple 5°Contrôle subtil

6°Transfert de la connaissance dans

l'organisation

1°Challenge

Cadre de travail Scrum



Origines de Scrum

Effort extraordinaire

Innovation révolutionnaire

Projets gigantesques

Génie

Limites de l'approche globale

Origines de Scrum Implications du Management

Encourager le processus

Encourager l'apprentissage en largeur

Catalyseur du changement de

l'organisation

1947 Wiliam Edwards Deming est envoyé à Tokyo comme conseiller de l'Etat-major des forces alliées pour appliquer ses théories sur le Management.

1948-1975 Taiichi Ohno et Eiji Toyoda développe le Système de Production Toyota (TPS), que l'on appellera plus tard le Lean.

1986 Hirotaka Takeuchi et Ikujiro Nonaka étudie notamment les méthodes des industries japonaises et publie le premier article sur Scrum.

Scrum, l’héritage TPS



1995 Jeff demande à Ken Schwaber (DG Advanced Development Methods) de l'aider à déployer Scrum chez Individual, société Internet.

1993 Jeff Sutherland déploie Scrum pour la première fois chez Easel Corporation.

1995 Ken Schwaber et Jeff Sutherland présentent le framework Scrum dans un contexte de développement logiciel lors de la conférence OOPSLA'95 à Austin, Texas.

Scrum renaît dans l’IT



Manifeste Agile Agile Quèsaco ?

2001 À Snowbird Ski Resort dans l'Utah

17 experts font une rétrospective :

*Alistair Cockburn (Crystal)

Andrew Hunt

Steve Mellor

Brian Marick (Testing)

Dave Thomas

James Grenning

*Jeff Sutherland (Scrum)

Jim Highsmith (ASD)

Jon Kern (FDD)

Ken Schwaber (Scrum)

Kent Beck (XP)

Martin Fowler

*Robert C. Martin

Ron Jeffries (XP)

Arie van Bennekum (DSDM)

Ward Cunningham

Mike Beedle (Scrum)

Manifeste Agile



Manifeste Agile Manifeste pour le développement Agile de logiciels (11-13 Fév 2001)

www.agilemanifesto.org/iso/fr

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces expériences nous ont amené à valoriser :

Les individus et leurs interactions plus que les processus et les outils

Des logiciels opérationnels plus qu’une documentation exhaustive

La collaboration avec les clients plus que la négociation contractuelle

L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers.

Traduit par le CARA

Manifeste Agile

Page 24 © 2011 DEKRA

Automotive Solutions

Principes sous-jacents au Manifeste Agile

Un logiciel opérationnel est la principale mesure

d’avancement.

Les processus Agiles encouragent un rythme de

développement soutenable. Ensemble, les

commanditaires, les développeurs et les utilisateurs

devraient être capables de maintenir indéfiniment

un rythme constant.

Une attention continue à l'excellence technique et à

une bonne conception renforcent l’Agilité.

La simplicité – c’est-à-dire l’art de minimiser la

quantité de travail inutile – est essentielle.

Les meilleures architectures, spécifications et

conceptions émergent d'équipes auto-organisées.

À intervalles réguliers, l'équipe réfléchit aux

moyens de devenir plus efficace, puis règle et

modifie son comportement en conséquence.

Traduit par le CARA

Notre plus haute priorité est de satisfaire le client

en livrant rapidement et régulièrement des

fonctionnalités à grande valeur ajoutée.

Accueillez positivement les changements de

besoins, même tard dans le projet. Les processus

Agiles exploitent le changement pour donner un

avantage compétitif au client.

Livrez fréquemment un logiciel opérationnel avec

des cycles de quelques semaines à quelques mois et

une préférence pour les plus courts.

Les utilisateurs ou leurs représentants et les

développeurs doivent travailler ensemble

quotidiennement tout au long du projet.

Réalisez les projets avec des personnes motivées.

Fournissez-leur l’environnement et le soutien dont

ils ont besoin et faites-leur confiance pour atteindre

les objectifs fixés.

La méthode la plus simple et la plus efficace pour

transmettre de l’information à l'équipe de

développement et à l’intérieur de celle-ci est le

dialogue en face à face.

Manifeste pour le développement Agile de logiciels (11-13 Fév 2001)

Scrum XP

Kanban

DSDM

Crystal

FDD

Parapluie Agile



Agenda Frameworks Agile

Stade 3

Maintenir un produit

Niveau

d’innovation

bas

Stade 2

Créer de nouvelles fonctionnalités

Niveau

d’innovation

moyen à haut

Stade 1

Créer un nouveau produit

Niveau

d’innovation

haut à très haut

Certitude

Optimiser

Prédictif

Incertitude

Expérimenter

Adaptatif

Protéger les actifs

de l’entreprise Investir dans le futur

Cycle de vie du Produit « Fail Fast to Succeed Sooner »

Dérisquer

Les 3 stades de l’Innovation

Frameworks Agile



Stade 2

Nouvelles fonctionnalités

Stade 3

Maintenance

Stade Innovation

« Fail Fast to Succeed Sooner »

Stade 1

Nouveau Produit

« Style » de Product Owner

Configuration du Projet

Itératif, expérimental

SCRUM

Linéaire

Kanban

Itératif, expérimental

SCRUM

Lean Startup & Kanban

Processus Démarche

Le Product Owner collabore avec l’équipe sur la mise à jour du produit.

Peut être réparti entre les rôles de Product Manager, Product Owner et Project Manager ou Business Analyst.

Le Product Owner fait partie de l’équipe qui crée le nouveau produit.

Colocalisé

Distribué ou colocalisé

Incubateur Entreprise

Incubateur (couplage faible)

Frameworks Agile



Stade 3

Maintenir un produit

Stade 2

Créer de nouvelles fonctionnalités

Stade 1

Créer un nouveau produit

« Fail Fast to Succeed Sooner »

PO unique

Travail d’équipe

Command

& Control

Connect

& Collaborate

PO dans l’équipe

Incubateur

Les 3 stades de l’Innovation Frameworks Agile



Agenda Itératif & Incrémental

Pourquoi itérer ?

• ... pour vérifier des hypothèses

• … pour trouver la bonne solution candidate

• … une fois trouvée, pour améliorer cette solution candidate

Démarche itérative



Pourquoi incrémenter ?

• … pour construire progressivement une fonctionnalité, de telle façon que si

son développement prend plus de temps que prévu, nous pouvons livrer ce que

nous avons jusque là réussi à réaliser de façon incrémentale

• … pour livrer de façon incrémentale et vraiment obtenir cette valeur métier que

nous recherchons; parce que nous savons que nous n’aurons pas de retour sur

investissement tant que les personnes n’utiliseront pas le produit que nous avons

fabriqué.

Démarche incrémentale



On combine ces deux tactiques :

• pendant une itération de développement, nous réalisons plusieurs histoires

utilisateur, certaines ajoutent de nouvelles fonctionnalités de façon incrémentale,

d’autres itèrent pour améliorer, changer ou supprimer certaines fonctionnalités

existantes.

Démarche itérative & incrémentale



Agenda Framework Scrum

A) Scrum… la mêlée de rugby



B) Scrum… un cadre de travail



B) Scrum… pour une équipe



B) Scrum… sur un produit complexe



B) Scrum… et donc dans un environnement non prédictif



Développement d’un produit logiciel



Vision du produit



Backlog du produit

Story

Item, Feature,

Exigence,

Requirement, ...



Priorité, Valeur, Effort, ROI, Ordre, …



Rôle n°1 de l’équipe Scrum : le Product Owner !

Détaillé

Estimé

Emergent

Priorisé



Estimation relative de l’effort



Rôle n°2 de l’équipe Scrum : l’Equipe de développement !



Taille de l’équipe : 72 , 3 ≤ x ≤ 9



Equipe pluridisciplinaire (équipe apprenante)



Partage responsabilité & propriété (équipe apprenante)



Sprint = Itération de durée fixe



Train de sprints (sustaining pace)

Planif.

Sprint

Revue

Rétro

Planif.

Sprint

Revue

Rétro

Planif.

Sprint



Réunion de planification du sprint

Story 3

Story 4

Story 5

À faire (le comment) En cours Fini

Tâche1 Tâche2

Tâche3 Tâche4

Tâche5 Tâche6

Tâche7

Backlog Sprint

Flux

S

M

L

Définition du Fini


Agilarium® Fabrice Aimetti Planif.

Sprint

Réunion de revue du sprint


Agilarium® Fabrice Aimetti Revue

Sprint

Mêlée quotidienne (daily standup meeting)

1.Qu’est-ce que j’ai fait depuis la dernière mêlée ?

2.Qu’est-ce que je vais faire aujourd'hui ?

3.Par quoi est-ce que je suis bloqué ?

« Ce n’est pas une réunion de reporting »

« C’est une prévision (/ engagement) devant ses pairs »

Management Visuel



Rôle n°3 : le ScrumMaster

Gardien

Protecteur

Facilitateur

Résolveur

Promoteur

Coach



Indicateurs

Burndown Chart

(Reste à faire)

Capacité

Mesurée

Vélocité

(Vitesse de l’équipe)



Réunion de rétrospective du sprint


Agilarium® Fabrice Aimetti Rétro

Sprint

Qu’avez-vous compris ?

Artefacts Cérémonies Rôles

Vision du Produit

Product Owner



Backlog du Produit

Vision du Produit

Product Owner



Planif. du Sprint

Backlog du Produit

Vision du Produit

Product Owner

ScrumMaster Equipe Dév.



Backlog du Sprint

Planif. du Sprint

Backlog du Produit

Vision du Produit

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Backlog du Produit

Vision du Produit

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Mêlée quotidienne

Backlog du Produit

Vision du Produit

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Mêlée quotidienne

Backlog du Produit

Vision du Produit

Burndown Chart

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Mêlée quotidienne

Incrément du Produit Backlog du

Produit

Vision du Produit

Burndown Chart

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Mêlée quotidienne

Incrément du Produit

Revue du Sprint

(démo)

Backlog du Produit

Vision du Produit

Burndown Chart

Product Owner




Backlog du Sprint

Planif. du Sprint

Sprint de 1 à 4

semaines

Mêlée quotidienne

Incrément du Produit

Revue du Sprint

(démo) Rétrospective

du Sprint

Backlog du Produit

Vision du Produit

Burndown Chart

Product Owner




Documents

Journée Agilité à Ei.Cesi (17 avril 2013)