In this timely follow-up to Extreme Programming Explained, software engineering gurus Kent Beck and Martin Fowler show exactly how to plan your next software project using Extreme Programming (XP). Planning is a vital element of software development -- but all too often, planning stops when coding begins. Beck and Fowler show how to make software projects far more manageable through a series of simple planning steps every project manager and team leader can easily perform >every day. The book follows XP projects from start to finish, presenting successful planning tactics managers and team leaders can use to adjust to changing environments more quickly and efficiently than ever before. This book is full of war stories and real-world analogies, and offers actionable techniques on virtually every page. It will be invaluable for every project manager called upon to deliver reliable, high-value code in "Internet time."
1. Why Plan?
3. Driving Software.
4. Balancing Power.
6. Too Much to Do.
7. Four Variables.
8. Yesterday's Weather.
9. Scoping a Project.
10. Release Planning.
11. Writing Stories.
13. Ordering the Stories.
14. Release Planning Events.
15. The First Plan.
16. Release Planning Variations.
17. Iteration Planning.
18. Iteration Planning Meeting.
19. Tracking an Iteration.
20. Stand-Up Meetings.
21. Visible Graphs.
22. Dealing with Bugs.
23. Changes to the Team.
25. Business Contracts.
26. Red Flags.
27. Your Own Process.
This is a book about planning software projects. We are writing it mostly for project managers--those who have to plan and track the correspondence of the planning with reality. We also are writing it for programmers and customers, who have a vital role to play in planning and developing software. Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn't even be happy if it did, because by the time the software gets there, the customers don't want what was planned; they want something different.
Like so many, we enjoy Eisenhower's quotation: "In preparing for battle I have always found that plans are useless, but planning is indispensable." That's why this isn't a book about plans; it's about planning. And planning is so valuable and important, so vital, that it deserves to go on a little every day, as long as development lasts.
If you follow the advice in this book, you are going to have a new problem to solve every day--planning--but we won't apologize for that, because without planning, software development inevitably goes off the rails. The scope of this book is deliberately narrow. It covers how to plan and track software development for XP projects. It's based on our experience as consultants and coaches, together with the experience of the growing band of early adopters who are using XP.
As a result this isn't a book about the whole of project management. We don't cover typical project manager jobs such as personnel evaluation, recruiting, and budgeting. We don't address the issues of large projects with hordes of developers, nor do we say anything about planning in the context of other software processes, or of planning other activities. We think there are principles and techniques here that everyone can use, but we have stuck to the parts of the process we know--getting everybody on the team pointed in one direction, discovering when this is no longer true, and restoring harmony.
XP (Extreme Programming) is a system of practices (you can use the m-word if you want to; we'd rather not, thank you) that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.
XP isn't just about planning. It covers all aspects of small team software development--design, testing, implementation, deployment, and maintenance. However, planning is a key piece of the XP puzzle. (For an overview of XP, read Extreme Programming Explained: Embrace Change. While you're at it, buy copies of all of the rest of our books, too.)
XP addresses long projects by breaking them into a sequence of self-contained, one- to three-week mini-projects. During each iteration
Without careful planning, the process falls apart.
The job of the daily planner is to help keep the team on track in all these areas.
We come by our project planning ideas by necessity. As consultants, we are usually introduced to projects when they are mostly dead. The projects typically aren't doing any planning, or they are drowning in too much planning of the wrong sort.
The resulting ideas are the simplest planning ideas we could think of that could possibly work. But above all, remember all the planning techniques in the world, including these, can't save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motiviated and they will deliver.Kent Beck, Merlin, Oregon
I have a cunning plan.