I assigned the pairs and established two rounds, during each round a pair need to complete only one task per developer. Then pairs must switch. At the end of the second round if any developer had pending work he (yes all boys, boring), must complete it alone. That way during the day everyone get to work with two partners.
After my 2 to 3 minutes explanation someone asked:
- Why don we need to do pair programming?
- Because I want to force some knowledge transfer level, I said
That question got stuck in my head the hole day, first because for me the answer was so obvious and also because there were so many other reasons like:
- To learn IDE tricks
- Double checking of (complex, and error prone) refactoring
- Bounding: the sense that we are fixing "our" work, not just dealing with private garbage let by me
- Etc.
Results & Pros
- We manage to reduce the issues reported by our code quality tool by 17%
- In the process we learned new IDE tricks from peers, or discovered by laziness (trying to change more code in less time)
- We improve HTML files by removing unnecessary attributes or deprecated elements (by HTML5 spec)
- We discuss why the, cherry-picked, list of violations to fix were important and how they could affect us in the future
- By the end of the session we all agree to set apart one day of each sprint to paid old technical debt
- Now everyone is more vigilant, during code reviews, for newly introduced violations to coding standards
Cons
- Most of the time it was tedious manual labor
- Around 3 pm everyone was exhausted
- Merge conflicts: because I distributed "violations" by type, not by, physical, file or class there was a high frequency of conflicts
Retrospective
Maybe it is better to assign work by file, or groups of files. That way the conflicts will only occur when public interfaces get touch.
Also, a per class / file cleaning session is not so boring because you get to handle different kinds of violations.
No comments:
Post a Comment
enter your comments here...