CSC/ECE 517 Fall 2007/wiki3 10 tm: Difference between revisions
No edit summary |
No edit summary |
||
Line 16: | Line 16: | ||
requires too much cultural change to adopt | requires too much cultural change to adopt | ||
can lead to more difficult contractual negotiations | can lead to more difficult contractual negotiations | ||
===Individuals and Interactions Over processes and tools=== | |||
===Working software Over comprehensive documentation=== | |||
===Customer collaboration Over contract negotiation=== | |||
===Responding to change Over following a plan=== | |||
==Agile Methodologies' Values== | ==Agile Methodologies' Values== | ||
Line 31: | Line 39: | ||
==External Links by Side== | ==External Links by Side== | ||
===Arguments *Against* | ===Arguments *Against* XP=== | ||
*[http://www.amazon.co.uk/Extreme-Programming-Refactored-Case-Against/dp/1590590961 "Extreme Programming Refactored: The Case Against XP "] <br> | *[http://www.amazon.co.uk/Extreme-Programming-Refactored-Case-Against/dp/1590590961 "Extreme Programming Refactored: The Case Against XP "] <br> | ||
*[http://www.amazon.com/exec/obidos/ASIN/0201844575/ref=nosim/armaties "Questioning Extreme Programming"] <br> | *[http://www.amazon.com/exec/obidos/ASIN/0201844575/ref=nosim/armaties "Questioning Extreme Programming"] <br> | ||
Line 43: | Line 51: | ||
*[http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp "The Case Against Extreme Programming"]<br> | *[http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp "The Case Against Extreme Programming"]<br> | ||
===Arguments *Support* | ===Arguments *Support* XP=== | ||
*[http://portal.acm.org/citation.cfm?id=962352&coll=GUIDE&dl=GUIDE&CFID=42425829&CFTOKEN=88673594 "Are agile methods good for design?"] <br> | *[http://portal.acm.org/citation.cfm?id=962352&coll=GUIDE&dl=GUIDE&CFID=42425829&CFTOKEN=88673594 "Are agile methods good for design?"] <br> | ||
===Success Stories=== | ===Success Stories=== | ||
* [http://portal.acm.org/citation.cfm?id=999442&coll=Portal&dl=GUIDE&CFID=42448435&CFTOKEN=54833985 "Breaking the Ice for Agile Development of Embedded Software: An Industry Experience Report"] <br> | * [http://portal.acm.org/citation.cfm?id=999442&coll=Portal&dl=GUIDE&CFID=42448435&CFTOKEN=54833985 "Breaking the Ice for Agile Development of Embedded Software: An Industry Experience Report"] <br> | ||
* [http://portal.acm.org/citation.cfm?id=1297967&coll=Portal&dl=GUIDE&CFID=42448435&CFTOKEN=54833985 "Agile enterprise software development using domain-driven design and test first"]<br> | * [http://portal.acm.org/citation.cfm?id=1297967&coll=Portal&dl=GUIDE&CFID=42448435&CFTOKEN=54833985 "Agile enterprise software development using domain-driven design and test first"]<br> |
Revision as of 00:13, 14 November 2007
The Agile debate. Perhaps the most prominent controversy in o-o design today is whether it is possible to do a robust design with as little advance planning as agile methodologies recommend. Research this issue, on the Web and in the ACM DL, and report (fairly) on the major arguments of both sides, and on the evidence for both positions.
What is 'Agile Methodology'?
Agile Methodology was introduced as an iterative approach for developing software as a counter to waterfall approach. Where the five main phases of waterfall (requirement, design, codeing, integration, testing) are practiced through every iteration, where iteration take 1-2 week(s). Moreover, it put more practices in term of coding and testing, such as: Test drivin design; Unit testing; Refactoring; Pair programming; Collective ownership; Simple design; Metaphor; Continuous integration; and Customer access.
Many Agile methodologies are introduced in the last decade (XP, Scrum, DSDM, FDD, Lean, Adaptive, Crystal). It would be very difficult to introduce every aspect of these methodology in this wiki. That is why current wiki will concentrate in the most popular methodology XP (Extreme Programming).
Comparison Basis for Robust Design
A comparison between Agile methodologies and Waterfall methodology is found to be a little out of scope, as it is already recognized the advantages of iterative methodologies to capture the requirement and generate better softwares. That is why the current wiki will concentrate to compare with other iterative methods, such as RUP (Rational Unified Process). RUP share many of Agile's practices such as Unit testing, Metaphor, and Continuous integration. There is no depate about the benefits of previous practices for design, proparely that is why it is included in most of new processes. Other practices such as Simple design, Collective ownership, Pair programming, and Refactoring which represent a minor practices in XP, although can be immegrated to RUP is discussed. While, other features that are unique in XP as Customer access, early coding and simple design and refactoring is disscussed more.
In the current wiki we will try to test the Agile Manifesto and its related practices relative to design quality. These found to be the best basis as it provide the basis Agile methodologies trying to establish over other iterative methods.
lack of structure and necessary documentation
only works with senior-level developers
incorporates insufficient software design
requires too much cultural change to adopt
can lead to more difficult contractual negotiations
Individuals and Interactions Over processes and tools
Working software Over comprehensive documentation
Customer collaboration Over contract negotiation
Responding to change Over following a plan
Agile Methodologies' Values
Previous practices were introduced to achieve certain values (Communication, Feedback, Courage, Simplicity, Respect). It is true that these practices will help to provide the best environement for these values to exist. Neverthless, many of these practices acquire the existance of these values in the project, the company, the manegment, the individuals, and moreover the customer. Certain enough these values represent a moral and professional values that should exist in every social and individual system, neverthless we recognize there variation in every system. Moreover, many of these values might be out of the control as simplicity of the project or the courage of the customer. The author think that is why Agile approach will give even a better results in different area such as R&D or education, where these values exist.
Conclusion
This wiki is intended to be a Guide for Principle of Least Astonishment. It provides many links to online sources that explains the topic simply with easy-to-understand examples, and/or gives an idea where this principle can be used in real-life. These links should be helpful for the ones who want to learn more on this topic or understand the topic in more detail.
This principle can be used in many different disciplines for a universal useful solution for good designs. But it should be taken into consideration that the principle goes parallel with common sense, although it may not go with the convention.
Refrences
External Links by Side
Arguments *Against* XP
- "Extreme Programming Refactored: The Case Against XP "
- "Questioning Extreme Programming"
- "Extreme Programming vs. Interaction Design"
- "Towards Extreme(ly) Usable Software"
- "The Case Against Extreme Programming"
- "The Agile Method and Other Fairly Tales", *.PDF
- "Kevin Brady Blog"
- "Opinion: Extreme Programming Is Evil"
- "Xp Critique"
- "The Case Against Extreme Programming"
Arguments *Support* XP
Success Stories
- "Breaking the Ice for Agile Development of Embedded Software: An Industry Experience Report"
- "Agile enterprise software development using domain-driven design and test first"
External Links by Field
Programming
Education
- "Extreme Learning"
- "A cross-program investigation of students' perceptions of agile methods"
- "eXtreme Programming at universities: an educational perspective"