Friday, January 15, 2010

Agile Simplified with Feature Driven Development



FDD differs from other Agile methods in its focus on upfront design and planning. As can be seen from the FDD process diagram in this picture, the Object Model, feature list, and planning are done once at the beginning of the project, and iterations are essentially an incremental building of identified features. This is not to say that the model, feature list, and plans never change; rather, it indicates that evolution of those items is not an inherent part of this method.



FDD practices

Domain Object Modeling

FDD begins with the construction of a relatively detailed object model for the system to be built. This model is not intended to provide all the design details for the features. Rather, its intention is to force all stakeholders’ assumptions out into the open and provide a road map for the project. Although the initial Object Model is built at the beginning of the project, each increment of development results in updates to it as details are filled in and corrections are made. Thus, the Object Model is a continually evolving picture of the product, as it is currently understood.

Developing by feature

The Object Model identifies all the expected classes in the system, but development is not done class by class. Rather FDD requires that development be done a feature at a time.

FDD defines a feature this way. “A feature is a small, client-valued function expressed in the form: Action - Result - Object

with the appropriate prepositions between the action, result, or object”. An example of a feature might be, “Retrieve the medical records of a patient.” As can be seen from the example, a feature is small and can normally be developed in a few hours or days. FDD defines the upper limit on feature size at 2 weeks. Because developing a feature can require additions or changes to several classes, the next two practices are included in FDD to define how this activity is managed.    

 

 

Class (code) ownership FDD prescribes that a single developer owns each class. This is diametrically opposed to XP’s practice of “collective ownership” and grows from a different philosophical basis. FDD depends on the class owner to have a full and detailed understanding of all that his or her class does and contains. The philosophy is that such an individual will be more efficient at making changes to a class than anyone else on the project team. Of course, the danger in this practice is that the loss of a team member can be catastrophic. This class ownership practice essentially requires that the class owner be directly involved in the development of each feature that affects his or her class. The next practice (feature teams) defines how this requirement is managed.   

 

Feature teams Each feature is implemented by a team of project members, consisting of the feature owner (a Chief Programmer) and the owners of all the classes affected by the feature. With direct participation of the expert on each class involved in the feature, that feature should be implemented not only very quickly but also in the most effective way. If, during a feature implementation, the team determines that another class must change, the owner of that class is simply added to the feature team. Thus, feature teams are a dynamic part of FDD, forming and disbanding on a daily or weekly basis as the development of each feature is undertaken and completed. Multiple feature teams will likely be operating at any one point in time, and each individual may be operating on more than one feature team at a time. A feature team has not completed its work until it has verified its feature and integrated it into the current product baseline.     

 

Inspections The primary purpose of an inspection is to detect defects in designs and code, but FDD identifies two other critical results of inspections. First, it mitigates the risks involved in the class ownership practice by ensuring that many team members have a good understanding of each class. And second, it is a forcing function to ensure that the project’s coding standards are adhered to consistently.      

 

Regular build schedule FDD does not prescribe any particular timing for builds, only that they be “regular.” How often builds are done must be defined for each project based on the project’s needs and constraints and the environment. Even so, FDD envisions that builds are done no less often than weekly, and possibly daily or continuously. Regular builds are done to maintain an up-to-date system comprised of all the features that have been developed to date. This current system then can be used as the baseline for testing each new feature, as a basis for writers to develop documentation, and as a continually available demonstration for customers and project sponsors.      

 

Configuration Management This FDD practice acknowledges the importance of good CM to the success of an FDD project. The dynamism of the feature teams and regular build schedule make it critical that the project carefully manage its artifacts. But FDD does not prescribe any specifics about CM. It simply directs that the project team practice a level of CM rigor that is appropriate to the project size, complexity, and scope.  

 

Reporting/Visibility of results FDD uses a unique mechanism for tracking and reporting the project’s status so that the common “90% complete” syndrome is avoided. This mechanism uses the project’s feature list and feature development milestones along with some weighting factors for those milestones. 

 

FDD defines the milestones for each feature to be: 

◗ Domain walkthrough—complete; 

◗ Design—ready for inspection; 

◗ Design inspection—and any rework and reinspection complete; 

◗ Code—ready for inspection; 

◗ Code inspection—and any rework and reinspection complete; 

◗ Promote to build—all feature code checked in and ready for the next build. 

 

Each FDD project team uses its historical data to assign a weight to each milestone. For example, if their data shows that they average 4% of their time in design walkthroughs, then that milestone is given a weight of 0.04 for every feature in the project. 

 

 

References 

Palmer, S. R., and J. M. Felsing, A Practical Guide to Feature-Driven Development, Upper Saddle River, NJ: Prentice-Hall, 2002.


Posted by at 12:51 AM

1 comments:

  1. Thanks a lot for this short and very concise description of FDD.
    However, I consider FDD not a "real" agile methodology because there is too much up-front effort needed. This is likely to introduce quite some waste on designing features that never will get developed because of changed requirements.

    Cheers,
    Urs

    ReplyDelete

Subscribe to: Post Comments (Atom)