When it comes to Agile development, Scrum and Kanban are often the popular ones. However, that does not mean they are the only Agile development methods out there. Extreme Programming (XP) is another Agile method of development that aims to provide iterative and frequent small releases throughout the project. This allows both team members and customers to examine and review the project’s progress throughout the entire Software Development Life Cycle (SDLC).
You might be wondering, “Do I REALLY need to know about Extreme Programming?”. Well, the answer is it really depends. It is one thing to know the ins and outs of something and it is totally another different thing to know about the existence of something. So, it would benefit you as a software developer to know about the existence of XP and how it works on the high level.
Extreme Values
In XP there are five fundamental values. These values are simplicity, courage, communication, respect, and feedback.
Simplicity
XP focuses on creating simple solutions to difficult problems. As a result, you do what is needed and asked for, but no more. You take small simple steps toward the goal and mitigate failures as they happen. The team creates something they are proud of and maintain it long-term for a reasonable cost.
Courage
When it comes to XP, it is important to tell the truth about progress and estimates. The team does not fear anything because no ever works alone. Lastly, the team will adapt to changes whenever they happen.
Communication
Everyone is part of the team and communicates face-to-face on a daily basis. Everyone works together on everything from requirements to code. Focus on creating the best solution to problems together.
Respect
Everyone gives and feels the respect they deserve as a valued team member. Developers respect the enterprise of the customers and vice-versa. Management respects our right to accept responsibility and receive authority over our own work.
Feedback
Deliver working software in every iteration. Demonstrates software early and often then listen carefully and make changes as needed.
Extreme Rules
XP also have rules for each part of the SDLC. These rules keep XP suitable for modern development.
Planning
- The project is divided into iterations
- Make frequent small releases
- Iteration planning starts each iteration
- Release planning creates the release schedule
- User stories are written
Managing
- Move people around
- The project velocity is measured
- Fix extreme programming when it breaks
- Set a sustainable pace
- Give the team a dedicated open workspace
Designing
- Use class responsibility collaborator (CRC) cards for design sessions
- Create spike solutions to reduce risk
- No functionality is added early
- Refactor whenever and where ever possible
- Simplicity
Coding
- Code must be written to agreed standards
- Code the unit test first
- The customer is always available
- All production code is pair programmed
- Integrate often
- Use collective ownership
- Set up dedicated integration computer
Testing
- When a bug is found tests are created
- Acceptance tests are run often and the score is published
- All code must have unit tests
- All code must pass all unit tests before it can be released
Extreme Programming in Practice
To define how XP works in a nutshell, it involves doing the following:
- Starting with a simple design just enough to code the features at hand and redesigning when required.
- Writing unit tests before programming and keeping all the tests running at all times. The unit tests are automated and eliminates defect early, thus reducing the costs.
- Programming is done in pairs (pair programming), with two programmers at one screen, taking turns to use the keyboard. While one is at the keyboard (the driver), the other is constantly reviewing and providing inputs.
- Integrating and testing the whole systems several times a day.
- Putting a minimal working system into the product quickly and upgrading whenever necessary.
- Keeping the customer involved all the time and obtaining constant feedback.
Advantages of XP
Here are some of the advantages of XP and why you might consider using XP:
- The main advantage of XP is that it saves cost and time required for project realization. Cost saving comes from not too much documentation. Problems are usually solved through discussions inside of a team. Time saving comes from the fact that XP focuses on the timely delivery of final products.
- Simplicity is the result of XP projects. The developers end up creating simple code that can be improved at any moment.
- The entire process is visible and accountable. Developers commit to what they will accomplish and show progress.
- There is constant feedback. It is necessary to listen and make changes needed in time.
- Regular testing at the development stage leads to faster creation of the software.
Disadvantages of XP
There are plenty of benefits for XP, but that doesn’t mean XP is perfect. Here are some potential issues with XP:
- Requires everyone on the team to be physically available. XP is not a good option if programmers are separated geographically.
- XP does not measure code quality assurance.
- There is a lack of documentation and defect documentation is not always good. This may lead to the occurrence of similar bugs in the future.
The Developer’s Role in XP
The developer role or programmer role is the most important when it comes to XP. Now don’t start feeling special, because like anything important, it comes with a set of responsibilities. In addition to a set of responsibilities, you will also need to be accustomed to your rights as a developer, the skills you need, collective ownership, and the various hats you might need to wear.
Major Responsibilities
Some of the major responsibilities you’ll be responsible for includes estimating stories, defining tasks from stories, estimating tasks, writing unit tests, writing code to pass the written unit tests, performing unit testing, integrating continuously, and refactoring.
Developer Rights
You have the right to know what is needed with a clear sense of priority for each task. You have the right to produce quality work at all times. You have the right to ask for and receive help from peers, superiors, and customers. You have the right to make and update your own estimates. You have the right to accept your responsibilities instead of having them assigned to you.
Developer Skills
The minimum skills you need is to be able to pair program, communicate what is necessary with sufficient detail, maintain simplicity, and code only what is required. You must also always use the metaphor to use the right names. You can think of metaphor in this context to be the architecture of the system to be built in a way that is easily understandable by everyone involved in the development.
Collective Ownership
You need to get used to the fact that the code that you have written doesn’t belong to you, it belongs to the team. That means if someone changes the code you wrote, you must trust the changes and learn. If the changes are wrong, you are responsible for making things better, but be careful to not blame anyone.
Wearing Multiple Hats
Sometimes you’ll be the programmer and other times you might be a UI designer. Be prepared to take on the roles of an architect and designer, UI designer, database designer and DBA (database administrator), operations and network designer, in addition to a being a programmer or developer. Also, you might be a tester too. In such case, you’ll be probably running the functional tests, reporting the test results, and ensuring the testing tools run well.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are experiences with extreme programming? Have you been part of a team that uses extreme programming? What do you think of extreme programming in comparison to other Agile development methods?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.