Posted On May 18, 2016 by Sneha Latha filed under Enterprise
Extreme Programming (XP) can be described as a software development discipline that uses a cluster of practices, methodologies and approaches to problem solving. While XP by itself is not a single methodology, the number of practices that make up XP as a whole when implemented properly provide you with incredible results.
XP is nearly a decade old and every year more developers and development outfits embrace XP to improve their productivity. Over the past decade or so, the number of projects implemented on XP has grown at a remarkable rate. Today, XP is being used for projects small and big, local and multi-sited, and across a wide range of domains and industries.
Extreme Programming was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments, dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.
Extreme Programming finds its origins in the Chrysler pay roll project in 1996, where Kent Beck came in as a consultant. The project, which had gone haywire, was completed when the development model was changed by introducing some practices that finally came to be known as Extreme Programming.
Extreme Programming is an Agile methodology and is one of the strictest of all Agile disciplines. The original XP methodology consisted of 12 principal practices, which were recommended to developers in the first books on Extreme Programming by Kent Beck.
The original 12 practices have seen some changes and a few new practices have been added by different XP practitioners. However, most of these are considered as a part of the original 12 practices.
In this article we will take a look at the original 12 practices and also some of the new practices that have been adopted by XP practitioners.
The planning game is used upon two occasions — release planning and iteration planning.
The primary goal during the planning game is to bring in line customer requirements or the tasks scheduled for an iteration with the available programming capacity.
First, the effort for implementing user stories and tasks is estimated. If the required effort is higher than the available capacity, it is necessary to discuss with the customer this situation. Usually, user stories are written by customers themselves as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. A user story can be just a description in plain English of what the module of the portion of software will do. It is the customer’s responsibility to decide which of the user stories and tasks should be deferred to in the next iteration. If, on the other hand, free capacity is available, additional user stories or tasks can be added to the current iteration.
It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.
Small releases are very critical for stability of an XP project. The biggest problem with a big release is that sometimes customer requirements change. And at many a times the customer would have never understood what their requirements were. Smaller releases provide snapshots of the final system, part by part. And this helps a customer to analyze the progress of the software being developed. It is easier to make changes in early stages than in the final stages of development.
A lot of functionality can be delivered with one large release, but typically the requirements are determined at the beginning of the implementation, i.e. at the beginning of the release cycle. During the release cycle, the requirements may change, for example because the market has changed. If ultimately the system is shipped, it could well be that the functionality does not meet the actual requirements. The customer can use the already available functionality in production without waiting a long time. The customer has an additional mechanism for influencing the future direction of the project, for example by changing priorities or by adding or removing features. Small releases may take anything from a day to three months, depending on the size of the project and the manner in which the releases are being planned.
Project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity, you simply add up the estimates of the user stories that were finished during the iteration.
You need to choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system.
In some cases it will be difficult to find an appropriate metaphor. In this situation, it helps to go one step back, to look at the system from a broader perspective. If you look at it from 10,000 feet, which elements can still be identified? Which terms from the real world can be used to describe what can still be seen? You can start with those terms. Later on, you can switch to a better metaphor whenever you like.
What do we need a metaphor for? In XP the metaphor replaces - to a certain degree - the software architecture. By looking at the metaphor, one can discover the essential elements of the evolving system.
Some XP experts will tell you to start writing code for a reasonably sized project within an hour of studying requirements. A simple design always takes less time to finish than a complex one. So, always do the simplest thing that could possibly work. If you find something that is complex, replace it with something simple. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it, later. Keep things as simple as possible and as long as possible by never adding functionality before it is scheduled. Beware though; keeping a design simple is hard work!
This is different from traditional approaches. In practice, there are problems associated with upfront design. One of the problems is that during implementation new insights emerge, which more often than not require a design change.
Onsite Customer is a must for XP projects. In a few cases that may not be possible. In such a scenario, you need to have a domain expert taking the role of a customer; not only to help the development team, but to be a part of it as well. All phases of an XP project require communication with the customer, preferably face to face, on site. It's best to simply assign one or more customers to the development team.
If you are developing a product, an online customer is out of the equation. In such cases, a product manager or product research manager needs to take that seat.
All this may be harsh on the customer, as the customer needs to spend a lot of time with the development team. However, you end up saving time that a customer would have to spend during the design stages in a traditional water fall-based development effort.
All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting delivery time. It is counter intuitive, but two people working at a single computer will add as much functionality as two working separately except that it will be qualitative much higher. With increased quality comes big savings later in the project.
The best way to pair program is to just sit side by side in front of the monitor. Slide the keyboard and mouse back and forth. One person types and thinks tactically about the method being created while the other thinks strategically about how that method fits into the class. It takes time to get used to pair programming so don't worry if it feels awkward at first.
Experienced XP professionals recommend the following steps to aid Pair programming:
- Large monitors; and
- Open environment (See the picture of Thoughtworks office that sans cubicles).
It is also learnt that almost 40% of productive time of a programmer is usually spent in answering mails, browsing the net and doing other non-productive activities. Pair programming forces people to not waste time.
Essential Pair programming says one plus one is more than whole of the sum of the parts.
One of the much-debated aspects of XP is testing. XP recommends developers to write unit tests for each and every function and method. The unit test coverage has to be hundred percent. In case tests break, you write more tests.
When you create your tests first, before the code, you will find it much easier and faster to create the code. The combined time it takes to create a unit test and some code to make it pass is just about the same as coding it up straight away. However, if you already have the unit tests you don't need to create them after the code, thus saving you some time now and lots later.
You test everything that can fail. In other words: If no defects are detected after the system has been released, you have had enough tests. If there are defects, the set of tests is not sufficient; at least the set does not contain the necessary ones. If this happens, a test that reproduces a known defect has to be written. Then the system has to be modified until all tests (including the new one) run successfully.
There are a number of Unit Testing frameworks like Junit, Nunit, PUnit and so on, which are Open Source and free.
Apart from Unit Tests, Acceptance tests are also equally important.
Acceptance tests are created from user stories. During an iteration, user stories selected during the iteration-planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure that the functionality works.
Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of the highest priority. Acceptance tests are also used as regression tests prior to a production release.
Continuous integration is accomplished via a serialized build process. At the completion of a task, the developer (or development pair) takes a build token and runs the build process, including tests. If the tests pass, the task can be committed to the source code repository and release the token.
The more popular form (also known as Automated Continuous Integration) takes the form of a server process or daemon that monitors a version control system for changes and automatically runs the build process (e.g. a make script or Ant-style build script) and then runs test scripts (e.g. JUnit or NUnit). In many cases the build script not only compiles binaries but also generates documentation, website pages, statistics and distribution media (such as Windows MSI files or RPM files).
Developers should be integrating and releasing code into the code repository every few hours, whenever possible. In any case, never hold on to changes for more than a day. And also only a pair integrates the code at a time.
Scheduled builds, if done frequently enough, would fall under continuous integration. However, nightly builds are too infrequent to qualify.
The main advantages of continuous integration are:
- Integration problems are detected and fixed continuously - no last minute hiatus before release dates;
- Early warning of broken/incompatible code;
- Immediate unit testing of all changes;
- Constant availability of a "current" build for testing, demo or release purposes; and
- The immediate impact of checking-in incomplete or broken code acts as an incentive to developers to learn to work more incrementally with shorter feedback cycles.
XP recommends consistent refactoring of code. Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly retaining its meaning/behavior.
Refactoring does not fix bugs or add new functionality. Rather, it is designed to improve the understandability of the code or change its structure and design, and remove dead code, to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program's given structure, so a developer might refactor it first to make it easy and then add the new behavior.
An example of a trivial refactoring is to change a variable name into something more meaningful, such as from a single letter 'i' to 'interestRate'. A more complex refactoring is to turn the code within an 'if' block into a subroutine. An even more complex refactoring is to replace an 'if' conditional with polymorphism. While "cleaning up" code has occurred for decades, the key insight in refactoring is to intentionally "clean up" code separately from adding new functionality, using a known catalogue of common useful refactoring methods, and then separately testing the code (knowing that any behavioral changes indicate a bug). The new aspect is explicitly wanting to improve an existing design without altering its intent or behavior.
Remember to refactor code as much as possible.
Every programmer can improve any code anywhere in the system at any time if they see the opportunity. You do not have the blame game in the team. You also move around people as much as possible. So everyone understands the system perfectly. This means that an absence of a resource (programmer) is never felt in case it is not available.
Collective Ownership improves team unity and morale. XP demands that you start each day with a stand-up meeting where every team member is told what he needs to do. Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system that only addresses the problem under examination and ignores all other concerns.
You can write code any way you want. Everybody chooses class names and variable names in the same style. They format code in exactly the same way. There isn't a short-term benefit to coding standards that I can think of. Longer term, coding standards that are chosen for communication help new people learn the system, and as the standards become a habit, they improve productivity. Pair programming works much more smoothly with coding standards, as do collective code ownership and refactoring.
Working overtime sucks the spirit and motivation out of a team. Projects that require overtime to be finished on time will be late no matter what you do. Instead, use a release planning meeting to change the project scope or timing. Increasing resources by adding more people is also a bad idea when a project is running late.