Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Abstract
Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your teams definition of done. Verifying that your teams definition of done meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well. The definition of done can also be seen as: a checklist of valuable activities required to produce software useful reporting mechanism for team members, an input for reporting is informed by reality is not static (extendable and can make exceptions) is an auditable checklist
Rationale
The definition of done will help the team making sure that the implementation meet expected behavior. Another equally important aspect is that the definition of done will help the team focus on the code, system and team quality attributes. Code quality examples: Coding standard compliance, its highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Architectural review, aligning the new code to fit existing architecture and design principles makes sure the system can meet NFRs. Tested, automated tests are vital to regression testing, the business of ensuring that new changes in code don't break things that were working before. Documented, clearly documented code support integration and understanding of the intent of a specific component or method.
Product/System quality examples: Integrated, a change should not be considered done until its fully integrated and working as expected. (There are cases where the final consumer is still not implemented but the integration can usually be verified with automated tests.) Usability, testing usability early will avoid future redesign and customer feedback. NFR, there is little use of new functionality that will not meet the non-functional requirements since this will probably just increase the technical depth.
Team quality examples: Do not over-commit, predicable velocity, adding new features as fast as possible will give a first impression that the teams are high performing. Later when technical depth is catching up the speed will radically start to slow down.
Technical debt, Pay me now or pay me later, making sure we upfront pay enough attention to quality will help the teams delivering new features in a sustainable pace. Knowledge sharing, using techniques like code review will boost code quality, team knowledge, understanding of the system design principles and increase developer skills.
Example
The table below recommends activities used to build the definition of done on the three levels. Task (team member) Acceptance criteria Coding standards Unit test Compiler acceptance Static code analysis Code review Dynamic code analysis Green CI Accepted by Team Story (team) Acceptance test Meet NFR Architectural review Documented No known defects Accepted by PO Feature (multiple teams) Acceptance test Meet NFR Full regression test Integrated to mainline Exploratory testing Accepted by PM