During 2016 and 2017 I worked in a small 3 people dev team at Wikimedia Deutschland, aptly named the FUN team. This is the team that rewrote our fundraising application and implemented the Clean Architecture. Shortly after we started working on new features we noticed room for improvement in many areas of our collaboration. We talked about these and created a Best Practices document, the content of which I share in this blog post.
We created this document in October 2016 and it focused on the issues we where having at the time or things we where otherwise concerned about. Hence it is by no means a comprehensive list, and it might contain things not applicable to other teams due to culture/value differences or different modes of working. That said I think it can serve as a source of inspiration for other teams.
Make sure others can pick up a task where it was left
- Make small commits
- Publish code quickly and don’t go home with unpublished code
- When partially finishing a task, describe what is done and still needs doing
- Link Phabricator on Pull Requests and Pull Requests on Phabricator
Make sure others can (start) work(ing) on tasks
- Try to describe new tasks in such a way others can work on them without first needing to inquire about details
- Respond to emails and comments on tasks (at least) at the start and end of your day
- Go through the review queue (at least) at the start and end of your day
- Indicate if a task was started or is being worked on so everyone can pick up any task without first checking it is not being worked upon. At least pull the task into the “doing” column of the board, better yet assign yourself.
Make sure others know what is going on
- Discuss introduction of new libraries or tools and creation of new projects
- Only reviewed code gets deployed or used as critical infrastructure
- If review does not happen, insist on it rather than adding to big branches
- Discuss (or Pair Program) big decisions or tasks before investing a lot of time in them
Shared commitment
- Try working on the highest priority tasks (including any support work such as code review of work others are doing)
- Actively look for and work on problems and blockers others are running into
- Follow up commits containing suggested changes are often nicer than comments
See also:
I like it, though to be more specific regarding “When partially finishing a task, describe what is done and still needs doing” The way I encourage my team to accomplish this is to leave it with a failing test representing where they left off. As we practice uncle bob’s 3 laws of TDD – http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html