Index: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Home > Agile software development
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 they reevaluate the project priorities - a feature it shares with iterative development methodologies, and most modern theories of project management.
1 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 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.
2 XP values
In [2], 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 I want a Money class today that handles addition but not multiplication, then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'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.
Read more »