Talk:Agile software development
From Wikipedia, the free encyclopedia
[edit] Critical Points To Add
Agile methods promote systems having implemented and tested source code. Costs after delivery are ignored since Agile processes produce no real business process requirements, no technical documentation and no data models. Agile is well suited to short lifespan (<2 years) systems that are not updated or maintained. This is shown in Agile's difficulty in dealing with legacy data and legacy databases as Agile assumes the development team does not need to know and research (i.e., develop business rules, requirements or data models) legacy database systems. —Preceding unsigned comment added by 98.197.208.99 (talk) 21:33, 10 February 2008 (UTC)
[edit] XP, Scrum, Crystal, etc. are Agile Methods
The History sections says: "Methodologies similar to Agile created prior to 2000—include Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995)." However, according to p. 396 of Sommerville's Software Engineering textbook (reference 7 in the article), these methodologies are different types of agile methods. Will someone confirm this and make the change?
[edit] Old posts
Any documentation to the success of the 2nd, 3rd, ... commercial release of agile software developed systems would greatly help as the current article touts agile software methodology as an effective way to deliver complete working software without any evidence to back up that claimed advantage. Furthermore, documentation to the cost of maintaining an agile methodology developed softare system would help since close to 3/4ths of the cost of a piece of softare is after it is released.
Link 10 doesnt work and archive.org doesnt have a copy of it and its not even listed at the references list at the bottom of the page. www.hacknot.com is apparently a mystery lost to the mists of ancient internet time.
This is an unnecessay page - Wikipedia is not an instruction manual. We don't have, say, When to use a riding mower rather than push mower or When to speak American English. The basic extreme programming page is more than sufficient, although it may need work or expansion. - DavidWBrooks 20:12, 6 May 2004 (UTC)
oh bollcks
-
- Checkout "Waterfall model", "Moore's Law", etc. and get back to me when you get it. The page is far more than necessary. In fact Wikipedia is a primary source for me in keeping up with changes to technical terminology. In fact you could look up Riding Mower and Push Mower here and learn something. wjbean (UTC)
This page now includes the text formerly at Agile Methods. I believe the XP values and XP principles sections should be moved to the Extreme Programming page, but I'm to scared of trying to merge the related footnote references with the extensive list of references on the XP page. Niteowlneils 02:18, 21 Jul 2004 (UTC)
This page is, as mentioned, unnecessary. In addition, it's not neutral. The author covered up his tracks pretty well, but it's still quite obvious he doesn't like XP. --jae 04:08, Dec 29, 2004 (UTC)
-
- Why is it unnecessary? If you are going to knock the article at least give a substantive reason for knocking it. wjbean
[edit] XP != Agile
This page is a great description of Agile programming. XP and Agile are two similar, but distinct approaches to software development. They both exist in the real world and they both should be reflected in the Wikipedia.
- Well I think that this is not whole truth. XP is just one of the agile methodologies. Agile software development can be an wikipedia category as well.
[edit] Song lyrics
I agree that the page needs to stay - however, what's with the parody song lyrics here? They shed no light on the subject and don't look very professional. (More "joke".)
[edit] Peer review requested for waterfall model.
Hi, I've just requested peer review for waterfall model. I'd really appreciate if some people could review the changes I've made. Thanks. :) GeorgeBills 15:05, 17 November 2005 (UTC)
[edit] Agile vs Iterative-Incremental
Well, I think that all agile methodologies are just a subset of iterative-incremental models. In the section Ag. vs. I-I two differences are mentioned:
- time period of increments is measured in weeks -- but Iterative-Incremental model does not prescribe increments length,
- work is performed in a highly collaborative manner -- again, in the I-I model you are free to use any of the other methodologies when working on one increment, from the waterfall approach to a total chaos.
So, agile development is, let's call it, an "instance of I-I model" defined by its paramaters (increment length, increment development process, ...).
What is your opinion?
--Ondrejsv 10:29, 29 May 2006 (UTC)
- I think that there are fundamental differences, and they are in the perspective of the values and principles. The iterative nature of delivery is merly an mechanism of providing it. It could be copied from iterative methodologies, but it isn't so important as is, for Agile. The agile is a framework for all lightweight methodologies, as they respect values and principles fom the manifesto. - Littlesal 20:47, 24 November 2006 (UTC)
[edit] Agile Software Development vs. Agile Unified process
What is the relation between Agile software development and Agile Unified Process ?!!!
"Both lightweight and heavy-weight methodologies may still lead to this breakdown as the user(s) attempts to facilitate within social/political environments within organizations. The probability of this breakdown can be directly correlated to the degree of processes inhibiting the risk of user(s) deviating from the organization standard, however at the cost of efficiency opportunities." This is quite possibly the most incomprehensible paragraph I've ever read. To whoever wrote it: kudos, you've achieved an unprecedented level of obfuscation. --IQpierce 19:25, 26 June 2006 (UTC)
[edit] some articles do need to be combined for these subjects
The current group of related articles to agile software development answered my questions, but they do need to be refactored. Mathiastck 17:31, 3 August 2006 (UTC)
[edit] Merge from Adaptation of Agile Methods
Merge from Adaptation of Agile Methods was suggested in April 2006. Since this has not been disputed, I intend to merge that article shortly. The result will still need cleaning up, but it will be in one place.
Boson 15:29, 27 August 2006 (UTC) Have now performed the merge. I hope that meets with approval. More refactoring probably needed as well as general cleanup and condensing.
Boson 16:50, 27 August 2006 (UTC)
[edit] Condense PRINCE2 discussion
The information on PRINCE2 appears to me to be much too detailled, going in the direction of a proof of concept or feasability study rather than an encyclopedia article. I would characterize it as an argument for using PRINCE2 for the management of agile software development and a lengthy demonstration by the author of one possible way of doing that. I don't, personally, disagree with the content, but I would delete the PRINCE2 sections and replace the section Agile methods and project management with something on the lines of the following:
- Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally not comprehensive support (footnote citing Abrahamsson et al., 2003). PRINCE2 has been suggested as a suitable, complementary project management system. -- adding a footnote citing Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf
and quoting
- PRINCE2 (Projects in Controlled Environments) . . . is a project management method that was specifically designed to be generic and independent of any particular project type or development method. As with DSDM,its use is dramatically on the increase in both the public and private sectors. As a development method and a project management method, the two should be complementary. Some have perceived the dynamic emphasis of DSDM and the control emphasis of PRINCE2 to be in conflict. However, this is not the case. When DSDM was being developed, those involved had PRINCE firmly in mind. This is reflected in a number of the DSDM principles and techniques – for example, product-based planning, the involved partnership of users and developers, and the strong emphasis on the underlying business case.
I thought I should propose it here before deleting a rather large chunk of text.
Boson 21:09, 30 August 2006 (UTC)
Have now done this and also tried to fix the citations. This still needs work, but I think the missing-citations problem is fixed; so I have removed the citations required template. Boson 23:06, 1 September 2006 (UTC)
I do disagree with the content here. I propose removing the citation of PRINCE2 altogether. The PRINCE2 methodology IS clearly in conflict with the philosophy of Agile - it is a documentation intensive, big phase methodology, and it is diametrically opposite to Agile. Although PRINCE2 is purportedly designed to be scaled according to the project's needs, the core philosophy is about "big-bang" delivery, and hence its application in an Agile project would result in what is known as PINO: PRINCE in Name Only. I would expect that both PRINCE2 and Agile practitioners would agree with this; on the whole, each probably believe that the strength of their approach is their rejection of each other. (This does not mean that they two practises exclude each other's techniques, just that their core philosophy is at odds.) —The preceding unsigned comment was added by 62.128.215.24 (talk • contribs) 2007-03-13.
- I have now updated the link to agilealliance.org in the reference, which had become invalid owing to a reorganization of that Web site. The DSDM consortium seem to be pushing the ability to combine DSDM with PRINCE2, which is why I was loth to remove PRINCE2 completely. The reason may be "political" but it does seem to be a valid POV. I would not oppose its deletion but would welcome more input from the UK, where PRINCE2 may be a de facto standard(?). It would be nice to have more information on project management. The DSDM article could probably do with a rework as well. --Boson 22:36, 13 March 2007 (UTC)
[edit] Merge from Manifesto for Agile Software Development
Supported. --Boson 23:03, 9 September 2006 (UTC)
Completed. Rich257 21:29, 19 September 2006 (UTC)
[edit] Industrial extreme programming
It really promises advance of XP. I added it in list as I saw it on cutter consortium site. Maybe it deserves an artical of its own. What do you think? Could you help me build it, if you want to help go to my user_talk page --Littlesal 21:53, 8 November 2006 (UTC)
[edit] Measuring Agility
This whole section appears to have been added by the author of the presentation that has been cited, and so by definition it presumably constitutes original research. Does the section really merit inclusion in this article?--Michig 14:45, 7 December 2006 (UTC)
[edit] Merge with Post-Agilism
Editors of this article- I've added the content from Post-Agilism into the eponymous section of this article. I'm not knowledgeable with this subject, so I prefer not to make any major edits here. For more context on the move, see Talk:Post-Agilism and Wikipedia:Articles for deletion/Post-Agilism. Thanks, A Train take the 17:47, 16 December 2006 (UTC)
[edit] thanks all
Notwithstanding the work you're obviously engaged in here, I found this article particularly helpful! Thanks to everyone for your efforts so far! HiTrish 19:04, 4 January 2007 (UTC)
-
- I second that! Wjbean
[edit] Questionable pargraph removed
I removed the paragraph from the end of the "Principles behind agile methods ..." section. I think it is biased, not very encyclopedic in tone and makes unsupported assertions. Maybe the original author would like to try to fix it up. Here it is (Peashy 14:29, 15 February 2007 (UTC)):
One fundamental difference of an iterative/agile approach is the recognition that specs are typically built in a vacuum of theory prior to real-world experience. An iterative/agile development cycle forces the real world into the picture (thus "working code"), whereas the document driven process puts far too much pressure on the document author(s) to get it right the first time, which cannot be done. This is not an argument against documentation - just a recognition of documentation as a process tool and not the end goal. Further, the agile approach draws developers into the problem definition process, so that they are actively engaged in the solution. This active engagement also allows them to introduce new technology accelerators that the spec process would never have introduced.
[edit] Agile Developement
Thi site cane be more useful if practical examples are provided or case studies are provided.
C.A. Biplab Dutta Ray —The preceding unsigned comment was added by 59.95.173.212 (talk) 09:43, 14 April 2007 (UTC).
- That sounds to me like a good idea for wikibooks:Computing department. (Wikipedia is not intended for textbooks or instruction manuals).--Boson 10:23, 14 April 2007 (UTC)
Ok. All fame and craze about Agile development provides far less thinking on the processes. I think the people who developed this methodology are averse to the idea of so-called processes coming under ISO9000, CMM etc. The argument about Agile is that it is fast. That is absolutely not true. Coz, except for 2x2 or 2+2, nothing is fast in this world. You have to do good planning, thinking and more planning before giving a solid output. Where is Agile supporting these characteristics. I am not sure. For sure it is more viable to implement to those products where user interface is important and requirements are not rigid.
- I respectfully disagree. Agile Software development is about a mind-set of planning for and embracing change. Once the developers have a mindset that the requirements have flexibility, they change their approaches so that as many things on the project are as loosely coupled and configurable as possible. They use design patterns to ensure that, when the boss changes things at 11:59 in the project, it minimizes the impact of this change. That is the goal - to meet change with a smile instead of a sigh. That smile is possible by being smart and embracing the reality that things change because we cannot truly know everything up-front. Dprust 18:26, 14 May 2007 (UTC)
[edit] Graphical Model
Could someone come up with a loose graphical model of Agile Software Development; similar to the Waterfall_model.png? If someone can give a verbal example I can come up with something. Thanks Wjbean
- Unless somebody comes up with a graphic from a published source, the risk is that the answer to your question violates No Original Research. Iterator12n 20:24, 11 June 2007 (UTC)
[edit] Clarification
I clarified the first paragraph to include the goal of Agile Software engineering. It did not state the goal, so it was just a "framework", and learning that goal took a lot more reading later. Dprust 18:28, 14 May 2007 (UTC)
[edit] Question
Will there be time to learn and implement in the Agile development?
[edit] Additional content for Criticism section
I've read quite a few ACM and IEEE articles concerning the criticism of agile methods with respect to application security. For example, because there is no big up-front design, security is often addressed along the way rather than near the beginning. Would mentioning such issues (with references to the ACM/IEEE articles) be appropriate here? Gmazeroff 14:12, 11 June 2007 (UTC) GMazeroff
- I think so - with the references, as you say. By the way, it is my experience that addressing security needs up front doesn't necessarily lead to better results than addressing them in the course of developing the successive iterations. It seems whatever you already know "for sure" should be addressed up-front, and whatever the customer and the developer learn in the course of developing and using the iterations can be addressed in the iterations still to come - including changes in the things they thought they knew "for sure." Iterator12n 19:39, 11 June 2007 (UTC)
203.57.241.67 03:27, 14 June 2007 (UTC) In reading this for the first time I can't help but view it as a sales pitch for using an Agile methodology rather than a balanced discussion of what it is and its pros and cons. While there is a "Criticisms" section, the criticisms mentioned are very quickly rebutted.
- Like the above reader I am reading this for the first time and the article represents *far* from a NPOV. Another wikiarticle ruined by a lack of objectivity. —Preceding unsigned comment added by 212.69.54.14 (talk) 14:53, 16 October 2007 (UTC)
[edit] This article *really* needs work.
As a programmer with over 15 years of experience, I feel that this article fails to clearly describe a substantive "conceptual framework" mostly due to poor writing. The first sentence, as prominent as it could possibly be, is nearly useless. All software sporting a version stamp beyond 1.0 experiences development iterations. And, when it refers to 'the project' what project is it referring to? Shouldn't it say 'a software project' instead?
Some other things I'm wondering:
- What kind of risk is being minimized by developing software in short amounts of time? Seems to me that various risks are compounded when software is rushed out the door: bugs, security, etc.
- What is the scope of software project that gets delivered in "weeks, not months"?? Are we talking about a new OS for big iron? I doubt it. Are we talking about web wiki software written in PHP? perhaps. Or maybe a form to upload one picture on my niece's blog? I hope not. This repeated use of an arbitrary time frame in the discussion of such a general concept suggests the author completely lacks any understanding of the variability in scope exhibited by different software projects. It sounds like the author has been brainwashed by some motivational disciple of the 'agile programming' movement.
- the section titled "Contrasted with other iterative development methods" is especially poor for several reasons:
- every software development method would like to build releasable software in a short time period. also, aren't we *contrasting* things here? this is listed as a similarity. - that stupid 'weeks not months' bit. - other forms of software aren't 'highly collaborative' ?
This article is lengthy and confused and sounds more like it was written by a poorly informed apologist for the movement rather than an objective author assessing a distinct development approach with its own unique earmarks. It should be completely rewritten.
- I agree with you (whoever you are). it's all over the place at the mo. It (the article) needs a cold-blooded and knowledgable editor. Matt Whyndham (talk) 17:25, 3 March 2008 (UTC)
If somebody had the time (a lot of time) he/she could analyze the article and make it into a case study: The Anatomy of a Real Bad Article, and the Many, Many Reasons it got that Way. If you had to make up a bad article, it wouldn’t be as bad as this one. A natural! For one thing, an article like this one exposes the subject as a fake. Happy for them, the promoters don't see it, they are blinded by vanity. Unbeatablevalue (talk) 22:28, 3 March 2008 (UTC)
- Agile software development goes back to the time when English lit. majors took over software engineering. In the run up to Y2K, everybody with a half a brain was hired to swell the ranks. Once safely into the new millennium, after the consultancy firms had had their run, these people were looking for a new job. They could still write stories.... so here it came, garbage trucks of books about flavor-of-the-month agile development. Agile this or that is mostly a publishing event. The article provides an archeological record of that unfortunate course of history. Move on people, there’s nothing to see here. Unbeatablevalue (talk) 23:03, 3 March 2008 (UTC)
- Whether or not it is real is irrelevant, as long as the article documenting its significance in the wider world is encyclopedic and well-referenced. Heck, we have an entire set of articles on creationism. ~ Jafet (spam) 19:51, 16 April 2008 (UTC)
Isn't agile about other processes besides software development?131.107.0.73 (talk) 23:58, 9 June 2008 (UTC)
[edit] Citation needed
This paragraph:
The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method which can easily be tailored into agile processes such as XP.
needs a citation. Needs to be written in a more encyclopedic way.
- Is it really easy to tailor into the agile process? says who?
- Where are the criticisms addressed? —Preceding unsigned comment added by 216.241.162.100 (talk) 19:17, 7 January 2008 (UTC)
[edit] External Links
Some of the links removed as spam weren't IMHO. For example the collection of book reviews here: http://www.techbookreport.com/SoftwareIndex.html seems to me a useful addition to this article. Books have played an important part in propagating Agile ideas, and there are more books published on the subject everyday. The link provided a set of reviews of many of these - making it a useful resource. Similarly the list of key Agile techniques from the same site was also useful - there are lots of readers who aren't interested in the philosphical underpinnings of Agile, what they want is a succinct list of practises (such as this: http://www.techbookreport.com/tutorials/agile-30-secs.html). Looking back through the history of this article the link to the book reviews seems to have been here for a long time - so why only the recent removal? —Preceding unsigned comment added by 217.205.90.120 (talk) 17:24, 3 December 2007 (UTC)
- TechBookReport fails WP:EL and WP:PG on a number of points. For instance, as its About page explains, TBR accepts reviews from publishers, hardly a neutral party. Cheers. -- Iterator12n Talk 18:51, 3 December 2007 (UTC)
-
- You're being very unfair - on the about page it's stated that publishers can suggest books for review. That's not the same as accepting reviews from publishers. The whole point of the site is that the book reviews are independent. —Preceding unsigned comment added by 86.30.116.196 (talk) 22:37, 3 December 2007 (UTC)
-
- Here's a quote from that about page: If you would like to propose a book for review please send an email and, if the title is considered suitable, arrangements will be made to route the book to an appropriate reviewer. That's not the same as accepting reviews from publishers. —Preceding unsigned comment added by 217.205.90.120 (talk) 10:39, 4 December 2007 (UTC)
Why only recently? Uhhh, did I somewhere miss a Wikipedia statute of limitations? 70.126.40.85 19:42, 3 December 2007 (UTC)