The Practices of Extreme Programming

Technical Practices

The second edition of Kent Beck’s book, Extreme Programming Explained, defines 21 technical practices that an Agile team should apply to its work.

Our book provides an interpretation of these practices within sidebars located in the chapters that contain the associated subject matter. In this way we present XP within the context of its practical implementation.

Pair Programming: it is form of continuous peer review requiring that all production code be written by two people sitting together at the same computer, sharing a single mouse, keyboard, and monitor Whole Team: it brings people with different expertise together so that they can work as a cross-functional team. In other words, people on the team don’t work for different departments (programming, testing), but instead work for the project and shares its objectives Sit Together: the team works in an open space that is large enough to accommodate everybody rather working in their own offices or even desks are separated by small partitions Team Continuity: keeping effective teams together rather than splitting them apart at the end of a project. It is a case of recognizing that good social interaction among people plays as much a part in the team’s success as the knowledge and skills provided by the team’s individual members Shared Code: source code doesn’t belong to individuals; it belongs to the team. There are no off-limits areas in the code base, so everyone is able, and indeed expected, to make improvements whenever the opportunity arises Single Code Base: version control manages just one main line of development for your Team Project, so you avoid creating different sets of files (i.e., branches) for particular customers, special releases, and so forth Code and Tests: treats test and source code files as the primary artifacts of your project and, when possible, uses them to generate other files and documents automatically as they are needed Ten Minute Build: less than ten minutes after someone puts his changes into the repository the latest version of the team’s software has been rebuilt and its integration tests run Continuous Integration: requires your software to be rebuilt from the team’s shared code base whenever you check-in any changes to the repository Test-First Programming: Test-First Programming (TFP) requires you to let your coding activities be driven by two simple rules: 1) never develop new code unless you have a failing automated test. 2) eliminate duplication Energized Work: helps the team avoid any long-term decline in its productivity by ensuring that people get the frequency, quality, and duration of breaks they need in order to recover fully from their work Incremental Design: makes design an everyday activity, so you perform it in small steps which you immediately validate by coding and testing Real Customer Involvement: puts the people with the requirement in direct contact with the people responsible for satisfying their needs by making the customer as part of the development team Stories: each feature that has value to the business is specified in terms of a story which arises from conversations between a developer and the customer. A story is summarized on an index card and specified by functional tests and so that the team can then plan their work by estimating and prioritizing their work using these cards Weekly Cycle: synchronizes the achievement of the team’s immediate iteration goals with some naturally reoccurring event like the end of the week (or the end of two weeks) Quarterly Cycle: promotes the idea of a collection of stories with a common theme being implemented over a number of iterations and then released to the business together so as to satisfy some general strategic goal Slack: provides time for people to work on things like automating processes that in the long term will make the team more effective. It also provides a buffer so when something goes wrong people can still meet their commitments Daily Deployment: requires you to put all new software into the production environment at the start of each business day. It is often used to drive improvement in the release process, but is seldom fully implemented Incremental Deployment: releasing a product a bit at a time rather than attempting to release it all at once. It avoids having to make an abrupt transition to the new system; the big-bang approach Informative Workspace: taking control of your environment and making it support the team’s work. It is an antidote to the institutionalization that exists in many workplaces Root Cause Analysis: requires you to identify and correct the real cause of a problem rather than addressing just its symptoms

Addison-Wesley ISBN-10 0-321-27865-8

Business Practices

In addition to the technical practices, Kent Beck also identifies three practices which seem more business orientated than the technical ones covered in our book.