tools

How I Use Pivotal Tracker for GTD

I’ve been using (and talking about) the GTD system for about three years, and along the way I’ve tried a variety of tools ranging from the most basic (paper) to the most sophisticated (humans) to help capture and manage my tasks.

For the better part of Grockit’s existence, we’ve been using Pivotal Tracker to manage our agile software development process. Without question, it’s the best organizational tool for agile development teams we’ve seen, and we consider it an essential part of our productivity.

I’m working on a series of blog entries showing how we use it at Grockit for software development, but thought I’d show how you could use Tracker as a personal GTD-style task manager.

Here’s a very fast and light tour of some of the Tracker basics with a bias towards using it as a GTD system. If you’re a software developer and practice or want to practice agile software development, keep an eye out for a series of more extensive tours in the near future.

Pivotal Tracker as a GTD tool from Michael Buffington on Vimeo.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

Introducing CCToaster

Hi! My name is Kunal and I’m an engineer at Grockit!

At Grockit, we practice eXtreme Programming (XP). No – not that kind of extreme. We are however very serious about testing code. Our process of delivering a clean build to our target environments hinges on a continuous integration (CI) tool called CruiseControl.rb. Confused? Don’t worry – I’ll explain!

After every commit to our Git repository, CruiseControl.rb wakes up from its slumber and starts running all the designated integration tests. For us, that means Ruby, JavaScript, concurrency, and selenium specs. If we’re “green,” meaning that all of our tests passed, then our commit is tagged and worthy of being deployed to a testing environment. If we’re “red,” meaning that a test failed, then the offending Grockiteer has to fix the glitch. CruiseControl.rb has helped us maintain a high level of quality whenever we want to put a feature in front of our users.

CruiseControl.rb works just fine when the build and development team size is small. As Grockit continues to iterate and release, both variables have increased in scope and size:

  • Business logic and tests are directly proportional. We write our tests before we write a line of code. When our system complexity increases, the number of tests, and therefore the amount of time it takes to run CruiseControl.rb also increases.
  • More engineers = more checkins! In between long CI builds, lots of changesets tend to accumulate in the ether, making it harder to determine the results of your changeset. It’s just not productive to search for needles in haystacks.

To help improve our CI process, I built a tool called CCToaster. CCToaster is an OS X menulet that displays the current status of CruiseControl.rb. Here is what the tool looks like in your status bar:

The icon color denotes the state of CruiseControl – green = success, red = fail, black = unknown. The neatest feature of CCToaster is the ability to track a changeset’s status. Here is what the interface looks like:

And of course, there are preferences:

As you can see, it’s very lightweight and easy to use. If you are interested in downloading the binary or checking out the source code of the project, head on over to the CCToaster Git repository. The application was written in PyObjc and was tested on Leopard (10.5).

Feel free to shoot me an email if you need help setting this tool up for your environment. I hope you enjoy using this application and learning more about the Grockit process.

Farb & Kunal pair posted this on December 24, 2008

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati