Agile agile method development methodology

Agile development methodology (eng. Agile software development , agile methods ) - a series of software development approaches focused on the use of iterative development, dynamic formation of requirements and ensuring their implementation as a result of constant interaction within the self-organizing working groups consisting of specialists in various fields ^{[ source not specified 309 days ]} . There are several methods related to the class of flexible development methodologies, in particular, extreme programming, DSDM, Scrum, FDD.

It is used as an effective practice of organizing the work of small groups (which do homogeneous creative work) in combination with their management by the combined (liberal and democratic) method.

Most of the flexible methodologies are aimed at minimizing risks by reducing development to a series of short cycles called iterations, which usually last two to three weeks. Each iteration itself looks like a software project in miniature and includes all the tasks necessary for issuing a mini-increment in functionality: planning, requirements analysis, design, programming, testing and documentation. Although a separate iteration is usually not sufficient to release a new version of a product, it is assumed that a flexible software project is ready for release at the end of each iteration. At the end of each iteration, the team reevaluates the development priorities.

Agile methods emphasize direct face-to-face communication. Most agile teams are located in the same office, sometimes called English. bullpen . At a minimum, it includes “customers” (the product owner is the customer or his authorized representative defining the requirements for the product; this role can be performed by the project manager, business analyst or client). The office may also include testers, interface designers, technical writers, and managers.

The main metric of agile methods is the work product. By preferring direct communication, agile methods reduce the amount of written documentation compared to other methods. This led to the criticism of these methods as undisciplined.

History [edit]

In February 2001, the Manifesto of a Flexible Software Development Methodology was released in Utah, USA. It was an alternative to documentation-driven, “heavyweight” software development practices, such as the “waterfall method,” which was the gold standard for development at the time. This manifesto was approved and signed by representatives of the methodologies: Extreme Programming, Crystal Clear, DSDM, Feature Driving Development, Scrum, Adaptive Software Development, Pragmatic Programming. A flexible development methodology was used by many companies even before the adoption of the manifesto, however, it was after this event that Agile development entered the masses.

Principles [edit]

Agile is a family of development processes, not the only approach in software development, and is defined by Agile Manifesto ^[1] . Agile does not include practices, but defines the values ​​and principles that guide successful teams.

Agile Manifesto was designed and adopted on February 11-13, 2001 at The Lodge at Snowbird in the mountains of Utah. The manifesto was signed by representatives of the following methodologies: Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming. Agile Manifesto contains 4 basic ideas and 12 principles. It is noteworthy that Agile Manifesto does not contain practical advice.

Key ideas:

• people and interaction are more important than processes and tools;
• a working product is more important than comprehensive documentation;
• cooperation with the customer is more important than agreeing the terms of the contract;
• willingness to change is more important than following the original plan.

Principles explained by Agile Manifesto ^[2] :

• customer satisfaction with the early and uninterrupted supply of valuable software;
• welcome changes in requirements even at the end of development (this can increase the competitiveness of the product received);
• frequent delivery of working software (every month or week or more often);
• close, daily customer communication with developers throughout the project;
• The project deals with motivated individuals who are provided with the right working conditions, support and trust;
• The recommended method of transmitting information is face-to-face conversation;
• working software is the best measure of progress;
• Sponsors, developers and users should be able to maintain a constant pace for an indefinite period;
• constant focus on technical excellence and user-friendly design;
• simplicity is the art of not doing extra work;
• the best technical requirements, design and architecture are obtained from the self-organized team;
• constant adaptation to changing circumstances.

Criticism [edit]

One of the recurring points of criticism: in the agile approach, the creation of a plan (“roadmap”) for product development is often neglected, as well as requirements management, during which such a “map” is formed. A flexible approach to requirements management does not imply far-reaching plans (in fact, requirements management simply does not exist in this methodology), but implies the ability of the customer to suddenly and unexpectedly at the end of each iteration set new requirements that often contradict the architecture of the product already created and delivered. This sometimes leads to catastrophic "rummaging" with mass refactoring and alterations at almost every iteration.

In addition, it is believed that working in agile motivates developers to solve all incoming tasks in the simplest and fastest possible way, while often ignoring the correctness of the code in terms of the requirements of the underlying platform (the approach “works, okay”, it does not take into account that can stop working at the slightest change, or it can give defects that are hard to reproduce after real deployment at the client). This leads to a decrease in the quality of the product and the accumulation of defects.

Methodologies [edit]

There are methodologies that adhere to the values ​​and principles stated in Agile Manifesto, some of them are:

• Agile Modeling ( English ) - a set of concepts, principles and techniques (practices) that allow you to quickly and easily perform modeling and documentation in software development projects. Does not include detailed design instructions, does not contain descriptions how to build diagrams in UML. Main goal: effective modeling and documentation; but does not cover programming and testing, does not include issues of project management, deployment and maintenance of the system. However, it includes verification of the model code ^[3] .
• The Agile Unified Process ( English ) (AUP) is a simplified version of the IBM Rational Unified Process (RUP) developed by Scott Ambler, which describes a simple and understandable approximation (model) for creating software for business applications.
• Agile Data Method ( English ) - a group of iterative software development methods in which requirements and solutions are achieved within the framework of cooperation between different cross-functional teams.
• DSDM is based on the Rapid Application Development (RAD) concept. It is an iterative and incremental approach that emphasizes continued participation in the user / consumer process.
• Essential Unified Process (EssUP).
• Extreme programming (English Extreme programming , XP).
• Feature driven development (FDD) is a function-oriented development. The concept of a function or property used in FDD is quite close to the concept of use case used in RUP, a significant difference is an additional restriction: “each function must be implemented in no more than two weeks”. That is, if the usage scenario is small enough, it can be considered a function. If it is large, then it should be divided into several relatively independent functions.
• Getting Real is an iterative approach without functional specifications used for web applications. In this method, the program interface is first developed, and then its functional part.
• OpenUP is an iterative-incremental method of software development. Positioned as a light and flexible version of RUP. OpenUP divides the project life cycle into four phases: the initial phase, the refinement, design, and transfer phases. The project life cycle ensures that stakeholders and team members get to know and make points throughout the project. This allows you to effectively control the situation and make decisions about the acceptability of the results in time. The project plan defines the life cycle, and the end result is the final application.
• Scrum sets the rules for managing the development process and allows the use of existing coding practices, adjusting requirements or making tactical changes. Using this methodology makes it possible to identify and eliminate deviations from the desired result at earlier stages of software product development.
• Lean software development (eng. Lean software development ) uses approaches from the concept of lean manufacturing.