Multiple forms of agile DOD completion Definition

Weibo by Zhang Keqiang: Zhang Keqiang-agile 307

Definition of completion of done in the past, exit criteria, completion criteria, success criteria, and so on are commonly used in Agile Software Development. There are multiple levels of completion definitions. Typical is the iterative DOD, which is also the place where the initial DOD application is located. In scrum, DoD needs to be pre-defined. The common iteration DOD terms include: 1. All completed user stories are verified by po. 2. All codes are statically analyzed, correct the highest level of non-conformities. For more information about static analysis rules, see... 3. All new codes are reviewed manually. 4. All completed user stories have corresponding test cases.
In general, there are more stringent requirements for release. Typical DOD release terms include: 1. Complete the key content required by the release plan. 2. Pass the full release test, the regression test scope is full. The regression ratio is no less than 50% 3. All defects with levels 1, 2, and 3 are fixed. The number of defects with levels 4 and 4 is no more than 200. Level 1 and level 2 defects must be repaired, and level 3 defects can be released after being approved by the release with defects.
Since release needs to meet higher requirements than iteration, it is generally difficult to set the length of time required for release testing. That is to say, the time box method commonly used in agile is not suitable for testing before release, high-quality release is the top 1st Priority. If there are still defects that impede the release by the end of the originally planned test, the release should be repaired before it can be released. The results of iteration are generally presented internally or within a controllable range. Compared with release, the results are less demanding. Therefore, the time box method is applicable. Of course, iteration itself is the time box, testing in iterations has a time limit. The use of time boxes to schedule tests in iterations can obtain the advantages of time boxes. Under such an arrangement, regression coverage should be a variable for observation, it should not be a required indicator.
In order to achieve better iteration of DOD, you need to pay attention to it in advance, so some more detailed Dod can be identified and used. The most typical is daily DOD. The typical terms are as follows: 1. Set up a daily Build Environment and perform Automatic Static code check, compilation, deployment, and testing at night, fixes defects and problems found during build and test on the previous day. 2. Check the code written on the current day before leaving work. 3. The code for the current day must be reviewed by the peer on the current day or the seventh day. 4. Build a continuous integration environment, the code must be checked at least once in the previous afternoon (this may conflict with 1st). 5. TDD is used. All functional code checked in must have corresponding unit tests (TDD is used strictly)
There is also a DOD for a user story (or use case), such as 1. The final description of the user story conforms to invest2, and the user story is overwritten by the corresponding test case 3, the user story gets the corresponding automated test case 4, and the user story gets the user representative trial and preliminary approval
A few organizations have considered that the test set is too large to be completed within one day. In this way, weekly full regression automated tests are conducted. In this way, weekly DOD is available. Typical terms include: 1, whether the defects found last week are resolved 2, and whether the automated tests with new features last week are added to the weekly test set.

Multiple forms of agile DOD completion Definition