"If I have seen farther than others, it is because I was standing on the shoulders of giants."
I think it's important, in the interest of educating the public, as well as improving the state of the art, to share hard-won knowledge. With that in mind, I thought I might share a couple of tidbits from my own experiences, both with the FDD process itself, and with trying to track it.
I feel that the importance of choosing class owners carefully is a bit understated in the existing literature. In classes with Steve one day, he had us form a mock implementation team, and try to assign class ownership, and then schedule chief programmer worksheets and team assignments. The group I was a member of was, I felt, spending far too long trying to decide who should own what classes. The two CPs were trying to wrangle for important classes, because they felt the need to have some architectural control over the whole system. In the interests of getting the phase over with, so we could move on, I put on my Dictator Hat and randomly assigned classes to the teams, including giving the two CPs the classes they'd been eyeballing.
We quickly discovered this to be a big mistake: it turned out that one of the CPs ended up being in almost all of the other CP's worksheets, and in the reverse situation, a third of the worksheets needed both CPs. This drove home the lesson far more intensely than the admonitions made in the class and in the literature: key classes should not be owned by a Chief Programmer.
The second lesson to report is in the realm of tracking feature milestones. It may come as no surprise to hear that features in the same worksheet tend to reach milestones as a single group, or sometimes two. Generally, a worksheet will deal with one part of a functional area (approximately, a feature set, perhaps two). As such, there is typically only one design document, perhaps two, and so a single design review should suffice for a given worksheet. If the milestones are clustered together, that means that data entry also will be clustered together.
In the original implementation of Galileo, milestones were editted on the feature edit page. You could thus enter two milestones for one feature in a single edit, but you'd have to go to each and every feature edit page to update the status of a worksheet. But the path from viewing a worksheet to editting a feature and saving it took far too many mouse clicks. This typically resulting in the CPs doing bulk data entry on friday afternoon, both because it was a painful process, and waiting until a feature had passed several milestones meant only one edit was necessary per feature. This, however, left you little indication of how the week had gone until it was over.
In the second version, we added breadcrumbs to the top of each page, and the ability to get directly to edit pages from any of the table views, reducing almost by half the number of navigations necessary to perform the task. This helped a bit, in that bulk entry took less time, but it didn't discourage the practice.
What was needed was a way to enter milestones on multiple features at the same time. On a spreadsheet, this is easy enough to do by copying and pasting data from row to row. In a web application, this gets a little more complicated.
However, on further consideration, it seemed to be the case that you didn't necessarily -need- to enter arbitrary milestones on multiple features. You just needed to be able to set the -same- milestone (and date) on multiple features. Because walkthrough, design, design review, and code review were usually occuring lock-step, this would be good enough so that only one or two edits were normally required to update the status of a worksheet, instead of one per feature.
So, we came up with an edit page for the worksheet that had a choicebox for the milestone type, the necessary date/comment fields, and a pick list of all of the features in the worksheet (all of which were selected by default). This made the CPs far happier than they anticipated from the initial description, and now progress started appearing in the database on Tuesday afternoon, instead of Friday at 3:30 pm.