At Evolving Web, we’ve been working with an agile project management methodology for some time now. Compared to the waterfall approach, we’ve found that the agile method best captures our team’s momentum and creativity during development. This translates into an involved client and a better product. By breaking our mandates into two and three week sprints, we work within a limited timeline to implement the project’s specifications. We demo our progress at the end of each sprint to affirm that we’re on the right track and that all of the client’s concerns have been addressed.
Affirming a belief in the agile approach is easy enough. Its the implementation and tracking of the project that gets tricky. Introduce large volumes of legacy data, content spreadsheets and translations, and you’ve got a hot pot of information just waiting to get lost. For help with all of this, we use Redmine, an open source project management tool that is great for scoping, tracking and maintaining our development tasks.
Why Redmine?
After experimenting with several agile bug-tracking tools (Trac, Jira, Pivotal Tracker, etc), we settled on Redmine because of its extensible and customizable framework. We’ve been able to seamlessly integrate our other project management tools, including Google Docs and Git, into Redmine to ensure that we have a comprehensive and inclusive way of tracking a project’s development. In this post, we'll explain how we've customized Redmine for defining issues and creating filters, and in a follow-up piece we'll go into more detail about our integration with Google Docs and Git.
Out of the box, Redmine comes with a great deal of functionality, including:
- Project-based issue tracking.
- Time-tracking tools which allow developers to track their own time and managers to monitor time spent on a task-by-task basis.
- A wiki for collaborative notes and documentation.
- A document repository for uploaded files.
Tracking Specs and Stories
We’ve customized the application’s framework to take advantage of the agile concept of “stories” - use cases for various site functionality. In Redmine, we call them Specs. Each Spec is maintained as a general, parent item and is then broken into actionable tasks and assigned to a developer. Children tasks are not closed until they’ve gone through a QA review (managed in Redmine) and Specs are not marked as ‘Ready to Deploy’ until all associated tasks are complete. We use Redmine’s Versions feature to represent the agile concept of “sprints”. Each task is assigned to a specific Version when it is expected to be presented to the client.
Viewing these issues within Redmine is made easy by customizable views. For instance, at the start of a project we create one view for tracking all the main Spec items, and another to track their children issues. By never closing the parent items, all progress made on the entire task is visibly tracked via the progress bars of the children issues. This customizability is ideal for managers keeping track of the project’s development while also focusing on the timeline and budget.
Managing time and budgets in the wiki
Speaking of a timeline and budget, each Redmine issue can have time logged against it. This helps keep track of those mammoth, time-consuming features. Once time has been logged against a project, we create time sheets in the project’s wiki. This helps us track hours usage by person, task and week. These form the basis of the reports we send our clients. Other project documentation, including mockups and wireframes, are also housed in the wiki. Essentially, Redmine becomes the repository for all project documentation.
We’ve come to discover that the best part about Redmine is the great degree of flexibility it allows its users. A lot of functionality comes out of the box, but a lot more can be integrated into the infrastructure. With each new project, we look for ways to improve our process, through tweaks to the workflow and the use of new complementary tools. Because Redmine is open source and inherently customizable, we're confident that it will keep pace with our project management expectations. In the next post we’ll explain how we’ve taken advantage of this flexibility to integrate Google Docs and Git into our workflow.
This post was written by Simone Pereira and Aran Rasmussen.