The notion of "done done" has had its time in social history, and memes abound. The idea is that someone says, "I am done", and when you ask ", Did you test?" they go back to their desk. This gave rise to the notion that we must declare what done means.
How do you typically use DoD?
A general understanding of the team and a simple checklist are the usual way to go. It may include something like this:
- Code is committed
- Code has a test and passes
- Code Review complete'
- QA has signed off with no issues
This definition of done varies in size and commitment. The team invariably checks each thing off the list before they say it is done.
What is wrong with it?
It depends on the team, but most of the definitions you will find involve the feature and the quality of the feature. This, in turn, is driven by processes and or "feature tested". Another way of saying it is that its quality is deemed as "it fits the bill, and no one has found an issue when looking". This is hardly the complete picture of a feature and gets much more complicated when defining architecture or other higher levels. What is done at the application architecture level? What is done, done-done, in a continuous iterative approach?
Depending on your view, you may say that the most significant problem is that it does not get developers thinking about architecture, design and the big picture unless someone has moulded the team in that way. Nothing inherently asks the question, is the design done correctly, are the correct design patterns in place for the business vision? These are more significant questions that are very rarely found in DoD.
AMMERSE brings a whole new side to DoD
How are you reviewing the code? What are the architectural objectives behind this feature?
AMMERSE Sets can be assigned to features and incorporated into any ‘definition of done’.
Alignment of code structure and patterns
In the AMMERSE definition, we have a set of weights, which was calculated ahead of time. The feature is context-oriented, the AMMERSE Set was created for the checklist. Code reviews are conducted to check the gap between vision and implementation.
Definition of quality
Quality is not only passing a test but also availability, the correct trade-offs, and scale (only if part of the requirement), in other words, an entire set of qualities that are contextual and subjective. An AMMERSE Set can describe the desired goal.
