Feature Driven Development

"Agile development is an attitude, fitted with selected policies and techniques. It is achieved by the sponsors, managers, and developers, jointly.

This conference is an integrated, 4-day conversation about those attitudes, policies, techniques; about both development and management; accessing the latest thinking and bridging communities that rarely get a proper chance to exchange thoughts." Alistair Cockburn, conference chair.

"Agile Software Development is an emerging and dynamic discipline. The overriding objective of the Agile Development 2003 Conference is to spread knowledge about the state-of-the-art in Agile Development practices and provide a forum for advancing the state of the art.

After reading the discussions on continuous frequent delivery, I was reminded of some misconceptions regarding the "two weeks" rule that's mentioned in FDD.

Firstly: what is it? When building the features list in process #2 we decompose the domain into a Subject Area (SA), Business (BA) and Feature hierarchy. The guideline for the granularity of features is that it should take no more than two weeks to complete, i.e. to put through processes #4 and #5 (design and build by feature). If it's bigger than that we break it down further.

The first common misconception is that all features are two weeks long, and that we perform processes #4 and #5 for a single feature that lasts for two weeks. This isn't how we do it. There's a discussion of workflow elsewhere on this site, but bascally the Chief Programmer (CP) bundles up a set of features into a work package, forms a feature team, and then takes the package through processes #4 and #5. The size of the work package is not fixed, and depends on a lot of factors. There is no hard-and-fast rule about how big a work package should be.

This is hardly a surprise move but it still will be very interesting. Read the story here.

In this article, I would like to look at the Agile Manifesto Principles and see how FDD relates to each.

This article is only a draft, and feedback is actively solicited!

Agile processes have rapidly gained mindshare over the last few years as practitioners, disillusioned with the so-called "heavyweight" processes have sought to find better ways of delivering software to spec.

FDD was around before the Agile Manifesto was published. But FDD seemed to be aligned with the values expressed in the Manifesto, and thus was placed under the same Agile umbrella term. There are quite a few processes that fall under this same umbrella; apart from eXtreme Programming and FDD, there is Scrum, and others.

FDD says nothing how requirements are formulated prior to process 1 - Develop an Overall (Domain) Model. In fact FDD downplays the importance of formal requirements and stresses the importance of participation of Domain experts. I know in part this is due to Jeff's, far from unique, prior experiences with Use Cases!

I have commented that - Any idiot can write a Use Case, and most of them do! What I mean by this is that the Use Case format and notation is loose and you can put pretty much anything in a Use Case format. This problem is exacerbated by Business Analysts who, while they understand the business, often have a limited grasp of what software developers need and can use. An additional problem is what I call the paid-by-word syndrome - aka more is better!

The site has just been updated to the latest version of drupal. The "number of reads" against stories and comments (and other node types) is a new feature and these counts have only just been switched on. ***UPDATE*** The forums and Files section are back online.

I spotted this post on the Scrum Development list and thought it worthy of reposting here.

---------------------------------------------------------------------------

CALL FOR PAPERS

1st Workshop on

Knowledge Management for Distributed Agile Processes:
Models, Techniques, and Infrastructure
(KMDAP '03)

for the

Twelfth IEEE International Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises (WET ICE '03).