Kent Beck和Martin Fowler撰写了《规划极限编程》（Planning Extreme Programming）一书专门详细阐述了在极限编程（XP）中如何来规划和计划Project，有兴趣的朋友可以在此下载并阅读。在阅读过程中，我也把一些重要的Notes记录了下来，供大家参考。
/Files/pdclh/Planning_Extreme_Programming.rar
In the field of IT, we are just emerging from a time in which armor (process) has been king. And now we are moving into a time when only mobility matters. Building a product the right way still sounds like a laudable goal, but—let's face it—what really matters today is building it fast. Because we are process-obsessed in our field, we have tended to react to this new imperative as we reacted to the imperatives thrust upon us in the 1980s and 1990s. We have asked, "What shall we add to our process to deal with this new situation?" No answer to that question is going to be right because the question itself is wrong. What the new mobility imperative requires is that we subtract from process:
We need to get light.
"Getting light" means more than just abandoning heavy process and its attendant mountain of documentation. It means investing in people so they can work quickly and effectively without formal process and without generating a ton of paper.
Plans must also be both simple to build and simple to keep up-to-date.
Keep your plans honest, and expect them to always change.
Our planning process relies on clearly separating the roles of business people and software people. This ensures that business people make all the business decisions and software people make all the technical decisions.
Choosing the relative priority between features is a business decision.
Business decisions in planning are
• Dates
• Scope
• Priority
Technical decisions in planning are
• Estimates
Ask yourself at all times, "What is the most valuable functionality to have next?"
Never let a date slip. Slipping dates is one of the worst habits in software development.
Provide a little valuable functionality every single release, and release to real customers as often as you can. Don't be afraid to release something that's not enough yet. Use your creativity to look for ways that you can take a large new capability and break it up into little pieces so you can keep delivering. If you release frequently enough, you won't have long to wait before you get more of what you want.
The result of an iteration must be a fully tested, production-ready system.
The various development activities won't be phases inside our little two-week project.
Each iteration contains all the elements of full-scale development. At the end we have shippable software, ready to deploy. It just doesn't contain many features. Maybe it will contain only one feature. So we will have to do another iteration and another and another.
One of the purposes of planning is to ensure we always work on the most valuable thing possible at any given time. At the beginning of each iteration the business will pick the most valuable features for the next iteration.
The process makes sure we get off to as good a start as possible by laying out the whole of development.
The process mitigates requirements risk by picking new requirements every few weeks.
The process mitigates implementation risk by breaking planning up into small enough pieces that when one piece blows up it will affect the overall plan as quickly and visibly as possible.
When you are overloaded, don't think of it as not having enough time; think of it as having too much to do. You can't give yourself more time, but you can give yourself less to do, at least for the moment.
When you have too much to do you can
• Prioritize and not do some things
• Reduce the size of some of the things you do
• Ask someone else to do some things
Doubling your team doesn't make you go twice as fast because it increases the amount of communication that needs to go on. Adding people to a late project just makes it later.
Try to move nonfunctional requirements over to scope.
Nothing kills speed more effectively than poor internal quality. That's why Extreme Programming puts so much attention on practices like testing and refactoring. If you keep internal quality high you can see where you are and predict where you can go.
If we are overcommitted, we will tend to try to finish some items in any given time period instead of half finishing them all.
The strategies you will use are similar to making the big plan in the first place:
• Break the big stories into smaller stories.
• Sharpen the focus on the stories by estimating how long each will take.
• Defer less valuable stories until what is left fits in the time available.
The customer
• Defines the user stories
• Decides what business value the stories have
• Decides what stories to build in this release
The programmers
• Estimate how long it will take to build each story
• Warn the customer about significant technical risks
• Measure their team progress to provide the customer with an overall budget
How stable is the release plan? Not at all.
The only thing we know for certain about a plan is that development won't go according to it. So release planning happens all the time. Every time the customer changes his mind about the requirements and his priority, this changes the plan. Every time the developers learn something new about the speed of doing things, this changes the plan.
We know that the further ahead we plan, the less accurate we will be. We prefer to plan one or two iterations in advance and one or two releases in advance.
Doing infrastructure without customer function leads to the following risks:
• You spend a lot of time not delivering things that are valuable to the customer, which strains the relationship with the customer.
• You try to make the infrastructure cover everything you think you might need, which leads to an overly complex infrastructure.
Therefore, evolve the infrastructure as you build the functionality. For each iteration, build just enough infrastructure for the stories in that iteration. You won't build a more complex infrastructure than you need, and the customer is engaged in building the infrastructure because she sees the dependent functionality as it's evolving.
A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration.
One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.