Feature Driven Development (FDD)

There are so many development methodologies out there; each promising to solve our software development nightmares. Each promising to make software development easier. I will not even go on to suggest that there is any one or two methodologies that work.

The methodology you choose depends on:

• Your organizations experiences.
• Your team dynamics and skills.
• And of course how much confidence you have on the selected methodology.

Often I have worked with teams that follow home-grown methodologies that are lite and tuned to what that organization believes is the best way for them to get work done. Fair enough.

I worked on one project a while back that used the Feature Driven Development (FDD) agile process. Personally to me the success of a methodology depends on how simple it is to understand. Software development happens in three main areas: requirement gathering, coding it and testing. Everything else is done to support these three related tasks. FDD is a relatively simple process; which is what attracted me to it. And I am living proof that it worked when we used it. Though in hindsight we did not formally follow every step as prescribed.

So what is FDD. FDD is an agile iterative development process. The dictionary defines agile as 'moving quickly and lightly'. When you hear agile look for that meaning. If you look in your process and you do not see that then you are not in an agile process. Seems obvious ah! You need to change your mindset and work culture to fit agile. Organizations that are not agile often have difficulty moving towards agility. Then there are those that are agile since many years before the buzzword agile development even came along.

Being agile to me does not mean you do away with traditional requirements gathering procedures and mechanisms. You still have to gather detailed requiurements. I often see Ruby On Rails developers prescribe that framework as the framework to choose for agile development of web projects. Look up on that on your own. They have a childish view of the development world where there is no corporate politics, there is no need to gather requirements upfront (gather as you code...best of luck), the business users seem to have all the time to sit with the developers, etc. The real world is often quite different. Dont get me wrong. I like Ruby and Ruby On Rails. I think Java has a lot to learn from there.

FDD is divided into 5 main activities. Each activity encompasses a set of steps that seem so obvious in software development. It does not do away with requirements gathering or any other step. It just places them in the right activity. Here are the five activities and what I think are some of the things

• Develop Overall Model: Work with analysts/business users to get the application domain model defined. Based on the complexity of the application you may divide the project into many sub-domains and create a domain model for each area. You would gather high level requirements and may even be doing some use cases in this phase, though I doubt that will happen this early. Lot of interaction with business users during this phase.
• Build Feature List: Work with project management to define and create the feature list for the current release. The feature list should reflect business users priorities. Features should be as small as possible to implement in terms of time.
• Plan By Feature: Organize your features in terms of priority (related to client needs as well as development). For every feature we capture LOE (level of efforts). Drop your features into interations, each no longer than 4 to 6 weeks in duration. LOE should include design, coding and testing (if possible include reviews). Plan for dropping each feature into a QA test environment. For subsequent iterations (after the first) keep aside some time to fix defects and changes to earlier iteration. You can even increase by a week or so subsequent iterations. This filler time you can adjust as needed based on outstanding defect count and change requests.
• Design By Feature: Developers get your hands dirty now. Draw up class diagrams, sequence diagrams for current iteration.
• Build By Feature: Code it and drop iteration into QA enviornment.

One step I feel is missing is a 'Test By Feature'. This is so that the QA teams work can get recognized as a critical part of development and can be planned in advance.