Software development projects are subject to a number of risks. One of these risks is schedule risk. By this I mean that you may not be able to ship on time because of some nasty discovery while executing the project.
Of course you don’t know what you don’t know. You cannot foresee what you will discover as you work through the project plan (or backlog). No matter how much effort you put in planning your project, breaking down the stories, even running some spikes, you will find that you cannot totally eliminate surprises that add to your workload.
Although we cannot totally eliminate that risk there are techniques that help with mitigating it. Firstly you can build in an allowance for discovery into your plans. Some people would call it a buffer.
A different option is to break your deliverable into multiple features. Often you will observe that most of the features are completed within the deadline while a small number may overrun. You will run into a problem, though, if you are using a single branch in the version control system (VCS) for your work. Your only option will be to deliver late once all features are complete.
Therefore a different approach is using feature branches. For each feature that you have scheduled you create a separate branch. Once the feature is complete you merge it back into your main branch, e.g. ‘trunk’ in Subversion. As you approach the deadline, e.g. the release date, you now have options. You can either ship with just the features that are complete or you wait until some or all of the remaining features are complete as well.
Of course this changes the scope of the release. However, if the features are worked on in their priority you may be able to ship the more important features even early or at least on time. This is sometimes a viable alternative to not shipping at all.
In the teams that I have worked with this approach is working quite well. There are a few more aspects to this but I’ll cover these in a future post.
3 comments:
Manfred, are you familiar with the current generation of distributed version control systems like Git or Mercurial?
Under those systems, the local checkout is itself a repository that can be branched, so creating feature branches is more or less a default - not just for large pieces of work, but potentially even for individual bug fixes. Works pretty well because local branch creation is trivial - no need to get permissions from the owner of the central repository...
Simon, thank you for your comment. Yes, I am aware of distributed version control systems (DVCS) like GIT and Mercurial. Thank you for pointing out, though, that these tools make it even easier to work with feature branches. In my experience the merging also appears to work better.
I guess that with such tools, merging *must* work better, in order for the tool to be usable. You can get away with a painful merge process if it's something you only do every few months when a big project finishes up - not so much if it's something developers do daily.
Post a Comment