Agile methods are groups of practices for the development of projects in IT (software design) that can be applied to various types of projects. They have in common the Agile manifesto. Written in 2001, this one embodies the term “agile” to reference multiple existing methods. Agile methods are intended to be more pragmatic than traditional methods. They involve the maximum the applicant (client) and allow greater responsiveness to requests. They aim to real customer satisfaction a priority under a development agreement.
Agile methods are based on a common (iterative, incremental and adaptive) structure (development cycle), four shared values declined in twelve common principles which derive base practices, shared or complementary.
The first agile methods that have appeared were EVO (Evolutionary Project Management) (1976), RAD (Rapid Application Development) (1991) and DSDM, the English version of RAD (1995). Several other methods, such as ASD or FDD, acknowledge their direct relationship with FDR. The three most used agile methods are now: Kanban, after the industrial method Lean, Scrum published in 2001 by Ken Schwaber and Jeff Sutherland, and XP Extreme programming method published in 1999 by Kent Beck.
A larger movement (agile management) join agile values with techniques of continuous quality improvement (particularly lean). There is a wider use of agile to the entire structure of the business.
Iterative, incremental and adaptive
The development cycle for software development began with an incremental vision called “waterfall” or “V-cycle” of the estate of deliverables to produce and validate and become more complex in accepting recoveries phases of concurrent engineering,
The iterative and incremental work cycle output back to the 1930s and 40s, with the work of Walter Shewhart and William Edwards Deming. This research is applied to IT production in the late 1950s, especially with the development of software parts under the Mercury program. Gerald Weinberg refers to a development project carried out in 1957 to Motorola, which used a similar technique to what would later eXtreme programming.
In the reality of current methods, the qualifier iterative usually covers a semi-iterative reality: the production phase is preceded by several steps such as exploring the need, design of architecture and planning.
An agile method is primarily based on iterative refinement of needs implemented in functionality in progress and even already completed. This refinement, essential to the implementation of the adaptive concept, is realized in software engineering in two ways:
- functionally, by systematic product adaptation to changing needs detected by the user during the design and construction of the product (concept of permanent user validation with RAD and emerging design concept with XP);
- technically, by regular redesign of code already produced (refactoring).
An agile method is then, possibly, incremental. When the project duration, regardless of the number of participants, exceeds ten days on average, the production of its features is performed in several steps.
The notion adaptive, in turn, requires, beyond a simple principle, the implementation of control technologies available and the evolution of a formal metric changes, before, after and during production. It follows a basic operational planning directly visible through the wall display.
An agile contract is entirely possible. It is based on the evaluation of the scope known to occur with agile technique as the consensus estimate game. This principle expressed in units of work, as the ideal days for example, a team commitment to specific goals. These objectives are the subject of the initial contract draft. The functional content can then be changed continuously and even being developed by the project owner. Each change is marked on the card user modified or terminated under development feature story. Development of reusable parts are then reintegrated into the formal evaluation of changes or new features. In this context, the team has an obligation to deliver at the end of an increment number of units of work at least equal to its nominal design speed early in the project (number of people * number of days of work on increment); the number of work unit (WU) to graphically present productivity obtained for each increment is then composed of: WU delivered total = WU delivered useful + WU delivered abandoned. This principle is then materialized in the shape of agile reporting named BurnUp chart.
Acceptance of the adaptive mode, which allows the customer to modify its requirements during the project, will result in the possibility of a variable structure. In most consistent or strategic projects the constraints must be taken into account to optimize the management of the implementation.
Translated from Wikipedia