This summer, my company invested about 3 man-months on a web application for tracking FDD projects. We identified approximately 160 features that such a tool would need over the full lifecycle of a product.
Before myself and my cohorts were pulled off onto other things, we managed to implement approximately a third of that functionality. The outcome was, if a bit light on features, quite robust, and adequate for use with teams that are relatively new to FDD.
I am currently contemplating how to broach the subject of open-sourcing the tool, as it has no relevance to my company's business markets. Unfortunately, I'm not sure how attractive the idea of some 'free labor' is to them, as they seem to be content with what they already have.
Galileo Feature Tracking System
What are the major feature sets of this tracking device? Did it give management a real time look into the project's status? How did it help in process 4 and 5? Does it facilitate design and code reviews?
I am rather curious.
Feature Sets
Glad you asked, Bob.
The current implementation focuses mostly on progress and issue tracking in real time. Releases, Chief programmer worksheets, and features show live, up-to-the-second data about percent complete based on the status of the milestones of their features, and subject areas and feature sets can show completeness both for a specific release and for the product as a whole. Each of these concepts has its own view, and (with the exception of the product view), and show summary information about all of their children in a (client-side, stable) sortable tabular form, which comes in handy for visualization, in the absence of graphs, or the parking lot view, both of which are planned for later releases.
Issues can be associated with any number of features from the product (this allows issues spanning multiple releases). Open issues are displayed prominently near the top of each view. Unresolved issues that exceed their planned resolution date cause the associated features to transition to 'blocked' status automatically. Similarly, features become late when planned dates for milestones are missed.
As the tool doesn't comprehend code, or design documents, it doesn't facilitate process 5 (Build by feature). It's not clear to me how one could expect much help from a webapp in that area, but I'm open to suggestions. As for process 4 (design by feature), all it offers is tracking progress, and some gentle nagging in the form of red blobs on the status summaries. There's no integration with version control, or support for attachments, so it can't manage the documentation associated with milestones, though all of the concepts support free-form commentary, which comes in handy from time to time.
I've had the fortune of getting feedback from Steve Palmer on the design, and a couple months of user feedback have highlighted the need for numerous workflow improvements, and so I feel that, at least for what parts of it are there, that it's a fairly solid tool.
The remaining functionality identified for a 1.0 release would include more feature metrics such as velocity, inventory, level of complexity, lead time, and graphs of some of these values over time. There are a number of missing aggregate calculations to be completed, which will allow for status to be calculated for the coarser grained feature groupings (CPW, SA, FS, Release). Additionally, there are plans for tracking feature sources/churn (requirements documents, change requests) and marketing priorities.
After that, I'm not sure what direction the tool might take. Integration with external systems, like source control or bug tracking, can be problematic largely because there are so many of them available.