The dilemma of software quality management and the countermeasure thinking

Believe that in many software development-related enterprises, quality management departments and software development departments in the day-to-day operation of the formation of the following figure shown in the "dumbbell-shaped" organizational structure.

The Development Department executes the process established by the Quality Management department, and provides the data feedback to the Quality Management department (including defect rate and various process records) in the form of the evidence, and the Quality Management department according to these data supervise the execution effect of the process, and revise the process timely. The two main independent departments, the thin two lines and some interdepartmental meetings. Ideally, the Quality Management department and the Software Development department between the formation of a counter clockwise virtuous quality management ring, should get good results. But in my opinion, the truth is not so!

There are two hypotheses in the dumbbell-shaped organization structure. First, metrics can truly reflect software quality. Clearly, the fact that the software crisis is still await today, the industry does not find a fully capable of measuring the quality of software indicators, this assumption for the reality of how much seems very slim. Second, the software Development department can honestly provide metric data. This assumption is also difficult to establish for the current state of low levels of professionalism in the country.

Therefore, the first dilemma brought about by the dumbbell-shaped structure is that the two departments are transformed into two camps: "Data-viewing" and "data-making". Software Development Department in order to achieve Quality Management department set up the "goal", sometimes it is necessary to consider how to "build" the data, even if the "made" method is a bit inferior, and the Quality Management department because only through the data to understand the quality of software products, apart from the inability to understand why some indicators suddenly up and down, Not to urge the development Department on the quality of the root causes of a radical cure.

The countermeasures to overcome this dilemma I think need to start from breaking the organizational structure. The real quality of the software is not the people from the Quality Management department, because they do not touch the source code, but from the development department software engineers. To this end, the two departments should have the intersection of the more likely to do quality management work, perhaps the structure of the following diagram to help achieve this goal.

In the new organizational structure, the two-sector focus should come from the development department, the technical experts who have a good knowledge of software quality management from the next two layers of the "capacity Pyramid" (see "Software development: the core of the individual and the team is Forever"). In addition to helping the Quality Management department understand the true state of software quality, they should also help the development department understand the root causes of quality problems and seek technical solutions. People in the intersection can consider the form of virtual team to organize and manage.

Another big dilemma for quality management is that too much emphasis is placed on processes and data, and the importance of neglecting quality management is to help engineers improve their work habits (such as programming habits) and improve the productivity of the development environment (such as project compilation efficiency, Unit test implementation efficiency). In this dilemma, quality management activities are more "steel"-to achieve set targets or not to achieve, and lack of due to the "flexible" understanding. Although the idea of "product quality stems from Process Control" is widely recognized by the industry, it is still easy to overlook the importance of incorporating the work habits of the engineers and the efficiency of the development environment into the quality management category, which is also the key factor that causes many quality dilemmas. The importance of these two elements cannot be overemphasized.

Finally, I think quality management should focus more on practice than on measurement. Because of the nature of software development, it is difficult to find effective measures in this respect, it is better to spend more time to establish their own practical methods, and to integrate these practices into the work habits of Engineers and development environment.

This article is from the "Liyun" blog, please be sure to keep this source http://yunli.blog.51cto.com/831344/1060117