Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |