l’agilité dans des projets d’envergure

© Copyright Pyxis Technologies

Ou la quête de la recette miracle

L’agilité dans des projets de grande envergure


Présentation

Objectif• Démontrer que les grands projets peuvent être agiles et

qu’ils en ont besoin

Qui suis-je?• Ex-directeur TI d’une compagnie financière• Projet de 20 000 jours-personnes

La vraie vie • Des bonnes pratiques basées sur une expérience vécue

2


Les prémisses

Oubliez ça! Il n’y a pas de recette!

Gardez ça simple et stupide (KISS)

3


C’est quoi un projet d’envergure?

4

Plus de 10 000 jours-personnes?

Réalisé dans une grande organisation?

Voué à l’échec?

De plus de 1 000 000$ ?

Inutile?

Longgggggggggggggggggggggggg?

Avec beaucoup de ressources?

Avec des nouvelles technologies?

…


Quelques exemples

Les projets ponts• Grande complexité• Planification hyper-détaillée• Valeur d’affaires importante

5


Quelques exemples

Les projets cathédrales• Durent longtemps• On plante les chênes au

départ pour faire des bancs à la fin

• La valeur est produite qu’à la toute fin

• Le résultat final correspond rarement au besoins initiaux

6


Quelques exemples

Les projets pyramides• Grande complexité de conception• Valeur discutable• Mode de construction peu collaboratif

7


Quelques exemples

GIRES, 200 millions• Radio-Canada, septembre 2003

CSST, 30 millions• La Presse, janvier 2009

Carra, 53 millions• La Presse, mars 2009

Dossier de santé du Québec, 178 millions• MSSS, avril 2009

Ontario e-health system, 1 milliard• National Post, octobre 2009

8


La valeur

Difficulté de définir la valeur• Paradoxe de l’eau et du diamant, Adam Smith, 1776

La définition de la valeur en économie :• Utilité dans l’organisation• Rapport de l’offre et de la demande• Investissement nécessaire

La valeur varie selon les projets et est basée sur l’apport à la mission et à la vision de l’organisation (alignement avec les affaires).

9


La complexité des projets

La technologie• N-tiers• 3GL• Multiples vendeurs• Open Source

Les êtres humains• Le choc des générations• Les personnalités• Les trois « dités »

10


Traditionnellement

11

Complexité

Valeur

d’affaires


Où on veut des projets agiles?

12

Complexité

Valeur

d’affaires


Les livraisons

But : Livrer de la valeur souvent• Radically Simple IT, David M. Upton, Bradaly R. Staats,

Harvard Business Review, Article R0830J

Mais : Livrer souvent a des impacts sur :• Les utilisateurs (essais continus, présence constante,

rétroaction rapide, …);

• Les développeurs (intégration continue, humilité, rigueur,…);

• Les affaires (nouveaux indicateurs de gestion, perte du sentiment de contrôle, …);

• Les fournisseurs TI : infrastructures, support, DBA, orientations technologiques,…

13


Les acteurs d’un projet

14

Les affaires

Les fournisseursLes utilisateurs


La gestion du changement

Les utilisateurs seront touchés• Nouvelle version plus souvent, formation adaptation des processus

d’affaires plus rapide• Les former sur l’Agilité• Éviter le clivage – informatique – utilisateurs - affaires

Les TI seront touchées• Ne pas l’oublier• Le rôle des gestionnaires

Ça prend :• Une volonté de la direction (engagement);• Une équipe ou une personne dédiée à la gestion du changement.

15


L’engagement de la direction

Facteurs d’engagement de la direction• Leadership

• Communication

• Implication

• Adhésion

• Confiance

Concrètement• Donner les moyens aux équipes

• Aménagement adaptée• Formations• Technologies (vidéo conférence, écrans, post-it, salles pour démo…)• …

• S’intéresser à l’Agilité (en faire la promotion)

• Célébrer le succès

16


Les rôles et responsabilités

Les rôles SCRUM traditionnels

Les nouveaux rôles hors SCRUM• Liés au scrum de scrum

• Liés à la gestion de projet

• Reddition de compte

• Coordination

Hiérarchie – Pouvoir - Responsabilisation• Favoriser le leadership

• Attention aux rôles de gestion à des gens innovants (principe de Peter, 3M)

• Attention au contrôle

17


Le contrôle

18

« You can’t control what you can’t measure »- Tom de Marco, Controlling Software Projects: Management, Measurement, and Estimation, Prentice Hall/Yourdon Press, 1982

« Implicit in the quote is that control is an important aspect, maybe the most important, of any software project. But it isn’t. » … « Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go. »- Tom de Marco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009


La structure des équipes

Trois niveaux de structure• La structure utilisateurs/affaires• La structure de projet• La structure de l’équipe de développement

La structure doit être comprise de tous• Communiquée à tous les niveaux – attention à la

« réunionite aiguë »• À garder simple à tous les niveaux

19


Des équipes à dimension humaine

Divide et impera

Wikipedia : En politique et en sociologie, diviser pour régner

est une stratégie gagnante visant à réduire des concentrations

de pouvoir en éléments qui, pris individuellement,

ont moins de puissance que celui qui implémente la stratégie.

Le Petit Robert : Créer des rivalités, des discordes entre ceux

qu'on gouverne, qu'on dirige, afin qu'ils ne s'unissent

pas contre le dominateur.

20


La structure des équipes TI

21


Les comités nécessaires

22

Comité d’arrimage avec les partenaires

Comité utilisateur

Comité suivi de programme

Comité directeur du

projet

Comité organique

Comité d’arrimage

technologique

Comité de suivi en projet

Scrum de scrum

Comité de gestion du

changement

Comité de formation

Comité d’architecture fonctionnelle


La structure des équipes TI

23

Les équipes sont responsables de l’architecture et du support de

l’environnement


Motivation des ressources

24

Charge de travail

Motivation

…je crois que la façon la plus sûre de tuer un homme c'est de l'empêcher de travailler en lui donnant de l'argent. – Félix Leclerc


La qualité

Il y a un coût à la qualité• Ressources• Outils• Processus

Selon l’équipe TI• Équipe dédiée• Intégrée aux équipes• Coordination avec les utilisateurs

Il y a un coût à ne pas faire de qualité• Beaucoup plus élevé

25

The biggest defect we have now [in software development] is tolerating defects

- Mary Poppendieck


Quoi documenter?Quoi! Documenter!

Habituellement les gros projets se font dans de grandes organisations• Il y a déjà une culture de documentation• Des rôles existent déjà en ce sens

Livrer du code fonctionnel avant la documentation• Agilité et documentation ne sont pas incompatibles• On peut faire autre chose que du code de façon agile

26


Documentation légère

27


Documentation légère

28


Conclusion

« La vitesse est une chose merveilleuse,

sauf si vous allez dans la mauvaise direction. »*

* The value habit (A practical guide to creating value), Deloitte Development, Deloitte Touche Tohmatsu

29

l’agilité dans des projets d’envergure

Technology