Agile outsourcing project series 4: rational selection of quality management level (1)

Document directory

• Quality Control
• Agile Quality Control

The fourth article in the agile outsourcing project series (topic directory ).

Industry Problems

Cmme has not been on fire recently. One of the reasons is that SEI has discovered that many companies in China and India are making fake assessments, especially high-level assessments. To this end, SEI has been reviewed at level 4 or above.

Why are so many enterprises scrambling to compete for a higher level? I want to prove my high quality.

In software outsourcing, or project development (rather than product development), the progress, quality, cost, and demand factors may have limited final effects, however, their investment may be unlimited, but every factor operates in a log curve. Even if you invest 10 times of manpower and material resources, it only doubles.

Therefore, before investing, you should ask yourself: Which is my ultimate goal?

In the field of software outsourcing or project development, cost is the ultimate goal.

BecauseThe ultimate goal of outsourcing or project is to tradeIt is a process of purchasing manpower with money. If the cost exceeds the contract amount, no matter the progress, quality, and needs, the essential goal of the transaction has been hurt, both parties will pay the price sooner or later.

Therefore, both parties should properly select quality levels to control costs.

By the way, the ultimate goal of product R & D is to provide functions (that is, the requirements in project development), and the remaining three serve them.

Quality Management Level

There are roughly the following quality management activities, and the corresponding quality management level can be reached due to the implementation of these activities:

Quality Control

Process and product quality assurance

Quality definition

Quantitative Quality Management

Root Cause Analysis and Defect Prevention Causal Analysis and Resolution

Quality Control

A typical case for implementing quality control is that there are basic software testing behaviors that correspond to level 1 of CMMs (a level that has been described but not defined in the CMMS model ).

Why is it control? Because the test activity occurs after the product is completed, it cannot directly improve the product quality, but it can check the bad parts of the product. In the manufacturing industry, nonconforming products will be thrown away after detection, and the software industry will return the nonconforming products and modify them again.

Quality control has limitations:

1. Limited effect

Just as we do not want to buy a car or home appliance that has been "repaired", the software that has been "modified" has problems, because most of the defects are not isolated incidents, it is a manifestation of low overall software quality.

2. High Cost

It would be very painful to know the quality of a car only after it is fully installed. Once it is known, it can only be discarded or completely disassembled for repair.

Software testing is exactly like this. Before the software can run, it cannot be tested. However, detecting and discovering the defects are two different things. We must re-"split" the software with the naked eye, to find the root cause of the defect.

Agile Quality Control

Continuous integration and automated testing in Agile development can effectively reduce high costs becauseContinuous integration greatly accelerates the installation and splitting Processes.

The accelerated installation process is easy to understand. Why does it mean that the process can be accelerated?

Due to the continuous integration, very few codes are installed. Once a problem is detected in the test, it is easy to judge where the problem exists, that is, the newly added code, or at least because of the code, you can quickly locate the problem.

This is much faster than testing when the final product is formed.

However, sinceContinuous integration is used to solve cost problems, so do not invest too much manpower in continuous integration itself, Ask yourself some questions to determine whether continuous integration plays a role, for example:

1. is the length of the project long enough to require continuous integration in the middle?

If there is only one month, it is estimated that the disassembly speed may not be worse after one month.

2. Even if continuous integration is required, how often and to a certain extent should we perform integration and testing?

Do not be agile for agility.

3. After integration, have you invited the customer to observe the current product to propose improvements?

Some improvements may not be code defects, but may be demand defects.

4. Is there any phase III and Phase IV of this project? Do I need to build a better continuous integration and testing environment?

5. Are there multiple customers in this project? (Almost productized)

This affects whether a large environment is required to set up multiple customers at the same time, so that after modifying the underlying layer for a customer, you can quickly check whether other customers are affected.

......