Let’s start by asking what is Extreme Programming? Also called (XP).
What is extreme programming?
Extreme Programming is designed for enhancing your software.
We will be covering what exactly Extreme Programming is and have a run through of how it works, starting with the principles of it to the values that are behind this system, to the procedures that have been best practiced.
The 5 foundations that are needed
These are the 5 foundations that are key points towards extreme programming, and what it needs for it to be able to work successfully for you and your company. This will cover how one can use extreme programming and what you might need.
Everyone is included in the community and have frequent conversations daily. We will create code as a team. As a team, we will create the best methods and tackle bugs as they happen together.
This will increase the investment’s value. We will only do what is needed and asked of us and no more than that, taking baby steps towards our goals and fix failure as they appear. We will produce something we support and will do the upkeep long term for the consumer.
We will work on each section as a team and as a community that enjoys creating. We will need to review the developments early on to help reduce issues that might come up at a later stage. Furthermore, we will communicate about our project as a team and adapt to it, this can not be the other way around.
We will be honest about the progress that has been made. Documentation of failure is not accepted as it is not something we conduct in the project. Nothing is feared as we all work together.
Everyone will get the respect they deserve as a teammate, and everyone will get that respect back. Everyone in the community contributes in some way or another this can even just be enthusiasm towards the project. The team respects the consumer and is reciprocated back from the consumer. Higher-ups acknowledge our rights to accept responsibility.
This iteration of Extreme Programming Rules, first published by Don Wells in 1999, were originally intended to help counter the claims against Extreme Programming, with saying’s that it fails to support some of the disciplines necessary for current development.
- Stories are written by the team.
- Sections are created for the project.
- There is a planning start for each section.
- Updated planning helps create an end schedule for the project.
- Frequent and small updates are too made.
- Have your team in a permeant work area.
- Let people move around freely and comfortably.
- Extreme Programming should be fixed when it may fail or break in the project.
- Have a good pace for the team.
- A stand-up meeting is to be held at the beginning of each work-day.
- The updates are recorded for the project.
The Designing Section
- Simplicity is key to the design.
- Choose a system metaphor.
- None functional designing is to be added at the start.
- Reiterate when is needed.
- Use CRC cards for design sessions as it helps keep focus.
- Create solutions to reduce the risk of failure.
- The customer is always available for checking.
- The Code must be written to the accepted standards.
- All code written for the production is pier to pier programmed.
- Only one pair may update the code at a time.
- Upload your code as frequently and often as possible.
- Set up a repository computer for the team.
- Have collective ownership.
The Test Drive
- All code needs testing.
- All of your code must pass the unit tests before it may be released to the consumer.
- When an error is found, more tests will need to be created.
- Tests are run frequently to ensure good code.
Developers Tip #1
A concept for a healthier balance between work, with developers on a project is the statement that no-one is required to work more than they normally schedule. The concept of “crunch time” is frowned upon and the same is said about overtime, when developers are looked at to work extreme over-time near the end of a project to get it finished at the right time.