Extreme Programming is a software development centric agile method. The
core values of this methodology are:
- Simplicity: The team should keep the phrase “Find the simplest thing that could possibly work” in mind and build that solution first. Thus, this value addresses complexity, extra features and waste.
- Communication: Ensure all team members know what is expected of them and what other people are working on.
- Feedback: The team should get early feedback. Failing first can be useful, especially if in doing so we get new information while we still have time to improve the product.
- Courage: It takes courage to allow our work to be entirely visible to others.
- Respect: Respect is essential on XP projects where people work together as a team and everyone is accountable for the success or failure of the project. Respect team member differences
In XP, lightweight requirements are known as “User stories”. User stories are used in planning releases and iterations. Iterations are typically two weeks long, and developers work in pairs to write code during these iterations. All Software developed is subjected to rigorous and frequent testing. Then upon approval by the customer, the software is delivered as small releases. While scrum focuses on "how to accomplish the complex scope through incremental iterations, XP focuses on what good software development practices to implement.
XP Practices:
1. Pair Programming: In XP, production code is developed by two developers working as a pair and provides real time reviews of the software as it emerges. It saves time because the pairs catch issues early and there is a benefit in having the larger knowledge of two people. Working in pairs also helps spread knowledge about system through the team.
Pair programming means that all code is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. Programmers exchange roles after agreed periods. The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication.
2. Test Driven Development: Almost all the product organizations today are struggling with lots of technical debt where we have lot of code in place that is not testable and scalable. We want to implement TDD because we want to build the product that is just sufficient to meet the necessary tests expected. This thought process when clubbed with refactoring will make our code testable, scalable and flexible. What is Test Driven Design? - Test Driven Development advocates "no code is added without first writing an automated test" To drive code with tests, a developer starts by writing a test for the code he wants to write. He runs the test to check that if it really does fail. Now He writes the minimum code to make the test pass. After each new test passes, he looks for opportunities to consolidate the code and eliminate duplication. He builds up the code by repeating these steps. Developing code this way encourages a developer to think about solving one small problem at a time. It also helps the developer work from the outside in rather than inside out, because for each test they consider the interface of the code before its internal logic, because applying TDD drives the developer to make small design decisions as they go, it’s also sometimes referred to as test-driven design.
2. Test Driven Development: Almost all the product organizations today are struggling with lots of technical debt where we have lot of code in place that is not testable and scalable. We want to implement TDD because we want to build the product that is just sufficient to meet the necessary tests expected. This thought process when clubbed with refactoring will make our code testable, scalable and flexible. What is Test Driven Design? - Test Driven Development advocates "no code is added without first writing an automated test" To drive code with tests, a developer starts by writing a test for the code he wants to write. He runs the test to check that if it really does fail. Now He writes the minimum code to make the test pass. After each new test passes, he looks for opportunities to consolidate the code and eliminate duplication. He builds up the code by repeating these steps. Developing code this way encourages a developer to think about solving one small problem at a time. It also helps the developer work from the outside in rather than inside out, because for each test they consider the interface of the code before its internal logic, because applying TDD drives the developer to make small design decisions as they go, it’s also sometimes referred to as test-driven design.
3. Refactoring: It is process of improving the design of existing code without altering the external behavior or adding new functionality. By keeping the design efficient, changes and new functionality can easily be applied to the code. Refactoring focuses on removing duplicated code, lowering coupling (dependent connections between code modules), and increasing cohesion. When "changes in one part of the code affect lots of other parts", the system is telling you to refactor your code by changing the architecture, making it simpler and more generic.
4. Simple Design: By focusing on keeping the design simple but adequate, XP teams can develop quickly and adapt as necessary. The design is kept appropriate for what the project currently requires. It is then revisited iteratively and incrementally to ensure it remains appropriate. XP follows a deliberate design philosophy that leans toward, “what is the simplest things that could work?” as opposed to complexity structures that attempt to accommodate possible future flexibility. Since code bloat and complexity are linked to many failed projects, simple design is also a risk mitigation strategy. Thus, XP practices advocate programming only what is needed today, and implementing it as simply as possible.
5. Collective Code Ownership: Multiple people work on all the code which results in increased visibility and knowledge of the code base. This practice leads to higher level of quality, with more people looking at the code. There is greater chance that defects will be discovered. There is also less of an impact to the project if one of the
6. Coding standards: Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project.
7. Sustainable Pace: XP recognizes that the highest level of productivity is achieved by a team operating at a sustainable pace. While periods of over time might be necessary, repeated long hours of work are unsustainable and counterproductive. The practice of maintaining a sustainable pace of development optimizes the delivery of long term value.
8. The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may create loan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue (class). For each class or operation the functionality is obvious to the entire team.
9. Continuous integration: Integration involves bringing the code together and making sure it all compiles and work together. This practice is critical, because it brings problems to the surface before more code is built on top of faulty or incompatible designs. XP employs a continuous integration, which means every time a programmer checks in code to the code repository (typically several times a day), integration tests are run automatically. Such tests highlight broken builds or problems with integration, so that problem can be addressed immediately. Thus, the development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.
10. Customer Tests: Customer develops the Acceptance Tests to be performed . It is to help the team to confirm that the software is working.
11. Whole Team: All the contributors sit together in the same location, as members of a single team. Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.
12. Planning Games: XP has two planning activities, or planning games – Release planning and Iteration planning. A Release is a push of new functionality all the way to production user. A project has typically one or more releases. Iterations are short cycled development cycles within a release that scrum calls “sprints.
13. Small Releases: The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project.