If you are familiar with Extreme Programming, these rules are not new to you. If you are not, they will certainly give you a lot of insight in good software development. We have been using many XP principles in our projects, and have had very good success.
Here are the XP rules, straight from the XP website.
Planning
- User stories are written.
- Release planning creates the schedule.
- Make frequent small releases.
- The Project Velocity is measured.
- The project is divided into iterations.
- Iteration planning starts each iteration.
- Move people around.
- A stand-up meeting starts each day.
- Fix XP when it breaks.
Designing
- Simplicity.
- Choose a system metaphor.
- Use CRC cards for design sessions.
- Create spike solutions to reduce risk.
- No functionality is added early.
- Refactor whenever and wherever possible.
Coding
- The customer is always available.
- Code must be written to agreed standards.
- Code the unit test first.
- All production code is pair programmed.
- Only one pair integrates code at a time.
- Integrate often.
- Use collective code ownership.
- Leave optimization till last.
- No overtime.
Testing
- All code must have unit tests.
- All code must pass all unit tests before it can be released.
- When a bug is found tests are created.
- Acceptance tests are run often and the score is published.
Sometimes I think these are too idealistic. The real world demands are to deliver working software fast. A team that’s tuned to extreme programming can certainly deliver good code quickly, but most programmers are taught differently. They are not tuned to pair programming or test driven development. Many managers too doubt the value of these principles. That makes it more difficult to implement them.
I am dreaming of a project where we can implement all these rules!
Hello Sir,
This rules are perfect
But A team with variety is needed
70% can not be freshers
Pair programming is something which is one of the best technique which i have ever practised
Nice one, Google is also following same methodology.
XP is really efficient & produce good results if you follow at least 80% of rules of XP in your project. If you adopt only few rules, then it will fail for sure. Communication, Simplicity, Feedback, and Courage are the four important values in XP.
“XP is successful because it emphasizes customer involvement and promotes team work.” – In normal case, customer involvement is not as excepted.
According to XP rules, Its require that, a customer or a representative of your customer have to sit/coordinate continuously with your programming team.
Also, most people are not following or failed to follow the rules given below, for some or other reason.
Planning
* The Project Velocity is measured.
[Due to lack of experience]
* Move people around.
[Due to shortage of good resources]
* Fix XP when it breaks.
Designing
* No functionality is added early.
[Bcoz, customer can change his requirement at any time]
* Refactor whenever and wherever possible.
Coding
* The customer is always available.
[This is not true all the time]
* All production code is pair programmed.
[It works only if you have clear understanding of project. If not, then its wast of time & resources]
* Use collective code ownership.
* No overtime.
[No one wants to do overtime, but it will always there if you have started any project without proper understanding & risk. Means, if you are doing overtime for any project, you have failed in first phase of project itself. Also, from PM/management point of view, they are always happy; if some programmer will do overtime. Can any PM/CEO ask to their team member/employee for not to do overtime 🙂 100% No one will say like this. So; this will never be in practice]
Testing
* When a bug is found tests are created.
[Personally I don’t believe in this].
But Test cases should be ready after User Story approved.
Any way, on paper, all sounds good 🙂 but it will require ownership & commitment to follow the rules, then & then you will complete your project on / before time.