-->
1. INFORMATIQUE. Pour programmer, quatre mains c’est bien mieux. Dans le petit monde de la programmation, l’extreme programming remporte un succès de plus en plus grand. Cela permet non seulement de faire des économies, mais aussi et surtout de réaliser des logiciels sans bogues. |
|
1. Totally awesome software ? "Extreme programming" sounds like no more than a marketing-driven fad, but fans are convinced that its rules hold the key to better code. |
-->
-->
2. SALON MAGAZINE, San Francisco |
|
2. By Sam Williams. May 29, 2002 |
-->
-->
3. Le bogue était vraiment banal, juste une lettre en moins. Dans un document normal, le correcteur d’orthographe l’aurait facilement repéré. Pourtant, cette fois, il se tapissait dans l’ombre, aussi dangereux qu’un tesson de bouteille sur du linoléum, au milieu d’un logiciel bourré de commandes plus illisibles les unes que les autres et de pseudo-mots tels que "CallOutOriginal", "CallOutCopy" et "CallOutFormRequest". |
|
3. The bug was trivial, nothing more than a missing letter. In a normal document, spellcheck would have caught it easily. In a software program filled with dozens of dyslexia-inducing commands, pseudo-words such as "CallOutOriginal," "CallOutCopy" and "CallOutFormRequest," it lurked invisible, and dangerous, like a piece of broken glass on a linoleum floor. |
-->
-->
4. Alors qu’Eli Collins, programmeur de l’entreprise de logiciels new-yorkaise Union Square Internet Development, passait en revue la liste des messages d’erreur, Tom Clarke, son collègue et partenaire de programmation pour l’après-midi, mit le doigt sur le problème. |
|
4. As Eli Collins, a programmer with the New York-based software firm Union Square Internet Development, scoured the list of error messages, Tom Clarke, Collins’ colleague and "pair programming" partner for the afternoon, made the discovery. |
-->
-->
5. "Je crois que je le vois, dit Clarke. |
|
5. "I think I see it," said Clarke. |
-->
-->
6. —Où ça ? demanda Collins. |
|
6. "Where ?" asked Collins. |
-->
-->
7. —Là, reprit Clarke, en indiquant une ligne de code-source à l’écran. On dirait que tu n ’as pas tapé le deuxième i d’original à la ligne 172." |
|
7. "Right here," Clarke said, pointing toward a line of source code on the screen. "Looks like you left out the second ’i’ in ’original’ on line 172." |
-->
-->
8. En quelques secondes, Collins avait corrigé son erreur. Un clic plus tard, le programme repassait toute une batterie de tests internes écrits au cours des deux semaines précédentes par les deux informaticiens. Cette fois, pas de lumière rouge : la barre d’état de leur programme brillait d’un vert tendre. Aucune erreur. Leur nouvelle trouvaille, une fonction d’édition commandée par la souris, recevait le feu vert leur permettant de continuer. |
|
8. Within seconds, Collins, the designated typist, had fixed the error. With a click of the return button, the program was running once again through a battery of internal tests written by the two-man coding team over the last two weeks. This time around, the offending red tinge signifying a failed test was gone. The program’s status bar showed solid green. Zero failures. Their newest feature, a point-and-click editing command, had received the green light, literally, and Collins and Clarke were ready to move on. |
-->
-->
9. "Eh bien !" s’exclama Clarke, laissant Collins piloter la machine, "voilà un autre exemple prouvant qu’une deuxième paire d’yeux est bien utile." |
|
9. "Ah yes," said Clarke, leaning back while Collins piloted the machine. "Yet another example where having a second set of eyes helps." |
-->
-->
10. UN NOMBRE CROISSANT DE PROGRAMMEURS S’Y INTÉRESSE. En ces temps d’ordinateurs portables accessibles à tous et de connectivité universelle, l’image de deux personnes travaillant au-dessus du même clavier semble aussi pittoresque qu’un tube à vide de la Radio Corporation of Amerrira (CA). Il s’agit pourtant de la dernière tendance à la mode pour un nombre croissant de programmeurs : le pair programming [la programmation en tandem]. Cette tactique fondamentale, qui fait partie d’une méthodologie émergente de développement de logiciels, est en passe de connaître un franc succès. |
|
10. In an era of cheap, portable computers and universal connectivity, the image of two people working over the same keyboard seems about as quaint as an RCA vacuum tube. For a growing number of programmers, however, it’s the latest thing : "pair programming," a cornerstone tactic in an emerging grass-roots software development methodology sweeping the industry. |
-->
-->
11. Le nom utilisé pour la décrire varie d’une personne à l’autre. Certains l’appellent "agile programming", la plupart "extreme programming" [programmation de l’extrême] ou, plus court, |
|
11. The name used to describe that methodology varies. Some call it "agile programming." Most call it "extreme programming," or "XP" for short. Whatever the name, the methodology’s tenets boil down to an intriguing mix of age-old developer wisdom, newfangled coding tactics and a sugary-sweet layer of marketing-speak. Depending upon on whom you talk to in the software industry, it’s either the biggest breakthrough since object-oriented programming or the biggest pile of hype since "push" technology. |
-->
-->
12. "XP". Quel qu’en soit le nom, sa doctrine professe un étrange mélange de sagesse de développeur aguerri et de tactiques de codage supermodernes, le tout agrémenté d’une bonne couche de marketing mielleux. |
|
12. "XP improves a software project in four essential ways : communication, simplicity, feedback, and courage," reads one XP booster site. |
-->
-->
13. "L’XP permet d’améliorer un projet de logiciel de quatre manières essentielles : au niveau de la communication, de la simplicité, du feed-back et du courage", peut-on lire sur un site faisant l’éloge de l’XP. Il est comme une chaîne aux maillons constitués de serpents venimeux", proclame un autre. Il suffit que l’un d’entre eux réussisse à s’échapper pour que vous vous trouviez en face d’un méchant reptile qui fonce droit sur vous." |
|
13. "XP is like a ring of poisonous snakes, daisy-chained together," counters another. "All it takes is for one of them to wriggle loose, and you’ve got a very angry, poisonous snake heading your way. " The truth about XP, which is no relation to the Microsoft operating system Windows XP, actually lies somewhere in the middle. Communication is certainly the key component of any XP project. Designed to overcome the endemic problem of programmers promising one thing and delivering something totally different, the XP methodology is built around putting the face-to-face interaction between developers and customers — not to mention developers and developers — over the keyboard instead of over the conference table. XP’s underlying article of faith is that if programmers and customers just communicate better, quality software will be the natural result. |
-->
-->
14. "Le principe consiste à admettre dés le premier jour que vous ignorez complètement à quoi votre logiciel va ressembler à une certaine date et à accepter que ça ne pose aucun problème", expose Colin Strasser, responsable chez Union Square Internet Development. L’alternative, se hâtent de souligner Strasser et d’autres adeptes de l’XP, est contenue dans le cauchemar trop banal de l’industrie du logiciel. Une entreprise A loue les services d’une entreprise B afin de développer un programme de plusieurs millions de dollars. Les deux sociétés rédigent un contrat détaillé précisant toutes les spécifications voulues, et l’entreprise B se met au travail. Dix-huit mois plus tard, quand l’entreprise B livre le logiciel, il ne ressemble en rien à celui qui était décrit dans le contrat. Ou, pis encore, l’entreprise B respecte le contrat à la lettre, mais livre un produit infesté de bogues. |
|
14. Totally awesome software ? 1, 2, 3 Extreme programming also means giving up a little control — acknowledging, at the outset, that software development is an imperfect process. "It’s the idea of admitting on Day 1 of a software project that you have no idea what your project’s going to look like on a given future date and saying, ’I’m OK with that,’" says Colin Strasser, managing principal of Union Square Internet Development. The alternative approach, as Strasser and other XP boosters are quick to point out, is the now familiar tale of software industry woe : Company A hires Company B to develop a multimillion dollar software program. The companies draft a contract, complete with specifications, and part ways while Company B writes the software. Eighteen months later, when Company B finally delivers, the resulting software looks absolutely nothing like the program specified in the contract. Or, even worse, Company B meets all the specifications but delivers a product riddled with bugs. |
-->
-->
15. Kent Beck, programmeur de l’Oregon qui s’est vu attribuer la paternité du terme "extreme programming", fait remonter ses origines au début de 1996. A cette époque, la société Chrysler lui avait demandé de mettre à jour le système de paie de tout le personnel. Lors des tests, Beck fit une découverte angoissante : tous les montants des salaires étaient faux. Malgré dix-huit mois de développement et des millions de dollars investis, si le logiciel répondait aux spécifications prévues, ses modules se transmettaient des données erronées. Au bout de quelques semaines, avec embarras, Beck se vit obligé d’avouer au responsable informatique de Chrysler, Sue Unger, qu’elle et ses collègues se retrouvaient avec un truc énorme et complètement inutile sur les bras. |
|
15. The history of the software industry is rife with high profile examples of this process. In 1997, the U.S. Internal Revenue Service scuttled a software upgrade to the tune of $3.5 billion. In 1995 the Denver Airport spent an extra $88 million, not including lost revenue, to debug its $193 million baggage handling system. Such examples, however, are less scandalous than the overall culture of shoddiness that seems to have infected the high tech industry over the last decade. "There’s a real tendency for business people and geeks to see development as a zero-sum game," says Kent Beck, the Oregon programmer now credited with coining the term "extreme programming." "The suits say, ’Give me more stuff, more stuff !’ The geeks say, ’But I have to do a worse and worse job to give you more stuff.’ I wanted to get away from that." Beck traces the XP story back to early 1996. At the time, the Chrysler Corp. had called him in to help bring the company’s new payroll system up to speed. In the process of putting the system through its paces, Beck made a troubling discovery : All the paycheck amounts were coming out false. Despite 18 months of development and millions of dollars, the software lived up to the original specifications but couldn’t deliver correct data from one component to the next. After a few weeks, Beck found himself in the unwelcome position of telling Sue Unger, Chrysler’s chief information officer, that she and her fellow executives had a giant lemon on their hands. |
-->
-->
16. Au lieu d’aider à corriger le logiciel, Beck recommanda à Sue Unger de s’en débarrasser et de recommencer à zéro. A sa grande surprise, elle suivit son conseil, tout en retournant la situation : elle lui confia le nouveau projet. |
|
16. Instead of helping to overhaul the system, Beck offered his professional advice. He recommended that Unger dump the software and start over from scratch. To his lasting surprise, Unger accepted the advice — with a Solomon-like twist. She put Beck in charge of the new project. |
-->
-->
17. " Je lui ai dit : ’Vous ne comprenez pas, je suis consultant, je ne vais pas sur le terrain’, se souvient Beck en riant. Elle m’a répondu : ’Vous ne comprenez pas, je m’appelle Sue Unger, et vous irez sur le terrain. " |
|
17. "I said, ’You don’t understand. I’m a consultant. I don’t do in charge,’" recalls Beck, laughing. "She said, ’You don’t understand, I’m Sue Unger. You’re in charge.’" |
-->
-->
18. UNE MÉTHODE EFFICACE A CERTAINES CONDITIONS. Dans l’espoir fou de fournir à Chrysler un logiciel utilisable, Beck fit appel à bon nombre des meilleures recettes rencontrées au cours de sa carrière. Il décida de mettre au rebut le tableau blanc et les techniques classiques pour considérer l’élaboration du logiciel comme un processus en constante évolution, enrichi par diverses critiques. |
|
18. In the mad scramble to give Chrysler something it could use, Beck called upon many of the best practices he’d come across during his career. Early on, he decided to discard the usual whiteboard planning and view system design as an evolving, feedback-driven process. |
-->
-->
19. "C’était un mélange de préparation soigneuse et de panique, se souvient Beck. J’ai décidé que nous discuterions le projet en plusieurs étapes. Chacune serait consacrée à une caractéristique voulue par le client. Il fallait également que nous puissions les tester, afin de pouvoir montrer que nous répondions à la demande." |
|
19. "It was a combination of preparation and panic," Beck says. "I decided we were going to divide the project into stories. Each story would involve a specific feature that the customer wanted. It would also be something we could test, so we could show that we had fulfilled the customer request." |
-->
-->
20. Écrire les tests avant de rédiger le code rendait superflues les spécifications exhaustives, explique Beck. Plus besoin non plus d’une vaste équipe "assurance qualité", qui, dans la plupart des projets de grande envergure, s’assure qu’un logiciel répond aux spécifications demandées. |
|
20. Writing tests before writing the code eliminated the need for exhaustive specifications, Beck says. It also eliminated the need for a large "quality assurance" team, which in most large-scale projects makes sure a software program obeys its specs. |
-->
-->
21. Beck s’est tourné vers la programmation en tandem dans un souci d’économie. A l’en croire, travailler à deux élimine la nécessité de fournir une documentation extensive sur le logiciel. Si un programmeur parvient à communiquer clairement ses idées à un autre programmeur travaillant à ses côtés, il y a de grandes chances pour que celui qui vérifiera le programme deux ans plus tard n’ait aucun mal à le comprendre. En outre, le fait qu’il y ait deux copilotes sur chaque machine permet de réduire considérablement le nombre de bogues. |
|
21. Beck turned to pair-programming out of a similar desire for economy. The way he saw it, pair programming eliminated the need for extensive software documentation. If a programmer could communicate his ideas clearly to the programmer sitting over his shoulder, chances are, the programmer inspecting the code two years later would find it easier to understand. What’s more, having a copilot on each machine would reduce the overall number of bugs. |
-->
-->
22. Plus Beck expliquait sa théorie, plus son approche lui paraissait sensée. "Au bout de quinze personnes, c’était devenu tout à fait concevable", se souvient-il. |
|
22. The more Beck explained, the more solid the approach became. "By the 15th person, it had become fully streamlined," Beck says. |
-->
-->
23. A l’été 1996, il décida de baptiser son concept. Puisque les autres méthodes donnaient la priorité au planning sur la programmation, Beck décida que "programmation" devrait faire partie du nom. "]’avais alors besoin d’un adjectif attrayant, suffisamment descriptif et défendable." |
|
23. By the middle of 1996, Beck decided to give his management concept a name. Because other methodologies emphasized planning over programming, Beck decided that "programming" should be in the title. Still, "I needed an adjective that would be catchy, descriptive and defensible," Beck says. |
-->
-->
24. Il décida alors de nommer sa méthode "extreme programming", après avoir découvert la puissance des athlètes de l’extrême. "Je voulais que mes équipes aient le même sentiment d’invulnérabilité face aux défis à relever." |
|
24. Beck says decided to name his methodology "extreme programming" after noting the intensity of extreme athletes. "I wanted my teams to have that same sense of fearlessness in the face of challenge," he says. |
-->
-->
25. Sa stratégie s’avéra payante. En 1997, Chrysler avait un nouveau système de paie, et Beck, assisté de son collègue et ami Ron Jeffries, écrivait le premier ouvrage d’une série sur la "méthode XP” tout en s’appliquant à faire des adeptes. |
|
25. Ron Jeffries, a friend and colleague called in to coach the Chrysler team, grabbed onto the term immediately. "The way it was described was we were taking all these practices that the best programmers already did and turning the dials all the way up to 10," Jeffries says. Beck’s strategy worked. By 1997, Chrysler had a new payroll system, and Beck and Jeffries were writing the first of many books on the XP "methodology" and convincing others to give it a try. |
-->
-->
26. […] Matt Stephens, qui, lui, n’est pas convaincu par l’XP, s’en prend aux faiblesses de cette approche. C’est lui qui, dans son essai d’août 2001, A Case Against Extreme Programming [Argumentation contre la programmation de l’extrême], la compare à une chaîne de serpents venimeux. Cette analogie, explique-t-il, trouve son origine dans la proscription de l’“amateurisme", qui consisterait à n’adopter que certains principes de l’approche XP, ce que dénoncent les programmeurs de l’extrême. D’après ses partisans, il semblerait en effet que l’XP ne soit efficace que si l’on en respecte scrupuleusement toutes les étapes. Cependant, pour Stephens, certains de ces éléments comportent des risques. Par exemple, l’XP n’accorde qu’une importance négligeable à la documentation sur les codes-sources, le cauchemar de tout programmeur, en se fondant sur le principe selon lequel un code bien écrit et correctement testé sera plus facile à comprendre par d’autres programmeurs qu’un code bien documenté mais mal écrit. |
|
26. [XP’s ensuing rise from ad hoc method to next big thing is as much a testament to the evangelization skills of Beck, Jeffries et al. as it is to the virtues of the XP method itself. Five years after the fact, the number of XP testimonials trails well behind the number of XP books — currently numbering more than a dozen on Amazon.com. Such numbers prompt skeptics to wonder if "extreme programming" shouldn’t be changed to "extreme hype." Doug Rosenberg, president of Itrix Software, a Santa Monica, Calif., company whose consulting and tutorial services now compete head-to-head with the growing number of XP tutorials in the marketplace, likens the XP phenomenon to a "brush fire" — heavy on the flash but light on the fuel. "Some of the ideas are actually pretty interesting," says Rosenberg. "They’ve actually contributed positively to the industry in terms of having people pay more attention to unit testing and automated testing frameworks. [But] the way they’ve marketed it, creating this whole fad phenomenon is objectionable to me."] Matt Stephens, another XP critic, prefers to zero in on the weaknesses of the XP approach itself. His August 2001 essay "A Case Against Extreme Programming" is the one that likens the XP approach to a ring of poisonous snakes. The ring analogy comes about, Stephens says, because of the XP proscription against "dabbling" — adopting only certain elements of the XP approach. In order to make the XP methodology work, project managers must employ all the elements, according to XP proponents. But Stephens considers certain elements risky. For example, XP places a low priority on source-code documentation, a common developer bugbear, on the rationale that well-written, well-tested code will be easier to understand by third party programmers than well-documented, poorly written code. "If everything goes according to plan, XP might just get you there," Stephens warns. "If something goes wrong (e.g. your key programmer leaves ; the on-site programmer, who is essentially the walking requirements spec, is hit by a bus ; the janitor accidentally vacuums up your pile of story cards) then things can really go awry." |
-->
-->
27. Pour Beck, l’argument selon lequel l’XP doit être appliquée à la lettre ou pas du tout n’a pas tant d’importance. Ce qui ne l’empêche pas de souligner que les chefs de projet remportant le plus de succès grâce à cette méthode sont ceux qui mettent de côté l’obsession culturelle des spécifications rigides, un héritage de domaines moins flexibles comme l’ingénierie civile et mécanique, et adoptent le concept de l’XP sans aucune réserve. "Ma tactique : se jeter à l’eau ! s’enthousiasme Beck. |
|
27. Beck downplays the argument that XP is an all-or-nothing approach. Still, he does note that the project leaders who report the most success with the methodology tend to be the ones who put aside the cultural obsession with rigid specs, an obsession inherited from less flexible fields such as civil and mechanical engineering, and approach XP’s design-on-the-fly philosophy wholeheartedly. "My strategy has been to say, ’Let’s push it,’" Beck says. |
-->
-->
28. Si vous croyez faire de l’XP mais qu’en fait vous n’effectuez que quelques petits tests et des séances de planning hebdomadaires, vous êtes encore loin de modifier fondamentalement le contrat social.” […]. |
|
28. "If you think you’re doing XP, but all you’re really doing is a little bit of testing and weekly planning sessions, you haven’t fundamentally changed the social contract yet." [After all, Beck notes, it was the gaping disconnect between management and software development that prompted him to develop XP in the first place. Rather than paint XP as yet another revolutionary trend in the software business, Beck prefers to describe it as a much-needed "return to civility." After nearly two decades of working on both sides of the line, Beck says he was looking for a way to eliminate, or at least diminish, the sociological disconnect that seems to characterize most software projects. "Going into XP, I was very conscious that this had to be good for both sides," he says. "The suits can’t say, ’We need these three things by Friday,’ and the geeks can no longer say ’That’s impossible.’ With XP, you’ve got a situation where the programmers come back and say, ’We can give you two out of three. Which do you prefer ?’ Then the negotiating begins." Whether or not other programmers and managers accept the bargain, XP is already lowering stress levels in some corners of the industry. Tom Clarke, the Union Square Internet Development programmer currently using techniques such as pair programming to fulfill his company’s latest development contract, a Web site rebuild, says his first brush with XP was a very positive experience. "I was working on a project for another company that involved sending out 50,000 e-mails every night," says Clarke, recalling his first brush with XP. "I’d go to bed wondering if the e-mails were going to the right addresses or if they were even going out at all. I had no way of knowing for sure. When I stumbled onto the notion of unit testing, I started experimenting with it. By the time I was done, I came up with a few tests that verified that, yes, the software did what I said it did. Suddenly, I found I was sleeping a lot better." Since then, Clarke has helped to form a New York City XP interest group which meets in the Union Square Internet Development offices one night a week. As for his programming mate, Eli Collins, he reports a similarly positive take on the XP methodology. "There’s none of this worry about breaking things three days before release, which is a serious concern on most projects," he says. "[With XP], you can sit down with a client and if they say they want to do something new, you can say, ’OK. We’re ready.’" Recalling the earlier pair programming episode, Collins adds with a smile, "It’s also a confidence booster when you know that stuff like a missing ’i’ isn’t going to come back and bite you."] |
-->
-->
29. Sam Williams |
|
29. salon.com |
-->
-->
30. Méthodologie : La communication est au cœur de tout projet d’XP. Conçue pour surmonter le problème récurrent des programmeurs, qui promettent une chose et en livrent une autre totalement différente, la méthode XP se fonde sur l’interaction entre développeurs et clients, et entre développeurs et développeurs, autour d’un clavier plutôt que d’une table de conférences. La profession de foi de l’XP est que, si programmeurs et clients communiquent mieux, il en résultera tout naturellement un logiciel de meilleure qualité. Pour en savoir plus : http://www.ExtremeProgramming.org. |
|
30. About the writer : Sam Williams is a freelance reporter who covers software and software development culture. He is also the author of "Free as in Freedom : Richard Stallman’s Crusade For Free Software." http://www.ExtremeProgramming.org |
-->
|