Concordiagile

La Vision de Concordiagile

David Gageot — Tue, 12 Feb 2008 13:33:00 +0100

« Concordiagile » est une alliance de personnes morales motivées par la promotion commune des méthodes agiles en France.

L'objectif de l'alliance est de fédérer toutes les bonnes volontés françaises mettant en œuvre l'Agilité afin d'installer les pratiques de l'amélioration continue dans le secteur informatique. L'alliance permettra d'amplifier le discours de ses membres afin que celui-ci porte plus loin que la somme des discours individuels.

L’alliance est ouverte à toutes les entreprises utilisatrices, sociétés de services et éditeurs qui embrassent cette vision. Les membres actuels de l'alliance sont Agilii, OCTO Technology, Pyxis Technologies, Sfeir, Valtech et Xebia.

L'activité de « Concordiagile » se traduit dans un premier temps par un blog communautaire et par des rencontres régulières entre ses membres puis se traduira par des séminaires et conférences telles que les Rencontres Agiles.

Déspécialisation

Bernard Notarianni — Mon, 04 Feb 2008 22:33:00 +0100

Kent Beck nous propose dans sa méthode eXtreme Programming d’adopter sur nos projets la pratique de propriété collective du code. Il propose que l’application soit comprise et maitrisée par tous les membres de l’équipe.

A titre d’exemple, une équipe peut mettre cette pratique en œuvre au travers des actions suivantes :

Les développeurs travaillent en binômes sur une grande majorité du codage de l’application. Les binômes tournent régulièrement. (Pair Programming)
Aucune personne ne se spécialise dans un module ou une partie de l’application en particulier. L’équipe évite de se retrouver avec un spécialiste de la base de données, du build, du framework IHM ou de l’architecture générale de l’application.
Tout le monde participe à l’effort de création des jeux de tests unitaires et fonctionnels. L’équipe évite d’avoir une personne dédiée uniquement à la qualité.

L’absence de spécialisation des membres de l’équipe apporte entre autres les bénéfices suivants:

Si une personne s’absente de manière volontaire ou involontaire, l’équipe peut continuer à faire avancer le projet. Le client n’est pas obligé d’organiser le contenu des itérations en fonction de la disponibilité des spécialistes.
Les conventions de conception et d’implémentation adoptées par l’équipe sont suivies de manière homogène sur l’ensemble de l’application. L’application devient plus maintenable.
Les membres de l'équipe sont responsabilisés sur l'ensemble de la livraison de l'application. L'alignement est renforcé.

Ces effets sont connus et il est aisé de comprendre leur valeur intrinsèque. D’autres bénéfices plus subtils apparaissent grâce à la propriété collective du code.

Dans une équipe avec spécialisation, il est difficile de parler des difficultés qui apparaissent sur les modules des spécialistes. Les membres de l’équipe ont tendance à éviter le conflit (à tord ou à raison) et n’osent pas discuter le travail d’un spécialiste. Qu’il s’agisse de la conception d’un module java, d’un schéma de base de donnée relationnelle, du choix d’un outil ou de l’architecture, si un de ces éléments est confié à un spécialistes (expert, DBA, architecte..) il aura moins de chance d’être amélioré par les feedback de l’équipe.

De même, si un spécialiste se sent en difficulté sur son domaine, il sera plus difficile pour lui de l'exprimer car par nature, il n’a pas l’habitude de demander de l’aide à ses coéquipiers.

Les membres d’une équipe sans spécialiste peuvent plus facilement discuter des difficultés qu’ils rencontrent. Ils se sentent tous responsables du code produit. Ils peuvent discuter de la qualité sans avoir le sentiment de remettre en cause les compétences des autres membres de l’équipe.

La déspécialisation va à l’encontre des habitudes que nous a imposé l’ère industrielle depuis des décennies. C’est pour cela qu’il est difficile de l'adopter. Pourtant, ses vertus sont nombreuses, et permettent souvent d’aller plus loin, plus vite, contrairement à ce que nous expliquait Taylor au début du 20eme siècle. L’industrie l’a compris depuis Toyota et l’approche Lean. Il est temps que nous suivions le même chemin dans l’informatique.

Tester son agilité

dgirard — Sun, 03 Feb 2008 21:19:00 +0100

"Ma méthode est aussi itérative que la votre : d'abord nous faisons les spécifications, ensuite nous concevons le logiciel pour finalement le coder, le tester et le mettre en production."

Afin de valider qu'un projet annonçant respecter SCRUM respecte quelques principes de base, Nokia propose un test divisé en deux parties :

Le projet est-il incrémental ?
- Les itérations du projet sont-elles fixes et durent-elles moins de 6 semaines ?
- Le logiciel fonctionne-t-il et est-il testé à la fin de chaque itération ?
- L'itération a-t-elle démarrée avant que les spécifications ne soient complètes ?
Le projet respecte-t-il SCRUM ?
- Y-a-t-il un "product owner" sur le projet ?
- Y-a-t-il un backlog prioritisé par la valeur métier ?
- La complexité du backlog a-t-elle été estimée par les membres de l'équipe ?
- L'équipe connait-elle sa vélocité et crée-t-elle ses "burndown charts" ?
- Personne ne perturbe le travail de l'équipe durant une itération ?

Ce test, reste le test de Nokia. Il a le mérite d’indiquer les pratiques que Nokia estime être les plus importantes.

Chaque équipe peut avoir un petit test/manifeste de ce type qui permet d’indiquer les pratiques défendues.

Source du test Nokia : Jeff Sutherland on Scrum and Not-Scrum

Les bénéfices des méthodes agiles

David Gageot — Wed, 30 Jan 2008 14:51:00 +0100

Voici quelques situations qui doivent vous amener à penser méthodes agiles (XP, Scrum, ...) :

Votre client/MOA sait exprimer ses besoins mais ne se sent pas capable de spécifier complètement sa nouvelle application ?

C'est normal. Personne ne sait figer ses exigences dans les moindres détails avant que les développements ne commencent.

Les clients qui vous le promettent ne sont pas de mauvaise foi, par contre leurs utilisateurs en voudront pour leur argent et changeront forcément de point du vue en cours de projet. Sans parler des changements d'environnement tout au long du projet (fusion, changement de stratégie, nouvelle législation, infaisabilité technique, mauvaise compréhension du besoin, ...)

Votre client/MOA ne croit plus aux développements forfaitisés à prix fixe. Ce soit disant prix fixe explose dès le premier comité de pilotage !

C'est normal. Aucun développeur, chef de projet ou directeur de projet ne peut chiffrer un développement à l'avance. S'il dit le contraire, il n'est pas de mauvaise foi, il se voile juste la face en se rassurant avec des feuilles de calcul Excel, des points de fonction et des abaques. Un développement est une fonction avec trop d'inconnues.

La pire des situations est l'appel d'offre ouvert qui incite les prestataires à évaluer à la baisse sans jamais voir le client en face pour lui poser des questions sur son projet.

Au mieux, on doit pouvoir donner une estimation du type : Votre projet a 70% de chances de prendre 1000hj, plus ou moins 200hj. Ceux qui ont un peu étudié les statistiques, savent que les résultats de sondages doivent être donnés sous cette forme, même si les médias pensent que communiquer un pourcentage est suffisant.

Votre client/MOE souhaite contrôler la qualité de vos livrables sans savoir trop comment s'y prendre.

C'est normal. Dans le cas de forfaits, l'application livrée a rarement la qualité attendue, faute de temps pour mieux faire. Pour se protéger, les clients fixent donc des normes de développement, des outils de vérification (type cast), des jalons de livraisons, des processus complexes, ... En fait, nos clients cherchent à nous faire porter les risques en fonctionnant en forfait. Mais comme nous n'arrivons pas à livrer la qualité attendue dans le temps imparti, ils doivent passer en mode flicage.

Le pire c'est que ce mode flicage nous rapporte (nous SSII), puisque l'on aide d'autres clients à mettre au point des normes, des processus, des audits,...

Le seul indicateur de qualité devrait être le produit livré, confronté aux utilisateurs finaux. Pour tester la satisfaction de ses clients, Sun ne pose plus qu'une question : Seriez-vous prêt à recommander nos produits ?

Alors que faire ?

Il faut aider nos clients à utiliser les méthodes "agiles". Les bénéfices sont multiples :

Plus de big upfront design, donc des coûts réduits : Le projet classique (architecture technique, POC, socle technique personnalisé, développement) est remplacé par une architecture émergeante au fil de l'eau plus légère et plus flexible. Cela ne veut pas dire que l'on ignore les règles d'architecture ou d'urbanisation du client. Cela reste des exigences en entrée du système.

Plus de dépassement de budget incontrôlé : Si le budget maximal est atteint, on peut choisir :

D'arrêter les développements et d'utiliser le produit tel quel. Avec les méthodes agiles, on a un produit fini à chaque itération. Avec les méthodes classiques (même itératives), le projet est rarement utilisable en l'état.

De contrôler l'augmentation de budget car le produit est affiné à chaque itération sans risque de régression (grâce au test driven development). Pourquoi pas ne pas mettre le logiciel en production tout en repoussant l'ajout de fonctionnalités à l'année prochaine ? C'est d'ailleurs un peu ce que l'on fait en achetant un progiciel.

Les meilleurs développeurs travaillent pour vous : Les méthodes agiles attirent en effet les développeurs expérimentés ou en quête de nouvelles compétences. Grâce au pair programming ou au rythme des itérations, ils seront plus motivés, plus efficaces et le turn-over est réduit.

Voila pour un court article sur les bénéfices des méthodes agiles. Un dernier point en passant : L'itératif n'est pas forcément agile. Ne vous trompez pas, il manque beaucoup à UP pour devenir agile. Pour moi, les deux points importants sont le pilotage par les tests et le fait que l'on doit aider le client à décider le contenu des itérations lui-même. C'est donc bien le client qui tient les commandes ! (Pas juste le porte monnaie)

Un nouveau type d'architecte: l'Architecte Agile

Guillaume Carré — Tue, 29 Jan 2008 23:02:00 +0100

(Ce billet est une libre traduction de l'article posté par notre collègue Vikas Hazrati sur le site Agile Journal).

On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d'un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l'architecture évolue à chaque itération.
Les architectes « Tour d'Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.
Une nouveau genre est en train d'apparaître et de sortir du lot comme le prédit la théorie de l'évolution de Charles Darwin - question d'adaptation. Le rôle d'un Architecte Agile ne doit pas susciter de questions et tout membre d'une équipe agile vous le confirmera: ce sont des équipiers qui apportent l'une des plus grandes valeurs ajoutées.

Alors qui est cet Architecte Agile ? Comment savoir si l'architecte de votre équipe est un Architecte Agile ?
La réponse n'est pas aisée ; néanmoins l'Architecte Agile présente des signes distinctifs, des aptitudes qu'il exercera au quotidien. Un Architecte Agile doit savoir jongler entre ces différentes caractéristiques. Si l'architecte de votre équipe possède la plupart des caractéristiques qui suivent, et que vous le voyez jongler entre celles ci, c'est certainement un bon Architecte Agile.

Petit avertissement, la description faite ci-dessous peut certes paraître un peu idéaliste, mais elle donne sans aucun doute la direction qu'un Architecte Agile doit prendre.

Le but premier d'un Architecte Agile : délivrer une solution qui fonctionne avec une qualité optimale

Il y a deux aspects à aborder ici. Premièrement, la solution doit être de qualité optimale. Idéalement, sur un projet agile, les exigences de qualité (souvent appelées exigences non fonctionnelles) doivent faire partie intégrante de chaque itération. Les aspects tels que la sécurité, la performance, la qualité du code, etc. font partie intégrante d'une User Story [1] existante dans le backlog ou forment une user story distincte. Cependant, force est de constater que l'équipe agile, impliquée dans l'implémentation des fonctionnalités oublie bien souvent ces exigences de qualité. L'Architecte Agile doit alors s'assurer que le serveur d'intégration continue communique bien, à tous les membres de l'équipe à la fin de chaque cycle de build, différentes métriques, telles que des statistiques sur la qualité du code, la performance du système, les anomalies dans le code détectées par les tests unitaires... Il doit garder un œil sur ces données et attirer inlassablement l'attention de l'équipe agile sur celles-ci.

Le deuxième but est de délivrer une solution qui fonctionne. L'Architecte Agile évalue différentes options d'implémentation avec l'équipe afin de parvenir à une solution qui fonctionne et qui génère de la valeur métier pour le client. Il s'assure non seulement que la solution fonctionne de manière isolée mais également qu'elle s'intègre également parfaitement dans l'architecture de l'entreprise déjà en place, et qu'elle est suffisamment robuste pour être modifiée et étendue dans le futur. Il se concentre sur la solution qui fonctionne, non sur des documents et des livrables qui ne contribueraient pas directement à la mise en place de la solution.

L'Architecte Agile est garant de l'intégrité conceptuelle

Il s'assure que, dans le coeur de l'action, personne n'oublie la mission initiale. Sous la pression du calendrier et des obstacles techniques, les développeurs prennent parfois des décisions qui éloignent le projet de ses objectifs métiers. L'Architecte Agile maintient dans un esprit collectif les objectifs de la mission.
L'intégrité conceptuelle est atteinte lorsque le système développé démontre consistance et uniformité de ses éléments ainsi que la fluidité de leur intégration.
Prenons pour exemple la métaphore du Drag and Drop présente dans tous les systèmes d'exploitation modernes. Si le système d'exploitation a été bâti avec une bonne intégrité conceptuelle, le Drag and Drop devrait fonctionner partout. Ainsi, pour ouvrir un fichier on doit pouvoir le prendre et à le glisser sur l'application adéquate, et supprimer un fichier doit être aussi simple que de le prendre et de le glisser/déposer dans la corbeille. En résumé, l'intégrité conceptuelle consiste à créer un système sans surprise.

Un Architecte Agile travaille réellement au sein de l'équipe

Il est impliqué durant la totalité du projet. Des tâches de programmation lui sont affectées, et il implémente des User Stories, comme n'importe quel autre développeur. L'implémentation des User Stories ne constitue pas son unique tâche dans la journée, mais représente une part non négligeable de son travail.
Il fait profiter le projet de son expérience, et donne les grandes directions sur les différents choix d'architecture effectués tout au long de la vie du projet. L'architecture n'est pas figée durant les premières itérations, et continue à évoluer lors de chaque itération, ce qui signifie que contrairement aux architectes « traditionnels », il ne quitte pas le projet pour en rejoindre un nouveau après la traditionnelle phase projet de « mise en place de l'architecture ».

Un Architecte Agile écrit les tests systèmes qui permettent de tester les performances de l'architecture

Il écrit les tests d'infrastructure qui permettent de tester l'architecture du système. Si un mauvais choix d'architecture provoque un problème de performance, celui-ci doit être détecté par le test d'infrastructure. Puisque les méthodes agiles recommandent d'écrire les tests en premier lieu (Test Driven Development), il écrit les tests qui prouvent que le système n'offre pas la qualité de service attendue, puis effectue ensuite les modifications nécessaires afin de faire passer ce test. Dans les cas les plus rares où l'écriture d'un test peut s'avérée être difficile, il réfléchit à d'autres manières de tester l'architecture.
Tout ceci permet de s'assurer que des efforts ne sont pas vains, donnant lieu à un design non éprouvé. Le test confirme la viabilité d'un bon design dans lequel les efforts de développement vont êtres portés. N'importe quelle décision d'architecture, qu'elle soit majeure ou mineure, doit donc être précédée par un test.
Par exemple, si le système est supposé supporter une charge de 10 000 utilisateurs simultanés, l'Architecte Agile écrit des scénarios JMeter (ou à l'aide de n'importe quel autre injecteur) qui vont générer la charge adéquate sur le système, afin de s'assurer que tout fonctionne normalement en charge. Si le test échoue, il convient ensuite de modifier l'architecture pour faire en sorte que le test passe (NDT: ou de corriger les anomalies de développement qui ont fait échouer le test). Après ces modifications, le test est à nouveau exécuté cette fois ci avec succès.

Un Architecte Agile participe et travaille en équipe, avant tout

Il n'effectue pas seul les choix techniques et de conception: ces décisions doivent être prises de manière collégiale par l'équipe. Il a l'esprit ouvert, est totalement conscient du fait qu'il n'est pas omniscient, et n'est jamais obtus et fermé à propos de ses propres idées.
Les meilleures idées viennent de l'équipe, lorsque ses membres réfléchissent tous ensemble; n'importe qui est capable d'avoir une bonne idée ou de donner un point de vue intéressant. Une communication ouverte et honnête permet aux gens de prendre de meilleures décisions basées sur une information plus précise. L'Architecte Agile doit faire preuve d'empathie, doit traiter les gens avec respect, et montre qu'on apprend en permanence les uns des autres. Il favorise le consensus et permet à tous les membres de l'équipe de contribuer à l'élaboration de la solution, et par la même de tous les responsabiliser.
Si le client présente la problématique du projet et que l'architecte propose seul dans la foulée une unique solution, vous ne travaillez probablement pas avec un véritable architecte...

Un Architecte Agile est un mentor sur lequel on peut se reposer

C'est une des caractéristiques les plus importantes. Il travaille en permanence avec l'équipe afin d'améliorer sa capacité à prendre des décisions. Ce travail pédagogique est évidemment également une corde supplémentaire à son arc. Il utilise au mieux les capacités de l'équipe en la guidant sur les nouvelles technologies, en lui apportant son soutien sur les frameworks techniques. Il s'assure par exemple qu'elle ne va pas rejeter un choix de design par facilité, manque de motivation ou d'expérience sur certaines techniques ou technologies. Si tel est le cas, il comble le déficit technique de l'équipe afin de lui permettre de prendre les décisions en toute connaissance de cause.
Comme Martin Fowler le dit, "Ceci établit la règle empirique que la valeur d'un architecte est inversement proportionnelle au nombre de décisions qu'il ou elle prend".

Un Architecte Agile est un habile médiateur

Une équipe agile comprend des membres qualifiés et passionnés. On observe fréquemment des divergences d'opinion sur certains choix de design, sur la meilleure manière d'implémenter une fonctionnalité, sur les façons d'améliorer le processus de développement, etc. Ces différences d'opinion, si elles ne sont pas prises en compte rapidement et de manière efficace, peuvent mener à de houleux échanges et de sérieux différents au sein de l'équipe. Dans ces cas précis, l'équipe a besoin d'un médiateur mature et plus expérimenté, qui saura aider l'équipe et régler ces différents. L'Architecte Agile convient parfaitement par son niveau de maturité et d'expérience.

Un Architecte Agile ne fait jamais de « Big Modeling Up Front » (BMUF)

La plupart du temps il n'utilise pas les outils de génération de code qui permettent de modéliser les grandes décisions d'architecture. A la place, il ne modélise juste « ce qu'il faut », généralement sur un tableau. Le premier modèle simple imaginé grandit et s'enrichit ensuite à chaque itération. L'Architecte Agile suit les concepts du Agile Modeling, et pour lui "le modèle, c'est le code". S'il est nécessaire de générer le modèle à des fins documentaires, il peut par exemple être généré par un outil de reverse engineering.
Les modèles, les documents, le contenu, et la manière de communiquer doivent être les plus simples et concis possibles. L'idée est de se concentrer sur le contenu, et non sa représentation ou sa « mise en forme » qui ajoutent peu de valeur métier.

Un Architecte Agile cherche à faire du refactoring à grande échelle

Il est en permanence à la recherche de problèmes qui pourraient s'avérer par la suite être de sérieux obstacles techniques, et nuire à l'architecture du projet. Au fur et à mesure que le système s'étend, il s'assure que l'architecture suit le rythme. Il est en permanence à l'affût de changements importants qui pourraient avoir un plus fort impact que prévu. Par exemple, si l'application n'utilise pas assez de CPU, et que les performances globales ne sont pas ce qu'elles devraient être, il va introduire du multi-threading dans l'application afin qu'elle utilise ces ressources disponibles, afin de délivrer de meilleures performances. Il démarre par la solution la plus simple possible, et refactor ensuite en permanence la solution afin de garder le niveau de qualité requis tout en implémentant les nouvelles fonctionnalités.
L'Architecte Agile aide également à rendre le système modulaire. Au lieu de l'approche « Diviser pour mieux régner », il recommande de « Régner pour mieux diviser ». Au démarrage du projet, un système le plus simple possible qui fonctionne va être implémenté par une petite équipe. Par la suite, grâce à l'expérience de l'Architecte, l'équipe divisera le système en sous composants naturels, en gardant la vision globale, et on ajoutera si nécessaire de nouveaux membres à l'équipe pour le développement de chaque nouveau sous composant.

Un Architecte Agile est une « super glue »

Il se comporte comme une « super glue » entre l'équipe, les différents fournisseurs et les clients en leur communiquant les différentes décisions prises sur l'évolution de l'architecture et du design, les obstacles techniques rencontrés, etc. C'est l'intermédiaire entre les mondes métier et technique (NDT : dans la méthode SCRUM, c'est plutôt le ScrumMaster qui prend en charge ce rôle de suppression des obstacles rencontrés).
Il a la capacité de voir les obstacles métiers d'un point de vue technique, et les problèmes techniques à travers un contexte métier. Il sait expliquer la valeur métier de tel ou tel choix technique au client. Par exemple, s'il s'agit de choisir une technologie par rapport à une autre, il doit être capable d'expliquer au client la valeur métier ajoutée en terme d'utilisation des ressources, de capacité de changement, d'économies réalisées, etc. Il pense au « comment » mais aussi au « pourquoi » lorsqu'il travaille sur un projet où il faut répondre à la fois à des problématiques métiers et techniques.
La plupart des architectes traditionnels vont se concentrer sur la manière d'implémenter une solution, sans prendre le recul nécessaire qui permettrait de se demander si la solution est la meilleure possible. L'Architecte Agile s'efforce de travailler avec le client et cherche à savoir pourquoi une solution donnée est nécessaire, s'il y aurait une manière plus simple et plus efficace de répondre au besoin exprimé que la solution proposée par le client.

Dernier signe, mais pas des moindres, l'Architecte Agile embrasse le changement

Il embrasse le changement à la fois pour l'architecture et pour son propre rôle. La vraie architecture agile consiste à supporter le changement rapidement et facilement sans la dégrader, et avec le minimum d'impact sur les systèmes externes. Afin de s'en assurer, l'Architecte Agile démarre avec un design correct, et le fait évoluer constamment tout au long du cycle de vie du projet. Il implémente de façon modulaire les composants communs, masque derrière des interfaces ceux qui sont susceptibles de changer le plus souvent afin de minimiser les impacts lorsqu'ils évoluent.
Enfin, un vrai rôle agile consiste à pouvoir jouer de multiples rôles. Il prend les rôles de programmeur, de testeur de performance, de mentor, de médiateur, de membre de l'équipe, de « glue », et potentiellement celui de manager, tout ceci peut-être dans une seule journée de travail.

Conclusion

Les fondations de la tour d'ivoire des architectes sont ébranlées. Le nouveau type d'architecte appelé Architecte Agile grandit, s'affirme, travaille, et contribue aux équipes. Elle adhère totalement au principe numéro 12 de Toyota : « Allez et voyez par vous-mêmes afin de totalement embrasser la situation ». Ils sont des membres de premier ordre de l'équipe de développement et ne travaillent pas pour l'équipe mais dans l'équipe. Pour pouvoir prétendre au rôle d'Architecte Agile, il convient ainsi de faire preuve de maturité, d'expérience, et par-dessus tout d'être capable de jongler entre différents rôles et caractéristiques au sein de l'équipe de développement.

Alors, possédez-vous déjà un Architecte Agile au sein de votre équipe?

[1] Une "User Story" est une exigence définie par le "Product Owner" (dans le "Backlog" avec la méthode SCRUM)

Pourquoi les méthodes agiles peinent-elles à pénétrer l’entreprise ?

Pierre Pezziardi — Fri, 25 Jan 2008 10:44:00 +0100

La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail.... Chronique à paraître dans 01 Informatique

La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail. Il en existe deux grands types : la cascade (ou cycle en V) et la construction incrémentale pilotée par les tests. Dans une cascade, l’accent est mis sur le produit, que l’on considère comme descriptible dans un cahier des charges, puis des spécifications détaillées. Il est ensuite codé et enfin testé. Dans une approche incrémentale, l’accent est mis sur le process : il n’est pas nécessaire de décrire exhaustivement le produit mais plutôt ses grandes lignes, puis on développe cas d’usage par cas d’usage, en montant progressivement en complexité. Chaque cas d’usage est associé à des tests de recette qui seront automatisés, donc rejoués à coût marginal.

La cascade représente 99% du portefeuille projet des grandes entreprises, l’incrémental 99% des projets Open Source et des sites Web grand public les plus connus (Amazon, Telemarket ..). L’observation des faits devrait aiguiller votre choix : la cascade échoue dans ses grandes lignes (1), l’incrémental piloté par les tests permet la maîtrise de logiciels aussi complexes que ceux des grands éditeurs (2). Cette observation semble manichéenne, mais elle ne fait que corroborer la théorie du Defect Cost Increase énoncée par Barry Boehm dans les années 80 : Le coût de correction d'un défaut croît exponentiellement à chaque phase du cycle de développement dans laquelle il est détecté. Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides.

Alors comment expliquer que malgré ces faits, votre choix se portera très vraisemblablement sur la cascade ? J’y vois trois facteurs : un mythe fondateur, l’insouciance d’une jeune industrie dispendieuse, et un système de valeur hérité du Fordisme.

Commençons par le mythe fondateur du cahier des charges : pour réussir un projet de développement, il suffit de rassembler les besoins dans un document complet et exhaustif, puis d'écrire un logiciel qui soit conforme à cette spécification. Le philosophe Wittgenstein nous avait pourtant mis en garde dans les années 50 contre cette fausse assertion héritée du positivisme. Tout exercice du langage qui n'est pas étayé par des cas concrets finit en abîme de sens. Il n’y a pas de « beauté », il n’y a que l’expérience que chacun s’est forgé de la beauté. Ainsi Wittgenstein démontre à quel point seul des tests dans des cas concrets peuvent cerner un sens exprimé : « c’est beau quand c’est jaune », « c’est beau si c’est rond » ...

L’insouciance : à l’image de l’industrie automobile qui a mis plusieurs décennies avant de réaliser qu’elle polluait et tuait quand même beaucoup, l'industrie informatique a encore beaucoup de mal - tant ses apports ont été spectaculaires - à réaliser l'impact de la non-qualité. Les chefs de projet sont jugés sur les coûts et les délais. Point. La griserie procurée par la vitesse occulte ainsi souvent les problèmes de freinage et d’airbag que rencontreront les utilisateurs ou les équipes de maintenance et d’exploitation…

Enfin, la grande entreprise place la spécialisation et la fongibilité des ressources au centre de son système de valeur. Tout processus tend à être découpé en phases et en tâches, auxquelles sont rattachées des équipes spécialisées. Cette vision s’applique à merveille dans certaines chaînes de valeur industrielle, mais très mal dans un processus de construction logiciel, par essence risqué donc requérant des cycles courts, sans circulations hiérarchiques. Construire du logiciel, sera donc avant tout construire une équipe intégrée, ce qui reste compatible avec l’informatique d’entreprise, massive et interconnectée.

Fort de ce constat, nous pouvons proposer 4 conseils au dirigeant soucieux d’améliorer l’efficacité de son entreprise, en permettant aux chefs de projet de faire un autre choix que la cascade :

demander à ce que tout cahier des charges ne dépasse pas 5 pages et soit assorti de tests dans des cas concrets,
mettre en place et suivre les mesures de qualité du développement (couverture de tests, homogénéité, taux de duplication), au même niveau que les mesures de coûts et de délais,
au-delà de trois mois de travaux, reconsidérer l’idée de forfait, ce mode de travail désastreux qui repose sur une bien hypothétique maîtrise de la complexité; et préférer des contrats d’engagement de moyens contrôlant fréquemment la performance (vélocité & qualité) d’équipes intégrées,
diffuser ces pratiques, en les améliorant encore et encore, pour obtenir des chaînes de réalisation où le temps entre une demande cadrée et sa mise en production sans régression ne cesse de diminuer ... plutôt qu’augmenter comme c’est trop souvent le cas aujourd’hui.

Longue vie à ConcordiAgile

Luc Legardeur — Thu, 24 Jan 2008 12:05:00 +0100

Notre Alliance en vue de promouvoir les méthodes agiles en France voit enfin le jour !!! et nous en sommes très heureux.

ConcordiAgile a pour ambition de fédérer toutes les bonnes volontés françaises en vue de faire de l'Agilité le nouveau paradigme de développement, porteur de qualité, de pragmatisme, de valeur métier et de bonnes relations IT/Business.

Longue vie à CondordiAgile !!!