Introduction
We are about to expand the development team at OpenCorporates, and thought this was a good opportunity to explain a little about our development process. In part, because it’s always interesting to understand how teams structure their development process; in part because it’s the sort of thing every good developer would want to know. We are keen to develop a culture where we not only care about what we do, but also care about how we go about doing it.
This is part 1 of a two-part series, where we look at the weekly planning cycle we follow. Part 2 covers how we actually write, review and deploy code.
Of course the process at OpenCorporates is continually evolving (does anyone really think they have the perfect process?). Over the past 12 months we’ve continually iterated, from a fairly simple base, adding complexity only where we could see benefit. As a result we’ve become more productive and have produced better code.
We have previously worked in teams which do scrum/kanban etc. My general feeling is that you need to find a process which works for everyone (the team and the company as a whole), based on what people’s needs are. So while our process clearly takes inspiration from existing methodologies, it is being built completely organically from scratch based on those needs as they emerge.
Tools
We use JIRA for recording and tracking the work. There are many tools out there which do similar things. We chose JIRA because some of us had used it in previous jobs and it had worked pretty well. The main advantage of JIRA is its customisability – you can define different ticket types, different workflows for each type, and things like that. So with a small amount of effort you can have something which matches your desired process, and then as you iterate your process you can configure the workflows in JIRA to follow it. This means you can start with something super-simple and grow it, rather than having to jump in the deep end with whatever process the system you’re using expects you to follow.
We use Airbrake for exception tracking, and have configured the JIRA integration so we can create tickets from Airbrake notices with one click.
We use GitHub and GitLab (we have a self-hosted Gitlab server for some repos) for code reviews, via pull/merge requests.
The process
Once a ticket is recorded in JIRA, the process is roughly as follows:
- Triage and prioritise
- Schedule to be worked on “next”
- Pick up and work on it
- Pull request
- Merge and deploy
- Close
Essentially, this is just a kanban-esque process. Each of those is a separate status in JIRA so you can easily see at which stage a given ticket is at. At the moment we have a weekly team meeting on Friday afternoons where we move from (1) to (2) and (5) to (6). So in that case “next” means “likely to be worked on next week”. Steps (2) to (5) happen during the week as developers pick up the “next” tickets and work on them.
1. Triage and prioritise
A fairly simple process where we review new tickets that have come in (usually bugs, but also general non-feature-related dev tasks which have been identified during the week) and prioritise them against the existing backlog.
2. Schedule to be worked on “next”
Really, from a conceptual point of view, the backlog is prioritised and developers are simply taking tasks from the top of it. But we’ve found that slicing a week’s-worth of tasks off the top and putting them into a separate bucket helps us focus on getting them through the process. We call this bucket “next” for obvious reasons.
Quite often we’ll assign tickets to developers when we move them into “next” because it’s usually quite clear who should work on what because of their specific skills and experience. As the team grows, not only in terms of number of people but also growth in individual developers’ skills and experience, we expect this to happen less as there’ll be more people around who can cover the core functional areas we work on (whilst still possibly having more specialist skills).
3. Pick up and work on it
Once the weekly planning meeting is complete developers then go off and start working on tickets. Sometimes they’ll be able to go straight into coding, other times they will need to organise meetings/discussions with other team members to help flesh out the ticket a bit more and discuss requirements. We try and keep tickets small enough so that it’s possible to do this and implement and deploy in the same week. If we think the task is larger than that we’ll create a reduced-scope ticket which is just about having the discussion, and make a separate ticket for implementation which would get scheduled for the following week.
4. Pull request
The topic of pull/merge requests and code reviews will be discussed in part 2 of this series. Needless to say we think good practice, process and style of pull requests is critical to high-quality code and effective development. This is why all our code goes via them.
5. Merge and deploy
Once the pull request is approved the original developer can merge and deploy it. We deploy continuously (with the usual caveats of not deploying big things at 5pm on Friday etc).
6. Close
Part of the weekly planning, this is where we briefly discuss the tickets that were done that week. It helps us communicate to the whole team what was done, catch anything we’ve forgotten and also generally just give ourselves a pat on the back!
A note about multiple projects
One of the many interesting things about working at OpenCorporates is that as well as the “core” opencorporates.com website and API, we also work on other open company data/transparency projects (for example, OpenOwnership launched last month). We deal with this by having separate backlogs for each project which are triaged and prioritised (step 1 above) separately. Then the tops of these separate backlogs are combined into a single sorted backlog as they move into “next” (step 2). So basically we do a merge sort! Albeit a lazy one where in the final run we only sort the top part of the list.
And lastly,
As mentioned above, this process is continually being iterated on (in fact, the bit above about multiple projects we only started doing last week). So if you look at it and think we’re doing things completely wrong, let us know in the comments! But so far it’s working well, and we look forward to iterating further, as new developers bring new suggestions. So if you’re a developer/engineer who cares about writing good code and making the world a better place, do apply today!
blog.opencorporates.com 