Soyons en contact

 

Bertrand Meyer: Agile! The Good, the Hype and the Ugly - Les extraits et citations

10-11-2016 - 08:2313-11-2016 - 16:00

Here another page of the Blog Apocryphe that is focused on extracts and quotes of a book. As a matter of fact, I consider the book of Bertrand Meyer, “Agile! The Good, the Hype and the Ugly”, to be one of the very best I have ever read about Agility. All quotes have been extracted by the author of this blog, (me 😑), and are his/my own very personal choices. I assume all responsibility about it. The reader however should never forget that extracts may need their entire context in order to be fully understood without injustice to the author's original ideas. In case you feel interested by more of Bertrand Meyer's ideas, you can always head to his personal blog or to his blog at Communications of the ACM.

Agile methods are undeniably one of the important recent developments in software engineering. They are also an amazing mix of the best and the worst. — in Agile! The Good, the Hype and the Ugly, p. 6
This is an extraordinary situation: usually, when a new set of concepts bursts forth, one can quickly assess its overall contribution as beneficial, neutral or detrimental. Agile texts, however, defy such a simple judgment: you may find in one paragraph a brilliant insight, in the next paragraph a harmless platitude, and in the one after some freakish advice guaranteed to damage your software process and products. — ibidem
[…] every agile team in the field makes up its own cocktail of agile practices, rejecting the ones that do not fit. — ibidem, p. 6
[…] constant exhortation to join the cult. — in Agile! The Good, the Hype and the Ugly, p. 7
[…] empirical software engineering, the objective study of software processes, is still a science in progress. — in Agile! The Good, the Hype and the Ugly, p. 7
Anyone trying to gain a clear, cool-headed understanding and appreciation of agile methods has, so far, faced three difficulties […] : partisanship, intimidation and extremism. — in Agile! The Good, the Hype and the Ugly, p. 7
Most of the existing texts are partisan. At issue here is not just the normal phenomenon of inventors arguing for their inventions, but a lack of restraint that sometimes borders on religious fervor and demands from the reader a suspension of disbelief. — in Agile! The Good, the Hype and the Ugly, p. 7
With agile methods you are asked to kneel down and start praying. — in Agile! The Good, the Hype and the Ugly, p. 7
The agile literature is often intimidating. It dismisses previous approaches as passé, scornfully labeling them “waterfall” (even though no company applies a strict waterfall process), and leaving the impression that anyone supporting them is a rigid, pointy-hair-boss type. — in Agile! The Good, the Hype and the Ugly, p. 7
The very name for the approach, “agile”, a brilliant marketing decision — no, a stroke of genius! —, is enough to make any would-be skeptic think twice: who wants to be cast as not agile? — in Agile! The Good, the Hype and the Ugly, p. 7
Crystal […] is more of a flexible, your-mileage-may-vary approach — in Agile! The Good, the Hype and the Ugly, p. 8
[…] the prevalence of the all-or-nothing view in many of the foundational texts further complicates the task of identifying which techniques will work for your own project, and which will not. — in Agile! The Good, the Hype and the Ugly, p. 8
[…] everything that agile methods do not want to be and agile texts love to lambast: traditional plan-based software engineering methods, including the derided “waterfall”. — in Agile! The Good, the Hype and the Ugly, p. 8
[…] laws of software engineering continue to apply, and cautions against the “either-what-or-when” fallacy that works well for (“Agile“) consultants but not for their clients. — in Agile! The Good, the Hype and the Ugly, p. 9
[…] agile ideas can be classified into three categories:
  • The good (including the “brilliant”): principles and practices — some new, some not — that agile authors rightly present as helpful to software quality and productivity.
  • The hype: widely touted ideas that will make little difference, good or bad, to the resulting software.
  • The ugly: agile-recommended techniques that are just plain wrong, contradicting proven rules of good software engineering, jeopardizing the success of projects, and harming the quality of the resulting software.
in Agile! The Good, the Hype and the Ugly, p. 9

Software methodology is a tricky business because it is difficult to prove anything. Many ideas get adopted on the strength of an author’s powers of conviction. It does not mean they are good, or bad. — in Agile! The Good, the Hype and the Ugly, p. 10
Experiential arguments are among the favorite tools of agile authors. The typical agile book is a succession of alternating general observations and personal anecdotes of project rescues (rescued, remarkably, by the author) and project failures (failed, remarkably, after not following the author’s advice). These anecdotes are usually entertaining and sometimes enlightening, but a case study is only a case study, and we never know how much we can generalize. — in Agile! The Good, the Hype and the Ugly, p. 10
Anecdotes and individual cases […] can have force of proof, but only in one case: disproving a general law. — in Agile! The Good, the Hype and the Ugly, p. 10
Logical reasoning is a powerful tool […]. But it is only as convincing as the hypotheses from which it starts, and there is the risk that it will remain academic. — in Agile! The Good, the Hype and the Ugly, p. 10
Credible answers to questions of software methodology require systematic, rigorous, realistic studies of projects. — in Agile! The Good, the Hype and the Ugly, p. 11
[…] the burgeoning field of empirical software engineering has not yet provided answers to many fundamental issues. — in Agile! The Good, the Hype and the Ugly, p. 11
Progress in science and engineering relies on free, critical inquiry of previous work. In reviewing the agile literature, I have found a number of reasons to disagree with its authors, and a few reasons to be shocked; — in Agile! The Good, the Hype and the Ugly, p. 11
I have also […] found elements to admire, and learned new insights about software development. — in Agile! The Good, the Hype and the Ugly, p. 11
I would not have spent a good part of my last three years immersing myself in agile methods and the supporting texts if I had not felt that I had something important to learn. — in Agile! The Good, the Hype and the Ugly, p. 11
[…] the agile pioneers are experienced professionals, passionate about software. Even when I find them to be wrong, I value their views and share the passion. We are all in the same boat. — in Agile! The Good, the Hype and the Ugly, p. 11
Agile ideas date back to the development of Extreme Programming in the 1990s, but reached fame with the appearance in 2001 of the “Agile Manifesto” — in Agile! The Good, the Hype and the Ugly, p. 19
Agile ideas have become the buzz of the industry, the darling of the technical press, the kind of argument companies use in the fierce competition to attract the best programmers: Come to us! Our development is agile! in Agile! The Good, the Hype and the Ugly, p. 19
“Agile” is not just a collection of software techniques but a movement, an ideology, a cause. — in Agile! The Good, the Hype and the Ugly, p. 20
“Agile is an emotion”. — in Self-Organization: The Secret Sauce for Improving your Scrum Team, video at www.youtube.com/watch?v=M1q6b9JI2Wc.
Agile methods redefine and limit the manager’s job by transferring many of the duties to the team as a whole, including one of the most important responsibilities: selecting tasks to be performed and assigning them to developers. — in Agile! The Good, the Hype and the Ugly, p. 21
It is possible to give a sociological interpretation of the agile movement as a “revolt of the cubicles”: the rejection of rigid, top-down, Dilbert’s-boss-like techniques for managing software projects. — in Agile! The Good, the Hype and the Ugly, p. 21
Agile methods are, in part, the rehabilitation of code. — in Agile! The Good, the Hype and the Ugly, p. 21
[…] rejection of “Big Upfront Anything” — in Agile! The Good, the Hype and the Ugly, p. 21
In the agile view:
  • Requirements cannot be captured at the beginning of a project, because users do not know what they want. Even if one managed to write a requirements document, it would be useless because requirements will change through the project.
  • Building a design upfront is a waste of time because we do not know what will work and what will not.
in Agile! The Good, the Hype and the Ugly, p. 21

Regression testing has been known and applied for a long time, but agile methods have given this task a central place in the development process. — in Agile! The Good, the Hype and the Ugly, p. 22
[…] agile methods as empowerment of programmers and consultants against managers — in Agile! The Good, the Hype and the Ugly, p. 23
Scrum introduced the important rule that functionality is frozen during iterations — in Agile! The Good, the Hype and the Ugly, p. 24
[…] a use case is a complete interaction, a user story an application of a smaller unit of functionality — in Agile! The Good, the Hype and the Ugly, p. 24
[…] the traditional software engineering view presents requirements as a specific lifecycle step, coming early in the process, it does not rule out — except in the imagination of agile authors — a scheme in which the requirements are constantly updated in the rest of the lifecycle. — in Agile! The Good, the Hype and the Ugly, p. 24
[…] the traditional software engineering view presents requirements as a specific lifecycle step, coming early in the process, it does not rule out — except in the imagination of agile authors — a scheme in which the requirements are constantly updated in the rest of the lifecycle. — in Agile! The Good, the Hype and the Ugly, p. 25
A decade or two ago, it was not uncommon for software projects to split into sub-developments and only try to put them together (“integrate”) at intervals of months or more. This is a terrible approach: when attempting integration, projects often discover that the subsystems have made incompatible assumptions and have to undergo substantial rewriting. — in Agile! The Good, the Hype and the Ugly, p. 27
Just as scenarios and tests are the agile replacement for Big Upfront Requirements, refactoring is the agile answer to Big Upfront Design. — in Agile! The Good, the Hype and the Ugly, p. 27
[…] rather than closed offices, it should be set up as an open room to favor constant interaction between team members — in Agile! The Good, the Hype and the Ugly, p. 30
The agile approach to requirements is based on user stories: units of functionality corresponding to interactions of users with the system. — in Agile! The Good, the Hype and the Ugly, p. 30
User stories, like use cases, are a valuable tool for validating requirements, to check that the identified functionality covers the most common scenarios. — in Agile! The Good, the Hype and the Ugly, p. 30
(User Stories), as a tool for defining requirements, […] are inadequate because they only document examples of system execution — in Agile! The Good, the Hype and the Ugly, p. 30
The task of requirements is to go beyond these individual examples, which can only cover a fraction of the possibilities available, and identify the more general functions of the system. If you forgo this step of generalization and abstraction, you get systems that do a few things — the user stories — and little else. — in Agile! The Good, the Hype and the Ugly, p. 30
When using software systems, for example web applications, have you ever felt like Tintin the day he was being marched in a straightjacket? As soon as you dare to depart from the exact scenario that the designers, in their supreme wisdom, have planned for you, nothing works any more. This kind of system is the direct result of requirements based on the sole analysis of use cases or user stories. — in Agile! The Good, the Hype and the Ugly, p. 31
Good requirements shoot for more abstract specifications, subsuming many different scenarios and supporting the development of flexible, extendible applications. — in Agile! The Good, the Hype and the Ugly, p. 31
[…] pair programming can be an effective technique if applied with reason. — in Agile! The Good, the Hype and the Ugly, p. 31
[…] studies show pair programming to be no superior to other classical techniques such as code reviews. — in Agile! The Good, the Hype and the Ugly, p. 31
[…] pair programming can be dismissed as folklore […] — ibidem, p. 31
Worse consequences of agile methods come from the injunction to develop minimal software, stated earlier as principle 4. Its component rules 4.2 (produce only the product requested) and 4.3 (develop only code and tests) may appeal to inexperienced project managers as a way to combat programmer perfectionism and deliver results quickly, focusing on the essential. But from a software engineering perspective they are not good advice, since they discourage efforts that have proved to be among the most fruitful practices of software engineering: generalizing code for ease of extension and reuse, and developing tools to automate repetitive processes. In Lean terminology, the results of such efforts are “waste” since they are not delivered to the customer; in reality, when applied appropriately, they are the key to the continuous improvement of a company’s software process and the professionalization of software practice. — ibidem, p. 31
[…] requirements will change, and are hard anyway to capture at the beginning. In no way, however, does it imply the dramatic conclusion that upfront requirements are useless! — ibidem, p. 31
[…] requirements should be subject to change, like all other artifacts of the software process. — ibidem, p. 31
The agile advice here (about skipping the requirements phase) is irresponsible and serious software projects should ignore it. The sound practice is to start collecting requirements at the beginning, produce a provisional version prior to engaging in design, and treat the requirements as a living product that undergoes constant adaptation throughout the project. — ibidem, p. 32
[…] a number of the productive ideas of agile methods have long been advocated in the standard software engineering literature. — ibidem, p. 32
The agile literature has helped anchor the idea of frequent releases into the mindset of the software industry, but agile methods did not invent it. — ibidem, p. 32
Agile methods may enhance software change through organizational practices, but they make no technical contribution in this area; in fact, as we will see, some of the agile precepts work against making software easy to change. — ibidem, p. 32
The first major contribution is team empowerment. Giving a central place to the team and insisting that it can handle many traditional management responsibilities is a plus for any software project staffed by competent people. — ibidem, p. 32
Some of the management practices of agile methods, which may seem simple-minded at first, can actually make a considerable contribution to project success. One of the most significant is Scrum’s daily meeting; reinforcing programmer interaction, and requiring everyone to describe every morning what he just did, what he will do next, and what impediments he faces, is a brilliant idea […] that makes a real difference […] — ibidem, p. 33
A particularly interesting idea is the freezing of requirements during iterations. — in Agile! The Good, the Hype and the Ugly, p. 33
The time-boxed iteration is also a productive practice, particularly through its influence on the planning process, since it discourages unrealistic promises. — ibidem, p. 33
On the technical side, a major achievement of agile methods has been to establish the practical importance of tests and specifically of the regression test suite. — ibidem, p. 33
[…] agile methods taught us that the regression suite is a key asset of the project, that many activities should be organized around it — ibidem, p. 33
[…] it is futile to move on to new functionality as long as important tests do not pass. — ibidem, p. 33
Short Iterations. While the more competent companies have relied on iterative development for a long time, it is partly thanks to agile ideas that this practice has become so widely accepted. — ibidem, p. 33
The central role of code. Once again this is not new but the agile movement has been instrumental in reminding everyone that our primary product is code, not diagrams or documents. — ibidem, p. 33
[…] this is how we will remember the self-proclaimed agile revolution: as an incremental step, which — aside from indulging in some lunacies that were not destined to last long — improved our understanding of existing concepts and introduced a precious few new insights. — ibidem, p. 33
In the case of software projects […] there are many reasons for writing down at least part of the requirements — ibidem, p. 36
[…] we need more precise forms of requirements; that would mean formal (mathematical) specifications […] — in Agile! The Good, the Hype and the Ugly, p. 36
Many projects today involve people of different backgrounds and particularly different accents. It can be hard — say in a Skype discussion between teams in Germany and in India, both using English, or believing they are — to make out the details of what the other party is trying to say. — ibidem, p. 36
it is dangerous to follow the lead of the last person you heard. — ibidem, p. 36
People in a software project come and go. — ibidem, p. 36
One of the benefits of consigning requirement elements to writing is that they survive the context of a conversation, when six months later no one remembers why a particular decision was taken; or, worse yet, key participants are no longer around. — ibidem, p. 36
If verbally communicated requirements were truly superior to written ones, engineering of any kind could discard such old-hat techniques as design specifications and plans, relying instead on frequent interactions between engineers and other stakeholders. — ibidem, p. 36
No one has ever argued that writing things down removes every risk of “miscommunicating” — in Agile! The Good, the Hype and the Ugly, p. 37
“Written words are misleading — they look more precise than they are” — in Succeeding With Agile, Addison-Wesley, 2010.
Do not let the written form of a requirement element impress you into believing that everything has been clearly defined. Written implies neither precise nor correct. — in Agile! The Good, the Hype and the Ugly, p. 37
[…] communication is hard. — ibidem, p. 37
In any large and ambitious project […] communication issues are just as important as technical issues, and can wreck the project if the leadership does not handle them properly and proactively. — ibidem, p. 37
written descriptions are not enough; the various project stakeholders should talk — ibidem, p. 38
Verbal communication is […] a complement to written documents, not a replacement. — ibidem, p. 38
you must keep your defenses up. You must also keep an open mind and be prepared to draw your own conclusions, even when the author’s own do not hold up to examination. — ibidem, p. 38
The general problem with an anecdote is that it is to a principle what — in software — a test is to a specification: it gives you one example and you are never sure how much you can extrapolate from that example to the general case. — ibidem, p. 40
the favorite butt of agile scorn is the “waterfall” process, something that everyone knows is bad. But of course not everyone who does not agree with all agile ideas is preaching a return to a nineteen-seventies-style waterfall process; in fact almost no one practices it, and absolutely no one advocates it. — ibidem, p. 40
Many defenders of a cause feel more comfortable if they can identify an enemy; or, if none is available, make one up. — ibidem, p. 42
If you are not an enthusiastic promoter of agile approaches, you are by definition a dinosaur. […] a “member of the command-and-control gang”. — ibidem, p. 42
a large spectrum of styles exists, from the completely self-organized team to the military-style organization micro-managed by a control freak, and many variants in-between. More than one strategy can work, and a strategy that succeeds in one environment may fail in another. — ibidem, p. 42
Serious agile proponents should be wary of the damage caused by extreme propaganda — ibidem, p. 43
Software projects are too diverse, and software development too difficult, to allow for a single recipe that will work identically for everyone. — ibidem, p. 44
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
— ibidem, p. XXXXXXX
JE N'AI RIEN EXTRAIT AVANT LA PAGE 74. TOUTES LES CITATIONS SONT SURLIGNEES DANS LE BOUQUIN PAPIER. J'AI ACHETÉ UNE AUTRE VERSION PAPIER QUE JE VAIS IFFRIR À TOM VEEKMANS TOUT EN BÉNÉFICIANT DE LA VERSION PDF. TOUTES LES CITATIONS QUI PRÉCÉDENT SONT DES CITATIONS QUE J'AI RECOMMENCÉ À EXTRAIRE DE LA VERSION PDF
The professional is the one who knows how to make the fundamental decisions even under incomplete information-and get most of these decisions right the first time. — in Agile! The Good, the Hype and the Ugly, p. 6
[…] testing can show the presence of errors, never their absence. — in Agile! The Good, the Hype and the Ugly, p. 75
in Agile! The Good, the Hype and the Ugly, p. XXXXXXXXXXXX
in Agile! The Good, the Hype and the Ugly, p. XXXXXXXXXXXX
in Agile! The Good, the Hype and the Ugly, p. XXXXXXXXXXXX
in Agile! The Good, the Hype and the Ugly, p. XXXXXXXXXXXX

Top
Le Blog Apocryphe utilise des cookies pour sauver vos préférences et RIEN d'autre. Je vous demande de bien vouloir accepter les cookies qui sont positionnés sur mon blog et je vous promets en retour de ne RIEN laisser transparaître de votre parcours de visite, dont d'ailleurs vous me faites l'honneur. Au cas où néanmoins vous n'accepteriez pas d'utiliser les cookies, vous aurez probablement une navigation LÉGÈREMENT dégradée sur le Blog Apocryphe. Bonne visite!X