Feature Driven Development

I wanted to anounce the launch of an FDD enabling tool - FDDManager.

To find out more and download an evaluation copy go to http://www.fddmanager.com.

I am interested in comments/feedback/feature requests

Cheers
Reece Robinson

Okay, I've been reading about FDD on and off for the past 9 months. The process makes sense and follows very closesly to other popular development processes. The most popular of which utilize Use Cases or User Stories in some shape or form. So, I'm confused on how Feature Sets and Features are not identical to Use Cases and their individual steps. What is wrong with writing a Use Case in the following manner:

UC 113 - Verify Hardware Module Properties

1. [Action] [Result] [Object]
2. [Action] [Result] [Object]
3. [Action] [Result] [Object]
4. [Action] [Result] [Object]
5. [Action] [Result] [Object]

Here's a paper by Jianxiong Pang and Lynne Blair on their refinements to FDD for Aspect Oriented programming.

Click here to read [TRESE]

This paper is written for Harvard University (Boston, USA).
It compares the two agile development methodologies:
Feature Driven Development and eXtreme Programming

Hello Everyone,

I have visited your site several times now and I have found the discussions very informative & thought provoking. They have helped me put my experiences with feature driven software development (in general but not FDD in particular) into perspective. I want to make this distinction since my experiences did not involve the use of the FDD methodology as it is proposed in this site, but rather, with ones where the product features drove the release schedule as well as the development (i.e. incremental release, themed release, Staged Delivery, etc…). I think that FDD is definitely more evolved than these others, but it too needs some more refinement, which of course is one of the goals of this site. Nevertheless, after having worked with RUP & XP, I truly think that FDD is the way to go.

All,

I have a question on how people think refactoring fits into FDD. It doesn't seem to fit to me, but I would still want to evaluate feature priorities including a refactoring task. In general, after reading the practical guide book, it seems like there is a lot of emphasis on the PD or the business area and not much cohesion between that and technical development aspects even though the book talks about UI and SI layers.

Thanks

Aaron

Hi,

I am involved in a somewhat larger project in the embedded domain. Traditionally, embedded systems have tremendously grown over the last couple of years whereas the ways of working have often remained, well, chaotic to ad-hoc at best. This also includes the way requirements are (not) captured.

In my cases, requirements come to us from Telco operators, product management, and a technical system group outside of the actual SW development. Our input is somewhere between Power Point and Excel.

In that context, I would have thought high-level use cases for capturing functional or at least the behavioral requirements would actually be a progress towards the right direction. However, having read about FDD I am somewhat confused. I have started wondering whether finer-grained features as suggested by FDD can be used INSTEAD of Use Cases or are a secondary step.

I love the new XML/GUI FDD Viewer tool. What do people use to track feature lists in general? Excel?

CALL FOR PAPERS

Cutter IT Journal

Jim Highsmith, Guest Editor

THE EVOLUTION OF AGILE PROJECT MANAGEMENT

The agile software development has always been, in part, about project
management, although the term "project management" carries a negative
connotation for some agile practitioners. But when you look at agile
software development methodologies such as DSDM, ASD, Scrum, Feature-driven
Development, and XP, you see that they all incorporate managing projects in
addition to their technical software development practices. XP, for example,
is weighted to technical practices (simple design, refactoring, etc.), but
it also has a few project management practices (iterative planning with
stories, for example). DSDM, on the other hand, has been almost entirely a
project management methodology with a few generic references to good
technical practices. Companies are now using agile project management (APM)
for projects beyond software development, and even hardware product
development efforts are using APM and other technical elements of agile
software development methodologies. New books are touting agile or adaptive
project management in their titles. Even the call for submissions for next
fall's PMI conference mentions APM.

I have a question about capturing requirements. I can see the usefulness of the feature naming template, especially as it seems to encourage a fairly fine granularity in the description of the features that can be described. What I do wonder though is how fine grained or even how generic a feature description could/should be. My concern is that we either spend too much time worring about the really nit-picky details early on, or that we end up providing estimates that are too short, or too long because our feature list isn't as fine-grained as it should.

Can anyone think of some examples of feature descriptions that they have considered either too generic, or too finely-grained for use under FDD? Is this something that only personal experience with FDD can teach us?