« Agile 3.0 · Raisons pour utiliser des méthodes agiles Time Box (conception à délais objectifs) Cash Box (conception à coûts objectifs) Scope Management (conception pour satisfaire

Vocabulaire Contexte Logique Adéquation Echecs Distorsions Solutions

« Agile 3.0 »Ian Stokes, Metanaction, AgilePM / DSDM, MSP

DynamiqueMéthodiqueSystémiqueDéveloppementMaîtrise

RésilienceCéléritéAlacrité

ElasticitéPlasticitéDuctilité

ExtensibilitéMalléabilitéSouplesse

CollaborationCoopérationCotraitance

Co-conceptionSynergie

SynchronisationTransparenceTransversalité

Transition

Résistance Réversibilité

RéconfigurabilitéRéutilisabilité

Réactif / Proactif

DesseinDessinDestin

Utilisateur Consommateur ClientProducteurLogisticien Service Interaction Transformation

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

« Il n’est pas ce que vous ne savez pas que vous met dans le pétrin . Il est ce que vous savez avec certitude qui n’est pas vrai justement. »

Mark Twain


Le « Master Builder »

Pendant la meilleure partie de l’histoire moderne, depuis le moyen-âge, la construction d’un gros

œuvre était assurée par un « Master Builder » qui concevait, définissait et prenait en charge la

construction, depuis le début à la fin, de la portique à la plomberie: Notre Dame, La Basilique de Saint

Pierre, le Capitol à Washington.

Depuis le milieu du 20ème siècle il n’y en avait plus de « Master Builders ». La diversité et la

sophistication des avancés dans tous les domaines de la construction avait largement dépassé les

aptitudes d‘un seul individu.

Désormais, le calendrier d’un projet avec chaque activité en lots de tâches est devenu l’outil qui permet de maitriser un projet réalisé par des intervenants dont aucun pouvait comprendre

intégralement l’ensemble de l’ouvrage.

Le planning global spécifie des interfaces et même des activités qui traitent de la communication. Par exemple, les ascenseurs nécessitent l’intervention

de divers métiers qui doivent apporter leur compétence et se synchroniser. L’amélioration la

plus important pendant l’époque de systématisation était la communication entre des experts.

Un contexte historique



Le « Master Builder »

Pendant la meilleure partie de l’histoire moderne, depuis le moyen-âge, . la construction d’un gros œuvre était assurée par un « Master Builder »

qui concevait, définissait et prenait en charge la construction, depuis le début à la fin, de la portique à la plomberie:

Notre Dame, La Basilique de Saint Pierre, le Capitol à Washington.

Depuis le milieu du 20ème siècle il n’y en avait plus de « Master Builders ». La diversité et la sophistication des avancés dans tous les domaines de la

construction avait largement dépassé les aptitudes d‘un seul individu.

Désormais, le calendrier d’un projet avec chaque activité en lots de tâches est devenu l’outil qui permet de maitriser un projet réalisé par des

intervenants dont aucun pouvait comprendre intégralement l’ensemble de l’ouvrage.

Le planning global spécifie des interfaces et même des activités qui traitent de la communication. Par exemple, les ascenseurs nécessitent l’intervention de divers métiers qui doivent apporter leur compétence et se synchroniser.

L’amélioration la plus important pendant l’époque de systématisation était la communication entre des experts.

Maître Intégrateur

Procédés Systématiques

Méthodes Coopératives

Démarches Mutualistes

Ingénieurs UtilisateursParties

Prenantes

Coopération Agile

Chronologie

Une histoire de contexte


Raisons pour utiliser des méthodes agiles

Time Box

(conception à

délais objectifs)

Cash Box

(conception à

coûts objectifs)

Scope Management

(conception pour satisfaire

les besoins)

Must have

Should have

Could have

Wont have

Un périmètre qui doit évoluer et des besoins à déterminer pendant le projet

Une stratégie complexe à gérer et des risques différents à maîtriser (flux d’informations)

Une équipe compétente composées des personnes engagées

FormJ

LStorm

Transform

KNorm

JPerform


APPROPRIATION

une vraie

coopération

EVOLUTION

la réactivité face

aux changements

ITERATION des résultats qui donnent satisfaction

PARTICIPATION des individus

et des interactions

Le partage de bons principes

Contexte Raisons Principes Adéquation Echecs Distorsions SolutionsVocabulaire Contexte Logique Adéquation Echecs Distorsions Solutions

Principes sous-jacents au manifeste

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.

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 renforce 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.

La justification économique et/ou stratégique

pour ce projet est exprimée avec clarté et

visible à tous les membres de l’équipe projet

Le sponsor et le visionnaire affichent leur

sens d’appropriation du projet

Le sponsor , le visionnaire et le coordinateur

technique comprennent tous la philosophie de

PM Agile et/ou Atern

L’échéance du projet est bien définie et

le projet apporte des enjeux

Les besoins peuvent être priorisés et

élaborés progressivement

Les besoins ont été définis globalement et on

a compris que des changements peuvent être

introduits dans les détails de la définition

On admet que le détail du projet peut émerger

ConstatComplét.

d’accord D’accord NeutrePas

d’accord

Pas du tout

d’accord

Questionnaire DSDM Atern adéquation Indiquer l’opinion la plus proche et collective

Comment se préparer pour un projet agile


Les besoins ont évolués pendant

le projet !

Les utilisateurs n’adoptent pas la

solution !Les risques ont été mal gérés !

Les coûts et les délais

sont dépassés !

Les fonctions du produit ne sont plus

alignées avec la stratégie !!

Nous n’avions pas de visibilité !

Des échecs traditionnels des projets


Produit

spécifié

Produit

livré

1ère itération

(exploration)

2ème itération

(exploration)

3ème itération

(exploration)

4ème itération

(ingénierie)

5ème itération

(ingénierie)

Déploiement

Projet traditionnel

Les démarches agile apportent des solutions


Pas de

documentation ?

Pas de

maintenance ?

Développeurs

autonomes ?

Echecs

plus rapides ?

Projets qui ne

terminent jamais ?

Exécution d’un

innocent ?

A condition de répondre aux états d’âmes


Les technologies

sont-elles adaptées ?

La qualité soutenable ?

La vision globale du cahier de

charges ?

Les documents en cas

de litiges ?

Les interfaces complexes et les

interdépendances ?

Et en cas de rotation du personnel ?

Ce produit est-il trop

personnalisé ?

Et portant des questions persistent


Option

développement agile

des produits

Préserver une distance entre

l’équipe et la direction

Séparer le niveau opérationnel

et le niveau décisionnel

Eviter le micro-management

Autonomiser l’équipe

L’équipe n’est pas responsable

pour la gestion des coûts

Option .

management agile

des projets

Rapprocher l’équipe

et la direction

Intégrer les décisions techniques

et les décisions stratégiques

Etendre le champ décisionnel

Renforcer le pouvoir de l’équipe

L’équipe est responsable pour

gérer les coûts

Besoin d’une intégration décisionnelle


Les « biais cognitifs » www.scribd.com/doc/30548590/cognitive-biases-a-visual-study-guide

Erreur de la

planification

Biais de

proximité

Effet de

congruence

Effet de

confirmation

Le défi des pièges décisionnels


Biais de la

production

Biais de la

délégation

Biais de la

connaissance

Biais du

propriétaire

Des «biais cognitifs» typiques des projets


Mesuresen action

PivotBac à sables

Produit minimal viable

Echouer mieux


Samuel Beckett

Documents

« Agile 3.0 · Raisons pour utiliser des méthodes agiles Time Box (conception à délais objectifs) Cash Box (conception à coûts objectifs) Scope Management (conception pour satisfaire