Since we pay per finished (or done) task, it should be obvious for every person in the team: is this task done or not?
So, we need to specify a strict number of rules to define “Done” state.
There are also other definitions around the web. I (@sobolevn) personally really like this Russian article.
A task is considered done only when the corresponding ticket is closed.
- A task should be created
- You should be assigned to the task before-hands. See “How tasks are assigned”
- You have asked all the required questions to understand what you should do
Steps to achieve it
Since tasks are only closed by a merge request, it may require several steps:
- You have created a new branch following our standards
- You have added some code to fix a bug or to implement some feature
- You have added new tests to cover new functionality or regression tests to confirm that bug is fixed
- You have added comments to illustrate your design decision in a source code
- You have updated project documentation if required
- You have updated installation instructions or build tools if required
- You may leave some
TODOsfor future development if required
- You have created a merge request with the proper message from your branch into
- You have filled in every required piece of information in the template, such as: actions you did, time spent, issue to close
- All the preconfigured
CIstages pass: existing tests, style and quality checks pass
- Your code passes a code review from one or several other developers including at least one architect
- Your code has been merged into
It may also require multiple iterations for you:
- Your code may fail some tests or style checks, so you would need to fix that
- Your code may fail a code review for multiple reasons: design, code quality, business logic, performance. You will need to fix that