A Practical Guide to Feature Driven Development (Coad Series) [Paperback]

This book is packed with good advice for developers and those involved in managing software development, and is clearly written by people with real world experience. The authors do a good job of explaining the issues in software development and how FDD helps address them.

The book is highly readable and should be accessible to those who currently have a limited understanding of formal software development processes. One of the themes carried through the book is an ongoing dialogue between the two authors and several other persons, including the project manager of a software project for a car dealership that is worked through in the book. At first I found this dialogue distracting, I guess because they were initially dealing with material I am already familiar with, but by the end of the book, I looked forward to these sections, and felt they gave the book an overall coherence.

FDD is most radical, in its approach to management (reporting), by dispensing with Gannt charts and estimates of task completeness (most people are aware of the 90% complete, 90% of the time, syndrome), replacing them with measuring features complete (as in 100% complete!) as a percentage of all features to be built. I am familiar with why Gannt charts and Microsoft Project style planning doesn't work for software projects, but the book would have benefited from a more detailed discussion of what will be the hardest part of FDD for many to accept. The book's only real fault is several digressions into software quality and online help, that it was hard to see the relevance of.

I recommend this book to people, including managers, who want to understand why we need software development processes and the issues involved in selecting one. The book, naturally enough, points out the issues with widely used processes such as RUP - too heavyweight, and XP - questionable scalability, and these criticisms are IMO largely valid. The book explains in a straightforward way, how FDD works and how it satisfies all the main requirements of a development process, especially scalability, manageability and getting the domain model (shape) right as early as possible, minimizing the need to refactor later.

The three part approach to the book makes it easy for you to find the topics you need to get your job done. Part 2 defines each of the processes in detail. Chapter 5, which covers reporting/tracking progress gives a good feel for the control you have in producing project deliverables, and reporting on the true progress of the project. Realistic, acurate reporting.

I would recommend this book to anyone who is a slave to their process, or even those that are new to process. This one works!

Although the approach is based on object-oriented development, and the book is focused towards that approach, it can be refactored into function- and procedure-oriented programming environments. Moreover, the book is written to fit within agile methods, but the approach can be fit to any development life cycle approach. This is because the focus is on features, which translate into what the business *needs* from an application. This is where elegance and simplicity comes in. By focusing on the features needed applications are less apt to be 'gold-plated' with unnecessary features that developers may think is nice, but add little business value. In this respect the time to deliver is shortened and what is delivered is going to reflect genuine business requirements.

The power of FDD comes from the highly structured approach that i based on the ETVX (entry-task-validation-exit) framework. Entry criteria is typical: requirements, authority to proceed and other 'quality gates' that must be passed before a development project is initiated. The tasks follow a five-step process as follows:
(1) Develop the model, including scope, validation in the form of walkthroughs, and peer reviews. The approach described in the book assumes an object model, but in a non-OO setting this can be realigned to first cut system diagramming in the form of block- and data flow-diagrams,and first-cut design.
(2) Build the features list. The OO approach is domain partitioning based on the model; in a non-OO setting this is where the team maps functional requirements to features.
(3) Plan by feature. This step, in my opinion, shows FDD to be a legitimate software engineering method. Feature prioritization, dependency analysis and effort estimation occur here. Done properly this step will make the difference between success or failure. I do have one issue with the book at this point: the prioritization is done by the technical team - it should be done with the business stakeholders.
(4) Design by feature. This is an iterative step that feeds back into step 1 (build the model) wherein class ownership is determined and the original model is refined based on the design approach. In non-OO environments this would loop back into the first-cut design and trigger trade-off analysis and design refinement.
(5) Build by feature. This is where the application is actually developed on a feature-by-feature basis within the context of the defined architecture (model).

Verification is accomplished using traditional methods. The authors introduce what they call 'feature-based testing' which is no different than product test (also called functional qualification testing, and in some circles, acceptance testing). Verification procedures are thoroughly covered in the book, further adding to the software engineering approach that is incorporated into FDD. Exit criteria is when the sponsors accept the system.

What makes this book important is that is gives a straightforward approach that is based on deliverables (features) within a process context (ETVX). This approach is consistent with best practices in software project management and has the additional benefit of assuring that what gets designed and built is what the customer needs. Bolt FDD onto your favorite methodology and you'll probably see quality increase, and costs and time to deliver decrease.