Feature Driven Development

This thread has several branches, so you must read my replies to your other questions in another branch here and here BEFORE we get into this discussion in this branch.

I appologise Jeff, if my PS sounded like a criticism. What I mean my Guru World, is of living in a community where people are experts on this subject amongst others and knowledge flows fluintely, wish is not the case of most of us (at least in Portugal). So it is something positive that I wish I could be part of, but I don't due to geographical location. In fact everything that I learned from you guys on this site I've been using it in practice with great success.

No need for any apology. What you said was not taken as a criticism.

* Relaxing the constraint a "allocating" a feature to one and only one Aspect. So that, we can allocate the same feature to multiple Aspect (UI, SI, Documentation), meaning a feature to be complete we need to work on its UI aspect, SI aspect, PD aspect and so on.

* The above results in a traceability matrix, were we can track per feature the work that needs to be done within the scope of each aspect.

* Build a cross aspect parking lot report that shows project status not only per business activity on one aspect but also on its multiple aspects if we choose.

I think this is unnecessarily complex. But I am making an assumption about all of what's important to you.

It seems like what you are really looking for is an end-to-end trackable item that cuts across UI, PD, SI, Documentation and whatever other work needs to complete that trackable item from an end-to-end standpoint.

This is a lot like what most use case people want (and do). A single use case, spans UI, PD and SI (usually) but in your case Documentaiton would also be added.

Now, this could be done with the NunoFeature class discussed elsewhere in this thread. But I have to ask, if that's the thing that matters the most (i.e. the end-to-end or cross-aspect trackable item), then what does it matter tracking PD or UI or SI as discrete Aspects? If this end-to-end trackable item is the thing that matters, then what I think you should do is simply have one Aspect that contains these end-to-end Features (note: now they can be called Features because they now are an FDD Feature).

For example, you have one Aspect, and a Feature within it is "Register Customer on the Customer List" (using your example) and this Feature is not complete until it's UI, PD, SI and Doc is complete. What is the value to you, given such a cross-aspect focus, of tracking Aspects such as PD and UI discretely?

Now, if you go this way you will run smack into the problem of how to define sequential milestones for such an end-to-end Feature for the tracking to work.

This leads into the discussion of why it's better to decouple UI, PD and SI development than to tightly couple them by orienting around end-to-end Features such as use cases.

I never do this. But if someone wanted to, I think a single Aspect is worth consideration.

Jeff

Hi Nuno,

well there's a lot of issues raised in this thread to discuss and explain. I'm going to start with a feature as defined by FDD and feature as also used in your example.

First, let me make it absolutely clear. There is nothing wrong at all with anyone extending or adapting FDD in any way they like. I teach a whole topic on how to do this and on some of the more common and obvious adaptations in the FDD workshop. Also, as stated in the readme for this site, at the end of the day I am for whatever it is that works for people - whether that be FDD or an adapted FDD or something completely different.

So, you adding the concept of a project level trackable item that comprises one or more FDD features is fine if that works for you. What's not ok though is also calling this project-level trackable item a feature - because that is confusing. A feature is well defined in FDD. It's the functional deliverable that is contained by a Business Activity (and a Subject Area and an Aspect) and it has a number of milestones.

Since you also talked about modeling this, here's a model fragment of what that looks like.

In FDD as mostly described here and elsewhere, we talk about three common Aspects: PD, UI and SI. But you could create an Aspect for visibility and tracking of any other classification of functional deliverable or work item. e.g. testing or documentation. (Note: these other two aspects plus more were used in Singapore in 1997).

In plain english, the word feature can be problematic because it is easily overloaded. The most common case is similar to what you're suggesting. i.e. some higher level "marketing feature" that may even be thought of before any of the FDD processes have occurred. Note: this is just an example of overloading the word feature. I don't mean that this is necessarily what you ahve in mind regarding timing.

Now, here is a model fragment along the lines of what you're talking about with your project level feature - which I've called a NunoFeature in this model to avoid confusion with a Feature.

The models really make it clear that these two classes are really very different things.

A Feature has milestones, is directly contained by a BusinessActivity (and a SubjectArea and an Aspect).

A NunoFeature is at the level of a Project. It comprises one or more Features from one or more Aspects.

Think about the behaviours in these two classes. What they know. Who they know.

They're just not the same thing.

So, by all means, use your cross-aspect item for the additional tracking and traceability you seek. But calling that item also a feature is not "relaxing a constraint" as you put it. It is to confuse two different things.

Now, with that explained, it's easier to understand why you're saying what I've quoted below.

one the problems that I have with FDD is that just becouse a feature is 100% (in the PD, so in Reports) does not mean may not delivery of the feature is 100% garanteed (for instance, it is not on the user manual).

To paraphrase: just because a PD feature is 100% complete does not mean a feature is 100% complete because the Doc feature is not 100% complete.

This confusion only exists because of the overloading of feature you have applied.

The PD Feature from the PD Aspect is complete. The Doc Feature from the Doc Aspect is not complete. Thus, the NunoFeature (from the model above) that comprises this PD Feature and this Doc Feature is not complete.

Cool - just find a name for NunoFeature.

It's because you've added this other concept of feature that you've got this problem with FDD of an FDD feature being complete not meaning complete for you.

Jeff

So we can still just track the PD layer only, as FDD does traditionally (simply ignore any other aspects and report only the PD) or include any other Aspect in the reports that you may want.

This is incorrect. FDD traditionally tracks multiple Aspects - not just PD.

You could argue that it traditionally tracks only three Aspects - PD, UI and SI (as that's what most of the literature would lead any reasonable person to conclude). But, even the so-called poster-child FDD project in Singapore tracked more Aspects than just those three.

Here's a screengrab of part of project homepage for the Signapore Lending project. Five Aspects are being tracked.

Here's an old image referenced in a few threads here that shows how I report status to steering committees or top management. This shows the three Aspects being reported - not just PD (Business Logic).