Talk:Extreme programming practices
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)
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)
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 22.214.171.124 17:29, 1 October 2007 (UTC)
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)
Surely this should be at Extreme Programming practices, i.e. practices in Extreme Programming rather than the current title, which suggests extreme practices in Computer programming?--Michig (talk) 14:29, 22 May 2010 (UTC)
The planning game details for XP don't make sense to me and aren't referenced. I think a reference should be provided. The exploration, commitment, steering for iterations suggests that part of the iteration planning game means actually completing the tasks - I've not heard concept that the planning phase extends for the entire iteration before ChanochWiggers (talk) 19:25, 16 March 2011 (UTC)
"Extreme programming (XP) is a POPULAR agile software development" I am removing "popular" because it is not defined or sourced (either in the lead or elsewhere in the article). Personally, I think the claim is dubious, but of course reliable sources could easily sway me. ;) Note that the Extreme Programming page itself does not make the claim of popularity. 126.96.36.199 (talk) 14:12, 19 July 2012 (UTC)