Quality standards in Scrum iterations

In the Scrum iteration process, the final acceptance quality is important, and iteration is rolling. If the quality of iteration is not up to standard, quality debt will always exist, in this way, it will gradually accumulate like a snowball, and become larger and larger, leading to only the shape of Scrum, rather than the real agility. Because you cannot release products at any stage.

 

The word "Product Quality" is a relatively imaginary word. No one can guarantee that the product has no bugs, and no one can say that the quality of the product has reached a certain level. In addition, there are three roles in the Scrum iteration process: product manager, R & D, and test. In the high quality agile quality requirements, the latter two are combined to become an all-around talent. However, in many companies, R & D and testing are still separated. Therefore, these three roles will also face quality requirements. R & D requires that the output of the product manager be within a reasonable quality range, rather than discovering problems during R & D or testing. Tests also have certain requirements for R & D quality input, so there cannot be too many low-level bugs. In this way, we face a quality standard problem.

 

At the earliest time, it was decided by the upstream. The requirement personnel handed over the document to the programmer and told the programmer that the development was complete and the tester was finished. Because there are no constraints, the quality is not very good. Testers always complain that the quality is too bad and the tests are all low-level errors. After practice, I performed checklist (self-check list) and adjusted the self-test list based on the test feedback. However, even so, the tester's satisfaction was not very high, I think that the output quality of R & D is still not very high, resulting in great pressure on the testing side. Another point is that the ratio of testers in the company is very low, with only a ratio of or. This also requires a higher output quality, avoid that the test of the previous iteration has not been completed, and the output of the next iteration has arrived. Testing will always be a bottleneck and the most stressful person. It also avoids being used as the final barrier because of the poor output quality, and cannot extricate themselves from being entangled in Common Bugs, this results in a low quality level.

 

Based on the experiences and standards of Japanese software, a set of quality standards for Scrum iteration are developed. Within the company's R & D system, Scrum iterations include the following content, detailed requirements, R & D, and testing. In this way, detailed requirements are selected based on the entries in this iteration, R & D is carried out, and the results are delivered to testers for testing. All three processes are constrained and quality standards are formulated. According to previous experience, the quality standards in Scrum iterations are defined as 16 bugs/KL (16 bugs per thousand lines of code), and the detailed requirements are 4 bugs/KL, the design + CD is 7Bug/KL, and the test is 3Bug/KL.

After this standard is agreed, developers are required to find the detailed requirement 4Bug/KL. After the R & D, developers must measure the 7Bug/KL standard before it can be delivered to testers, the tester must test the 3Bug/KL before the end of the iteration can be considered. Because the required document does not have the corresponding number of lines of code, it is estimated based on the R & D time and calculated based on the number of days of 50L/D. (In terms of production, it should be 20L/D. However, because of the existence of the duplicate code at the present stage, it is about doubled .) In this way, the quality constraints of the requirement document will be carried out according to the predicted R & D days.