Agile Software Development Process Model

Agile Alliance defines 12 principles for people who want to achieve agility:

1) The top priority is to satisfy customers by delivering valuable software as soon as possible and continuously.

2) You are welcome to change your requirements even after development. Agile processes use changes to create competitive advantages for customers.

3) Work-ready software is often delivered. The delivery interval can be from several weeks to several months. The shorter the delivery interval, the better.

4) during the entire project development period, business personnel and developers must work together every day.

5) Build projects around motivated individuals. Provide them with the required environment and support, and trust them to complete their work.

6) within the team, the most effective and efficient way to transfer information is face-to-face conversations.

7) working software is the primary metric of progress.

8) agile processes promote sustainable development speed. Owners, developers, and users should maintain a long-term and stable development speed.

9) constantly focus on excellent skills and good design, and enhance agility.

10) Simple: Maximize unnecessary work.

11) Good architecture, requirements, and design come from self-organizing teams.

12) at regular intervals, the team will reflect on how to work more effectively and adjust their behaviors accordingly.

Agility can be used in any software process. The key to implementation is to design the software process as follows: allow the project team to adjust and reasonably arrange tasks, understand the variability of agile development methods, and develop plans, streamline and maintain the most basic work products, emphasize the Incremental delivery strategy, and quickly provide the customer with runable Software suitable for the product type and operating environment.

Next, we will take extreme programming (XP) as an example to introduce the agile process model.

XP uses the object-oriented method as the recommended development model. XP includes rules and practices for planning, designing, coding, and testing four framework activities. Figure 2-9 describes the XP process and identifies key concepts and tasks related to framework activities.

Planning. Planning activities start with creating a series of "Stories" that describe the necessary features and functions of the software to be developed ". Each story is written by the customer and placed on an index card. The customer identifies the weight (that is, the priority) based on the Global Business Value of the corresponding feature or function ). XP team members evaluate each story and provide cost measured by the number of development weeks. If the cost of a story exceeds three development weeks, the customer will be asked to further segment the story, re-assign the weight and calculate the cost. New stories can be written at any time.

The customer and the XP team jointly decide how to group stories and place them in the next release to be developed by the XP team. Once a basic commitment on a release version is made, the XP team will sort development stories in one of the following three ways: (1) All selected stories will be implemented as soon as possible within weeks; (2) stories of the highest value will be moved to the front of the schedule and implemented first; (3) stories of high risk will be implemented first.

After the first release of the project is released, the XP Team calculates the project speed. In short, the project speed is the number of user stories implemented in the first release. Project speed will be used to help establish the release date and schedule for subsequent releases; Determine whether there is excessive commitment to all the stories in the entire development project. In the event of excessive commitment, adjust the content of the software release version or change the final delivery date.

During the development process, the customer can add stories, change the weights of stories, and break down or remove stories. Next, the XP team reconsider all the remaining Release versions and modify the plan accordingly.

Design. The XP design strictly follows the Keep It Simple (kis) principle and uses simple rather than complex expressions. In addition, the design provides a lot of implementation principles for the story, and does not encourage additional functional design.

XP encourages the use of class-Responsibility-collaborators (CRC) cards as an effective mechanism. In the object-oriented context, consider the determination of software and CRC cards, and organize the objects and classes related to the current software increment. The CRC card is also the only design work product that is part of the XP process.

If you encounter difficulties in designing a story, XP recommends that you immediately create an executable prototype for the design to implement and evaluate the design prototype, so as to reduce the risk at the beginning of the implementation, confirm initial estimates for stories that may have design issues.

Encoding. After story development and basic design are complete, the team should not start coding directly, but develop a series of unit tests used to detect all stories released this time (software increment. Once a unit test is established, developers can focus more on the required content to pass the unit test. You do not need to add anything (Keep It Simple ). Once the code is complete, you can immediately complete the unit test and provide immediate feedback to developers.

One of the key concepts in the XP coding activity is Pair programming. XP recommends that two people develop code for a story together with one computer. This solution provides real-time problem solving and real-time quality assurance mechanisms, and allows developers to focus on the problems at hand. The roles of different members in the implementation process are slightly different. For example, one member considers the detailed Encoding implementation of a specific design, while the other member ensures that the encoding complies with specific standards and the generated code conforms to the interface design of the story.

The pair completes the integration of the developed code and other work. In some cases, such integration work is implemented by the Integration Team on a daily basis. In other cases, the peer is responsible for integration. This "continuous integration" policy helps avoid compatibility and interface problems and establish an "smoke test" environment that can detect errors early.

Test. Establishing unit tests before coding starts is a key factor in the XP method. The unit test established should use a framework that can be automatically implemented. This method supports real-time regression testing strategies after code modifications.

Once individual unit tests are organized into a "Universal Test Set", system integration and validation testing can be performed every day. This can provide continuous progress instructions for the XP team, or early warnings when a problem occurs.

The XP acceptance test, also known as the customer test, is determined by the customer and focuses on the visible and auditable system-level features and functions of the customer, the acceptance test is based on the user stories implemented in this software release.