Talk:Extreme programming practices

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]

You actually need to do both first: the easy ones to demonstrate progress and build trust in your delivery capability, the high risk ones to fail fast, understand the problem better and gradually improve predictability 2A02:A46F:F253:1:A8A6:94D3:DDC7:432 (talk) 11:47, 12 January 2024 (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]

Title

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)[reply]

Planning Games

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)[reply]

I agree that this section does not make sense. It reads as if both Release Planning and Iteration Planning take place within each iteration, whereas it would seem to make more sense if Release planning were performed once per release.

The paragraph at the bottom tells us that 'Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery' and yet for the release planning commitment phase it says 'Within the commitment phase business and developers will commit themselves to the functionality that will be included and the date of the next release', ie a direct contradiction. FreeFlow99 (talk) 17:35, 17 March 2020 (UTC)[reply]

Popular?

"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. 173.172.95.186 (talk) 14:12, 19 July 2012 (UTC)[reply]

Agree XP cannot be most popular

1) Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. I can see many domains not being the same.. 2) The entire and whole team concept is loosely defined and more ever there are more conflicts then progress that i can imagine with such loose objectives / user stories/features.

3) i was surprised when there are many good quality sources claiming to be popular which did not make logical sense. — Preceding unsigned comment added by 71.184.73.224 (talk) 18:47, 1 March 2016 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Extreme programming practices. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20061215120657/http://www.xprogramming.com/xpmag/whatisxp.htm to http://www.xprogramming.com/xpmag/whatisxp.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:00, 26 September 2017 (UTC)[reply]