in Business & Leadership, Ideas Worth Sharing, Technology

Extreme Programming Rules

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

Designing

Coding

Testing

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!

Write a Comment

Comment

  1. 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

  2. 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.