The Portland White's

Tuesday night I attended a meeting for the XP User Group of Portland.  The presentation was on eXPlainPMT, an open source project management tool used to support the XP software process.  John Wilger, the presenter, made his slides available and wrote out his presentation in essay format for all you folks who couldn't attend.

A couple things to note about the product:

1. It was built on Rails
2. It was built using the XP software process
3. It is only for the project management which uses XP
4. If you don't use story cards, its not worth looking into
5. If you don't do pair-programming, you can still use the tool
6. The project is almost 1 year old (in the wild)
7. Project only has 7-8 contributors
8. Currently doesn't have burndown charts and reporting (but this is where I can get involved and become a contributor to the project)

This was the first time I'd been to this group.  The meetings are held over at OGI, and there usually is free pizza.  Most of the folks who attend are not developers, but instead project managers who want to talk about XP, Scrum, RUP, and anything related to Agile development.  These guys believe in pair-programming to a 'T'.

Now while I'm not convinced that XP is the way to go, I will concede a few things which I learned which may or may not be about XP:

1. Requirements on note cards are a great idea.  It works well for meetings, setting priorities on, grouping and organizing into iterations or with similar requirements.  Not good because they do get lost, this is where eXPlainPMT comes in handy.
2. There exists a RubyForge
3. If you have a story which takes longer to implement than a single iteration, break it up into smaller stories (yeah, I know, nothing new here, but it sounded good when talked about with note cards)
4. About pair-programming:
1. It is easier to refactor code
2. You write less code which later needs to be refactored
   

A couple things which I heard which sounded good:

• In most organizations, the team reflects the tools being used.  What you want is the opposite, you want the tools to reflect the team.
• Alistair Cockburn wrote a paper on using different methodologies per project.

  The ultimate point is that one methodology cannot possibly be the "right" one, but that there is an appropriate, different way of working for each project and project team."