Le besoin en méthode Agile
|
Au cours des dernières années, il y'a eu un intérêt croissant pour les méthodologies 'agiles', c'est à dire légères. Table des matières:
1. De Rien, vers Monumental, vers Agile La plus part des développements informatiques sont une activité chaotique, souvent caractérisée par la phrase 'coder et débuguer'. Le logiciel est écrit sans véritablement de plan, et le design du système est imbriqué avec une multitude de décisions à court-terme. Ceci fonctionne plutôt bien tant que le système est petit, mais au fur et à mesure que le système grossit il devient de plus en plus difficile à débuguer. Un symptôme caractéristique de cette maladie est une longue phase de test après que le système soit fonctionnellement mis à jour. Une telle longue période de test rends impossible toute planification, dans la mesure ou l'activité de test et de débuggage est imprévisible. Nous avons vécu avec ce style de développement pendant longtemps, mais nous avons aussi eu une alternative: la méthodologie. Les méthodologies imposent un processus discipliné sur le développement logiciel avec comme objectif de rendre le développement logiciel plus prévisible et plus efficace. Elles font cela en développent un processus détaillé qui souligne fortement la planification inspirée par d'autres disciplines d'ingénierie. Ces méthodologies sont disponibles depuis longtemps. Elles n'ont pas la réputation de déboucher sur des succès flagrants. Elles ne sont pas non plus connues pour leur popularité. La critique la plus fréquente de ces méthodologies est qu'elles sont bureaucratiques. Il y a tellement de travail à fournir pour suivre la méthodologie que l'avancement du développement dans son ensemble est ralenti. D'où le nom qui leur est donné de 'méthodologies lourdes', ou suivant le terme de Jim Highsmith: monumentales methodologies. En réaction à ces méthodologies, un nouveau group de méthodologies sont apparues au cours des dernières années. Pendant un moment, celle-ci étaient connues sous le nom de méthodologies 'légères', man désormais le terme accepté est 'agile'. Pour beaucoup, l'attrait de ces méthodologies agiles est leur réaction face à la bureaucratie des méthodes monumentales. Ces nouvelles méthodes constituent un habile compromis entre aucun processus formel, et trop de processus, fournissant juste le compte nécessaire pour obtenir un succès raisonnable. Le résultat de tout ceci est que les méthodes agiles changent significativement la perspective par rapport aux méthodes lourdes. La différence la plus immédiate est qu'elles sont moins orientées paperasse, évoquant généralement une quantité moindre de documentation pour une tâche donnée. Sur plusieurs aspects elles sont plutôt orientées code: en suivant la voie selon laquelle l'élément clef de la documentation est le code. Cependant je ne pense pas cela soit le point marquant des méthodes agiles. L'absence de documentation est un symptôme de deux différences plus importantes: - Les méthodes agiles sont adaptatives plutôt que prédictives. Les méthodes lourdes tendent à planifier de grosses parts du processus logiciel en détail pendant une durée importante, ce qui fonctionne correctement tant qu'il n'y a pas de changements. Donc leur nature est de résister au changement. Les méthodes agiles, par contre, s'accommodent favorablement du changement. Elles s'efforcent d'être des processus qui s'adaptent et s'épanouissent au changement, au point de se changer elles-mêmes. - Les méthodes agiles sont orienté vers l'humain, plutôt que vers le processus. Elles s'efforcent explicitement de travailler avec la nature de l'homme plutôt que contre elle, et de souligner que le développement informatique devrait être une activité agréable. Dans les sections qui suivent je vais explorer ces différences avec plus de détail, de manière à ce que vous compreniez ce qu'est un process adaptatif et tourné vers l'humain, ses bons et ses mauvais cotés, et dans quels cas vous devriez l'utiliser: soit comme développeur, soit comme utilisateur de logiciel. 2.1 Séparer le design et la construction L'inspiration habituelle des méthodologies provient de disciplines d'ingénierie comme les bâtiments travaux publiques ou la mécanique. Ces disciplines mettent en avant la planification avant la construction. Les ingénieurs travaillent sur une série de dessins qui indiquent précisément ce qui doit être construit et comment ces choses doivent fonctionner entre elles. Les dessins sont ensuite livrés à un groupe différent de personnes, souvent appartenant à une société différente, pour effectuer la construction. Il est assumé que le processus de construction va suivre les dessins. En pratique les constructeurs rencontrent des problèmes, mais ceux-ci sontgénéralement peu importants. Dans la mesure où les dessins spécifient les pièces et comment elles
doivent être assemblées, ils agissent comme le fondation d'un plan de
construction détaillé. Un tel plan peut faire figurer les tâches qui
doivent être faites et comment elle s'articulent entre elles. Ceci
permet d'obtenir une planification raisonnablement fiable, et un budget
pour la construction. Est également indiqué en détail comment les gens
faisant la construction devraient travailler. Ceci permet l'effort de
construction d'être moins intellectuel, bien qu'il soit Donc ce que nous voyons ici sont deux activités fondamentalement différentes. Le design, qui est difficile à prévoir et demande du personnel créatif et bien formé, et la construction qui est plus simple à prévoir. Un fois obtenu un plan pour la construction, nous pouvons nous occuper de la construction de manière plus prévisible. En bâtiment travaux publiques, le coût de construction est bien plus important que le coût cumulé du design et de la planification. Donc l'approche de beaucoup de méthodologies ressemble à ceci: nous voulons un calendrier prévisible qui puisse utiliser nos ressources peu qualifiées. Pour cela nous devons séparer le design de la construction. En conséquence, nous devons essayer de trouver un design pour le logiciel, tel que la construction soit simple une fois que le travail est planifié. Donc quelle forme doit prendre ce plan? Pour beaucoup, c'est le rôle de notations comme l'UML. Si nous pouvons faire tous les choix importants à l'aide d'UML, nous pouvons construire un plan de construction et livrer le design aux codeurs en tant qu'activité de construction. Mais nous atteignons les questions cruciales. Peux t'on obtenir un design capable de transformer l'activité de codage en activité de construction pure? Et si c'est le cas, est-ce que la construction est suffisamment plus importante en coût et en temps pour justifier cette approche? Tout ceci suscite de nouvelles questions. Premièrement, on peut
s'interroger sur la difficulté de produire un design type UML, pouvant
être livré tel quel aux développeurs. Le problème avec un design de
type UML est qu'il peut être joli sur le papier, et pourtant totalement
absurde lorsqu'il s'agit de le programmer. Les modèles qu'utilisent les
ingénieurs BTP sont basés sur des années de pratique qui s'est
concrétisée par des codes ingénierie En outre, les points importants
comme la manière dont les forces jouent dans le design, Deuxièmement, on peut s'interroger sur le coût comparatif. Lorsque vous construisez un pont, le coût de l'effort de design est 10% du travail, avec le reste en construction. En développement logiciel, le travail de codage est bien moindre (McConnell suggère que pour un large projet, seul 15% du projet est du code et test unitaire, presque l'inverse des ratios de la construction du pont). Même si vous mettez tous les tests comme faisant partie de la construction, alors le design représente toujours 50% du travail. Ceci soulève une question importante à propos de la nature du design logiciel comparé à son rôle dans les autres branches ingénierie Ce genre d'interrogations à conduit Jack Reeves à suggérer
qu'en réalité le code source est un document de design, et que la phase
de construction est effectivement l'utilisation du compilateur. Ces idées ont apporté certaines conclusions importantes: 2.2 L'imprévisibilité des Besoins C'est un refrain que j'ai entendu sur tous les projets à problèmes que j'ai rencontré. Les développeurs viennent me voir me disent: "le problème avec ce projet c'est que les besoins changent tout le temps". Ce qui me paraît surprenant dans cette situation c'est que quiconque soit en soit surpris. Dans l'activité de développement logiciel, les changements de besoins sont la norme, la question est: qu'est-ce qu'on fait pour s'adapter. Une voie est de traiter les changements de besoins comme le résultat d'une mauvaise ingénierie des besoins. L'idée derrière ingénierie des besoins est de faire une photographie des besoins avant que de commencer à construire le logiciel, d'obtenir une signature de l'utilisateur sur la base de ces besoins, et de mettre en place des procédures pour limiter les changements après la signature. Un inconvénient est que la simple compréhension par l'utilisateur des options possibles pour les besoins est délicate. C'est d'autant plus difficile que l'organisation qui développe ne fournit pas généralement de coûts sur les besoins. Vous vous retrouvez dans une situation où vous désirez peut-être un toit ouvrant pour votre voiture, mais le vendeur ne peut vous dire si cela rajout 10 euros au prix de la voiture ou 10 000 euros. Sans estimation du coût, comment savoir si vous voulez ou non payer pour ce toit ouvrant? L'estimation est difficile pour plusieurs raisons. D'abord parce que le développement est une activité de design, et donc difficile à planifier et estimer. Ensuite parce que les matériaux basiques changent sans cesse rapidement. Enfin parce que beaucoup dépends des individus qui sont impliqués, et que les individus sont complexes à prédire et quantifier. La nature intangible du logiciel a aussi son importance. Il est très difficile de concevoir la valeur d'une fonctionnalité logicielle avant de commencer réellement à l'utiliser. Ce n'est que lorsque vous avez une version initiale d'un logiciel que vous vous rendez compte de quelles parties sont valables, et quelles parties le sont moins. Ces facteurs amènent une situation ironique, suivant laquelle les utilisateurs s'attendent à ce que les besoins puissent évoluer. Après tout, le logiciel n'est pas du matériel, il doit être souple. Fixer les besoins avec les utilisateurs du logiciel demande beaucoup d'énergie. C'est encore pire lorsque l'utilisateur a été impliqué lui-même dans du développement informatique, et qu'il 'sait' que le logiciel peut être souple. Mais même si vous pouviez fixer une bonne fois pour toute cela, et
obtenir une expression des besoins stable et précise, vous seriez
probablement toujours maudit. Dans la nouvelle économie, les forces
fondamentales changent la valeur des fonctionnalités logicielles trop
vite. Ce qui peut être un bon ensemble de besoins maintenant, n'est pas
forcément bon pour dans six mois. Et beaucoup de changements dans A part cela, tout le reste dans le développement logiciel dépend de l'expression des besoins. Si vous ne pouvez pas obtenir des besoins stables, vous ne pouvez pas faire de planification un tant soit peu fiable. 2.3 Est-il impossible de prévoir? Ne généralisons pas. Il y a des développements logiciels ou la prévision est possible. Des organisations comme la NASA sont un exemple fameux, où trouver des projets de développement logiciel prévisibles. Cela demande un paquet de cérémonie, beaucoup de temps, une grosse équipe, et des besoins stables. Il y'a beaucoup de projets ici et la qui sont des 'navettes spatiales'. Cependant je ne pense pas que beaucoup de logiciels d'entreprise correspondent au profil. Pour eux il faut un processus différent. L'un des gros dangers est de prétendre suivre un processus prévisible, alors qu'en réalité pour ne le pouvez pas. Les personnes qui travaillent sur une méthodologie ne sont pas fortes pour identifier les conditions aux limites: les régions où la méthodologie devient inappropriée. La plus part des méthodologistes veulent que leur méthode soit utilisée par tout le monde, donc ils ne comprennent et ne publient pas les limites. Ceci conduit des gens à utiliser des méthodes dans des circonstances où elle n'est pas applicable, comme par exemple d'utiliser une méthode prédictive dans une situation imprévisible. Il y'a une forte tentation à suivre cette voie. La prévisibilité est un objet désirable. Cependant si vous croyez pouvoir prévoir quand en réalité vous ne le pouvez pas, vous risquez de construire un beau plan à l'avance et de ne pas bien gérer la situation lorsque le plan s'écroule. Vous voyez le plan et la réalité doucement s'écarter. Pendant une certaine durée, vous prétendez que le plan est toujours valable. Mais à un certain point l'écart est trop important et le plan s'écroule. Souvent la chute est douloureuse. Donc si vous êtes dans une situation imprévisible, vous ne pouvez pas utiliser une méthode prédictive. C'est un mauvais coup. Ce qui veut dire, que beaucoup des modèles utilisés pour contrôler les projets, beaucoup des modèles de relation client, ne sont plus valables. Les bénéfices de la prévisibilité sont si grands, qu'il est difficile de s'en passer. Comme dans beaucoup de problèmes, le plus difficile est de reconnaître qu'ils existent. Cependant laisser de coté toute prétention à la prédictibilité ne signifie pas que vous devez vous abandonner à un incontrôlable chaos. C'est précisément l'objectif de l'adaptabilité. 2.4 Contrôler un Processus Imprévisible Donc, quel contrôle pour un monde imprévisible? Le plus important, et toujours ardu, est de savoir précisément où nous en sommes. Nous avons besoin d'un retour d'informations honnête qui nous donne un tableau de bord de la situation à intervalles fréquents. La clef de ce retour d'information est le développement itératif. Ce n'est pas une idée neuve. Le développement itératif existe depuis des lustres sous différents noms: incrémental, évolution aire, à paliers, spiral,... beaucoup de noms. L'idée est de produire fréquemment une version du système qui marche, mais n'ayant qu'une partie des fonctionnalités demandées. Ces systèmes n'ont pas toutes les fonctionnalités, mais doivent autrement respecter les attentes vis à vis du système final. Ils doivent donc être intégrés et testés aussi soigneusement qu'une livraison finale. Rien ne peut mieux apporter de la réalité concrète dans un projet qu'une livraison testée et intégrée. Les documents (ou bien du code non testé) peuvent cacher toutes sortes d'erreurs et de compromis en qualité. Mais lorsque les utilisateurs assistent en face d'un écran avec le système, et travaillent avec lui, alors les défauts apparaissent: à la fois en termes de bogues, et aussi en terme de besoins mal compris. Le développement itératif est possible également dans le cas des
processus prédictifs. Mais il est nécessaire dans les processus
adaptatifs car un processus adaptatif doit être capable de s'adapter à Une décision importante porte sur la durée des itérations. Différentes personnes ont différentes approches. XP suggère des itérations de une à trois semaines. SCRUM suggère un mois. Crystal étend encore la période. La tendance, effectivement, consiste à faire l'itération aussi courte que possible. Ceci fournit un meilleur retour d'information, de manière à connaître la situation plus souvent. 3 Mettre l'Humain au premier plan Exécuter des processus adaptatifs n'est pas chose facile. En particulier cela requière une équipe de développement très efficace. L'équipe nécessite d'être efficace en terme de la qualité des individus, et dans son mélange de compétences. Il y a également une synergie intéressante: non seulement l'adaptativité demande une équipe de développement solide, mais aussi la plus part des bons développeurs préfèrent un processus adaptatif. 3.1 Equipes de développement 'Plug-and-play' L'un des objectifs des méthodologies traditionnelles est de
développer un processus dans lequel les personnes sont remplaçables.
Avec un tel processus vous pouvez traiter les personnes comme des
ressources qui sont disponibles sous différents types. Vous avez un
analyste, des Mais les personnes impliquées dans le développement, sont elles remplaçables? Un des trait caractéristiques des méthodes agiles, est qu'elles rejettent cette notion de remplacabilité. Peut-être le plus radical dans son rejet de la notion de 'ressource', Alistair Cockburn [AC19xx] affirme que les processus prédictifs requirent des composants qui se comportent de manière prévisible. Bien que Cockburn soit le plus explicite dans sa vue 'orientée-humain', la notion d'Humain d'abord est un thème majeur de beaucoup de penseurs en informatique. Le problème, trop souvent, est que la méthodologie a été opposée à la notion que les personnes sont les facteurs de premier ordre dans le succès des projets. Cette approche créée un effet fort et positif. Au contraire, si vous vous attendez à ce que les développeurs soient des unités de programmation plug-and-play, vous ne les traitez pas comme des individus. Ceci affecte négativement le moral (et la productivité). Les meilleurs individus cherchent une meilleure place pour travaillez, et vous vous retrouvez avec ce que vous voulez: des unités de programmation plug-and-play. Décider que l'individu compte avant tout est une décision
importante, dont l'implémentation requière une motivation importante.
La notion des individus en tant que resources est profondément
incrustée dans la 3.2 Les Programmeurs sont des Professionnels Responsables Une notion clef du Taylorisme est que les gens qui travaillent ne sont pas ceux qui peuvent le mieux définir comment faire ce travail. Dans une usine, cela peut être vrai pour plusieurs raisons. En partie, parce que les ouvriers qui travaillent dans les usines ne sont pas parmi les plus intelligents et créatifs. En partie aussi parce que il y a une véritable tension entre le management et les ouvriers, découlant du fait que les managers gagnent plus lorsque les ouvriers gagnent moins. L'histoire récente nous montre à quel point cela est faux pour du développement. Des personnes de plus en plus brillantes et capables sont attirées par le développement informatique, attirés par son excitation et potentiellement par ses attraits financiers. Des plans de motivation tels que les stock options alignent l'intérêt des programmeurs avec ceux de la société. (Il pourrait bien s'agir d'un effet de génération. Quelques anecdotes me font hésiter si plus de personnes brillantes s'aventurent aujourd'hui dans l'informatique, qu'au cours des dix dernières années. Si tel est le cas, cela expliquerait pourquoi il y a un tel culte de la jeunesse dans l'industrie informatique, dans la mesure ou tous les cultes ont une part de vérité en eux). Lorsque vous voulez embaucher et conserver des gens brillants, vous devez reconnaître qu'ils sont de professionnels compétents. En tant que tels ils sont les plus à même pour décider comment conduire techniquement leur travail. La notion Tayloriste de séparation entre un département de planification qui décide comment faire les choses ne fonctionne que si les personnes s'occupant de la planification comprennent comment faire le travail mieux que ceux qui le font. Si vous avez des personnes brillantes et motivées, travailler dans ce cas n'a plus d'intérêt. 3.3 Gérer un Processus Orienté vers l'Individu L'orientation vers l'individu se manifeste de différentes manières dans les processus agiles. Elle a différents effets, pas tous consistants. Un élément clef est l'acceptation du processus plutôt que l'imposition du processus. Souvent les processus de développement logiciel sont imposés par la direction. En tant que tels, ils sont souvent mal acceptés, surtout que la direction s'est écartée de manière significative du développement. Accepter un processus demande une motivation, et en tant que tel demande l'implication de toute l'équipe. Ceci conduit à un résultat intéressant, selon lequel seuls les développeurs peuvent choisir de suivre un développement adaptatif. Ceci est particulièrement vrai pour XP, qui demande beaucoup de discipline dans son exécution. C'est là où Crystal se distingue par son objectif d'être le moins discipliné possible. Un autre point est que les développeurs doivent être capable de faire _toutes_ les décisions techniques. XP atteint au cœur de ceci, en préconisant dans son processus de planification seul les développeurs peuvent estimer combien de temps leur est nécessaire pour exécuter une tâche. Un tel leadership de la technique est un seuil à franchir pour beaucoup de cadres de direction. Une telle approche demande un partage des responsabilités où les développeurs et le management ont une place équivalente dans la gestion du projet. Remarquez que je dis équivalente. Le management a toujours un rôle à jouer, mais reconnaît l'expertise des développeurs. Une raison importante pour cela est le taux de changement de technologie dans notre industrie. Apres quelques années les connaissances techniques deviennent obsolètes. Cette réduction de la durée de vie des compétences techniques est sans parallèle dans toute autre industrie. Même les techniciens admettent que l'accès à un poste de management signifie une perte rapide de compétences techniques. Les ex-développeurs doivent reconnaître que leurs compétences techniques vont rapidement disparaître et qu'ils doivent se reposer sur d'autres développeurs plus au courant des nouveautés. 3.4 Le rôle du Leadership Métier Mais les techniciens ne peuvent assumer l'ensemble du processus par eux-mêmes. Ils ont besoin de guidage sur les besoins métier. Ceci nous amène à un autre aspect des processus adaptatifs: ils nécessitent un contact rapproché avec l'expertise métier. Ceci va plus loin que l'implication classique de l'expert métier
dans les projets. Les équipes agiles ne peuvent exister sans
communication. Elles nécessitent un accès continuel à l'expertise
métier. En outre, cet accès n'est pas quelque chose qui peut être géré
par le management, c'est quelque chose qui doit être présent et
accessible pour chaque développeur. Dans la mesure où les développeurs
sont des Pour une large part, ceci est dû à la nature adaptative du processus de développement adaptatif. Puisque l'esprit du développement adaptatif est de s'adapter au changement, il faut un contact permanent qui informe tout le monde de ces changements. Il n'y rien de plus frustrant pour un développeur que de voir le résultat d'un effort important être jeté à la poubelle. Donc il est important de s'assurer qu'une expertise est disponible pour le développeur, et d'une qualité suffisante pour inspirer la confiance. 3.5 Le processus Auto-Adaptatif Jusqu'a présent j'ai parlé de l'adaptabilité dans le contexte d'un projet qui adapte un logiciel fréquemment pour tenir compte des changements des besoins des utilisateurs. Cependant, il y a un autre angle à l'adaptabilité: celui du processus qui change au fur et à mesure du temps. Un projet qui démarre en utilisant un processus adaptatif n'aura pas le même processus un an plus tard. Au fur et à mesure du temps, l'équipe va découvrir ce qui fonctionne pour elle et modifier le processus en conséquence. La première partie de l'auto-adaptativité est de faire des revues régulières du processus. Généralement vous faites cela à chaque itération. A la fin de chaque itération, vous faites une courte réunion et vous vous demandez les questions suivantes: - qu'est-ce qu'on a bien fait? - qu'est-ce qu'on a appris? - qu'est-ce qu'on peut faire mieux? - qu'est-ce qui nous étonne/inquiète? Ces questions vont vous apporter des idées pour changer le processus pour la prochaine itération. De cette manière, le processus qui démarre avec des difficultés peut l'améliorer au fur et à mesure que le projet mûrit, en s'adaptant de mieux en mieux à l'équipe qui l'utilise. Si l'auto-adaptativité fonctionne pour un projet, c'est encore plus marqué à travers toute une organisation. Afin d'accentuer le processus d'auto-adaptativité, je suggère aux équipes de faire une revue formelle des projets, en suivant une rétrospective des projets suggérée par Norm Kerth. Ces rétrospectives supposent une réunion de 2-3 jours (à la campagne) et un facilitateur d'expérience. Non seulement ces sessions forment l'équipe, mais elles bénéficient à l'ensemble de l'organisation. Une conséquence de l'auto-adaptativité est que vous ne devriez pas vous attendre à trouver une méthodologie unique d'entreprise. Au lieu de cela, chaque équipe ne devrait pas choisir leur propre processus, mais au contraire adapter un processus au fur et à mesure qu'ils avancent dans un projet. Tandis que les deux processus (le processus théorique, et le processus adapté) peuvent agir comme une inspiration et une base, une responsabilité professionnelle des développeurs est de faire évoluer le processus en fonction de l'activité courante. Cette auto-adaptativité est la plus marquée dans ASD et Crystal. Les
règles rigides de XP semblent l'interdire, mais cela n'est qu'une
première impression car XP encourage les utilisateurs à adapter le Plusieurs méthodologies sont rassemblées sous la bannière du
développement agile. Elles ont toutes des caractéristiques en commun,
mais il y a des différences significatives. Je ne peux pas souligner
toutes les différences dans cette étude, mais au moins je peux indiquer
où commencer une recherche plus approfondie. Egalement, je ne peux pas
prétendre avoir de l'expérience sur toutes ces méthodes. J'ai De toutes les méthodes agiles, c'est celle qui attire le plus d'attention. En partie pour la remarquable habilité des fondateurs de XP, en particulier Ken Beck, pour attirer l'attention. C'est aussi grâce au talent publicitaire et managérial de Ken Beck que XP a attiré tant de monde. Par certains coté cependant, la popularité de XP est devenue un problème, en occultant les autres méthodologies agiles et leurs bonnes idées. XP prend racine dans la communauté XP, et en particulier la collaboration étroite de Ken Beck et Ward Cunningham dans les années 80. Tous deux ont redéfini leur manière de travailler au cours de nombreux projets dans les années 90, construisant leurs idées sur une approche de développement logiciel qui soit adaptative et orientée vers l'individu. Une étape cruciale allant au-delà de la pratique informelle s'est produite au printemps 96. Kent faisait alors un audit d'avancement sur un projet de mise en place de C3 dans la division ressources humaines de Chrysler. Le projet était réalisé en Smalltalk par une société de service, et allait mal. Du fait de la mauvaise qualité du code, Kent a suggéré de jeter tout et de recommencer à partir de zéro. Le projet fut recommencé sous sa direction et devint ensuite la première vitrine de XP, utilisée pour la formation et la promotion. La première phase de C3 fut mise en production au début 97. Le projet a continué connu de nouvelles difficultés plus tard, qui ont eu pour résultat l'abandon des nouveaux développements en 99. A l'heure où j'écris ceci, il est toujours utilisé pour payer les 10 000 employés de Chrysler. XP commence avec 4 valeurs: la communication, le retour d'information, la simplicité, le courage. Il construit ensuite une douzaine de pratiques auxquelles les projets XP devraient se conformer. La plupart de ces pratiques sont anciennes, admises et testées, et pourtant oubliées par beaucoup, y compris dans les projets les plus planifiés. Outre la résurrection de ces pratiques, XP les assemble dans un ensemble cohérent et synergique, dans lequel chaque pratique est renforcée par les autres. Un des cotés les plus percutants, qui m'attire initialement, est l'accent mis sur le test. Alors que la plupart des processus évoquent le test, ils ne soulignent pas sont importance. XP met le test au cœur du développement, avec chaque développeur qui écrit les tests en même temps qu'il écrit le code source. Les tests sont intégrés dans un processus de compilation et d'intégration continue, qui tend à stabiliser une plate-forme pour les développements futurs. Sur cette plate-forme XP créé un processus de design évolutif, qui s'appuie sur le 'refactoring' -- la remise en cause perpétuelle de l'architecture et le design -- d'un système de base à chaque itération. Tout le design est concentré sur l'itération en cours avec aucune anticipation pour des besoins futurs. Le résultat est un processus de design discipliné, et pourtant impressionnant car il combine la discipline et l'adaptabilité. De telle manière qu'il peut prétendre à la première place parmi les méthodes adaptatives. XP a développé un leadership étendu, prenant souvent ses sources dans le projet initial C3. En conséquence, on trouve beaucoup de sources d'information différentes. [...] Kent Beck a écrit Extreme Programming Explained, le manifesto clef de XP, qui explique le raisonnement derrière la méthodologie et suffisamment d'explications pour commencer à s'y intéresser en détail. Deux autres livres ont récemment parus. Trois membres du projet C3: Ron Jeffries (xprogramming.com), Ann Anderson (extremeprogramming.org) et Chet Hendrickson (xPlorations) ont écrit Installer la Programmation Extrème, une explication de XP basée sur l'expérience C3. Ken Beck et moi-même avons écrit Planifier la Programmation Extrème, qui évoque les différentes manières de planifier de manière adaptative. Outre les livres, il existe une multitude de sources d'information
sur le Web. La plus part d'entre elles résultant de la vague de
propagation initiale qui sur l'outil d'expression collaborative Wiki de
Ward Cunningham. Le Wiki de XP reste un endroit fascinant à découvrir,
quoi que sa nature broussailleuse puisse vous engouffrer. Pour trouver
une approche plus structurée de XP, il vaut mieux commencer avec deux
sites d'anciens C3: xProgramming.org de Ron Jeffries et
extremeProgramming.org de Don Wells. xPloration de Bill Wake contient
aussi quelques documents utilisables. Robert Martin, l'auteur bien
connu de livres sur C++ et le design orienté objet a également rejoint
la liste des promoteurs du concept XP. Sa société, Object Mentor, fournit beaucoup de documents sur son site web, y compris une instance XP de RUP appelée dX. Ils sponsorisent également un groupe de discussion sur XP.
Un des vues "extérieur" des plus intéressantes de XP est celui de Mark
Paulk, qui est un des leaders de la communauté CMM - son article
visualise XP au travers d'une perspective CMM 4.2 La Famille de Méthodologies Crystal Alistair Cockburn a travaillé sur la méthodologie depuis qu'il a été affecté par IBM à leur rédaction et documentation par IBM dans les années 90. Son approche va au rebours de beaucoup de méthodologistes, cependant. Au lieu de construire une théorie de comment les choses devraient être faites, en se basant simplement sur son expérience personnelle, il supplante son expérience en allant activement interroger des projets pour voir comment ils fonctionnent. En outre il n'a pas peur de remettre en cause ses vues en fonction de ses découvertes: autant de raison pour être mon méthodologiste favori. Son livre, Survivre aux Projets Orientés Objet,
a été son premier essai sur le thème de la gestion de projets, et reste
ma recommandation numéro un pour gérer des projets itératifs. Plus
récemment Alistair a écrit un livre sur le développement agile de logiciel qui regarde les principes fondamentaux de ces genres de méthodologies Depuis ce livre il a exploré les méthodes agiles plus en détail, en sortant le livre La Famille Crystal de méthodologies. C'est une famille car il considère que plusieurs types de projets demandent différents types de méthodologies. Il aborde cette disparité suivant deux axes: le nombre de personnes dans le projet, et les conséquences des erreurs. Chaque méthodologie entre dans une case différente de la grille, si bien qu'un projet de 40 personnes ne pouvant faire perdre que peu d'argent a une méthodologie différente qu'un projet de six personnes dont dépendraient des vies humaines. Les méthodes Crystal partagent avec XP l'orientation vers l'individu, mais le coté humain est abordé différemment. Alistair considère que les gens trouvent difficile de suivre un processus discipliné, donc plutôt que de leur faire suivre le rigoureux processus XP, Alistair explorer les méthodologies les moins disciplinées qui pourraient encore marcher en favorisant la facilité d'exécution plutôt que la productivité. Il considère donc que bien que Crystal soit moins productif que XP, plus de monde pourront l'utiliser. Alistair met aussi beaucoup l'accent sur la revue à la fin de chaque itération, encourageant ainsi le processus à évoluer de lui-même. Son assertion est que le développement itératif est là pour trouver les problèmes en amont et permettre aux individus de les corriger. Ceci met donc l'accent sur la responsabilité des individus de suivre l'évolution de leur processus de travail dans le temps, et de le faire évoluer en fonction de leur expérience. En Février 2001 Alistair a annoncé que Jim Highsmith et lui-même allaient fondre leurs deux méthodologies. Ce que cela signifie, et même comment cela va s'appeler, est à ce jour encore une question ouverte. Vous pourriez vous étonner de ce sous-titre. Après tout, l'open source est un type de logiciel, pas un processus. Cependant, il y a une manière bien définie de travailler au sein de la communauté open source, et une part importante de leur approche est applicable aux projets fermés autant qu'aux projets open source. En particulier leur processus est adapté aux équipes physiquement distribuées, ce qui est important dans la mesure où les autres processus adaptatifs mettent l'accent sur des équipes rapprochées. La plupart des projets open source ont un ou plusieurs mainteneurs. Un mainteneur est une personne unique qui est autorisée à faire un changement dans le code source principal. Cependant beaucoup d'autres personnes peuvent soumettre des propositions de changements au mainteneur, qui les vérifie et les applique au code source principal. En général ces changements sont faits sous la forme de fichiers patch, ce qui facilite le processus. Le mainteneur est donc responsable de la coordination de ces changements et de maintenir la cohésion générale du logiciel, en terme de design. Différents projets gèrent la question du mainteneur de différentes manières. Certains ont un mainteneur pour la totalité du projet, d'autres le divisent en modules séparés, d'autres font tourner le mainteneur, d'autres ont plusieurs mainteneurs pour le même code, d'autres font une combinaison de ces idées. La majorité des développeurs open source sont à temps partiel, dont il y a un problème de qualité de coordination pour les projets à plein temps. Un trait particulier du développement open source est que le débuguage est hautement parallélisable. Donc beaucoup de personnes peuvent s'impliquer dans le débuguage. Lorsqu'ils trouvent un bug, ils peuvent envoyer le patch au mainteneur. C'est un bon rôle pour les non-mainteneurs dans la mesure où énormément de temps est passé à trouver les bugs. C'est aussi une tâche acceptable pour les développeurs qui n'ont pas de compétence importante en design. Le processus du monde open source n'est pas encore écrit. Le document le plus marquant est d'Eric Raymond, La Cathédrale et le Bazar, qui fournit un description excellente mais hélas trop brève. Le livre de Karl Fogel à propos de CVS contient aussi quelques bons chapitres sur le processus open source, même pour ceux qui n'ont aucune intention d'utiliser CVS. 4.4 Le Développement Adaptatif de Logiciels de Highsmith Jim Highsmith a passé
beaucoup de temps à travailler sur les méthodologies adaptatives. Il
les a développées, il les a installées, il les a enseignées, et il a
conclu qu'elles étaient profondément Son livre le plus récent se concentre sur la nature adaptative des nouvelles méthodologies, avec un accent plus particulièrement sur l'application des idées qui puisent dans les systèmes adaptatifs complexes (que l'on nomme communément la théorie du chaos). Il n'offre pas de manuel pratique détaillé comme dans XP, mais il fournit la base fondamentale pour comprendre le besoin d'un processus de développement adaptatif, et ses conséquences au plus haut niveau notamment sur les plans de l'organisation et du management. Au cœur d'ASD il y a trois phases non linéaires qui peuvent se chevaucher: la spéculation, la collaboration, et l'apprentissage. Highsmith voit la planification comme un paradoxe dans l'environnement adaptatif, puisque les résultats sont par nature imprévisibles. En planification traditionnelle, les écarts par rapport au plan sont des erreurs qui doivent être corrigées. Dans un environnement adaptatif, cependant, les écarts nous guident vers la bonne solution. Dans cet environnement imprévisible vous avez besoin de personnes qui collaborent efficacement pour s'accommoder de l'incertain. L'attention de la Direction doit se porter moins sur la dictée de ce que le gens doivent faire, que sur l'encouragement de la communication afin que les individus apportent eux-même des réponses créatives. Dans les environnements prédictifs, l'apprentissage est souvent découragé. Vous posez des jalons en avance, puis vous suivez le plan. << Dans un environnement adaptatif, l'apprentissage remet
en question tous les intervenants --les développeurs et les
utilisateurs-- pour qu'ils examinent leurs supposition et qu'ils
utilisent les résultats de chaque itération du cycle de développement
pour adapter le cycle suivant. >> En tant que tel, l'apprentissage est un aspect important et continuel, on peut aussi supposer que les plans et le design change au fur et à mesure que le développement progresse. << Le bénéfice prédominant, le plus puissant, indivisible
et révolutionnaire, dans le Cycle de Développement Adaptatif, est qu'il
nous force à confronter les modèles mentaux qui sont à la racine de
notre mise en erreur. Il nous force à estimer de manière plus réaliste
nos capacités. >> En mettant l'accent sur ce point, le travail de Highsmith se concentre directement sur les points délicats du développement adaptatif, en particulier comment faire naître la collaboration et l'apprentissage collectif et individuel dans le projet. En tant que tel, son livre fournit des éléments de réponse et pour faire naître ces éléments flous, qui sont des compléments si essentiels aux pratiques plus fournies telles que XP, FDD et Crystal. Aussi, l'annonce faite en Février 2001 qu'il va fondre sa méthodologie avec Crystal semble raisonnable et fondée. Cela fait un moment que l'on croise SCRUM dans les cercles du développement orienté-objet, bien que je doive confesser ne pas être trop au courant de sont historique et de son développement. Lui aussi, se concentre sur le fait que les processus répétitifs et définis ne fonctionnent que pour s'attaquer à des problèmes répétitifs et définissables, avec des individus répétitifs et définissables, dans des environnements répétitifs et définissables. SCRUM divise un projet en itérations (qu'il nomme des courses) de 30 jours. Avant de commencer une course vous définissez la fonctionnalité requise pour cette course et laissez l'équipe vous la livrer. Le point est de stabiliser les besoins pendant la course. Cependant la Direction ne se désengage pas pendant la course. Chaque jour l'équipe échange l'information au cours d'une courte réunion de projet --appelée une scrum-- au cours de laquelle on discute de ce qu'on va faire le lendemain. En particulier, on s'en tient aux aspects de la gestion de projet: ce qui empèche de progresser et que la Direction doit résoudre. On fait aussi un rapport de ce qui a été fait, si bien que la direction est au fait de l'avancement. La littérature sur SCRUM se concentre principalement sur le processus itératif de suivi et de planification. Il est très proche de celui des autres méthodes agiles en général et devrait donc marcher, par exemple, avec les pratiques de codage de XP. Après un long temps sans livre, finalement Ken Schwaber et Mike Beedle ont écrit le premier livre de scrum. Ken Schwaber héberge controlChaos.com qui fournit le meilleur survol de la méthode SCRUM. Jeff Sutherland maintient toujours un site web actif sur les technologies objet et a inclu une section à propos de SCRUM. Il y'a aussi un manuel pratique de SCRUM dans le livre PLoPD4. 4.6 Le Développement Orienté-Fonctionalité de Coad (FDD) Le Développement Orienté-Fonctionalité de Coad, ou encore FDD (Feature Driven Developpement) a été développé par Jeff de Luca et le gourou OO Peter Coad. Comme les autres méthodologies adaptatives, il se concentre sur des itérations courtes qui fournissent un résultat tangible sous la forme d'une fonctionnalité logicielle. Dans le cas de FDD, les itérations durent deux semaines. FDD a cinq processus. Les trois premiers sont réalisés en amont du projet. Les deux derniers sont réalisés pendant chaque itération. Chaque processus est décomposé en tâches et assigné des critères de vérification. Les développeurs viennent sous deux formes distinctes: le propriétaire de classes et le programmeur en chef. Les programmeurs en chef sont les développeurs les plus expérimentés. Il leur est assigné des fonctionnalités, qu'ils doivent développer. Cependant ils ne les développent pas tout seuls. Au lieu de cela, le programmeur en chef identifie quelles classes sont impliquées dans le codage de la fonctionnalité et rassemble les propriétaires de ces classes pour former une équipe fonctionnelle, qui va développer cette fonctionnalité. Le programmeur en chef agit en tant que coordinateur, designer et mentor, tandis que les propriétaires de classes font le plus lourd du codage de la fonctionnalité. Jusque récemment, la documentation sur FDD était très légère. Enfin il y a un livre complet sur FDD. Jeff De Luca, le premier inventeur a maintenant un portail FDD avec des articles et des forum de discussion La description principale de FDD est Peter Coad dans son livre UML en Couleur. Sa société, TogetherSoft, fait également du conseil et de la formation sur FDD. 4.7 Méthode Dynamique de Développement des Systèmes (DSDM) DSDM s'est développé en Grande Bretagne en 94 sous la forme d'un consortium de sociétés voulant construire sur le développement RAD (Développement Rapide) et itératif. En débutant avec 17 fondateurs il peut maintenant se targuer de plus d'un millier de membres et a grossi au delà de ses racines anglaises. Etant développé par un consortium, il se distingue des autres méthodes agiles de par sa nature. Il a une organisation à plein temps qui le supporte à l'aide de manuels, de cours de formation, de programmes d'accréditation, etc. Il a aussi un prix, ce qui a limité mes recherches sur la méthodologie. Cependant, Jenifer Stapleton a écrit un livre qui donne un aperçu de la méthodologie. L'utilisation de cette méthode commence par une étude métier et une
étude de faisabilité. L'étude de faisabilité considère si DSDM est
approprié au projet en cours. L'étude métier est un série courte Le reste du processus forme trois cycles imbriqués: le cycle du modèle fonctionnel produit l'analyse de la documentation et des prototypes. Le cycle du design, et le cycle de construction produit l'ingénierie du système en vue de l'utilisation opérationnelle, le cycle d'implémentation produit le déploiement pour l'utilisation opérationnelle. DSDM a des principes sous-jacents qui incluent une interaction active avec l'utilisateur, des livraisons fréquentes, des équipes autonomes, du test tout au long du cycle. Comme d'autres méthodes agiles, elles utilisent des cycles distinct de 2 à 6 semaines. Il y a un accent marqué sur la qualité et l'adaptation aux changements de besoins. Je n'ai pas trouvé beaucoup d'exemples d'utilisation de la méthode hors du Royaume-Uni, mais DSDL est remarquable pour son infrastructure, digne d'une méthode plus mature, tout en suivant les principes des méthodologies agiles. [...] Avec une telle similarité parmi ces méthodes, il y avait un intérêt
manifeste pour une forme de travail collaboratif. Aussi, des
représentants de chacune de ces méthodologies ont été conviés à un En fait, j'ai été surpris. Tout le monde était conscient qu'il y a un terrain d'entente, et cette reconnaissance était plus importante que les différences entre les processus. Aussi, outre la prise de contact utile entre les décideurs de différentes méthodologies, il y avait aussi l'idée de lancer un appel aux armes commun pour des processus de développement plus agiles (c'est aussi à cette occasion que nous nous sommes mis d'accord sur le terme agile, pour nos méthodes). Le résultat est un Manifeste pour le Développement Agile de Logiciels, un document à propos des valeurs communes et des principes des processus agiles. Il y a aussi un désir de collaborer plus loin dans le futur, pour encourager encore plus les ingénieurs et les responsables d'entreprises à utiliser et demander l'usage des méthodes agiles pour le développement logiciel. 4.9 RUP est-elle une méthode Agile? Chaque fois que nous commençons à discuter sur le thème des méthodes dans le domaine OO, nous touchons inévitablement au rôle de Rational Unified Process (RUP). RUP a été développé par Philippe Kruchten, Ivar Jacobson et d'autres à Rational comme le complément au niveau processus de UML. RUP est un framework et en tant que tel peut accommoder une variété de processus. En effet, c'est là le défaut principal de RUP -- puisqu'il peut être n'importe quoi, il finit par n'être rien du tout. Je préfère un processus qui vous indique quoi faire plutôt que de fournir des options à l'infini. La conséquence de cette mentalité 'framework de processus' est que RUP peut être utilisé de la manière traditionnelle en cascade ou de la manière agile. Donc vous pouvez utiliser RUP en mode agile, ou bien comme un processus lourd -- tout dépend de comment vous configurez votre environnement. Craig Larman est un moteur de l'utilisation de RUP dans sa forme agile. Son excellente introduction au développement orienté-objet contient un processus qui est basé sur son approche légère de RUP. Son opinion est que l'intérêt croissant pour les méthodes agiles n'est rien d'autre que l'acceptation d'une approche générale au développement orienté objet qui a été capturé dans RUP. Craig recommande en particulier de passer les trois premiers jours de chaque itération avec la totalité de l'équipe utilisant UML pour définir les grandes lignes du travail à faire durant l'itération. Ceci n'est pas une recommandation rigide, mais plutôt un exemple de comment les gens peuvent travailler durant les itérations. Une autre pointe à RUP agile est processus dX
de Robert Martin. Le processus de dx est un exemple entièrement
conforme de RUP, celui s'avère justement juste être identique à XP (dX
inversé pour voir la plaisanterie !). le dX est conçu pour les gens qui
doivent utiliser RUP, mais qui veulent utiliser XP. Pour moi, une décision que les acteurs industriels du monde RUP doivent prendre est de définir leur approche au développement logiciel. Plus d'une fois j'ai entendu dire que les gens qui utilisent RUP le font souvent pour formaliser un processus de développement en cascade. Grâce à mes contacts dans l'industrie je sais que Philippe Kruchten et son équipe sont de fermes défenseurs du développement itératif. La clarification de ces principes et l'encouragement d'instances agiles de RUP, que l'on retrouve dans le travail de Craig et de Robert, auront un impact important. Récemment nous avons vu deux bons livres paraître qui regardent le large sujet des méthodes agiles d'Alistair Cockburn et de Jim Highsmith. Il y a un certain nombre d'autres papiers et discussions au sujet de
ce thème des méthodes agiles. Tandis que ceux-ci peuvent ne pas être de
pleines méthodologies, elles offrent des perspicacités dans cette zone
croissante.. Quoique ceux-ci ne soient pas des méthodologies complètes,
elles offrent des points de vue dans ce champs en pleine croissance.
Les conférences sur la Programmation des Patterns
(Patterns Language Programming) ont souvent contenu des articles sur le
sujet, en partie parce que ceux qui s'intéressent aux patterns
s'intéressent aussi à des méthodes de développement plus adaptatives et
plus humaines. Un article majeur a été publié dans PLoP1
par Jim Coplein, qui héberge aussi OrgPatterns, un wiki qui collecte
des patterns d'organisation. Les Patterns 'Episodes' de Ward Cunningham
ont également été publiées dans PLoP2. Jim Coplein accueille maintenant le site d'OrgPatterns, un wiki qui rassemble ensemble des patterns pour les organizational patterns. Dirk Riehle a envoyé un article à XP2000 qui compare le système de valeurs de XP et de ADS. L'édition de Juillet de la lettre de Coad compare XP à FDD. L'édition de Juillet de IEEE Software inclut plusieurs articles sur la diversité des processus qui traite de ces méthodologies. Mary a écrit un article fascinant comparant les méthodologies agiles et les programmations maigres. Agile n'est pas à mettre entre toutes les mains. Il y a pas mal d'éléments à avoir dans l'esprit avant de décider de s'orienter vers cette voie. Cependant je pense que ces méthodes sont largement applicables et devraient être utilisées par plus de monde qu'actuellement. Dans l'environnement d'aujourd'hui, la méthode la plus habituelle est: coder et débuguer. Appliquer une méthode plus disciplinée que le chaos ne peut qu'améliorer les choses, et l'avantage de l'approche agile est qu'elle ne représente pas une barrière insurmontable que peut être par exemple, une méthode lourde. Les processus simples sont plus susceptibles d'être suivis quand vous avez l'habitude de ne suivre aucun processus. La limitation la plus importante de ces méthodes est comment elles s'appliquent à des équipes importantes. Crystal a été utilisé sur une cinquantaine de personnes, mais au delà de cette taille il n'y a pas d'exemple pour utiliser une méthode adaptative, ou même de preuve qu'une telle approche va fonctionner. On peut espérer qu'en ayant lu ce document vous avez compris que l'approche adaptative est bonne quand les besoins sont incertains ou volatiles. Si vous n'avez pas de besoins stables, alors vous n'êtes pas en mesure d'avoir un design stable et de suivre un processus planifié. Dans ces situations un processus adaptatif peut être moins confortable mais sera plus efficace. Souvent l'une des barrières les plus difficile est l'utilisateur lui-même. A mon avis il est important que l'utilisateur comprenne que suivre un processus prédictif quand les besoins peuvent changer est aussi risqué pour lui que pour le développement. Si vous avez plus de cinquante personnes sur un projet vous devriez utiliser une approche traditionnelle et prédictive, et si vous avez des besoins qui évoluent vous devriez utiliser un processus adaptatif. Que faire si vous avez à la fois un gros projet et des changements qui évoluent? Je n'ai pas de bonne réponse à cette question, aussi je suggère que vous cherchiez un second point de vue. Je peux vous dire que cette situation est risquée et difficile, mais je ne vous apprends rien. Si vous prenez le chemin des Processus adaptatifs, vous devez faire confiance à vous développeurs et les impliquer dans la décision. Les processus adaptatifs s'appuient sur une relation de confiance avec les développeurs, donc si vous considérez qu'ils sont mauvais ou peu motivés alors vous devriez utiliser une approche prédictive. En résumé, les facteurs suivants suggèrent l'utilisation d'un processus adaptatif: - des besoins incertains et volatiles - des développeurs responsables et motivés - des utilisateurs qui comprennent et s'impliquent Ces facteurs suggèrent au contraire l'utilisation d'une approche traditionnelle de processus de développement: - une équipe de plus de cinquante personnes - un prix fixe, ou plus exactement un cadre bien défini, par exemple sous la forme d'un contrat Tous ces processus sont nouveaux, et je ne peux que vous donner quelques indications pour vous guider. Selon moi, le choix découle de la taille de l'équipe et à quel niveau de discipline ils sont susceptibles de s'adapter. Avec une douzaine de développeurs ou moins qui sont inclinés à essayer, j'avancerais certainement XP. Il se peut que l'équipe ne s'approprie pas la totalité de XP, au moins au départ, mais vous obtiendrez déjà une plus value importante de la mise en place même partielle de XP. Un test de validation pour l'utilisation de ce processus est l'automatisation des tests unitaires. Si l'équipe y est préparée, alors les fondations techniques sont en place. Si elles ne peuvent s'y adapter, alors je m'attends à un échec sur le reste. Si la volonté de discipline est absente, ou que l'équipe est trop grande, alors je proposerais les conseils de Crystal. C'est certainement la plus légère des méthodologies agiles, et Cockburn est particulièrement adaptatif aux leçons du développement. J'utiliserai la planification de XP dans tous les cas. En ayant dit cela, je travaille avec une équipe de quarante personnes qui a essayé avec succès beaucoup de pratiques XP, y compris XP dans sa version pure et complète. Donc avec de la détermination et une équipe impliquée vous pouvez adapter votre processus en dehors des limites que j'ai cité plus haut. C'est là le vrai message. Quel que soit le processus avec lequel vous démarrez, ce ne sera pas forcément celui qui marche le mieux pour vous. Vous devez vous approprier le processus, le surveiller et l'adapter aux circonstances. A la fin il doit devenir votre propre processus, et tout autre label est secondaire. J'ai profité des idées de beaucoup de gens dans ce document, plus que je ne pourrais citer. Pour des suggestions concrètes, je voudrais remercier Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham,Bill Kimmel et Frank Westphal. Souvenez vous que ceci est un document web qui évolue et qui peut changer chaque fois que m'en prendra l'envie. J'enregistrerai tout changement majeur, mais les corrections mineures seront simplement faites. Voici une liste des changements majeurs à ce document:
|
Document original: The New Methodology, Martin Fowler, ThoughtWorks
Localisation: Elian Carsenat , source de l'article
Dernière mise à jour significative: Mars 2001