Skip navigation
Help

Software project management

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Sean Gallagher

This Q&A is part of a biweekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 80+ Q&A sites.

Robert Harvey asks:

My team and I are rebuilding a site we developed around ten years ago, and we want to do it in Agile. After I've spent a lot of time reading (probably not enough), I am having trouble with the question of how to divide work between developers.

I'll be more specific and say that the site is divided into separate modules which don't have much integration between them. What is the best/most accepted way to divide the work between the developers?

Read more | Comments

0
Your rating: None

Addison-Wesley has published a new book in my Signature Series. It’s by Robert Daigneau and it’s called Service Design Patterns. It’s a topic that’s already had too many books on it, but I added this one to the series because I think Robert has done a particularly good job of collecting together the best advice on the topic and organizing it into a useful handbook. This is the book that I think ought to become the standard book on the topic.

0
Your rating: None

In which Joey discusses his scheduling process and (hopefully) stumbles on a topic worthy of writing a real production blog post about.

0
Your rating: None

The Google Chrome team has released a blog post and a presentation that describes how their process can deliver a new version of Chrome to you every six weeks.  Maybe that is why, when I look at my logs, Chrome use has been climbing so quickly - up to 30% and gaining 2% per month. Their development process is very, very close to the "release early and often" process that I have been recommending, with at least one improvement.

The Chrome team can deliver a quality product with rapid evolution, while avoiding the stress that comes from arguing about scope ... and whether a feature needs to be in the release, and how they will stretch to squeeze it in, or change everybody's schedule .... They just release every six weeks, and people (read meddling managers) have confidence that if a feature doesn't make the release, there will be a new release soon.

Here is the basic structure:

The release goes out on time.  If a feature isn't ready, it just gets moved to the next release.

Features that are not ready can be disabled (hidden).  They have a flag for that.  After you start stabilizing a release, the only major thing that you can do is disable a feature, and you can do that by patching one little configuration.

They don't do development on "long running branches" and then do a big merge.  Everyone works most of the time on one trunk branch.

They have a long "feature freeze" period for testing, translation, and stabilization.  They make a release branch every six weeks and feature freeze it, and then the development team just keeps going. The release team spends the next six weeks stabilizing and building the production release. So, at any time, there is one development version, and one version in stabilization.

chrome dev cycle resized 600

 

Andy's Notes

I usually ask for a feature show/hide flag if I think a feature is going to pose a problem.  I now realize that I should ask for this on everything.  That's the improvement.

Before we get to the end of a release cycle (milestone), we create a new release milestone and start moving tickets.  This allows us to focus on the stuff that will be completed with quality.

Agile planning tools try to trick you into believing that you need to finish a complete feature inside one release.  This defeats the whole idea of incremental development and causes the sort of stress that makes releases difficult.  We designed the Assembla agile planner so that you can schedule the tasks for one feature into more than one milestone, encouraging a calmer incremental approach.

I also believe that developers should work together on basically the same code, with one branch, and that maintaining and merging feature branches is often not worth the effort.  Assembla will be introducing new workflows for git that make it easier to push, test, and review code in a shared repository.

The reality of continuous development processes is that you do need freeze time to stabilize a production quality release.  This overlapping approach, where you cut a stabilization branch, is the realistic approach to delivering quality releases.

In this process there are three live versions of the software at any given time - the production release, the release that is in stabilization, and the development version.  That's easy to manage for something self-contained like a browser that just requires some local disk space.  If you build Web server software, it's not so easy to have three completely separate environments with databases etc. ( development, stabilization, and production).  It's easier on the infrastructure side to have just one dev/stabilization environment, and switch your team from development mode to stabilization mode on that environment. However, this is the age of cloud computing and on-demand infrastructure.  An investment in infrastructure to build that third environment will allow your dev team to keep going.

0
Your rating: None