We've rolled out some new features in Pivotal Tracker.
New API Version
There's a new version of the developer API, with the following changes:
- support for ActiveResource
- responses no longer wrapped in an element, using HTTP return codes instead to indicate success or error
- ability to get a list of your projects
- you can now page through stories with a limit and offset
- it's now possible to obtain an authentication token by specifying a username and password (via basic auth or header parameters). This makes it easier to build interactive clients, for example a mobile app.
The previous API version (v1) is still supported, but will be deprecated at some point in the future. Please see the API Help page for more details.
Ability to change point scale
It's now possible to change your project's point scale, even if you've already estimated stories.
Demo Projects
New Tracker users will now see a link on the Dashboard to create a demo project, with example stories. You can also create a demo project from the My Projects page.
Story Comment Notifications
There's now an option (on the My Profile page to receive new comment email notifications for all stories in you project(s), not just stories you're a requester/owner of.
As always, we look forward to your feedback!
Michael Buffington has posted the first of a what will hopefully be a series of tours on Pivotal Tracker, this one about how Michael uses Tracker as a personal GTD-style task manager.
http://blog.grockit.com/2009/01/14/how-i-use-pivotal-tracker-for-gtd/
If you haven't heard of GTD, it stands for "Getting Things Done", a work-life "action management" method and book by David Allen. Read more about it here.
A lot of us here at Pivotal Labs have been using Pivotal Tracker as a personal productivity tool, and we're definitely getting more things done!
Thanks, Michael, we're looking forward to more tours.
Matthais Marschall at AgileWebOperations.com posted an interesting article the other day comparing Pivotal Tracker to Thoughtworks Mingle. He recognizes that the two tools have a very different philosophy when it comes to configurability: Mingle supports a huge number of different configuration options, whereas Tracker is intentionally very simple and more prescriptive about process. His take is that the simplicity of Tracker is fact a good thing. He likes Tracker's backlog management, its simple UI, and the way that the tool fits naturally into the agile process:
Where Mingle is more like an assistant, whom you can tell to put a card on the wall or give you this or that report, Tracker is more like an agile coach, making sure all the administrative tasks like iteration tracking are "simply there".
Chris's recent post called The Tracker Story points out that simplicity and ease-of-use has always been one of Tracker's core design principles:
Tracker embraces simplicity. It should make managing projects easy, rather than make its users slaves to maintaining the plan. It should give every user of the system more information back than they put in. Tracker doesn't have a huge list of features, because it tries to stay true to its core purpose.
Thanks for the post, Matthais, and we're glad you're finding Tracker to be a good fit for your development process.
The Tracker Story...
Pivotal Labs is a consulting shop and not a product company, so it might seem odd for us to release a product like Tracker. We didn't build Tracker for the sake of building a product; we needed it.
State of the art: index cards
We've been doing agile software development before terms like "Agile" and "XP" existed. Over the years we've made numerous attempts to use the variety of software project management applications available, from Microsoft Project to the more current agile-specific products.
We kept returning to index cards, sometimes augmented with a patchwork of wikis and spreadsheets. We followed the agile planning tools out there, but each attempt to adopt an one resulted in frustration. Configuration and data entry were a constant expense. User interfaces were clunky and had too much back and forth navigation. The workflows were inefficient and the overhead was high. (We kept hearing circus music in our heads, with all the hoops we were jumping through.) The usage cost never seemed sustainable. It always felt like we were working for the product, instead of it working for us.
But we needed something...
As our business grew, so did our frustration; index cards were far from ideal but the alternatives were worse. And at the same time, we were just starting to look at a promising new technology, Ruby on Rails. So we decided to build our own tool.
We started working on Tracker in late 2006. Its beginnings were very humble. All we needed was to have a backlog and be able to easily prioritize. We created simple story editing and built drag-and-drop prioritization and we were ready to start the switch from index cards. (These simple features gave us parity with index cards, with the bonus of having the backlog online.)
Who gets excited by project management software?
We started using Tracker on all of our client projects. We continually improved and tweaked the application, integrating our experience and feedback. And we started to find that it really transformed both the transparency and the flow of development.
Tracker quickly developed a following among client developers who had used it when working with us, too. We would routinely received requests for accounts: "I used Tracker at my last job. Can I have an account to use in my new one?"
We would always accommodate these word-of-mouth, friends and family type requests. Entire client organizations, beyond our projects, started using Tracker. The interest continued to grow and with much greater enthusiasm. We kept getting emails saying things like, "Please let me pay for Tracker; I can't live without it."
So we decided to make Tracker publicly available. We launched the public beta at RailsConf 2008. Over 10% of the attendees signed up that week.
Why Tracker is Special
We had three key insights at the outset that made Tracker work:
- the user interface needed to be simple.
- The project status and backlog needed to be easily (always) available.
- You shouldn't have to constantly plan iterations.
The first point is simply about good UI design, but it's amazing how many tools out there get this wrong.
The last point is more subtle. In agile processes, particularly XP, there is a concept called velocity. The basic idea is that you assign a point cost to stories and the sum of the point costs of completed stories in a given iteration is the velocity. You then use the velocity to project how much you will be able to get done in each future iteration. As teams start to gel, they exhibit a strong central tendency to get a consistent amount done each week, and this velocity becomes extremely predictive and reliable.
Traditionally, after completing an iteration, you would re-plan each subsequent iteration, adjusting for the actual rate of progress. This can also be onerous, but it's critical, as it is allows you to project when each milestone will be reached. The feedback needs to be taken into account so better-informed decisions can be made.
The solution is the emergent iteration. Pivotal Tracker automatically (and in real-time) tracks story completions, iterations and velocity and will dynamically adjust iteration backlogs based on actual progress; Tracker does the grunt work and your project schedule is always up-to-date.
The Tracker Philosophy
Tracker embraces simplicity. It should make managing projects easy, rather than make its users slaves to maintaining the plan. It should give every user of the system more information back than they put in.
Tracker doesn't have a huge list of features, because it tries to stay true to its core purpose. (Remember, it exists partly because of our frustration with the bloated alternatives.)
At times, Tracker appears opinionated as it can place strict limits on how you manage your project. But this is a consequence of its focus and the interdependence of features; the sum of Tracker is far greater than its parts.
While we don't always get it right, we try to make sure each additional feature or product change adds a lot of value and makes users' work easier.
By popular demand, we're working on making the Pivotal Tracker API ActiveResource-compliant.
However, there are some quirks that are required to make ActiveResource happy. For example, when you are doing a 'create' or 'update' request, ActiveResource wants the response location to point to the 'show' URL for the new or updated record. For example, here's an ActiveResource 'create' call:
new_story = Story.create(
:name => "New Story",
:requested_by => "Dan",
:description => "Make API ActiveResource compliant")
On the controller, you must add the :location option to the render - you can't redirect:
render :xml => xml,
:location => service_project_story_url(service_id, project_id, @story),
:status => status
...otherwise, you get this helpful error from ActiveResource:
/Library/Ruby/Gems/1.8/gems/activeresource-2.2.2/lib/active_resource/base.rb:1006
:in `id_from_response': undefined method `[]' for nil:NilClass (NoMethodError)
from /Library/Ruby/Gems/1.8/gems/activeresource-2.2.2/lib/active_resource/base.rb:993:in `create'
This is the type of error which you will only catch through end-to-end testing with a real ActiveResource client hitting the running app. When I did the initial spike to see what problems we would run into, I wrote a simple manual script to run against the local development environment, hacking my way to a point which didn't blow up and I could visually inspect the output:
#!/usr/bin/env ruby
require 'rubygems'
require 'activeresource'
require 'pp'
class Story < ActiveResource::Base
self.site = "http://localhost:3000/services/v1/projects/1"
headers['TOKEN'] = '6cfc2055d1df5605241759014b06b232'
end
p "========================== Stories#create ====================================="
new_story = Story.create(:name => "New Story", :requested_by => "Dan", :description => "Make API ActiveResource compliant")
pp new_story
# etc for all other supported API actions...
However, now that we are doing the real non-spike implementation, we want to automate this end-to-end integration testing as part of our Continuous Integration. That way, we'll ensure that we are fully ActiveResource-compliant (against current and future versions), and that we don't have any inadvertent regressions due to future API bugfixes/enhancements.
Digging through the internets and rubyonrails-talk list archives turns up some discussion, but no good answers:
- Thoughtbot blog post on ActiveResource and Testing
- rubyonrails-talk post on "Testing XML over HTTP in a Rails app"
- rubyonrails-talk post on "Testing ActiveResource models with HttpMock"
All of these mention using ActiveResource::HttpMock. However, as Eric and Xavier point out, there seem to be drawbacks to this approach. Plus, even if we get it to work, I'm worried the usage of HttpMock might mask some other issues related to authentication handling, or who knows what else. That's what real integration tests are for. Finally, HttpMock is an undocumented internal method that seems to exist in order to support Rails' test suite, so it's probably not a great idea to depend on that long term.
So, we don't have a great answer yet, but it seems clear that the highest-value, least-risk approach is to hit a real running app over HTTP with a real ActiveResource client.
The current plan is to leverage our existing Selenium RC test environment, which already has support for spinning up and managing a Rails server with the test environment. We can then port the manual spike tests above to automated ones which run as part of the selenium suite under Continuous Integration, and add appropriate assertions. This isn't optimal, though, because they won't actually use Selenium RC at all, which may confuse people. However, there's no sense reinventing the wheel (and adding time to the overall CI build) by spinning up a separate test server instance when we already spin one up for our selenium suite.
Let us know if you have any clever solutions.
-- Chad