Probably each of us had that dialogue with a developer:
- How is your task? Is it okay?
- Yeah! It's done!
- Where can I test it?
- No, it's not yet covered with unit tests / not passed code review / the last commit is almost there.
(Google points here for this picture: https://hoangluongsjsu.wordpress.com/ )
What is missing here is not exactly "Definition of "Done"", but a substitution of different levels of "Done":
- Personal "Done": "I can do nothing more about it", the task is handed over to another team member."
- Team's "Done": "We have done all we could do internally. Now we can demonstrate the results to a wider audience, but we are still open for changes and suggestions in case of interference with some other team."
- Project's "Done": "We ship it! All your claims and change requests you should send to our legal department."
Working with agile Scrum-like process which states team commitment, we should always put the Team's "Done" to tasks' Acceptance Criteria.
Because putting personal commitments to a task description looks like avoiding responsibility for possible future changes in its scope due to integration issues.
But putting project oriented goals is even worse as they are likely not to be testable at the point, when a particular task is done. That leads to "requirements inflation", when the "key project points" are written everywhere and at the same time are not met anywhere.
Watch your requirements. And keep your task descriptions clear and testable.
Ось мій особистий список того, що я хочу дізнатися у кандидата, безвідносно його професійного рівня. Просто відповіді провідного "сіньора" будуть більш фундаментальними та розлогими, а молодшого "джуніора" - короткими, наприклад "Не знаю." :-)
