Anyone tried PR reviews together as a team every day instead of individual team members reviewing them? Is it effective?
For further actions, you may consider blocking this person and/or reporting abuse
Anyone tried PR reviews together as a team every day instead of individual team members reviewing them? Is it effective?
For further actions, you may consider blocking this person and/or reporting abuse
Peter Kim Frank -
Thomas Bnt -
Best Codes -
ProDev. Staff -
Top comments (4)
Yes, and there's even a name for it - it's called a walkthrough.
When it comes to reviewing work, I've often seen it presented as a three-tier model.
At the lowest, least formal level is the "desk check". This is synomyous with how I see a lot of teams carrying out pull requests. The individuals who are asked to review the work do it at their own time, in their own space, and provide comments asynchonously.
The next level up is the walkthrough. It's a bit more organized and is done as a group activity with discussions and conversations in real-time.
The most formal level is the inspection. It's not only organized, but people tend to review the work in advance of meeting and then walk through it piece-by-piece as a group, finding problems.
As far as effectiveness, it varies. What are you trying to do? What are the other practices that you have in place? I've found that walkthroughs are great for learning. I've tended to use them when introducing something new. But they also may not have their place if the team is frequenly pairing or mobbing. It could be worth experimenting with walkthroughs for some or all changes just to see what the team thinks.
I was actually waiting for someone with "walkthrough" experience to write a reply in this post :) and gladly you did it.
I also wanting to try "walkthrough" in the team to have more interaction, some knowledge sharing, avoiding in and out messages in the PR etc.
One question about that would be, did someone experience anything different if some teammates are remote?
It should be fine if you do things with some people remotely, but make sure that you have good tools and use those tools effectively. Setting up the scope and time a few days in advance of meeting to make sure that people have the time to prepare so the walkthrough can be on the shorter side (60-90 minutes) would also help.
These are really more general "meeting with some remote people" type things, though. I don't think that there's much unique about a walkthrough in particular that would raise special concerns or considerations with remote people that other types of meetings wouldn't also have. There's quite a bit out there about how to effectively work and meet with people in fully remote or mixed settings that should help.
We actually took it one step further... we actually built a platform to facilitate this on an ongoing basis - livecycle.io/.
Here's what we've learned in our experience and research:
1) Many code reviewers want more context and visual representation for the PR that they are given to review.
2) PRs will often need multiple reviews by multiple stakeholders. These reviews are usually not coordinated.
3) Comments that come back to code owners are usually lacking context or clarity which then require the developer to burn a lot of time analyzing or perhaps even meeting with the other folks on the team to understand what they are talking about.
Our platform solves all of the above. And we've found it to be super effective. Not only for us internally, but for our users :-).