Starting a new thread to answer the question raised in this thread.
Let's start simple and then refine and enhance as our understanding increases.
An aspect is some slice of a project for which you want visibility and communicability. What's mostly talked about are the three main aspects I use which are the PD, UI and the SI. That is, there is a features list and a parking lot chart and a weekly summary report and a trend report and kill sheets and work packages for PD. There is also a features list and a parking lot chart and a weekly summary report and a trend report and kill sheets and work packages for UI. And the same for SI.
Now, you can create other aspects as well or use different ones altogether. The foundation is the features list (FBS) or the list of "trackable items." For each trackable item there is some number of named milestones and a corresponding percentage (FDD happens to enumerate these for PD and SI and it suggests some starting percentages).
From the trackable items and their milestones and from the actual progress (which comes from the work packages) all of the other visibility and communicability items are generated - e.g. the parking lot chart, trend report and so on.
Thus you might also have an aspect for system test or for tech writing and so on (I always do). If you were doing everything by use case, then that would be a aspect (not something I do).
Aspect really is the right word for this. Here's the definition from WordNet © 2003 Princeton University.
aspect n 1: a distinct feature or element in a problem; "he studied every facet of the question" 2: a characteristic to be considered 3: the visual percept of a region; "the most desirable feature of the park are the beautiful views"
All 3 meanings are in play. That we would want the visibility and communicability that the set of FDD artifacts gives, says that this is a characteristic of the project to be considered - a distinct feature of element of the project. And, of course, meaning 3 talks about the visibility and strong visualizations in the FDD artifacts.
Here's a slide from the FDD workshop that makes the point regarding the sets of artifacts produced at each weekly release meeting for each aspect - using only PD, UI and SI for this example. remember, the key point is that you can track anything using the same set of artifacts and whatever that characteristic or distinct part of the project is that you are tracking is what I call a project aspect.
Interesting
Interesting that you abstract the notion of feature into traceable items. I arrived to the same conclusion while modeling my new tool with the objective to suffice not only FDD needs but possibly other such as writing documentation. For instance in case of documentation we would have a TOC rather then a Feature List. In the case of the new MSF Agile we have scenarios rather then Features. They all can be traceable itens,
FDD combines artifacts in a very powerful way. But the the way features are represented (action result object) and the way they are tracked (milestones/completion weight) and the output combined to produce reports its master stuff.
Thanks again Jeff for the clatification.
Best regards,
Nuno Lopes
Correct
But it happened the other way around. The notion of a feature wasn't abstracted to a trackable item. The concept of trackable items with meaningful milestones and the visibility artifacts is what I'd been using for a looooooong time. The features in the PD or SI are simply an instance of this.
Yes, a TOC for documentation is EXACTLY the right idea. It is a categorized list of functional or client-valued deliverables that you want to track. That's the concept of the FBS. The first time I did this for documentation was back in 1985.
The trackable item abstraction has been discussed here before. Here's one thread from a quick search.
Jeff
Powerfull tracking technique!!
I'm a noob on these techniques in other areas besides FDD. Never had contact with the notion of trackable items has it was exposed when I started modeling the domain of FDD, and now you clarified that it is not just my imagination working. Do you have any references where the same techniques to "track items" are used with other subjects?
My background regarding project tracking is all around Gantt Charts, Critical paths etc etc, as you know it also uses a break down list, and I've never seen this before. In IMHO setting the completion of task in Microsoft Project is basically an ad-hoc process. This way to track "tasks" is far more flexible as ultimately "start dates"/"end dates" are irrelevant to calculate completion rates (they simply should not be there as it has a psicological effect). Furthermore, setting the percentage of completeness is now not an ad-hoc process full of incoherencies.
Best regards,
Nuno Lopes
Project Management failings
I agree that this way of tracking tasks fits software development better.
But I think that is because of poor application of traditional project tracking when applied to software development.
Percentages complete in MS Project are worthless, if the task isn't granular, or well defined, enough that you can "accurately" give percentages. And if there isn't a verification process, then 100% isn't meaningful either.
Take a traditional project, put a delivered item as 100% complete. Include a test to verify that it's on a build machine and you'll get less "guess work".
IMHO, this is the correct way to use project tools like MS Project in software development. And FDD essentially provides prescriptive guidance to ensure similar things are happening. If I was on a project where I "had to use MS Project and Gantt charts, I'd basically do FDD and use the prescribed completion percentages to update MS Project.
Maybe you are right, or probably not.
Thiis my HO regarding Gantts, FDD and Facets:
"Percentages complete in MS Project are worthless, if the task isn't granular, or well defined, enough that you can "accurately" give percentages. And if there isn't a verification process, then 100% isn't meaningful either."
True, the problem is that I rarely found a PM that had a clear view of what is to be developed. Becouse Gantt charts are PM tools it almost never reflect what is to be developed but what is being done or what is to be done (Like a super dup todo list) which is different. So in the end at most this people track a to do list from a political/functional prespective rather then the desired final outcome.
In fact according to ISO a Gantt chart should be present RFQ or Proposal, which is anecdotal at least. How can one make a reliable to to list if one does not have an overall coerent and assertive prespective of what is the desired output. Well one can, using common terms like (Analisis Phase, Develop UI, Build site templates, Integrate with POS etc etc), all together look like a real todo list that everyone understands but no one really cares for apart from the PM that built it and some burocrats.
Quite often a Gantt gets rebuilt, and then refactored, and refactored, and refactored then task names are changed, reordered, bars are moved around etc etc, a mess. From a work organization prespecive IMHO im most cases is not more of a Political document rather then something that a developer can look at it understand it and use it to guide his/her work.
Now don't get me wrong, I've see MS Projects being used effectively, to estimate costs, compute current cost costs etc etc.
IMHO, the main difference beween FDD aproach and the usual aproach people do when using Gantt Charts is that the Break Down list in case of FDD is not a to do list of tasks where you assign a start date for the task and an end date. Now one can start building break down lists with Gantt Charts in such manner. I've being doing this approach for years (but not using milestones the way described) but still had a hard time to update a gantt chart in terms of task completeness to the point that I decided that either the task was 0 or 100%. This meant that depending on the project it could take at least 4 weeks to have meaningfull data to update it in terms of tasks completed. Add this the fact that one could need one would multiply this tasks for each facet (PD, DM, SI, UI, etc) we would end up with more then 800 task entries on a medium project, turning the Gantt almost useless for project review meetings due to its complexity, not to mention developers. So powerpoints needed to be done to simplify compreention, resulting in more data to be mantained, etc etc.
Don't get me wrong, I believe that one can use sucessfully GantT, but the FDD approach is IMHO simpler and more effective. There are still some issues with FDD approach, but it simplifies management greatly. An example of a problems is - when do we say to a client that a feature such as "calculate Completeness of a Feature" is done? When the customer can see the result of it on the screen (leading to the use of two facets, PD and UI) or when it is done in terms of PD (passed the build process). But this is are minor issues.
Best regards
Nuno Lopes
A related discussion
Getting Flexible With Planning. Read the subsequent discussion thread as well.
Jeff