![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||
|
A new version was published in 2014. 1. This page needs updating with any changes (not many) 2. A significant re-positioning 'upwards' as a project management framework 'above' Scrum and positioned alongside other large corporate frameworks (e.g. PRINCE2, MSP, ITIL). — Preceding unsigned comment added by BWernham ( talk • contribs) 07:38, 3 August 2014 (UTC)
The key image referred to in the text is missing 213.86.200.19 15:14, 16 March 2006 (UTC) James@doctor-it.co.uk
What is "([The Deane], Wizdeane Corporation)" that I was finding in the article? RJFJR 16:09, 9 October 2006 (UTC)
The two diagrams in the article are both unreadable. Can someone upload clearer versions of these (assuming the copyright situation is ok, of course). Otherwise I think we should remove them from the article. Stumps 15:38, 20 November 2006 (UTC)
I agree that the diagrams are VERY DIFFICULT to read and that the original poster should realize that this gives a substantial negative impression to casual users of the entire subject. In spite of their poor quality, they should not be removed until replacements arrive. Actually, the fact that it is even possible to create illegible diagrams may mean that they are too complicated to begin with. I doubt the DSDM elders are listening though... 169.229.200.176 ( talk) 19:40, 17 April 2008 (UTC)
The W in MoSCoW is for "Won't" not "Would". It is often written as Would since people get carried away saying "could have", "should have", "would have". — Preceding unsigned comment added by 81.174.143.253 ( talk) 20:18, 17 March 2013 (UTC)
From experience I prefer the meaning "Won't have this time" (i.e. this Iteration) - it's more useful than 'Would' as it helps get agreement on what to leave out-- 81.146.43.237 16:22, 10 January 2007 (UTC) GBAC 10/1/06
I don't know if this is too much of a nit-pick or not. It seems to me that the phrase "MoSCoW approach," as it's first introduced in the "Phase 2: The Project life-cycle" section, is not actually an approach. It's a mnemonic for the categorization of requirements. And in general why relegate the definition of MoSCoW (as well as all the other "Core Techniques,") to a separate section? That's prime time stuff, part of what defines the actions in the various phases. I'd say include those techniques where they're first used, then link to the first use in the other places the technique is used. (As a side note, technique isn't the right description of MoSCoW either, I think.) As I stated below, I'm not qualified to make these edits, as someone learning about this topic from the article, but it seems like something that would improve the article. BenODen ( talk) 18:18, 30 January 2008 (UTC)
Removed the definitions of MoSCoW from this article, these were very brief and somewhat different from the definitions in the specific article. Pstansbu ( talk) 16:34, 1 May 2017 (UTC)
To cleanse this article of its buzzwords would sterilize beyond usability, so I would recommend removing only those which lay persons in a boardroom might understand. I move to supplant the word "baseline" as the first candidate, and relegate it to parenthesis. Any other candidates? N8mills ( talk) 05:50, 9 January 2008 (UTC)
Just coming by as a reader trying to learn what DSDM is all about, I concur with the concern about buzzwords. One example in is in the topic summary in the Principles section:
There are 9 underlying principles consisting of four foundations and five starting-points.
It's not clear to me that Principles means the same thing that is usually does. Are they "Principles of Design" or "Principles of Development" or what? The word principles usually needs a category to be meaningful. In addition, the section on principles doesn't describe how foundations and starting points are different. I would argue against simply removing the buzzwords and argue that turning them into terminology by defining the buzzwords instead of just dropping them as words that "any dummy should know." An encyclopedia article should define any terms that are not general knowledge for the target audience, in this case, software developers. I have no expertise to do this, but some editor of the wikipedia does. BenODen ( talk) 17:49, 30 January 2008 (UTC)
Incidentally, I guess I neglected to say that my perspective on the buzzword complaint is that it's is really about undefined jargon rather than about buzzword use. BenODen ( talk) 18:45, 30 January 2008 (UTC)
Ged Byrne ( talk) 12:22, 27 September 2011 (UTC)
It seems like for all the details given, this article doesn't actually describe how a prototype in the development section becomes an actual product to be implemented in the Implementation phase. There are certainly some things beyond the scope of an encyclopedia article, but simply implying that the prototype magically becomes part of the project without spending any time on it seems odd. A prototype is usually an incomplete implementation, a step above a proof of concept, so fleshing it out and integrating a prototype into the main product seems like a step that could take some time and should be at least mentioned in the method.
Is this vague transition from prototype to product just a weakness of this particular article on the subject or is it a general weakness of the Method? BenODen ( talk) 18:37, 30 January 2008 (UTC)
The transition from prototype to product is seen as one of the key strengths of the Method. However, it is true that this isn't reflected well in the article. I believe that part of the problem lies with the original DSDM 4.2 text.
In the above:
Would it be a good idea to end the confusion and update the whole article to only reflect DSDM Atern? — Preceding unsigned comment added by Ged Byrne ( talk • contribs) 12:13, 27 September 2011 (UTC)
Ged Byrne ( talk) 12:14, 27 September 2011 (UTC)
A user seems to have removed a HUGE amount of content, and replaced it with text which appears to be culled from the source of another site (the font tags are still present!). I suggest that this is not the proper way to edit an article, and that any changes should be worked into the existing article if at all possible, and that such large changes should not be made without discussion.
The current article is not at all encyclopedic (it reads more like marketing prose), is completely un-cited and has questionable origin - if the person who put it on Wikipedia did just take it from viewing the source on another site it may be a copyright violation displaying it here. It also suffers from a severe visual layout issue. For these reasons it must be changed.
I do not have a thorough understanding of the subject so am loathed to make such sweeping changes as to reinstate the older version of the article. Can someone who can speak authoritatively on the subject lend their expertise.
I am not the authority that this collaborator seeks, but I entirely agree with him/her. Please can someone competent revert the change which removed all the useful content! Thank-you. Katriona22 ( talk) 20:37, 8 January 2009 (UTC)
One or more portions of this article duplicated other source(s). The material was copied from: http://www.spoce.com/knowledge-base/dsdm-atern.aspx. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a license compatible with GFDL. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or printed material; such additions will be deleted. Contributors may use external websites as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. -- Moonriddengirl (talk) 13:19, 4 February 2009 (UTC) Please forgive the intervention and excuse any protocol breaches I may be making (I am new to Wikipedia editing but hopefully learning fast). I have some important and, I hope, useful points about the DSDM entry. The copyright of DSDM is owned by the not for profit DSDM Consortium. The latest version of DSDM is called DSDM Atern. This contains all of the richness of the older version represented by the material here and is free to view and free to use. DSDM Atern contains many improvements and many changes of terminology: life cycle phases, roles, principles. I would like to correct the entry here to show these current aspects and to make the entry up-to-date. This may mean removing material or putting it into historical context. The Consortium is happy to release new content under GFDL compatible license. The material is verifiable, published in hard copy and on the web. Please can anyone help me to correct the entry and add some up to date content to make this entry current and as useful as it can be. I do this in the spirit of the Wiki, not for any personal or organisational gain, but to make the entry accurate and current. With best wishes MagiciansNephew ( talk) 18:05, 12 June 2009 (UTC)
The author talks about FIVE STAGES of project life cycle in the introduction but then, in the corresponding section ,even the title, describes FOUR, although the business study is present inside stage 1A.
I've promoted the business study to stage 1B, just in case. Vgiralt ( talk) 16:42, 29 August 2009 (UTC)
The Five Stages and Four stages issue is still there, does the author want to correct this. -- Beyond the stars ( talk) 21:30, 6 May 2013 (UTC)
"Phase 1: The Pre-project" section contains the following phrase: "Handling these issues at an early stage avoids problems at later stages of the project like cows."
"Cows" is either a typo, an obscure metaphor, or a term that needs to be linked/defined. As is, this statement is confusing, to say the least.
I think "dynamic systems development method" is a common name not a proper name and therefore should not be capitalized. I know it is accepted practice in the industry to capitalize terms especially when they are normally identified by acronym but in Wikipedia capitalization is used only for proper names. Joja lozzo 23:53, 13 August 2011 (UTC)
I removed a great deal of unreferenced material that paralleled the DSDM manual contents. (There is still more, but by removing all unreferenced material the article would have become virtually contentless.) The article should be about DSDM but should not be a copy of what is in the DSDM documentation. If there are sources that discuss DSDM, especially as to how it differs from other agile products, those would be a good addition to this article. However, the DSDM documentation itself is not a reliable source of information except for minor facts. LaMona ( talk) 16:40, 27 March 2016 (UTC)
Various comments have highlighted new versions - in addition, given that the method/framework is no longer referred to as Dynamic systems development method but DSDM and generally books on the matter seem to either use DSDM alone (sometimes with a version name like Atern or Agile Project Framework) or both DSDM and the original, full version; is it better to rename this article as DSDM and ensure the original name is described appropriately? Pstansbu ( talk) 10:21, 16 May 2017 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||
|
A new version was published in 2014. 1. This page needs updating with any changes (not many) 2. A significant re-positioning 'upwards' as a project management framework 'above' Scrum and positioned alongside other large corporate frameworks (e.g. PRINCE2, MSP, ITIL). — Preceding unsigned comment added by BWernham ( talk • contribs) 07:38, 3 August 2014 (UTC)
The key image referred to in the text is missing 213.86.200.19 15:14, 16 March 2006 (UTC) James@doctor-it.co.uk
What is "([The Deane], Wizdeane Corporation)" that I was finding in the article? RJFJR 16:09, 9 October 2006 (UTC)
The two diagrams in the article are both unreadable. Can someone upload clearer versions of these (assuming the copyright situation is ok, of course). Otherwise I think we should remove them from the article. Stumps 15:38, 20 November 2006 (UTC)
I agree that the diagrams are VERY DIFFICULT to read and that the original poster should realize that this gives a substantial negative impression to casual users of the entire subject. In spite of their poor quality, they should not be removed until replacements arrive. Actually, the fact that it is even possible to create illegible diagrams may mean that they are too complicated to begin with. I doubt the DSDM elders are listening though... 169.229.200.176 ( talk) 19:40, 17 April 2008 (UTC)
The W in MoSCoW is for "Won't" not "Would". It is often written as Would since people get carried away saying "could have", "should have", "would have". — Preceding unsigned comment added by 81.174.143.253 ( talk) 20:18, 17 March 2013 (UTC)
From experience I prefer the meaning "Won't have this time" (i.e. this Iteration) - it's more useful than 'Would' as it helps get agreement on what to leave out-- 81.146.43.237 16:22, 10 January 2007 (UTC) GBAC 10/1/06
I don't know if this is too much of a nit-pick or not. It seems to me that the phrase "MoSCoW approach," as it's first introduced in the "Phase 2: The Project life-cycle" section, is not actually an approach. It's a mnemonic for the categorization of requirements. And in general why relegate the definition of MoSCoW (as well as all the other "Core Techniques,") to a separate section? That's prime time stuff, part of what defines the actions in the various phases. I'd say include those techniques where they're first used, then link to the first use in the other places the technique is used. (As a side note, technique isn't the right description of MoSCoW either, I think.) As I stated below, I'm not qualified to make these edits, as someone learning about this topic from the article, but it seems like something that would improve the article. BenODen ( talk) 18:18, 30 January 2008 (UTC)
Removed the definitions of MoSCoW from this article, these were very brief and somewhat different from the definitions in the specific article. Pstansbu ( talk) 16:34, 1 May 2017 (UTC)
To cleanse this article of its buzzwords would sterilize beyond usability, so I would recommend removing only those which lay persons in a boardroom might understand. I move to supplant the word "baseline" as the first candidate, and relegate it to parenthesis. Any other candidates? N8mills ( talk) 05:50, 9 January 2008 (UTC)
Just coming by as a reader trying to learn what DSDM is all about, I concur with the concern about buzzwords. One example in is in the topic summary in the Principles section:
There are 9 underlying principles consisting of four foundations and five starting-points.
It's not clear to me that Principles means the same thing that is usually does. Are they "Principles of Design" or "Principles of Development" or what? The word principles usually needs a category to be meaningful. In addition, the section on principles doesn't describe how foundations and starting points are different. I would argue against simply removing the buzzwords and argue that turning them into terminology by defining the buzzwords instead of just dropping them as words that "any dummy should know." An encyclopedia article should define any terms that are not general knowledge for the target audience, in this case, software developers. I have no expertise to do this, but some editor of the wikipedia does. BenODen ( talk) 17:49, 30 January 2008 (UTC)
Incidentally, I guess I neglected to say that my perspective on the buzzword complaint is that it's is really about undefined jargon rather than about buzzword use. BenODen ( talk) 18:45, 30 January 2008 (UTC)
Ged Byrne ( talk) 12:22, 27 September 2011 (UTC)
It seems like for all the details given, this article doesn't actually describe how a prototype in the development section becomes an actual product to be implemented in the Implementation phase. There are certainly some things beyond the scope of an encyclopedia article, but simply implying that the prototype magically becomes part of the project without spending any time on it seems odd. A prototype is usually an incomplete implementation, a step above a proof of concept, so fleshing it out and integrating a prototype into the main product seems like a step that could take some time and should be at least mentioned in the method.
Is this vague transition from prototype to product just a weakness of this particular article on the subject or is it a general weakness of the Method? BenODen ( talk) 18:37, 30 January 2008 (UTC)
The transition from prototype to product is seen as one of the key strengths of the Method. However, it is true that this isn't reflected well in the article. I believe that part of the problem lies with the original DSDM 4.2 text.
In the above:
Would it be a good idea to end the confusion and update the whole article to only reflect DSDM Atern? — Preceding unsigned comment added by Ged Byrne ( talk • contribs) 12:13, 27 September 2011 (UTC)
Ged Byrne ( talk) 12:14, 27 September 2011 (UTC)
A user seems to have removed a HUGE amount of content, and replaced it with text which appears to be culled from the source of another site (the font tags are still present!). I suggest that this is not the proper way to edit an article, and that any changes should be worked into the existing article if at all possible, and that such large changes should not be made without discussion.
The current article is not at all encyclopedic (it reads more like marketing prose), is completely un-cited and has questionable origin - if the person who put it on Wikipedia did just take it from viewing the source on another site it may be a copyright violation displaying it here. It also suffers from a severe visual layout issue. For these reasons it must be changed.
I do not have a thorough understanding of the subject so am loathed to make such sweeping changes as to reinstate the older version of the article. Can someone who can speak authoritatively on the subject lend their expertise.
I am not the authority that this collaborator seeks, but I entirely agree with him/her. Please can someone competent revert the change which removed all the useful content! Thank-you. Katriona22 ( talk) 20:37, 8 January 2009 (UTC)
One or more portions of this article duplicated other source(s). The material was copied from: http://www.spoce.com/knowledge-base/dsdm-atern.aspx. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a license compatible with GFDL. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or printed material; such additions will be deleted. Contributors may use external websites as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. -- Moonriddengirl (talk) 13:19, 4 February 2009 (UTC) Please forgive the intervention and excuse any protocol breaches I may be making (I am new to Wikipedia editing but hopefully learning fast). I have some important and, I hope, useful points about the DSDM entry. The copyright of DSDM is owned by the not for profit DSDM Consortium. The latest version of DSDM is called DSDM Atern. This contains all of the richness of the older version represented by the material here and is free to view and free to use. DSDM Atern contains many improvements and many changes of terminology: life cycle phases, roles, principles. I would like to correct the entry here to show these current aspects and to make the entry up-to-date. This may mean removing material or putting it into historical context. The Consortium is happy to release new content under GFDL compatible license. The material is verifiable, published in hard copy and on the web. Please can anyone help me to correct the entry and add some up to date content to make this entry current and as useful as it can be. I do this in the spirit of the Wiki, not for any personal or organisational gain, but to make the entry accurate and current. With best wishes MagiciansNephew ( talk) 18:05, 12 June 2009 (UTC)
The author talks about FIVE STAGES of project life cycle in the introduction but then, in the corresponding section ,even the title, describes FOUR, although the business study is present inside stage 1A.
I've promoted the business study to stage 1B, just in case. Vgiralt ( talk) 16:42, 29 August 2009 (UTC)
The Five Stages and Four stages issue is still there, does the author want to correct this. -- Beyond the stars ( talk) 21:30, 6 May 2013 (UTC)
"Phase 1: The Pre-project" section contains the following phrase: "Handling these issues at an early stage avoids problems at later stages of the project like cows."
"Cows" is either a typo, an obscure metaphor, or a term that needs to be linked/defined. As is, this statement is confusing, to say the least.
I think "dynamic systems development method" is a common name not a proper name and therefore should not be capitalized. I know it is accepted practice in the industry to capitalize terms especially when they are normally identified by acronym but in Wikipedia capitalization is used only for proper names. Joja lozzo 23:53, 13 August 2011 (UTC)
I removed a great deal of unreferenced material that paralleled the DSDM manual contents. (There is still more, but by removing all unreferenced material the article would have become virtually contentless.) The article should be about DSDM but should not be a copy of what is in the DSDM documentation. If there are sources that discuss DSDM, especially as to how it differs from other agile products, those would be a good addition to this article. However, the DSDM documentation itself is not a reliable source of information except for minor facts. LaMona ( talk) 16:40, 27 March 2016 (UTC)
Various comments have highlighted new versions - in addition, given that the method/framework is no longer referred to as Dynamic systems development method but DSDM and generally books on the matter seem to either use DSDM alone (sometimes with a version name like Atern or Agile Project Framework) or both DSDM and the original, full version; is it better to rename this article as DSDM and ensure the original name is described appropriately? Pstansbu ( talk) 10:21, 16 May 2017 (UTC)