Table of Contents
I. THE SPIKE—GETTING UP TO SPEED.
1. The Metaphor—Developing a Sense of Where We're Headed.
2. Getting Started—Introducing the Core XP Practices.
3. Pair Programming—Learning to Work Together.
4. First Test, Then Code—Understanding Why We Test First.
II. THE ITERATION—SHAPING THE DEVELOPMENT PROCESS.
5. The Client—Meeting Another Team Member.
6. The Plans—Beginning an Iteration.
7. The Values, Principles and Practices—Living the Iteration.
8. Acceptance Tests—Determining That a Story is Completed.
9. Evaluation and Regrouping—Wrapping Up an Iteration.
III. CORE PRACTICES—WORKING EXAMPLES OF CORE PRACTICES.
10. Test First—Learning a New Way of Life.
11. User Stories—Exploring with the Customer.
12. The Planning Game—Negotiating the Future.
13. Refactoring—Sharpening Your Knife.
14. Customer Written Tests—Automating the Acceptance Process.
15. Development Mechanics—Organizing Your Project.
Forewords & Introductions
At some point in the process of learning the craft of software development, you need to work on a real project for a real client. The project must be large enough that you can't hold all of the details in your head. The duration of the project must be long enough that you don't remember what you were intending when you wrote the code that you later are trying to understand. The project must be complex enough that you need to clarify requirements that you thought you once understood.
Many colleges and universities offer a one- or two-term course in which the students learn about software engineering by working on a significant project for a real client. We don't claim to have invented this idea.
Our version of a hands-on software engineering class is derived from the course created by Fred Brooks at Chapel Hill. Students work on a real project for a real client while spending class time discussing readings on various software methodologies and on issues that can arise during the students' practical experience.
eXtreme Programming (XP) is well suited to the academic setting. Initially, and for several years, software teams in our course used the traditional approach. They worked their way from requirements' analysis to final delivery over the course of a semester. One semester half of the class continued with the traditional approach and half of the class used XP The course now runs with all of the software teams using XP as their methodology for these practicums.
The pedagogical benefits of using XP were immediately clear. Students that work in small groups get consistent and useful feedback about their progress. This comes from other studentsthey pair with, from seeing the unit-tests pass, from completing tasks, and from quick and frequent client reaction. All students communicate with clients, coaches, "bosses," and each other. No skill is as important as communication. The students are constantly required to communicate verbally and through their code and other writing. Students begin to see, how various pieces fit together. Instead of working on toy programs intended to illustrate a particular point such as sorting, students see how they and others on the same project are dependent on the sorting code they've written.
HANDS-ON SOFTWARE ENGINEERING There is a gap between the way students learn to program in an academic setting and the way software is written in professional practice. Some of the differences result from the differing goals of the two environments: computer science departments aim to teach the craft of programming, and professional software developers set out to create useful programs. Students are learning the craft, so they can focus on one thing at a time; professionals must deal with a myriad of factors simultaneously. The larger the gap grows the more additional training students need after graduation.
Academia is faced with the task of being more relevant to students without becoming a purely vocational venue. Certification programs exist, and do provide useful, short-term value, but because of the blazingly fast refresh rate of technology, students who choose this route sacrifice building a general, far-reaching foundation. The simple fact is that the specifics of a given platform, package, or language covered during the four years of college may very well be outdated by graduation. Today's language syntax or operating system (OS) features have little more staying power than a passing fad or a moderately popular sitcom. Instead, students must develop an understanding of the trade-offs, the issues, and the broader context that will shape "next thing" and "the thing after that."
This book describes a course that begins to bridge the gap between academic and professional software practices. It describes how to build an environment within the academic crucible that more closely mirrors the pressures, constraints, and interdependencies of a realistic software development effort. It uses methodologies that are flexible enough to meet the changing needs of clients within the rigid time constraints of an academic calendar. But eXtreme Programming is more than just a schedule management tool, it promotes good programming practices, it improves the quality of the produced code, and it helps integrate a group of individual programmers into a development team. In short, it's more than just a way to program, it's a great way to teach software engineering.
WHO IS THIS BOOK FOR? This book is particularly well suited to be used in three settings.
- A project-based class in computer science where the students work in groups on long-term (one quarter/one semester or more) projects for actual clients.
- A team of developers interested in an immersive experience to investigate eXtreme Programming.
- One or more developers planning a self-directed exploration of the principles and practices of eXtreme Programming.
Academic Settings This book is primarily aimed at supporting an extended programming experience. The usual audience consists of established undergraduate computer science majors, with many semesters of computer science courses behind them. This course can serve as a capstone experience, and, as such, requires that students have a solid and varied collection of programming experience. Though it is not required for this course specifically or for software engineering in general, this book assumes an understanding of object-oriented programming, and in particular, the Java programming language.
This book is not intended to be a comprehensive introduction to software engineering. This book provides instruction, guidance, and examples in the experiential component of the class. Instructors will need to select a traditional software-engineering textbook or supplemental readings to cover methods from other Agile or traditional methodologies. As this landscape is always changing, we use supplemental readings as the basis for in-class discussions.
Professional Training Settings A weeklong immersive experience using XP will give you the flavor of the methodology and enough experience to jump start an XP project in your work environment. In that setting, this book can be used as a valuable reference so that you can prepare for the training by reading the chapters in the Parts I and II to prepare for the training experience. You can then read the chapters in the Part III after the training week to supplement your understanding of the core practices.
Self-Study Groups or Individuals For teams of software developers, the book provides you with a concrete look at the practices and of the life cycle of an iteration. In addition there are tutorial chapters designed to lead you step-by-step through the application of practices. The level of detail should support you and your group while studying this material on your own. Although pair programming is one of the central programming practices of XP, constraints may not allow you to explore XP with others. In this case you can still use this book as a study guide, but you should look for opportunities to try out pair programming.
FEATURES OF THE BOOK Some of the book's features that support this interactive, project-oriented approach include: guidelines for setting up and presenting an XP software-engineering course (including an intense introduction to all the features of XP), a collection of tutorials on the core aspects of XP, a detailed description of what to expect each week when applying XP to a development project, and feedback from students, faculty, and clients who have been through the process.
The centerpiece of the book is the collection of practical tutorials that allow the reader to learn by doing the key XP practices. The tutorials provide step-by-step instruction on test-driven design, refactoring code, writing and running acceptance tests, interacting with the client, and using XP's planning game to determine where the development should focus its energy. Even if the reader unfamiliar with XP does nothing other than work through the tutorials, he or she will get the essence of what it is to work on an eXtreme Programming development effort.
For a fuller and more detailed portrait, the book offers a broader view of XP and how it integrates into a software-engineering course. In particular, the book provides a detailed description of what happens during a typical XP development effort. From the first interaction with the client, to ongoing meetings and programming sessions with fellow XP developers, through the conclusion of the project, this book describes in detail the activities, expectations, and responsibilities of all the participants in the process.
NOTE TO INSTRUCTORS When a practical experience is the centerpiece to your course there are two basic approaches. In the first, you can take time to teach each of the practices or skills that the student will encounter before they encounter it. There are courses in traditional software engineering that do this. You lecture about creating a requirements document and then you have the students create one. A second approach is to get the students immersed in the programming experience as quickly as possible. The arguments for each of these approaches mirror the arguments for big up-front design versus the extreme just-in-time design.
We recognize the value in each of these approaches and have designed this book to meet some of the requirements of each. The fear that the up-front learning advocates have is that there are topics that may not be covered in the second approach. The extreme teaching crowd worries that the first approach spends a lot of time on concepts that the students don't know they need yet. This is not quite the you aren't going to need it (YAGNI) rule of XP This is more that you don't know that you are going to need it. In teacher-training classes, future teachers are taught six different ways of asking questions and about different learning styles. They nod their heads and pass tests, but until they stand in front of their own class, they don't understand the relevance of the material.
You can cover the material in Part I to prepare the students for their practical experience. We suggest a Spike—a small practice project designed to get some of the kinks out before the actual project begins. Part II explains the shape of the iteration to the students. They need to read Part II before beginning their actual long-term project. Part III can be used in two ways, depending on whether you're taking the just-in-time or the up-front approach. You can either use these tutorials to cover and explain each of the practices before the students engage in them or you can leave them to the students to explore when they recognize the need. The remainder of the text contains information that doesn't need to be imparted to the student at any particular time.
NOTE TO STUDENTS Most of the valuable learning from this book will come when you put it away for a while and work on exercises, step through tutorials, or try out a practice.
You can't learn Tai Chi sitting down, you can't learn to ski from the warmth of the lodge, and you can't learn to build large software systems using an Agile® methodology without ,booting up the computer. This book is designed for use in conjunction with an actual software development effort. The text shows you what to do instead of telling you what to do.
You will have a client. You'll find chapters that describe how to work with the client throughout the lifetime of the project. You'll work with a team. Much of the material in this book will help you negotiate with the team to figure out what is going to be done next and by whom. All of your code will be written in pairs. Pair programming may seem to fly in the face of how you've worked so far, but take this opportunity to give it a try. The biggest changes you will be asked to make are in how you actually write your code. You will be led through the process of writing test first code and looking for ways to improve it. As you need them, read and follow the tutorials on some of the more central practices.
Don't get too caught up in the details. XP is just a methodology. The goal in this course is to engage in all of the facets of software development. You will work with customers to elicit and focus requirements. You will design and build software. You will release your software and present your work to the customer. With XP you will pass through these steps many times during the semester. Each time, take a moment to note what you are learning and what you can do to make the next time through the XP process even better.
NOTE TO PROFESSIONALS The advice in the "Note to Students" section applies to you too. In addition, you will find an outline in the second appendix of how you might organize the material depending on whether you are organizing a self-directed study group or a formal training workshop.
The easiest way to learn a new programming language, technique, or methodology is to choose a real project on which to experiment. With XP, it is even better to have an independent customer to interact with. It could be a real client, a friend, or relative. In a pinch you can be your own client—just be clear to keep separate when you are making decisions as the client and when you are making decisions as the developer.
The final request is that you give XP a fair trial. When you are a student in a formal course you will have to commit to XP for the duration of the course. With self-study or following a short-term immersion you can give up on XP before you realize the benefits. Writing code test first may feel like an added burden until the first time you have to perform a major refactoring and the unit tests protect you.
loading...