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 students they 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.