Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Agile software for a nacent project



Doug wrote:
> Does an agile development process make sense for projects...with
> people who don't live in the same states or countries?

Yes. I've worked on long duration projects with distributed teams
following agile methodologies. It works just as well at a distance
(providing you can figure out a time that works for everyone's time zone).


> There are morning scrum meetings, story sessions, sprint planning and
> sprint completions.  That makes sense when everyone drives to the
> same building.

There is also peer coding and code reviews.

Those activities provide the same benefits at a distance. I've done
scrums via IRC and found it worked quite well. Sometimes even better
than using speaker phones or conferences calls when you have to deal
with bad audio and a variety of accents. (Something like a Google
Hangout with high fidelity audio might work well.)

These activities are all meant to facilitate better communication among
the developers, and that's even more beneficial with distributed teams.

I find that many non-distributed teams work no better, and sometimes
worse, due to each engineer segregating themselves in their own cube.


> For a volunteer based project, those regular meetings are not going
> to be held.

That may be an appropriate decision. If you are developing software at a
leisurely pace, and the penalty for going off track and missing targets
is low, then you won't get the same benefit from daily scrums. Likewise
if the developers are only working on the project sporadically. You
could still scale it back to every few days or weekly.

The situation where I think scrum would make the least sense is one
where you have only one lead developer and the other volunteers are just
occasional contributors. If there isn't a core team of consistent
contributors, then coordinating scrums with people that drop in once in
a while wouldn't work.


> ...what software would you use?

I'd consider Rally (http://www.rallydev.com/). I'm not crazy about it.
It's sort of a weak ticketing tool that's been hacked up to support
Agile artifacts. (It was built from the ground up to be an Agile
management tool, but it lacks loads or common issue tracker features,
which I would expect a mature tool to have at its foundation.)

I've used both the Enterprise and the free version. They've steadily
whittled down what is included in the free version, but it may cover
what you need.

I've also looked at Pivotal Tracker (http://www.pivotaltracker.com/) and
at the time (about a year ago) it was weaker than Rally (didn't support
stories with parent-child relationships).

I looked at a bunch of others in less depth. Nothing that particularly
stands out. I'm about to start looking at these tools again for a new
project.

Also, if you care about archiving your project data, you should look at
whether the hosted service you are considering supports that. As far as
I can see, Rally, for example, lets you export artifacts (i.e. stories)
individually as CSV or XML. No full project export feature. And although
it does support importing what you've exported, what you export is
dependent on your current view, so hidden fields will be lost unless you
make a custom view that includes them. Not the sort of comprehensive
export you want for worry free archiving.

I plan to explore the locally hosted, open source tools in some more
depth. There's a directory of them here:
http://www.agile-tools.net/

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org