FDD Process #2: Build a Features List

With the first activity being to build an object model, some may conclude FDD is a model-driven process. It is not. While the model is central to the process, an FDD project is like a Scrum or eXtreme Programming project in being requirement-driven. Small, client-valued requirements referred to as features drive the project; the model merely helps guide. Formally, FDD defines a feature as a small, client-valued function expressed in the form: <action> <result> <object> (e.g., “'calculate the total of a sale'”) [Palmer-1]. By small, we mean a feature typically takes 1-3 days to implement, occasionally 5 days but never 10 or more days to implement.

Unlike Scrum and eXtreme Programming that use a flat list of backlog items or user stories, FDD organizes its features into a three level hierarchy that it unimaginatively calls the feature list. Larger projects/teams need this extra organization. It helps them manage the larger numbers of items that are typically found on an FDD features list than on a Scrum-style backlog.

To define the upper levels in the feature list hierarchy, the team derives a set of domain subject areas from the high-level breakdown of the problem domain that the domain experts naturally used during the object modeling sessions. Then within these areas, the team identifies the business activities of that area and places individual features within one of those activities. Therefore, in the features list we have areas containing activities that in turn contain features.

In practice, building the features list is a formalization of the features already discussed during the development of the object model. For this reason, lead developers or Chief Programmers can perform this task using the knowledge they gained during the modeling (FDD refers to lead developers as Chief Programmers in honor of Mills/Brooks idea of ‘surgical teams’ [Brooks]). Other members of the modeling team including the domain experts provide input to, and verification of the list as necessary.

Not only does this avoid the problems often encountered when customers/domain experts that are unused to doing this sort of formal decomposition try to do it, it provides another level of assurance that the Chief Programmers do understand what is required.

In addition, the ubiquitous language the model provides helps phrase features consistently. This helps reduce frustration in larger teams caused by different domain experts using different terms for the same thing or using the same terms differently.

Fonte: http://agile.dzone.com/articles/introduction-feature-driven