Running a code sprint
Oct 4, 2005 13:53 · 402 words · 2 minute read
The first time I heard the term “sprint” for software, it was in the context of Zope. A ZopeMag article also credits Tres Seaver at Zope with this and talks about how Zope Sprints are run. I decided to write up how I’m planning to handle this Saturday’s TurboGears “Dilly” Sprint in Ann Arbor in hopes that I’d get some useful commentary. This will also provide tips for the people who are coming.
This is the first sprint for a “new” project. However, true to the ideas behind TurboGears, some of the people who are coming have previously worked with TurboGears parts, mostly CherryPy, before. There’s the possibility that one of the project founders will make it… fingers crossed! Everyone has some level of Python experience.
This sprint is only one day (10AM-3PM). I have no illusions that a group of new people, working together for the first time with new tools, are going to produce thousands of lines of code in a short day. I’d like for people to come there, have fun, get some ideas together for the “Dilly” (0.9) release and write some code in that direction. After the day of the sprint, we can pick up the work that was started and finish it up. By making the sprint just one day, I’m sure it was much easier for people to work into their schedules.
As in the Zope sprints, I’m planning that we’ll do pair programming. For the circumstances that I described in the last paragraph, pair programming will be a big help: two heads are often better than one at generating ideas, and people will be able to help each other find the best way to work on something. Beyond pair programming, I’m planning to use a lightweight, XP-based process that I’ve worked with before. The day will be broken into roughly 1 hour iterations, which will give people a chance to check in with the rest of the group, collectively work through any problems and validate solutions that have come up.
I’m planning to create several team logins with commit access to the svn repository so that we can do frequent integration. As long as all of the computers have Python and Subversion installed at the start of the day, we should be able to get going pretty quickly.
Comments from anyone who has run a sprint or attended a sprint would be greatly appreciated…