Tuesday, January 25, 2011

Extreme Programming installed: Chapters 1-3

Extreme Programming installed: Chapters 1-3
Ron Jeffries, Ann Anderson, and Chet Hendrickson

 Extreme programming, or XP for short, is a new way to develop software that focuses on improving the relationship between the customer and programmer.  XP has three main roles, the customer, the programmer, and the manager, each with their own responsibilities.  The customer is the stakeholder.  He or they decide what they want to be able to do with their program.  They determine the direction and the look of the project.  The programmers are responsible for meeting the customers specifications for the program as well as maintaining a steady flow of completed work.  The programmer needs to make sure he completes every user story the customer has given to him.  The managers responsibility is to make sure the programmers can accomplish their tasks.  They also handle all the planning regarding meetings and also handle any personnel issues.  The life cycle of an XP project is different than normal one.  The customer defines what he wants, the programmer determines the approximate cost of different implementations, the customer then chooses which he wants so that the programmer can get to work on it.  An XP project almost requires a customer to be on site, or at least on site most of the time.  This is because the interaction between the customer and the programmer is a lot closer.  The back in forth interaction between the two is what really sets agile programming apart.  XP wouldn't be taking advantage of this aspect if you didn't have a close relationship with your client.



I found these chapters really interesting because at my current job, we use agile development. Even though we don't use XP, the methods we use are extremely similar.  Agile methods are becoming more and more popular and that makes this book relevant.  Why is this? I could be a trend or maybe people just like the process better.  It's not that agile techniques are superior than traditional methods, they just have a lot of appeal for developers.  Agile methods do some things really well that the older methods lacked on.  However, agile techniques have their own issues.  It is so heavily dependent on communication that if there is a snag at all, it could put your program behind.  Also, agile methods use an estimation method to determine when the product will be ready, but this estimation can change greatly depending on how quick or slow the user stories can be completed.  So you can't say that agile is better than waterfall or vice versa, it really just depends on what suits your company better.  If agile allows you to complete projects on time with all the requirements met, why not use it.  If it fits your company and your employees, then agile will help your company succeed.

No comments:

Post a Comment