2 – Les codeurs au pouvoir ?

Cet été, ACDE Conseil publie une série d’articles éditoriaux sur les projets dans le monde numérique, à raison d’un chaque quinzaine.

Volontairement engagés, pas toujours politiquement corrects, ces articles ont vocation à faire réagir le lecteur et à nous faire prendre un peu de recul pendant cette période de congés.

Alors, n’hésitez pas à débattre, à commenter, à nous faire part de votre expérience, à nous contredire. La courtoisie reste de mise, aussi tout article n’en respectant pas les règles de bases sera irrémédiablement recyclé.

Bel été, bonnes lectures !

Vincent

2 – Les codeurs au pouvoir ?

Plusieurs générations d’utilisateurs, de développeurs, de managers, ont tenté d’apaiser ce conflit. J’en ai connus, cotoyés ou encadrés, et n’ai jamais douté de leur sincérité. Tous ont cru en des méthodes PMI, Prince2, Stage-Gate ou autres, héritées de l’industrie et sensées faciliter le dialogue.

Puis est venu vers la fin du siècle dernier le « Manifeste agile »

Ecrit par des développeurs et exprimé d’un ton très doct, ce manifeste porte d’immenses espoirs dès sa première lecture.

Prenons une à une les 4 valeurs fondatrices du manifeste :

• 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 ;

C’est bien gentil, mais pourquoi opposer ces éléments entre eux ?

• Les processus sont faits pour sécuriser l’action et ainsi mieux mettre en interaction les individus ;
• Sans documentation, un logiciel ne peut pas être maintenu par un tiers, et est voué à disparaitre ;
• Sans contrat, la relation client est fragilisée ;
• Le suivi d’un plan n’exclut pas la prise en compte de modifications ;

Regardons maintenant les douze principes sous-jacents qui illustres ces quatre valeurs :

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée. Qui pourrait penser que la priorité de toute équipe projet, agile ou non, n’est pas de satisfaire le client ?

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. Les référentiels traditionnels (PMI, Prince2 basés sur des cycles en V) intègrent la notion de « modification contrôlée /change control » précisément pour permettre les changements en cours de projet.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une
préférence pour les plus courts. La notion de « livraison incrémentale / evolutionary delivery » prônait cela dès la fin des années 80.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement
tout au long du projet. Personne n’a jamais prétendu le contraire, mais l’expérience montre qu’il est difficile de les mobiliser conjointement.

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. Il est bien connu qu’avant le manifeste agile, les dirigeants recrutaient sciemment des personnes démotivées et les laissaient à l’abandon. C’est d’ailleurs ainsi que Bill Gates, Steve Jobs et tant d’autres ont fonctionné dès les années 70/80, avec « l’échec » que l’on sait.

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. C’est pourquoi furent inventées les réunions de projet dès les années 60.

Un logiciel opérationnel est la principale mesure d’avancement. A condition que son architecture ait été un minimum pensée, réfléchie, et que des évolutions ultérieures soient possible sans remise en cause difficile et onéreuse.

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. Pourquoi « maintenir indéfiniment » ? Pour justifier indéfiniment son existence et sa charge de développement ? Une application informatique ne peut-elle pas un jour être déclarée « finie », « bonne pour le service », au moins pour un ou deux ans ? Les constructeurs automobiles ou électroniques par exemple, ne créent pas chaque mois une nouvelle version de leurs produits.

Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité. C’est une évidence, transposable dans n’importe quel environnement, que l’on soit développeur agile, ingénieur en btp ou chef cuisinier.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. Encore une tautologie, qui masque toutefois un phénomène endémique : Trop de développeurs ont trop longtemps considéré les tests ou la documentation comme du « travail inutile », avec les conséquences que l’on connait sur la performance et la maintenabilité des systèmes.

Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. C’est faux : dans l’histoire informatique, les grandes réalisations sont souvent l’œuvre d’une seule personne nettement plus douée que les autres.

À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son
comportement en conséquence. Dans le monde des bisounours, cela a pu se produire. Dans la réalité, il a fallu l’apparition des cercles de qualité dans les années 70, et des méthodes structurées de management de projet ensuite pour que ces réflexions soient stimulées.

Alors, drapé dans sa rhétorique vertueuse, le « Manifeste agile » serait-il en fait l’expression ultime d’un lobby de développeurs souhaitant s’affranchir des contraintes de spécification, de planning, de test et de documentation, pour mieux ne se consacrer qu’à leur art ?

La question mérite d’être posée.

A suivre…