Confluence is available for a free license for non-profits who can’t afford to pay. Our local java users group (SACJUG) fit the bill for this, though no one’s ever been quite organized enough to officially register as a non-profit.
At the last SACJUG meeting we debated over what wiki/content management system to use and eventually settled on Confluence. The feeling was as a java users group we needed to use a Java based tool. I volunteered to see if they’d grant a license since my company is already a Confluence customer. About a week later I got a nice email from Atlassian granting SACJUG the right to use Confluence for site.
Kudos to Atlassian for the program for non-profits. And if you’ve tried several wikis and they never caught on you might try out Confluence. It’s really taken off in our organization and the pricing is really reasonable.
I’m a tools guy. I love to try out new tools. I get excited by the most boring of build tools like ant, maven, or rake or even code review tools like Jupiter or Crucible. In the book Applied Software Project Management they introduce the concept of building support for change through tools:
Another way to approach this situation is to pitch the changes you want to implement as technical tools, rather than as core software engineering concepts. Most people who have been in the field for a long time are used to routinely applying new technical tools that have never been tested in the organization. This is also a good way to gain concensus among the programming team for your ideas.
— pg 217 Applied Software Project Management
If a tool can help with adoption of a new process I think it can make sense, but it’s a dangerous path. Relying on tools for everything can force you into things like Model Driven Architecture. And sneaking practices in with tools is a might bit disingenuous and less than fully transparent. I prefer to use tools to support practices I’m introducing.
Some tools make the practice possible:
- Cruisecontrol for Continuous Integration.
- JUnit for unit testing.
Some make merely support the practice and make it easier:
- Clover to help with TDD.
- Crucible to help with code reviews. (especially if you’re not pair programming)
- Checkstyle to help with code reviews.
Tools can support multiple practices much as XP practices support one another. Pair programming reduces the need for written documentation, enforces real time code reviews, and leads to collective ownership of the code.
Finally, never be afraid to ditch a tool that really isn’t working. I tried using XPlanner for managing a Scrum project, but it really just took more time than it was worth so I dropped it after a single Sprint. If you’re fighting the tool or caught up in tool complexity you’re better off stepping back and dropping it.
I’m working my way through a for fun side project using Rails 1.1 and I’ve been using ActiveRecord migrations instead of the older style SQL scripts. I like them a lot because it allows me to continue to stay in Ruby. Still each time you want to make a change to a table you need to create a new migration script.
There’s a downside to migrations. Over time, your schema definition will be spread across a number of separate migration files, with many files potentially affecting the definition of each table in your schema. When this happens, it becomes difficult to see exactly what each table contains.
After a bit of hunting I settled on my current fix. Keep all the changes one per table in their Create ActiveRecord Migration files. Keep all the data migrations in a separate file. When you alter one of them and need to reset your database run two commands:
rake db:migrate VERSION=0 rake db:migrate
Presto, your database is back to a clean state.
Yesterday my organization invented a new Agile methodology–Agile Lite! You might recognize it as Scrum minus collocation.
- 30 Day Sprints
- Planning Meetings
- Product Backlogs
- Review Meetings
- Sprint Backlog
- Daily Standups
- Scrum Master
- Product Owner
The name is a bit humorous, but as long as we get to run it as an Agile/Scrum project I’m not really very concerned about the actual name we use. The best part these days is the strongest proponents of doing Scrum projects are the customers. They really enjoy the control over the direction of the project it allows them.
Approximately two weeks after coming up with a new layout to swap my office into a team room I now have the following:
The vision was to pull out all the cabinets and mount another large whiteboard on the west wall and bring in a couch. This mainly just turns the focus of the room from an office into a meeting room while leaving the space eating cabinets, but it’s 70% of the vision and they only had to remove one desk panel.