Agile Project Management with Google Docs, Git and Redmine
At Evolving Web, Redmine is at the core of our project management methodology. Redmine’s extensibility makes it the open source tool of choice for scoping, tracking and maintaining projects. Today, we're highlighting some of the integration that's possible between Redmine, Google Docs and Git. This piece is complementary to our post on Customizing Redmine in Agile Project Management.
We’re big fans of Google Docs at Evolving Web. Most of our documentation is created in Google Documents, Spreadsheets and Drawings. The efficiencies and transparency of browser-based collaborative writing have completely changed how we write and document our work. Other advantages include revision history, user colour coding and advanced commenting features. Given our reliance upon these tools, it was important for us to integrate it with Redmine to maintain and manage our project flow. There's no point in creating documentation if it isn't being used as a basis for application development.
Google Spreadsheets + Redmine
We start a project by documenting the technical specifications in a Google Spreadsheet. This document evolves from many exploratory discussions with the client, and continues to be updated throughout the project. Once consensus on the specifications has been reached, we make a Spec issue in Redmine for each spreadsheet line item and Redmine tickets are created as sub-tasks of the Spec. (Many agile teams call them Stories, we call them Specs.) Now here's the cool part: Within Redmine, we’ve written custom code that pulls in entire sheets or just a single live row from the spreadsheet into the corresponding Spec issue in Redmine. This allows us to be confident that the developers are building according to the latest approved specifications. (UPDATE: We've released a Redmine plug-in if you want to try this at home.)
If a line item is edited in the spreadsheet, the change is immediately reflected in the embedded Redmine view. This customization resolves one of the major limitations of Redmine: multiple team members can't edit the same ticket at the same time. Embedding a row from a shared doc is more practical. Creating issues per spec item is also useful for tracking the feature’s development, time logged against it (Redmine is also our time-tracker), and in some cases serving as evidence of its existence when major changes are made to the spreadsheet.
Google Docs + Redmine
In addition to the Google Spreadsheets integration is our work with Google Documents. Using similar custom code, we’ve been able to embed entire documents into issue descriptions and updates.
This has proven to be a significant time-saver since any references to the document in the issue can be easily confirmed via the embedded view. If only part of a large document needs to be embedded in an issue, we create a table of contents in the Google Document, and then link to that unique anchor URL in the RM issue. The resulting view is of the document starting from the referenced header. (In the future, we'd like to experiment with live editing of the Google Doc within Redmine.)
Git + Redmine
Redmine offers tight integration with Git, our version control system. Each ticket includes information regarding when the relevant code was updated and links to the code changes made by the developer. This feature allows us to remain nimble when collaborating between developers and provides a basis for technical QA throughout the development process.
An important aspect of Redmine’s Git integration is the visibility that it gives to content files that we use to populate a site. Whenever we build a major site, it often needs to be populated with data from a legacy site or other sources, which we pull into CSV files (usually one per content type). Similarly, large translation sets are often received as a spreadsheet. When we receive these documents, our developers use Git to track each file and update the files in Git when we receive an updated version. Git exposes these files to Redmine, allowing managers access to a timeline of when documents were received and how they change over time.
(Another plug for Google Spreadsheets: sharing a spreadsheet between the dev shop and the client team is a great way to define, populate and QA the site content prior to import. Its much more practical than sending and merging Excel files as email attachments.)
While our customization has focused mostly on Google Docs and Git, we find Redmine’s built-in flexibility very encouraging. With a little work, almost any tool can be integrated into this framework, making project management and maintenance that much simpler.