domain and design model, but detailed design and dynamic interactions are done during the design by feature phase.
FDD Best Practices
That is the essence of the FDD process. It has the ability to fit securely in-between a set of front-end system engineering process of creating initial high level requirements, back-end process of system build/package, and independent system-level testing. It also resembles more traditional plan-based development in its approach to requirements, design and planning. Throughout the FDD process, the set of key or best practices that form the gears of the FDD machine are:
• Domain object modeling (typically using color modeling, though not always explicitly stated) done highly collaboratively with a chief architect and domain experts
• Iterative/incremental development driven by feature-sets and features as the units of integration, build, and promotion
• Feature teams, led by chief programmers
• Individual code ownership, on a per-class basis
• Inspections and reviews for models/designs, feature-lists, and code
• Regular builds
• Configuration management
• Visible and meaningful reporting of status/results
The first five practices above are evident from the description of the five processes of FDD. The later three practices are a bit less apparent and all strongly relate to CM, so let's discuss the CM aspects of FDD in a bit more detail in the next section.
FDD and SCM
Juha Kolska's 2003 report on Software Configuration Management in Agile Methods describes FDD as one of the few agile methods that explicitly mentions software CM (not just version control) and specific software CM practices as a key element. FDD contains the following practices that relate to configuration planning, identification and baselining,