David Anderson gave a talk on Feature Driven Development at Agile 2006. FDD is highly effective and produces high quality in a faster time to market. It increases productivity and quality and enhances team work. In FDD there is no overtime, no time tracking, no GANTT charts, no task tracking, and no time on task estimates.
FDD methodology involves developing an overall model at a high level and then building a feature list. Planning then proceeds by feature where each feature is designed in detail and then built in small code batches.
David defines a feature as a tiny piece of client valued functionality which can be delivered in less than 2 man weeks, typically 2 days. There are 4 types of features: User Interface, Problem Domain or Business Logic, System Interface, and Data Management or Persistence. A feature is written using the following format:
action result [of|to|from|for] object
Example: Calculate the interest for the bank account. This directly maps to the method name, return value, and class name. David then explains relating a feature to the model. A feature is a method on the domain model.
David then explains relating a feature to the model. A feature is a method on the domain model. There is 1 UML sequence diagram per feature. A feature set is related to a moment-interval on the domain model. All features in a set touch the same pink class on the model. A subject area is related to a chain of moment-interval.
Next David covers the Law of Demeter which ensures loose coupling by stating that classes should only depend on their immediate neighbors. This allows for postponed component definition and making decision at the last responsible moment. This enables componentizations of service orientation which allows building one big code base and breaking into components later and not having to refactor because interfaces between components are defined as the method signature on the classes.
Components are color coded pink, yellow, green and blue. They are re-usable enterprise components. The pinks and yellows are re-usable across multiple greens (the core enterprise components). The greens and blues are re-usable across discrete Enterprise Applications modeled as sequence of pinks.
FDD includes the concept of class or code ownership. This ensures that a class is not doing something it is not supposed to do from a design perspective. Classes are consistent and the api is concise. It also fosters collaboration and team work because if a feature is messaging a class owned by someone else, you need to work with that person.
David then compares bananas to requirement documents. He stresses that they are both perishable and thus cycle time is very important. He introduces CPW( Chief programmer work package) which is a collection or batch of features which can logically be grouped for development simultaneously and can be delivered within 2 weeks or less (each feature must be less than 2 weeks, each CPW must be less than 2 weeks). There is no timebox iteration in FDD. It is however long it takes, but must be less than 2 weeks.
Next feature teams are defined as dynamically formed per feature under guidance of chief programmer. All owners of relevant code are part of the team. This emphasizes team work and ensures that multiple minds collaborate on design and development.
David then provides some productivity statistics of using FDD and briefly covers configuration management in FDD using promotions groups instead of branch and merge techniques. Finally David gives some examples of dashboards used on his projects.
This presentation is available on InfoQ at http://www.infoq.com/presentations/fdd-crystal-agile-overview