Talk:Extreme programming practices

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Beck Reference

The reference to Extreme Programming Explained most likely is meant to be to the first edition of the book. The second edition contains practices which differ immensely from the list mentioned on this page. Also, in the second edition (seventh printing), page 54 is blank. Note that I have not edited the article, because I cannot confirm the practices originated from the first edition of the book. David Walschots (talk) 16:21, 23 March 2010 (UTC)[reply]

Risk

I know that the risk analysis here is just an example, and everyone views this differently. But, according to this example, developers develop the relatively complete, unchanging and simple stories before the complete, unchanging and complex stories. Isn't it a better practice to do the complex stuff first? Or is it completely subjective? DRogers 14:38, 8 August 2007 (UTC)[reply]

I was stuck with that at first too. I think what they are getting at, is at a given level of importance to the project, do the simplest first. So You'll do the must have parts of the project first. But you'll create the easy to code must haves first.

Why not do the hard must haves first? Well XP calls for quick releases, so the difficult topics might not be able to be coded while a lot of other stuff is going on. As well, a lot of the risk weighting will be in the category, of "requirements not completely known", and "highly volatile", so time is better spent doing the simple stuff. The requirements, and the volatility very well might disappear after a few interations.

Another reason for it, would be if the project gets dumped you at least have some of the functionality already coded, which presumablity could be used later on (if it is a must have, the functionality will have to go somewhere). MikeG 216.16.232.115 17:29, 1 October 2007 (UTC)[reply]

According to Dr. Umphress at Auburn University (who teaches the software process class, has managed many projects for the air force, and works as a process consultant); developing the easier base functionality provides you with something to demonstrate. For example, if management decides it has too many projects and needs to cut some, a project with something to demonstrate is less likely to be cut than one that does not. In extreme programming this is especially important. Since the customer is an integral part of this process, being able to show them something quickly helps to elaborate the system at a higher rate of speed. -ShiNoSaru —Preceding unsigned comment added by ShiNoSaru (talk • contribs) 07:46, 5 May 2008 (UTC)[reply]