Interesting pararell at a experimental web project for me: we have decided to run small, fast merge requests.
We trust the developer to not destroy the UI. We get faster to the result the faster we merge. Something broke? Fixed within minutes. We don't even take long for reviews.
On the other side there are developers who don't go this way, sticking for days on one merge request. They just can't follow up, and get behind quickly.
Small, consistent steps seem to work well in our case. Bigger merges get reevaluated and checked if it is possible to split into smaller merges if possible. This way the reviews are not too long, too. Why the extra effort: to learn for the future to structure your code for merges a little better.
End result: we move faster, get faster feedback, deliver faster.
Interesting pararell at a experimental web project for me: we have decided to run small, fast merge requests.
We trust the developer to not destroy the UI. We get faster to the result the faster we merge. Something broke? Fixed within minutes. We don't even take long for reviews.
On the other side there are developers who don't go this way, sticking for days on one merge request. They just can't follow up, and get behind quickly.
Small, consistent steps seem to work well in our case. Bigger merges get reevaluated and checked if it is possible to split into smaller merges if possible. This way the reviews are not too long, too. Why the extra effort: to learn for the future to structure your code for merges a little better.
End result: we move faster, get faster feedback, deliver faster.
It still is a marathon 😃
Bravo! We're pushing straight to master in aista ... ;)
Of course we can do it, because we have single individual teams, where each of us controls one aspect of the codebase ...
The more process overhead you apply to the project, the slower it goes - And, it does not increase quality either ...
Read "The Mythical Man Month" for a break down of the whys ... ^_^