Shulou(Shulou.com)06/02 Report--

What is DoD?

When you have two or more people involved in the same thing, our "team" is created, and the most important thing we do is to set and unify the team's expectations. In this article, this is the "completion standard".

After the completion of an iteration, the team will conduct acceptance to determine whether the iteration is completed. However, each team can not reach a consensus on whether to complete or not, some think that the coding is complete, it means that the task is completed; some think that a simple self-test is needed to ensure that the function can be used properly; others think that the automation use case needs to be written and tested before it is completed.

In order to avoid this problem, in agile software development, Definition of Done "completion definition" is commonly used to indicate whether the work has been completed or not, and different activities have different completion definitions. First of all, it is important to know that all DoD are not immutable, and our DoD will be very different with the passage of time, the accumulation of experience, the change of members, and the change of project, so we also need to check and improve regularly.

II. Classification of DoD

With the above mental preparation, let's take a look at the following definition of DoD, and we will find it not that difficult.

1. Iterative DoD

The most typical is iterative DoD, which is where DoD was originally used. Some common rules are:

1. All code has passed static detection, serious problems have been modified, the rules of static analysis, see.

two。 All new code is reviewed manually

3. All completed user stories have corresponding test cases

4. All test cases have been executed

5. All completed user stories are verified by Product Owner

2. Release DoD

For publishing, there are generally more stringent requirements. Typical terms of publishing DoD are:

1. Complete the key requirements required by the release plan

two。 Pass at least one full regression test

3. Repair all defects of grade 1 and 2, and no more than 20 defects of level 3 and 4

Third, version DoD

Version DoD refers to some rules before and after the launch of each version, such as:

1. All product documentation has been updated

two。 The code has been deployed to the production server

3. The operation and maintenance staff smoked through the acceptance test environment.

4. The original requirement submitter has checked and accepted the function.

5. The new function training for operation and maintenance, market and customer service has been completed.

Daily DoD

Other typical DoD is daily DoD, with typical terms: building a daily build environment, automatic static code review, compilation, deployment, and testing at night, and daily fixing defects and problems found in the previous day's build and testing.

1. The code written on that day must be checked in before leaving work, and the backlog of check in should be filled in clearly.

two。 The code of the day must invite a partner to review the code on the same day or the second day.

3. The checked-in functional code must have a corresponding unit test (strictly using TDD)

4. Trigger static code checking and automated regression testing every night

5. Please solve the problems in the continuous integration and construction environment on the same day.

5. User stories DoD

There are also DoD for user stories (or use cases), such as:

1. The final description of the user story conforms to INVEST

two。 User stories get the corresponding coverage of test cases

3. Get the corresponding automated test case from the user story

4. User stories have been tried out by PO and initially approved.

When the test set is relatively large, the test can not be completed within 1 day, you can carry out weekly full regression automated testing, so there is a weekly DoD. The typical terms are:

1. Are the defects found the week before last week solved?

two。 Whether the automated testing of the new features added last week was added to the weekly test set.

Tips:DoD must be discussed together by the team at the start of the project, and the team is willing to follow the principles that the team is willing to follow. Once determined, the team should follow it together.

III. The practical value of DoD

DoD is a list of activities that are valuable to the software

DoD is a simple list of activities. For example: coding, annotations, unit tests, integration tests, release statements, design documents, etc. All these activities can bring real value to the product. With DoD, teams can focus on what needs to be done, while eliminating useless activities that only complicate software development.

2. DoD is the main status reference for team members.

The simplest form of reporting for the iteration is only one sentence: "this feature is done." After all, there are only two states for a feature or a product Backlog Item: complete or unfinished. DoD is the best complement to the phrase "feature is done". Using DoD as a reference standard, team members can quickly and effectively keep other team members or PO informed of the status.

3. DoD is not immutable

DoD changes over time. Organizational help and increased team capabilities can remove more obstacles so that more activities can be included in the DoD of sprint or feature.

4. DoD is a list that can be reviewed

Feature/ user stories can be split into task in both sprint plan meeting and sprint. DoD can be used to measure whether all the major work is planned (the remaining time). Also, at the end of a feature or sprint, DoD can be used to check whether all the necessary value-added activities have been completed.

It must be noted that DoD itself is flawed. Not all value-added activities can be applied to every feature, and DoD itself is a large and comprehensive audit system for inspection items. The team needs to examine whether each value-added activity is applicable to this feature based on a feature.

For example, the pursuit of user experience can be added to feature such as web service, but it is not necessary for other feature.

Finally, it is important to note that the acceptance criteria are not necessarily determined by Product owner, depending on the display, and each team has to choose the appropriate DoD principles according to its own situation. CORNERSTONE provides functional modules including task / requirements / test management, iterative planning, defect tracking, report statistics, teamwork, WIKI, shared files and calendars, etc. Teams with less than 20 people can use it for free and click to register CORNERSTONE for free.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.