|
In software engineering, agile software development or agile methods are low-overhead methodologies that accept that software is difficult to control. They attempt to minimize risk by ensuring that software engineers focus on smaller deliverable units, which focus on one week cycles of work, for two- to three-person teams. When larger teams are involved, the cycles can be longer, to account for the difficulties in communication.
One way in which agile software development is generally distinguished from "heavier", more process-centric methodologies, for example the waterfall model, is by its emphasis on values and principles, rather than on processes.
Typical cycles are one week or one month, and at the end of each cycle the engineers reevaluate the project priorities. Such reevaluation is a feature agile development shares with iterative development methodologies, and most modern theories of project management.
Risks and benefits of different methodologies
The benefits of agile software development for small teams working with rapidly changing requirements have been noted. Among agile software development proponents (and critics), the applicability of agile methods to larger projects is debated. Large-scale projects, with high assurance requirements, have traditionally been seen as the home-ground for plan-driven software development methodology.
The picture often painted is that agile software developments and plan-driven methodologies are polar opposites. The author of [1] suggests that these methodologies should be seen as part of a continuum of options. At one extreme are hackers who work without any methodology. At the other end are "inch-pebble" projects where the smallest detail is planned in advance.
The author of [1], suggests that the spectrum is a measure of the emphasis on plans. Further, the author suggests that what methodologies are chosen should be based upon an analysis of risk exposure.
P(L) is the probability of loss. S(L) is the size of loss. Risk exposure is RE = P(L) X S(L)
By graphing RE against time and effort invested in plans, we can find the right mix of methods to use for a given project (graph from [1]):
Each methodology has different risks. Combining an analysis of the risk allows us to determine where on the spectrum our project should lie.
An example of this: Our project could contain some core database technology that needs extensive planning to mitigate risk. It could also contain a rapidly evolving user interface where not getting a demo on the market could be costly in terms of market share.
Deciding when to use agile software development is also dependant on the values and principles that a developer wishes to be reflected in their work. Extreme Programming (XP), one of the more popular of the agile software development methodologies, is explicit in its demand for developers to follow a "code of software conduct" that transmits these values and principles to the project at-hand. In keeping with the philosophy of agile software development, there is no rigid structure defining when to use any particular feature of these approaches.
XP values In [2], Kent Beck describes the four core values of Extreme Programming as Communication, Simplicity, Feedback, and Courage. - Communication
- It is acknowledged that poor communication in software teams is one of the root causes of failures within projects – whether it be schedule slips, botched requirements, faulty development assumptions, and the like. Extreme Programming mitigates this by stressing good communication between all project stakeholders – customers, team members, and project managers (or “coaches”) – on a consistent basis. A representative from the customer should be present on site at all times to answer questions and clarify project requirements. Programmers are expected to work simultaneously in pairs, with each programmer reviewing the other's work.
- Simplicity
- From [3]: “Two of the greatest rallying cries in XP are the slogans 'Do the Simplest Thing That Could Possibly Work' and 'You Aren't Going to Need It' (known as YAGNI). Both are manifestations of the XP practice of simplicity.”
“The way YAGNI is usually described, it says that you shouldn't add any code that will only be used by a feature that is needed tomorrow. On the face of it this sounds simple. The issue comes up with such things as frameworks, reusable components, and flexible design. Such things are complicated to build. You pay an extra up-front cost to build them, in the expectation that you will gain back that cost later. This idea of building flexibility up-front is seen as a key part of effective software design.”
“However, XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let those structures grow as they are needed. If a programmer wants a Money class today that handles addition but not multiplication, then the programmer builds only addition into the Money class. Even if they are sure they'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, they'll still leave it until the next iteration.” - Feedback
- In XP, there is the idea that there should always be some running system that delivers information about itself in a reliable manner. The system and the code itself serves as an oracle to serve up feedback regarding the state of the development process [4]. Feedback serves as a catalyst for change and an indicator of a project's progress. Code refactoring is derived from this value (see Principles, below).
- Courage
- XP acknowledges that projects are ultimately people_centric. It is the ingenuity of people, and not any particular process, that cause projects to succeed. Courage also manifests itself in the features of feedback and refactoring, as described the XP principles.
XP principles Beck [2] and Tomek [5] describe 12 core XP principles. Each principle is derived from one of the 4 core values. - Planning Game
- There are no long_term strategies in an XP project. The Planning Game phase of development is performed in two parts – firstly, use-cases (also called “user stories”) are elicited from the customer. The development team performs an estimating process from which it is determined what user stories will be implemented in the next release, and delivers a short-term schedule as to when the next release of the software will be completed.
- Small Releases
- As in evolutionary development, an XP project ascribes to deliver a series of fully-functional and completely tested releases leading up to the final delivery of the product under development. This is useful for two reasons. Firstly, by keeping releases small and functional, the development team avoids the “big bang” syndrome – an attempt to integrate several large subsystems near the end of the project. “Big bangs” can often be characterized by their hectic development pace and rarely produce favorable results.
Secondly, the development team always has a functional version of the code in the hands of the customer after the first release is completed. The customer can use the releases to give feedback on the project's progress, and this can inspire additional user stories for the development team to work on in future releases. - Metaphor
- In order to make the design of the system under development as simple as possible, it becomes necessary to develop some alternative description of the system at hand. This is the concept of metaphor. A metaphor serves to inspire development and design and to provide a common vocabulary of terms amongst the system stakeholders. Oftentimes developers will find themselves using the metaphor to talk about the system, instead of discussing the system in terms of programming language constructs.
- Simplicity in Design
- The overwhelming mantra of XP is to make things as simple as possible. The only code being worked on should be the code that is absolutely necessary to implement the latest user stories, and no more than this (see YAGNI, as described previously). The drive for simplicity leads to continual refactoring of code, an operation which we describe below.
- Testing
- In each collected user story, developers will naturally find paths of programming operation – some of which model successful operations, and some which model unsuccessful operations. These paths through each story are used to generate the system test cases before any code is written, a dramatic departure from the “code-first, test-later” subscribed to by heavyweight software development practices. Tests therefore become part of the natural design of the system under consideration, instead of an afterthought. It is desirable to develop an automated testbed composed of individual tests, and no system release is permitted until it has passed all tests.
- Continual Integration
- Upon completion of some subtask within a particular user story, the implementation code is released into a shared development environment. Other programmers may refactor the code (an operation described below) and use it within the context of their own particular assigned user story under development. No code is to be released into the shared environment until it has passed its full range of applicable test cases.
- Pair Programming
- No one person codes alone in an XP project. XP explicitly rejects any coding that is not done by (at minimum) a pair of programmers working together at the same machine. One member of the pair will write code while at the same time another programmer is critiquing the work at hand, and at the same time offering insight as to the next step as well as exposing trivial defects with the code. Programmers have been shown to make less errors and better increase their working knowledge of the system under development when working with a discipline such as this.
- Collective Ownership
- Working hand-in-hand with the principle of continual integration (described above), the idea of collective ownership does away with any notion that a solo programmer (or group of programmers) bears the full burden of responsibility for any one subsystem under development. Any code in the shared development environment is open to viewing and modification, and any member of the team may work on any subsystem (provided that all applicable tests pass for that subsystem once modification is complete). The idea here is to spread the knowledge contained within the system to the entire development team.
- Refactoring
- Once it becomes apparent to the development team that the system design is becoming too complex, the code is refactored. The refactoring process is one by which the system functionality remains stationary – all tests that pass prior to refactoring should pass after refactoring is completed – but the code base becomes greatly simplified. This may involve eliminating shared code, redesigning model hierarchies and relationships, or simply renaming variables to fit a particular metaphor.
- Sustainable Pace
- XP projects are notorious for their concern with the well-being of their developers. A 40-hour work week with no overtime is rigidly adhered to, based on the belief that development teams are able to produce high-quality product when they are comfortable and not overly-exerted. This principle serves to complement the idea of both pair programming and communication amongst the development team and their customer.
- On Site Customer
- XP insists that it is not enough to have only occasional access to a customer and that a customer representative must be continuously present in the development area. This ensures that all unanticipated questions concerning the requirements can be immediately resolved and eliminates the need to produce exhaustive and definitive (and probably still incomplete and non-definitive) specifications at the beginning of the project. This also allows the customer to interact with the development and help in the evolution of the product. Having a customer on site makes it possible to minimize the time spent on preliminary planning and focus on development, and maximize feedback, thereby maximizing the value delivered to the customer.
- Shared Coding Standards
- The entire development team agrees to maintain a common set of rules concerning the maintenance and creation of new code. These standards are specific to each project, and are intended to sponsor an ethic of shared ownership and responsibility among all developers.
History Agile software development evolved in the mid 1990s as part of the reaction against high ceremony methods, like Rational Unified Process (RUP), Prince and ISO 9000. The processes originated from those methods were seen as bureaucratic, slow, demeaning, and contradicted the ways that software engineers actually work. (Side note: Whilst Capability Maturity Model (CMM) is often labelled as a high-ceremony method, this is incorrect - it is not a method, but a measure of an organisation's ability to repeat success and many agile software development methodologies such as Scrum meet criteria for CMM accreditation.)
Extreme Programming is considered the first established agile software development methodology within the United States after some common tactics popular among computer programmers. DSDM is considered the first established agile method throughout Europe and was formed by a decidedly more deliberate purpose and process. Given the popularity, the term agile software development often is used to mean Extreme Programming specifically.
The term agile methods was chosen as an improvement over the term lightweight process, which had been widely used early on. More recently, agile software development has become more commonly used.
Reducing weight In general, agile software development imposes as little overhead as possible in the form of rationale, justification, documentation, reporting, meetings, and permission. Replacing before-the-fact permissions with after-the-fact forgiveness is one of the key elements of reducing overhead. ("To ask permission is to seek denial." — Scott McNeally)
The WikiWiki (of which Wikipedia is an example) demonstrates this by permitting anyone to edit an article - and anyone to quickly undo changes or raise objections. Not surprisingly, the creators of Extreme Programming are also the creators of the first Wiki software.
Agile software development methodologies include
Examples of similar concepts beyond the realm of software include
The case against XP and agile software development The effectiveness of the development methodology associated with Extreme Programming and similar agile software development methodologies has been at the center of a large_scale debate within the software engineering community. The lyrics below demonstrates one author's displeasure with some of the practices of Extreme Programming:
Imagine (with apologies to John Lennon)
Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin' for the sky
Imagine all the people, coding for today
Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand
You may say I'm an extremer but I'm not the only one
I hope someday you'll join us and make coding lots more fun.
Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand
You may say I'm an extremer, but I'm not the only one
I hope someday you'll join us and make coding lots more fun.[6]
The above passage frames the context of the debate perfectly: critics charge that a lightweight development environment such as XP fails to provide an adequate level of structure and necessary documentation. In [6], the authors go on to demonstrate the inadequacies of XP applied to large scale projects by detailing the failures of the C3 (a custom payroll system designed for the Chrysler Corporation) project.
C3 was one of the first large_scale projects developed using XP practices which also featured several of the principals involved in the creation of XP – including Kent Beck – as project managers. The C3 project was a failure. After numerous schedule slips and millions of dollars of overspending, C3 was eventually canceled and delivered with minimal completeness and functionality. A system that was originally intended to serve the payroll needs of the entire company only ended up serving a few thousand individuals. The authors of [6] claim that such a scenario occurs regularly in XP projects.
Another difficulty with embracing a lightweight methodology such as XP is the needed amount of change to effectively adopt the practices, a scenario which eventually doomed the C3 project. When cornered on this point, proponents of XP claim that failures in these projects are simply not following all of the core values and principles described by the methodology [6].
References - [1] Boehm, Barry, Get Ready for Agile Methods with Care, IEEE Computer, pp. 64_69, January 2002.
- [2] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison_Wesley, Boston. 1999.
- [3] Fowler, Martin. Is Design Dead? Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison_Wesley, Boston. 2001.
- [4] Riehle, David. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison_Wesley, Boston. 2001.
- [5] Tomek, Ian. What I Learned Teaching XP. http://www.whysmalltalk.com/articles/tomek/teachingxp.htm
- [6] M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003.
See also
External links - Ward Cunningham's website, Extreme Programming (http://www.c2.com/cgi/wiki?ExtremeProgramming), for more information on this and related topics
- Ron Jeffries web-mag XProgramming.com - an Extreme Programming Resource (http://www.xprogramming.com/)
- Matt Stephens website SoftwareReality.com - a critical eye on agile development (http://www.softwarereality.com/)
- ExtremeProgramming.org (http://www.extremeprogramming.org/)
- Manifesto for Agile Software Development (http://www.agileManifesto.org)
- The Agile Alliance (http://www.agilealliance.org)
- the Agile Data method (http://www.agiledata.org/)
- VersionOne (http://www.versionone.net/) - Agile Project Management
- DSDM Consortium (http://na.dsdm.org/) - Business Centered Agile Development Framework
|
Feeds |
Contact