Management

Dans son ouvrage « Le mythe du mois-homme » - dont on ne saurait trop recommander la lecture -, Frederick P. Brooks cite le projet de la Tour de Babel et le décrit comme le premier fiasco de l’histoire du génie civil ; il analyse ce ratage sous l’angle de l’ingénierie et en explique les raisons : malgré un objectif clair, de la main-d’œuvre et des matériaux en quantité, sans contrainte ni de temps ni de technologie, le projet échouera bien avant d’atteindre l’une de ses limites. Les causes de cet échec sont pour lui amplement imputables à un défaut de communication et, par extension, à un manque d’organisation. Selon lui, lorsque la coordination échoue, le projet s’arrête.

1. Arborescence

Pour éviter les inévitables conflits organisationnels, on a longtemps considéré - et c’est encore largement le cas aujourd’hui - qu’un employé ne pouvait rendre de comptes à plus d’un chef à la fois. Ce principe induit naturellement une structure arborescente des responsabilités. Attention toutefois à ne pas confondre hiérarchie et communication : ce n’est pas parce qu’on en réfère qu’à un supérieur qu’on n’obtiendra d’informations que de lui. Même si l’arbre est la structure la plus simple pour faire transiter des messages du haut vers le bas, c’est loin d’être la panacée lorsqu’on cherche à faire communiquer deux nœuds du même niveau. Il faudra alors privilégier une structure sous forme de graphe.

De plus, si l’on regarde cette arborescence de responsabilités en cascade sous l’angle financier, on s’aperçoit aussi qu’elle n’est pas optimale. En effet, la théorie de la gestion par activités, rendue publique en 1988 par le Consortium for Advanced Manufacturing, donne une méthodologie pour estimer le coût des activités par processus. Il s’agit alors d’une approche horizontale, à l’instar d’une chaîne de production, et qui permet aux dirigeants de piloter la consommation des ressources par activités plutôt que par enveloppes allouées aux objectifs de...

Processus

Un ensemble d’activités, de processus, de livrables, de conditions, de rôles, d’exceptions et de communications formalisé dans un cadre précis définit un modèle de processus.

Une activité possède un objectif atomique clairement défini (non fissible et généralement attribué à une ou un groupe de personnes) ainsi qu’une condition d’entrée et de sortie, comme par exemple « tester une exigence », « implémenter une classe ou une fonction »…

Un processus est un ensemble cohérent d’activités dont les objectifs ont fait l’objet d’un accord unanime au sein de l’organisation comme par exemple : « l’analyse des exigences », « le design d’une architecture », « la planification d’un test », « le développement d’un logiciel »…

Un livrable est la production tangible d’une activité prévue par un plan de projet comme par exemple : « une spécification technique », « un système d’information », « un document d’architecture »…

Une condition peut être placée avant le démarrage d’une activité ou d’un processus ou bien une fois ceux-ci réalisés afin de contrôler le flux d’exécution, comme par exemple « démarrer le plan de test si l’ensemble des exigences est couvert », « vérifier la validation du design par le chef de projet »…

Un rôle est une aire de responsabilités comme par exemple : « architecte technique »...

Maturité

Un modèle de maturité des processus (CMMI) a été introduit dans les années 90 par le Software Engineering Institute (SEI) dont le but est de promouvoir les échanges sur les technologies logicielles (pour la défense américaine notamment). Ce modèle a eu une profonde influence sur l’amélioration des processus. Il s’applique autant aux processus de développement logiciel qu’à l’ingénierie de systèmes et s’exprime en termes de niveaux de maturité d’une organisation.

On peut choisir de représenter le niveau de maturité sous une forme étagée ou sous une forme continue. Dans le premier cas, on qualifie globalement le niveau de maturité de l’organisation, alors que dans le second cas on exprime la capacité de chaque processus au sein de l’organisation.

Figure 2.6 : Niveaux de maturité CMMI

On obtient ainsi un escalier ou un histogramme à bâtons :

Figure 2.7 : Zones de processus

Ce modèle est composé de 24 zones de processus réparties en quatre groupes :

Gestion de processus	Définition du processus organisationnel
	Focalisation sur le processus organisationnel
	Formation organisationnelle
	Performance du processus organisationnel
	Innovation et déploiement organisationnels
Gestion de projet	Planification de projet
	Suivi et contrôle...

Épistémologie

Après avoir discouru de l’utilité des processus dans une organisation, nous allons désormais focaliser notre analyse sur les activités liées au développement informatique en retraçant l’historique des modèles traditionnels. Nous allons aller jusqu’à l’état de l’art en matière de méthodologie de conduite de projet informatique, à savoir les méthodes agiles.

1. Le formalisme libère !

« Sans technique, un don n’est rien qu’une sale manie » disait Georges Brassens d’une pratique professionnelle assez éloignée du monde informatique. Cette saillie demeure cependant fort à propos pour le sujet qui nous occupe.

La construction de logiciels est un processus de création qu’on nous permettra d’élever au rang d’art. À ce titre, on dira que la différence entre un bon et un mauvais design réside essentiellement sur des aspects méthodologiques. En revanche, les grands designs proviennent de grands designers ; la méthodologie libèrera l’esprit créatif, mais pas le laborieux. C’est ce qui fait la différence entre un grand peintre, un amateur besogneux, mais éclairé et un néophyte doué. Les deux premiers maîtrisent les techniques fondamentales de la peinture, tandis que le dernier (qui n’en connaît rien) ne se repose que sur ses prédispositions naturelles. Seul le premier atteindra l’excellence par une conjonction de dons et de techniques, les deux autres produiront au mieux des œuvres de bonne facture.

Une belle architecture est donc l’œuvre d’artisans bien outillés, créatifs et maîtrisant les techniques fondamentales. Ainsi, pour être pleinement libéré, le talent de ces ingénieurs doit s’épanouir à l’intérieur d’un processus de développement adapté au type de production et aux équipes.

2. Waterfall

À la fin des années 70, les développements logiciels se caractérisaient par de sérieux retards et des surcoûts désastreux qui faisaient frémir les chefs de projets. Ceux-ci se consacraient alors essentiellement à la planification...

Agilité

La dernière mouvance est à l’agilité. Selon le Petit Robert, est agile celui « qui a de la facilité et de la rapidité dans l’exécution de ses mouvements » ou au sens figuré « prompt dans les réactions intellectuelles » ; on comprendra qu’appliqué aux processus de développement logiciel, ce qualificatif, au propre comme au figuré, ne peut que séduire. En réalité, il englobe un certain nombre de méthodologies comme l’Extreme Programming, la méthode Iconix, le processus Open UP ou bien Scrum que le chapitre suivant va s’attacher à introduire.

Ces méthodes, toutes basées sur le principe de développement itératif, sont particulièrement adaptées aux équipes légères et aux organisations qui veulent montrer de la réactivité à leurs clients. Nous verrons toutefois que l’architecte éprouvera sans doute quelques difficultés à s’introduire dans des processus très agiles où sa place sera moins évidente que dans des zones plus formalisées.

1. Manifeste Agile

Tout commence par le « Manifeste pour le développement Agile de logiciels » que nous citerons dans le texte et qui fut dicté par les Engels et Marx du dogme logiciel : Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland et Dave Thomas :

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és à 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...

Approche processus