DEV Community

Discussion on: Please be professional and stop saying "I'm almost done!"

Collapse
 
dmahely profile image
Doaa Mahely

Hello Davide, thanks for your post!
We're a small shop and I usually review other people's code since I'm more familiar with the system, and we don't currently have a definition of done, a list of acceptable criteria or even a uniform way of creating and explaining tasks. Newer developers will usually refer back to the person who created the task to verbally explain the task without updating the description in the task management tool we use.

Now this and other reasons have caused a code review bottleneck as you mentioned, where I keep returning tasks that are marked as done to 'open'. Now we're working on improving this process, however I have two questions:

  1. Who is responsible for writing the acceptable criteria and user stories and that kind of thing?
  2. How much of the responsibility lies on the person writing them and the common sense of the developer? Surely not all cases will be covered by the acceptable criteria
  3. More of a managerial question, what if, after writing the DoD, developers are still marking tasks that aren't done as done, and thereby putting the responsibility (from a top management perspective) on the reviewer who is expected to review and merge?
Collapse
 
dvddpl profile image
Davide de Paolis

Hi Doaa, thanks for your comment.
Well, in a small shop it's a bit different and difficult because everything is less structured and there are fewer resources - no agile coach, no product owner, no project manager etc.
This does not mean you should not have a process. Start small and simple and build on top of it.

regarding your questions:
1) normally whoever is in charge of the project ( PO, PM, PjM, Lead, Agiile Coach) but if you don't have any... it could be anyone.

Who works on the ticket could before starting to code, write down some thoughts, some points of the stuff that is needed, and describe the task. that will work as reference for the the acceptance criteria and user story, instead of something that was just verbally explained.
2) There will always be cases that were not documented or taken into account. don't worry.

starting with TDD ( test driven development) can help ( and as long as you find new cases you can leave some tests as todo and open new tickets for the future.
3) if it's something major, send the review back, if it's something that is missing - but you haven't established yet, maybe just write it down as a comment, summarize them, share them in the first meeting/retrospective/standup, ).

I often create issues in gitlab for some stuff I think is needed but not necessary to proceed with merge - and open a ticket straight out of it - in such way, the technical debt is already being "documented""
Don't get demotivated or angry, just be propositive and try to make life and work better for you and your team. it will pay off - probably slowly, but it will.
Be proactive and lead the way :-)

Collapse
 
dmahely profile image
Doaa Mahely

Thanks a lot for your comment!
I do think TDD will help us a lot in our business - unfortunately we've had countless instances when simple tests would have caught embarrassing bugs. I'll do my best to advocate for it.
So as I understand it, retrospectives can be quite specific if I can mention issues in MRs/tasks? Up until now (and we haven't done many) it's just been general feedback about the week and workload.
As for your last point, we've tried creating tasks for technical debt but that caused a huge backlog and top management was confused in how those 4 tasks related to the same feature/bug are different, so for now when I send a review back I also send the task back, so that all of its history is there in one place.

Thank you again for your help! :D I'll keep my eye out for more of your articles.