loading...

re: Please be professional and stop saying "I'm almost done!" VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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...
 

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 :-)

 

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.

code of conduct - report abuse