软件工艺(英文版) (2008 年度畅销榜NO.1389 )

本书针对软件开发，提出了一些相当棘手和敏感的问题，并给出了颇具争议性的结论：从一个数百年来一直兴旺发达的系统——工艺学中获得启示，寻找答案。
本书通过5个部分，19章的篇幅系统地阐述作者的观点，并试图回答一直困扰着软件行业的难题——我们应该如何重组软件构造的过程，使其能够如我们所愿地有效运转？第1部分共4章，对传统的观点提出质疑——软件工程真的是解决软件开发问题的灵丹妙药吗？第2部分共2章，这一部分提出了本书的观点，即以软件工艺的视角看待软件开发。第3部分以7章的篇幅，不同的角度全面地展现了软件工艺理论所带来的主要变化，以及如何实践这个观念。第4部分共3章，对比了软件工艺与软件工程，并为各自适用的范畴重新划定了界限。第5部分共3章，分别讨论软件开发中的权宜之计和长期问题。
本书荣获2002年度Jolt图书大奖，阅读本书，有助于引发读者在软件开发问题上的独立思考，本书适合软件行业的所有从业人员阅读参考。

Preface to Chinese Reader
Foreword
Preface

Part I Questioning Software Engineering
1 Understanding Software Engineering
The Paradox of Software Engineering
The Modem Definition of Software Engineering
Is Software Engineering a Good Choice for Your Project?
2 The Problems with Software Engineering
Can Software Development Be Made Systematic
and Quantified?
The Hazards of the Good Enough Software Approach
What Is the Alternative to Software Engineering?
3 Understanding Software Development
Software as Capital
Does the Division of Labor Work for Software
Development?
One Size Does Not Fit All
Finding a More Applicable Metaphor Than
Software Engineering
4 Finding a Better Metaphor Than Software
Engineering
The Craft of Software Development
Parallels with Traditional Craftsmanship
The Resurgence of the Craft of Software Development

Part 2 Software Craftsmanship
5 Putting People Back into Software Development
Craftsmanship Is About Getting Better at Software
Development
Craftsmanship Encourages Developers to Write Great
Software
A Call to Arms
6 Craftsmanship Is the Opposite of Licensing
Craftsmanship Is Personal
Licensing Is an Illusion
Craftsmanship Focuses on the Individual

Part 3 Implications of Software Craftsmanship
7 How Craftsmanship Affects the Users of Systems
Software Craftsmanship Works Because Software Is
Easy to Copy
Craftsmen Have a Different Relationship with Their Users
Great Software Deserves to Be Signed
Craftsmen Need Demanding Users
Software Craftsmanship Leads to Collaborative
Development
8 Customers Have a Different Relationship
with Craftsmen
Setting Realistic Delivery Dates
Exposing the Fallacy of Good Enough Software
Allowing Software Craftsmen to Take Credit for Their Work
Start Exploiting the Difference in Productivity Between
Developers
But How Do We Know How Good a Developer Really Is?
Customers Make a Cost/Quality Trade-offWhen
Choosing Craftsmen
Customers Have Long Term Relationships with
Software Craftsmen
Customer Interests Are Aligned with the Interests of
Software Craftsmen
9 Managing Craftsmen
Software Craftsmen Are Not Hired Hands
Good Developers Are More Valuable Than Their Managers
Software Craftsmen Have a Different Relationship with
Their Managers
Managing Great Developers Is a Pleasure and a Privilege
Software Craftsmen Like Creating Applications
Managing Software Craftsmen Is Different
Software Craftsmen Push for What They Need
10 Becoming a Software Craftsman
Software Craftsmanship Is a Rejection of Narrow
Specialization
Craftsmanship Requires Dedication
How Does a Person Become a Software Craftsman?
The Craft Tradition Has Endured for Centuries
11 Mastering the Craft
What Does a Master Software Craftsman Look Like?
Use Your Old-timers
Mastery Implies the Use of Stable Technologies
Developing Mastery Takes Time
Mastery Implies Taking Responsibility for Passing on
the Craft
12 Apprentice Developers
We Must Reverse the Decline in the Quality of Developer
Training
Becoming an Apprentice Is a Significant Step
Apprenticeship Instills Lifelong Learning
The Role of Apprentices
An Apprentice.ship Is a Significant Investment of Time
and Energy
13 Journeymen Developers
Where Journeymen Fit in the Craft Tradition
Journeymen Developers
Journeymen Are Focused on Delivering Applications
Journeymen Play a Key Role in Software Craftsmanship

Part 4 Repositioning Software Engineering
14 Software Engineering Projects
Software Engineering Is Designed for Large Systems
Projects
Software Engineering Projects Are Diverse and Varied
15 Hazards of the Software Engineering Metaphor
You Cannot Do Software Engineering on a Low Budget
Software Engineering Encourages Scientific Management
Software Factories: The Production Line for Software
Reuse over Time Is Hazardous
The Myth of the Standardized Software Development
Process
Software Engineering Forces Us to Forget the Individual
We Need More Variety in Our Development Processes,
Not Less
16 Learning from Software Engineering
Size and Complexity Matter
Applications Need to Be Well Structured
Change Can Be Expensive Unless You Allow for It
Communication Inside the Team and with Users Is Crucial
Producing Accurate Estimates Is Very Expensive

Part 5 What to Do on Monday Morning
17 Experience--The Best Indicator of Project Success
Choose Software Craftsmen Based on Their Reputations
Evaluate Craftsmen Based on Their Reputations
and Portfolio
Auditioning a Software Craftsman
Let Your Software Craftsman Pick the Rest of the
Development Team
Collaborative Development
Avoid Bleeding-Edge Technology If At All Possible
Paying for Experience
Be Prepared to Be Amazed
18 Design for Testing and Maintenance
Think Applications, Not Projects
Maintenance Teams Should Refuse to Accept Bad
Applications
Design for Maintenance
Software Craftsmen Prefer Nonproprietary, Open
Source Tools
Great Software Is Global
Software Craftsmen Need to Fight Back Against
Planned Obsolescence
Great Software Needs to Be Given a Great User Interface
Maintainable Software Is Easy to Diagnose
The Hazards of Outsourcing
You Can Still Use Outside Craftsmen to Create Your
Application
Maintenance Is the Most Important' Part of the Life of
Any Application
Not All Software Has to Be Maintainable
Design for Testing and Maintenance Is Not Rocket Science
19 Perpetual Learning
Creating a Learning Environment
Mastering the Craft of Software Development
Choose Training Courses Very Carefully
Encourage Your People to Be Visible in the Software
Development Community
Becoming a Reflective Practitioner
Epilogue
Acknowledgments

Index

Craftsmanship is a return to the roots of software development: Good software developers have always understood that programming is a craft skill. Regardless of the amount of arcane and detailed technical knowledge that a person has, in the end, application development comes down to feel and experience. Someone can know ail of the esoteric technical details of the Java programming language, but that person will never be able to master application development unless he or she develops a feel for the aesthetics of software. Conversely, once a person gets the feel for software development, the specific technical details become almost irrelevant. Great developers are always picking up and using new technology and techniques; learning a new technology is just a normal part of the life of a software developer. The term software engineering was coined in 1967 by a NATO study group that recommended a conference to discuss "the problems of software." The report from this 1968 conference, which was sponsored by the NATO Science Committee and took place in Garmish, Germany, was titled Software Engineering.1 In the report, Peter Naur and Brian Randell stated "The phrase 'software engineering' was deliberately chosen to be provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering." In the same spirit, it is the intention of this book to be deliberately provocative in implying the need for practitioners to start paying attention to the craft of software development. Software craftsmanship is important because it takes us away from the manufacturing metaphor that software engineering invokes and makes us pay attention to the people who do software development. Craftsmanship brings with it the metaphor of skilled practitioners intent on mastering their craft, of pride in and responsibility for, the fruits of their labor. Software craftsmanship is not the opposite of software engineering or computer science. Rather, craftsmanship is a different tradition that happily coexists with and benefits from science and engineering. dust as the modern blacksmith benefits from better tools, materials , and understanding, so software craftsmanship benefits from better computers, reusable components, and programming languages, dust as blacksmiths transcend science and engineering with their skill and artistry, software craftsmanship can transcend computer science and software engineering to produce great programs, applications, and systems. UNIX and the modern-day GNU Linux are probably the best-known examples of this--systems that are thriving due to the craft, skill, and dedication of their creators. Software craftsmanship is a response to the problems of trying to force-fit software engineering into commercial application development. Software engineering was developed to meet the needs of NATO in developing very large defense systems. Commercial application development differs from the development of defense and government systems in that applications are a whole lot smaller and normally have to be up and running in less than 18 months. It is rare for a commercial application to be developed by a team of more than 20 people, and most application developers work in teams with fewer than 10 members. Software engineering is good at handling the problems of really large teams of 200 or more people, but it has little to say about how the individuals in a team should practice their craft. Software engineering encourages the "human wave"2 approach to software development. Rather than solving the problem of how to develop highly skilled developers, software engineering attempts to deskill software development by suggesting that every problem can be solved by throwing more people at it. Although this approach sometimes succeeds, the resulting software is junk. Slow and bloated, it just never feels right. Users are dazzled by the graphics and animation but never really manage to come to grips with the software. They are thwarted by their inability to learn the software and use only a small fraction of the available features. Software does not have to be tike that. All too often I see application development teams shipping valuable applications that provide real, measurable business benefit, but apologizing for not following software engineering best practices. For me, the real test of a team is whether it manages to ship and then enhance and extend the application for years afterward. Timely shipping of the first release is important, but it is more important that subsequent releases occur in a timely fashion and that each new release improves the application. Whenever I'm asked about hiring developers, I tell people to look for developers who have shipped a few applications successfully and then stuck around long enough to handle the next enhancement or maintenance release. Shipping proves that the developer can make something work; staying around for the next release allows the developer to experience the effects of the way that he or she built the application in the first place. If a developer has done this three times, my guess is that he or she is skilled and experienced enough in the craft of software development to be successful again. Software craftsmanship is the new imperative because many members of the software development community are starting to chase technology for its own sake, forgetting what is important. The purpose of software development is to create high-quality, robust software applications that deliver value to their users. What matters is growing a new generation of developers who can do that. Software craftsmanship stands for putting the joy and excitement back into creating applications for our users.