Architecture soa (architecture orientée services)

Une réalité ?

50 % des fonctionnalités développées ne sont pas utilisées. 

Jim Johnson, président du cabinet d'études Standish Group^102(*) énonce^103(*) que sur 100 fonctionnalités développées, 7 sont constamment utilisées, 13 le sont souvent, 16 sont appelées de temps en temps, et que par contre, 19 sont rarement utilisées et 45 ne le seront jamais. Si la réussite d'un projet est fonction du délai, du coût, et de la satisfaction client, qu'en est-il alors de la réussite de nos projets informatiques ?

Une part importante des fonctionnalités finales ne correspondent pas à celles du cahier des charges de départ

Selon cette même étude, l'écart serait à hauteur de 42% pour les grosses sociétés et 75% pour les PME.

Un taux de réussite de projet faible

La 10^ème édition du Chaos du Standish Group, publiée en 2004^104(*), rafraîchit les chiffres communiqués dix ans plutôt, en 1994^105(*) (« 31 % des projets informatiques sont arrêtés en cours de route, 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du budget et en offrant moins de fonctionnalités qu'il n'en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès ».). En 2004, 29 % peuvent être considérés comme un succès, 18% sont arrêtés en cours de route et 53% aboutissent au prix d'un dépassement budgétaire important). Le dépassement budgétaire est chiffré en 2004 à 56% et le pourcentage avancé pour le dépassement de délais est de 84%.

Illustration 40 : Sous Estimation de la charge par Todd Little^106(*)

(Source: «Context-Adaptive Agility: Managing Complexity and Uncertainty» [LIT-CAA])

L'estimation de la charge initiale d'un projet a 10% de chances d'être respectée, mais dans la plupart des cas il faudrait multiplier au moins par deux, voire par trois ces estimations, afin de se rapprocher du temps réellement passé.

Explication de ces chiffres par le Lean Software Management

Les équipes informatiques passeraient donc deux fois plus de temps que l'estimation initiale à développer deux fois trop de choses (la moitié des fonctionnalités n'étant jamais utilisées). Ce raccourci rapide peut trouver un début d'explication dans le compartimentage de la conduite de projet. Car, entre l'instant où l'idée du projet a germé et le moment où la solution est mise à disposition des utilisateurs, plusieurs mois se sont écoulés.

Illustration 41 : Conduite de projet classique, diagramme de Timing UML 2.0

(Source: «Lean Software Development «, Chapitre « Eliminate Waste », [POP-LEA], p10)

Dans le cas du Lean, les cycles itératifs sont encouragés afin de produire en priorité les fonctionnalités à plus forte valeur pour l'utilisateur. Ce dernier peut rapidement matérialiser la solution en cours de construction, et apporter ses remarques. Le feedback est source d'amélioration et d'élimination des demandes superflues détectées au vue des 1ères livraisons.

Illustration 42 : Projet Lean, diagramme de Timing UML 2.0

(Source: «Lean Software Development «, Chapitre « Eliminate Waste », [POP-LEA], p11)

Cette méthode de conduite de projet permet aussi de lisser le stress qui n'est pas un des facteurs de réussite d'un projet. Habituellement, dans le cadre d'un nouveau projet, les premiers mois ne sont pas particulièrement facteurs de stress. Partagés entre les choix techniques et l'étude détaillée, les équipes informatiques savent qu'il reste du temps. Dans cette première phase, l'utilisateur n'a pas encore pu se rendre compte de l'interprétation faite de son expression de besoins par la MOA.

Puis le temps passe, et s'approche alors la date de mise en recette auprès des utilisateurs. Il s'est passé plusieurs mois depuis les premiers échanges, et pendant ce temps (l'entreprise étant une entité vivante), les besoins ont pu évoluer (nouvelle stratégie, nouvelles personnes, changement des priorités, crise etc ...). Cette réalité fait que bien souvent, des fonctionnalités non prévues au cahier des charges de départ, doivent être intégrées au processus de développement. La sous-estimation initiale des charges s'en trouve impactée. Le retard sur les prévisions est d'abord tu, puis avoué, lorsqu'il n'est plus possible de faire autrement.

Ce sentiment de stress et d'échec est alors partagé par l'équipe toute entière. Des reports sont négociés et sont parfois accompagnés de coupes fonctionnelles.

C'est toujours pareil, si ça ne marche pas ce n'est pas de ma faute

Surtout : Ne rien oublier. Anticipons les besoins auxquels il n'a pas encore pensé

Voilà ce dont j'ai besoin aujourd'hui

Comment exprimer ma demande alors qu'elle encore floue ?

Désolé, on est déjà en retard

Spécifications détaillées

....

.....

Je vais essayer

Expression de besoin

Utilisateur MOA MOE

Illustration 43 : Interactions au sein d'un projet

« Lorsque la réaction de stress est inexistante,

l'efficacité est nulle. Au fur et à mesure que le

stress croît, la performance augmente pour

se stabiliser à un niveau maximal.

Cette partie ascendante de la courbe peut être

Considérée comme le « bon stress »

(le eustress en anglais). Ce stress continuant

de croître, la performance, pour sa part, va au

contraire décroître. C'est le « mauvais stress »

(ou distress en anglais qui signifie «détresse»). »

L'idée du Lean est de conduire le projet par cycles itératifs de deux à quatre semaines. Un « backlog » recense les fonctionnalités à plus forte valeur ajoutée. Chaque cycle se décompose en 3 étapes (préparer, faire, adapter) et aboutit à un produit stable sur un périmètre réduit, pour l'utilisateur. Ainsi le stress ne se concentre pas deux mois avant la fin de projet, mais est dilué à chaque itération de cycle.

Docteur Patrick LÉGERON ^107(*)

(Source : Le stress au travail :

De la performance à la souffrance [LEG-LST])

Illustration 44 : Courbe du stress

Ce challenge mensuel et partagé est source de motivation et l'objectif à atteindre est limité. Il est donc plus facile de se concentrer sur l'essentiel. Les cycles réussis ajoutent à la motivation et à la confiance générale. Ils rapprochent ceux qui travaillent ensemble vers un but commun. Chaque cycle produit un lot stable et testé. Le risque est plus maîtrisé que lors d'un « One-Shot ».

2

1 : Préparer

2 : Faire

3 : Adapter

Fonctionnalités à plus forte valeur

3

1

Produit final

Illustration 45 : Le Cycle itératif

Comment le Lean apporte de la valeur

V

aleur :

Jugement porté sur le produit/service sur la base des attentes et des motivations de l'utilisateur, exprimé par une grandeur qui croît lorsque la satisfaction du besoin de l'utilisateur augmente et/ou que la dépense afférente au produit/service diminue.

Norme AFNOR NF X 50-150, 1990.

(Source : http://www.afnor.org/portail.asp)

* ¹⁰² Le Standish Group est un cabinet de conseil de Boston fondé en 1985, spécialisé sur les aspects de coûts et les ROI informatiques. Son panel d'étude est constitué de 365 entreprises américaines et européennes (PME et gros groupes industriels, bancaires, de la santé, des assurances, des services, de négoce, de vente au détail et en gros) pour un total de 8380 applications.

* ¹⁰³ Au Keynote Speech XP 2002 (XP est une des méthodes agiles).

* ¹⁰⁴ Cf. source : http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

* ¹⁰⁵ Cf source : http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

* ¹⁰⁶ Todd Little, Responsable de développements chez Landmark Graphics, leader dans la vente de solutions dans le domaine pétrolier et gazier, auteur de plusieurs articles concernant les mesures d'estimation de projet. Cette étude a été produite à partir d'un portefeuille de 570 projets.

* ¹⁰⁷ Docteur Patrick LÉGERON : Docteur en médecine, psychiatre et "post-doctoral scholar" de l'Université de Californie à Los Angeles.