The Case Against Extreme Programming
Extreme Programming problems
This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation.
I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system.
If you are lucky enough to be on a project where the customer can clearly articulate their requirements once, then maybe XP isn't right for you. From experience, most customers in the e-business arena, don't know what they are building. Some don't even know the problem they are trying to solve. XP, then, is a great way to tackle the problem.
Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understand when XP is good, and understand when it's not. But don't try to change XP into something it's not, when all you needed was a different process.
P.S. A personal gripe. I've seen these types of arguments against XP before. They usually come from a person that feels threatened by the process. This person might fancy themselves an Architect, one that sits on the mountain and dispenses Beautiful UML Diagrams down to the people. XP completely removes this type of position from the team. It spreads it out, valuing an emergent design over one that is dictated.
This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation.
I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system.
If you are lucky enough to be on a project where the customer can clearly articulate their requirements once, then maybe XP isn't right for you. From experience, most customers in the e-business arena, don't know what they are building. Some don't even know the problem they are trying to solve. XP, then, is a great way to tackle the problem.
Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understand when XP is good, and understand when it's not. But don't try to change XP into something it's not, when all you needed was a different process.
P.S. A personal gripe. I've seen these types of arguments against XP before. They usually come from a person that feels threatened by the process. This person might fancy themselves an Architect, one that sits on the mountain and dispenses Beautiful UML Diagrams down to the people. XP completely removes this type of position from the team. It spreads it out, valuing an emergent design over one that is dictated.