快速软件开发（英文版） (2008 年度畅销榜NO.5519 )

如何严格控制开发进度是所有软件开发团队都想解决的一个重要的问题。在本书中，作者Steve McConnell总结了包括微软公司在内的众多软件开发项目的经验和成果，提出了有助于缩短开发日程和控制开发进度，并使项目不断推进的综台策略、最佳实践和重要的建议。
主要内容
1.可以应用到任何项目中的快速软件开发策略和使该策略发挥作用的最佳实践
2.对各种快速软件开发实践的客观评论——评估、原型开发、被迫超期、激励、团队协调、快速软件开发语言和风险管理等技术
3.快速软件开发项目要避免的各种典型错误，包括滞缓的需求、质量欠缺和“银弹综合症”
4.生动的案例分析，说明成功与失败的原因以及如何把握项目发展的方向

PART I EFFICIENT DEVELOPMENT

1 Welcome to Rapid Development What Is Rapid Development? " Attaining Rapid Development
2 Rapid-Development Strategy
General Strategy for Rapid Development * Four Dimensions of Development Speed * General Kinds of Fast Development * Which Dimension Matters the Most? * An Alternative Rapid-Development
Strategy * Further Reading
3 Classic Mistakes
Case Study in Classic Mistakes * Effect of Mistakes on a Development Schedule * Classic Mistakes Enumerated * Escape from Gilligan 's Island * Further Reading
4 software-Development Fundamentals
Management Fundamentals * Technical Fundamentals * QualityAssurance Fundamentals * Following the Instructions * Further General Reading
5 Risk Management
Elements of Risk Management * Risk Identification* Risk Analysis *Risk Prioritization * Risk Control * Risk, High Risk, and Gambling *Further Reading

PART II RAPID DEVELOPMENT

6 Core Issues in Rapid Development
Does One Size Fit All? * What Kind of Rapid Development Do You Need? * Odds of Completing on Time * Perception and Reality * Where the Time Goes * Development-Speed Trade-Offs * Typical Schedule-
Improvement Pattern * Onward to Rapid Development * Further Reading
7 Lifecycle Planning
Pure Waterfall * Code-and-Fix * Spiral * Modified Waterfalls * Evolutionary Prototyping * Staged Delivery * Design-to-Schedule * Evolutionary Delivery * Design-to-Tools * Commercial Off-the-Shelf Software *Choosing the Most Rapid Lifecycle for Your Project * Further Reading
8 Estimation 163
The Software-Estimation Story * Estimation-Process Overview * Size Estimation * Effort Estimation * Schedule Estimation * Ballpark Schedule Estimates * Estimate Refinement * Further Reading
9 Scheduling
Overly Optimistic Scheduling * Beating Schedule Pressure *Further Reading
10 Customer-Oriented Development
Customers' Importance to Rapid Development * Customer-Oriented Practices * Managing Customer Expectations * Further Reading
11 Motivation
Typical Developer Motivations * Using the Top Five Motivation Factors * Using Other Motivation Factors * Morale Killers *Further Reading
12 Teamwork
Software Uses of Teamwork * Teamwork's Importance to Rapid Development * Creating a High-Performance Team * Why Teams Fail * Long-Term Teambuilding * Summary of Teamwork
Guidelines * Further Reading
13 Team Structure
Team-Structure Considerations * Team Models * Managers and Technical Leads * Further Reading
14 Feature-Set Control
Early Project, Feature-Set Reduction * Mid-Project: Feature-Creep Control * Late Project: Feature Cuts * Further Reading
15 Productivity Toole
Role of Productivity Tools in Rapid Development * Productivity-Tool Strategy * Productivity-Tool Acquisition * Productivity-Tool Use *Silver-Bullet Syndrome * Further Reading
16 Project Recovery
General Recovery Options * Recovery Plan * Further Reading

PART III BEST PRACTICES

Introduction to Best Practices
Organization of Best-Practice Chapters * Summary of Best-Practice Candidates * Summary of Best-Practice Evaluations
17 Change Board
18 Daily Build and Smoke Test
19 Designing for Change
20 Evolutionary Delivery
21 Evolutionary Prototyping
22 Goal Setting
23 Inspections
24 Joint Application Development (JAD)
25 Lifecycle Model Selection
26 Measurement
27 Miniature Milestonee
28 Outsourcing
29 Principled Negotiation
30 Preductivity Environments
3l Rapid-Development Languages (RDLs)
32 Requiremente Scrubbing
33 Reuee
34 Signing Up
35 Spiral Lifecycle Model
36 Staged Delivery
37 Theory-W Management
38 Threwaway Pretotyping
39 Timebox Development
40 Toole Group
41 Top-10 Risks List
42 User-Interface Prototyping
43 Voluntary Overtime
Bibliography
Index

Software developers are caught on the horns of a dilemma. One horn of the dilemma is that development are working too hard to have time to learn about effective practices that can solve most development-time problems; the other horn is that they won't get the time until they do learn more about rapid development. Other problems in our industry can wait. It's hard to justify taking time to learn more about quality when you're under intense schedule pressure to just ship it." It's hard to learn more about usability when you've worked 20 days. in a row and haven't had time to see a movie, go shopping, work out, read the. paper, mow your lawn, or play with your kids. Until we as an industry learn to control our schedules and free up time for developers and managers to learn more about their professions, we will never have enough time to put the rest of our house in order. The development-time problem is pervasive. Several surveys have found that about two-thirds of all projects substantially overrun their estimates (Lederer and Prasad 1992, Gibbs 1994, Standish Group 1994). The average large project misses its planned delivery date by 25 to 50 the average schedule slip increases with the size of the project (Jones 1994). Year after year, development-speed issues have appeared at the tops of lists of the most critical issues facing the software-development community(Symons 1991). Although the slow-development problem is pervasive, some organizations are developing rapidly. Researchers have found 10-to-1 differences in productivity between companies within the same industries, and some researchers have found even greater variations (Jones 1994). The purpose of this book is to provide the groups that are currently on the "1" side of that 1O0-to-1 ratio with the information they need to move toward the "1O" side of the ratio. This book will help you bring your projects under control. It will help you deliver more functionality to your users in less time. You don't have to read the whole book to learn something useful;no matter what state your project is in, you will find practices that will enable you to improve its condition. Who Should Read This Book? Slow development affects everyone involved with software development, including developers, managers, clients, and end-users---even their families and friends. Each of these groups has a stake in solving the slow-development problem, and there is something in this book for each of them. This book is intended to help developers and managers know what's possible, to help managers and clients know what's realistic, and to serve as an avenue of communication between developers, managers, and clients so that they can tailor the best possible approach to meet their schedule, cost, quality, and other goals. Technical Leads This book is written primarily with technical leads or team leads in mind. If that's your role, you usually bear primary responsibility for increasing the speed of software development, and this book explains how to do that. It also describes the development-speed limits so that you'll have a firm foundation for distinguishing between realistic improvement programs and wishful-thinking fantasies. Some of the practices this book describes are wholly technical. As a technical lead, you should have no problem implementing those. Other practices are more management oriented, and you might wonder why they are included here. In writing the book, I have made the simplifying assumption that you are Technical Super Lead-faster than a speeding hacker; more powerful than a loco-manager; able to leap both technical problems and management problems in a single bound. That is somewhat unrealistic, I know, but it saves both of us from the distraction of my constantly saying, "If you're a manager, do this, and if you're a developer, do that." Moreover, assuming that technical leads are responsible for both technical and management practices is not as far-fetched as it might sound. Technical leads are often called upon to make recommendations to upper management abouttechnically oriented management issues, and this book will help prepare you to do that. Individual Programmers Many software projects are run by individual programmers or self-managed teams , and that puts individual technical participants into de facto technical- lead roles. If you're in that role, this book will help you improve your development speed for the same reasons that it will help bona fide technical leads. 'Managers Managers sometimes think that achieving rapid software development is primarily a technical job. If you're a manager, however, you can usually do as much to improve development speed as your developers can. This book describes many management-level rapid-development practices. Of course, you can also read the technically oriented practices to understand what your developers can do at their level. Key Benefits of This Book I conceived of this book as a Common Sense for software developers. Like Thomas Paine's original Common Sense, which laid out in pragmatic terms . why America should secede from Mother England, this book lays out in pragmatic terms why many of our most common views about rapid development are fundamentally broken. These are the times that try developers' souls, and, for that reason, this book advocates its own small revolution in software-development practices . My view of software development is that software projects can be optimized for any of several goals----lowest defect rate, fastest execution speed, greatest user acceptance, best maintainability, lowest cost, or shortest development schedule. Pan of an engineering approach to software is to balance trade-offs: Can you optimize for development time by cutting quality? By cutting usability? By requiring developers to work overtime? When crunch time comes, how much schedule reduction can you ultimately achieve? This book helps answer such key trade-off questions as well as other questions. Improved development speed. You can use the strategy and best practices described in this book to achieve the maximum possible development speed in your specific circumstances. Over time, most people can realize dramatic improvements in development speed by applying the strategies and practices described in this book. Some best practices won't work on some kinds of projects, but for virtually any kind of project, you'll find other best practices that will. Depending on your circumstances, "maximum development speed" might not be as fast as you'd like, but you'll never be completely out of luck just because you can't use a rapid-development language, are maintaining legacy code, or work in a noisy, unproductive environment. Rapid-development slant on traditional topiee. Some of the practices described in this book aren't typically thought of as rapid-development practices. Practices such as risk management, software-development fundamentals, and lifecycle planning are more commonly thought of as "good software-development practices" than as rapid-development methodologies. These practices, however, have profound development-speed implications that in many cases dwarf those of the so-called rapid-development methods. This book puts the development-speed benefits of these practices into context with other practices. Practical focue. To some people, "practical" means "code," and to those people I have to admit that this book might not seem very practical. I've avoided code-focused practices for two reasons. Fint, I've already written 800 pages about effective coding practices in Code Complete (Microsoft Press,1993). I don't have much more to say about them. Second, it turns out that many of the critical insights about rapid development are not code-focused; they're strategic and philosophical. Sometimes, there is nothing more practical than a good theory. Ouick -reading organization. I've done all I can to present this book's rapid-development information in the most practical way possible. The first 400 pages of the book (Parts I and II) describe a strategy and philosophy of rapid development. About 50 pages of case studies are integrated into that discussion so that you can see how the strategy and philosophy play out in practice. If you don't like case studies, they've been formatted so that you can easily skip them. The. rest of the book consists of a set of rapid- development best practices. The practices are described in quick-reference format so that you can skim to find dle practices that will work best on your projects. The book describes how to use each practice, how much schedule reduction to expect, and what risks to watch out for. The book also makes extensive use of marginal icons and text to help you quickly find additional information related to the topic you're reading about, avoid classic mistakes, zero in on best practices, and find quantitative sup-port for many of the claims made in this book. A new way to think about the topic of rapld development. In no other area of software development has there been as much disinformation as in the area of rapid development. Nearly useless development practices have been relentlessly hyped as "rapid-development practices," which has caused many developen to become cynical about claims made for any development practices mwhatsoever. Other practices are genuinely useful, but they have been hyped so far beyond their real capabilities that they too have contributed to developers' cynicism. Each tool vendor and each methodology vendor want to convince you that their new silver bullet will be the answer to your development needs. In no other software area do you have to work as hard to separate the wheat from the chaff. This book provides guidelines for analyzing rapid-development information and finding the few grains of truth. This book provides ready-made mental models that will allow you to assess what the silver-bullet vendors tell you and will also allow you to incorporate new ideas of your own. When someone comes into your office and says, "I just heard about a great new tool from the GigaCorp Silver Bullet Company that will cut our development time by 80 percent!" you will know how to react. It doesn't matter that I haven't said anything specifically about the GigaCorp Silver Bullet Company or their new tool. By the time you finish this book, you'll know what questions to ask, how seriously to take GigaCorp's claims, and how to incorporate their new tool into your development environment, if you decide to do that. Unlike other books on rapid development, I'm not asking you to put all of your eggs into a single, one-size-fits-all basket. I recognize that different projects have different needs, and that one magic method is usually not enough to solve even one project's schedule problems. I have tried to be skeptical without being cynical-to be critical of practices' effectiveness but to stop short of assuming that they don't work. I revisit those old, overhyped practices and salvage some that are still genuinely useful-even if they aren't as useful as they were originally promised to be. Why is this book about rapid development ao big? Developers in the IS, shrink-wrap, military, and software-engineering fields have all discovered valuable rapid-development practices, but the people from these different fields rarely talk to one another. This book collects the most valuable prac-tices from each field, bringing together rapid-development information from a wide variety of sources for the first time. Does anyone who needs to know about rapid development really have time to read 650 pages about it? Possibly not, but a book half as long would have had to be oversimplified to the point of uselessness. To compensate, I've organized the book so that it can be read quickly and selectively-you can read short snippets while you're traveling or waiting. Chapters I and 2 contain the material that you must read to undersand how to develop products more quickly. After you read those chapters, you can read whatever interests you most. Why This Book Was Written Clients' and managers' first response to the problem of slow development is usually to increase the amount of schedule pressure and overtime they heap on developers. Excessive schedule pressure occurs in about 75 percent of aU large projects and in close to 100 percent of all very large projects (Jones 1994). Nearly 60 percent of developers report that the level of stress they feel is increasing (Glass 1994c). The average developer in the U.S. works from 48 to 50 hours per week (Krantz 1995). Many work considerably more. In this environment, it isn't surprising that general job satisfaction of software developen has dropped significantly in the last 15 years (Zawacki 1993), and at a time when the industry desperately needs to be recruiting additional programmers to ease the schedule pressure, developers are spreading the word to their younger sisters, brothers, and children that our field is no fun anymore . Clearly our field can be fun. Many of us got into it originally because we couldn't believe that people would actually pay us to write soffware. But something not-so-funny happened on the way to the forum, and that some-thing is intimately bound up with the topic of rapid development. It's time to start shoring up the dike that separates software developers from the sea of scheduling madness. This book is my attempt to stick a few fingers into that dike, holding the madness at bay long enough to get the job started.