Sunday, August 29, 2004

Feature Driven Development

In my last post I said that I would be building Sydney using an agile influenced code and fix methodology. Of those agile influences, Feature Driven Development (FDD) is likely to be the strongest. FDD isn't particularly well known so I've devoted this post to describing it.

This isn't the methodology I'll be using for Sydney, but it is where I'm going to steal a lot of ideas from.

What is Feature Driven Development?

From the book "A Practical Guide to Feature Driven Development", here's the authors guide to FDD in four sentences.

FDD starts with the creation of a domain object model in collaboration with Domain Experts. Using information from the modeling activity and from any other requirements activities that have taken place, the developers go on to create a features list. Then a rough plan is drawn up and responsibilities are assigned. Now we are ready to take small groups of features through a design and build iteration that lasts no longer than two weeks for each group and is often much shorter - sometimes only a matter of hours - repeating this process until there are no more features.

FDD is an agile software development methodology created by Jeff DeLuca of Nebulon Software. Like most modern methodologies it is based around iterative rather than waterfall development. FDD emphasises customer involvement and provides excellent transparency to both the developers and the customers through simple yet effective progress reporting procedures. Unlike some other agile methodologies FDD does incorporate initial design efforts and is designed to be easily scaled upwards to incorporate large development teams.

FDD is composed of 5 processes, with each process able to be described in 1-2 pages. The whole FDD methodology can be downloaded and printed out in just a few pages.

The 5 processes

  1. Develop an overall model
    • Form the modeling team
    • Domain walk-through
    • Study documents
    • Develop the model
    • Refine the overall object model
    • Write model notes
  2. Build a features list
    • Form the features list team
    • Build features list
  3. Plan by feature
    • Form the planning team
    • Determine the development sequence
    • Assign business activities to Chief Programmers
    • Assign classes to developers
  4. Design by feature - Start of iteration for one or more features
    • Form feature team
    • Domain walk-through
    • Study the referenced documents
    • Develop the sequence diagrams
    • Refine the object model
    • Write class and method prologues
    • Design inspection
  5. Build by feature - When features completed return to process 4
    • Implement classes and methods
    • Code inspection
    • Unit test
    • Promote to the build

Some FDD curiosities you might be interested in

A feature is the basic unit of development and is a task that can be completed within a 2 week timeframe. All features must be expressed in customer valued terms stating an action that a customer will perform using the system.

The object model is designed in the without first writing requirements documents and with the customers present and directly involved in modeling process.

There are one or more Chief Programmers who for each iteration assemble a different team of junior developers.

Each class is owned by a particular developer and only they are permitted to work on that class.

Code inspections and unit tests are used to ensure the ongoing quality of the system.

With FDD it is possible to give an accurate statement of your progress as a percentage. This is because FDD doesn't ask developers how much they've completed, instead it tells them how much they've completed.

More information

Your first stop for more information on FDD is the FDD website at Nebulon Software and the FDD community site both maintained by Jeff DeLuca. The online FDD community is reasonably active and the signal to noise ratio is generally quite high.

In regards to published material it isn't necessary to read a thick book to follow FDD and for some time there was no book dedicated to FDD at all. Eventually of course such a book was written, "A Practical Guide to Feature Driven Development" by Stephen Palmer and John Felsing, who have worked with the creator of FDD, Jeff DeLuca, on past projects.

I have mixed feelings about this book. On the one hand it is a valuable source of information providing answers to the many questions that are raised by the original 5 processes document. On the other hand even though it's not a particularly long book I feel that provides too much information and doesn't present it in a particularly well organised fashion. It's a book that I've tried to read right through several times but each time have failed to finish. Maybe it's just me, I'm not sure. Until something better comes along though, I do recommend you buy a copy if you'd like to learn more about FDD.

There is one more published source of information on FDD available that I'm aware of. There is a book by Peter Coad called "Java Modeling in Colour". The last chapter in that book is an explanation of FDD written by Jeff DeLuca. This book is harder to find these days, but you can download that particular chapter as a PDF file.

1 Comments:

At 3:17 AM, Blogger i_answer_to_john_most_of_the_time said...

Hi, like your blog. I've had to merge a couple of the agile methods to accomadate the business side and development side of the equalations. This was due to the large nature of the company I'm helping to get jump started using agile methods. Anyway, I've combined some of the good points of FDD then use scrum. It seem to work very well. john cook john_chess01@yahoo.com

 

Post a Comment

<< Home