Feature Driven Development (FDD), created by Peter Coad and Jeff de Luca, combines the compelling advantages of agile methodologies with model-driven techniques that scale to the largest teams and projects. This book demonstrates FDD at work in real-world projects, giving project leaders all the information they need to successfully apply it in their own organizations. The authors begin by introducing FDD's goals and rationale, and the compelling advantages of its model-driven, short-iteration approach to software development. You'll discover which types of projects FDD is best suited for; and understand FDD's roles, artifacts, goals, and timelines. The book includes practical, hands-on coverage of all five key FDD activities: developing an overall model, building a feature list, "plan by feature," "design by feature," and "build by feature." The book also offers specific guidance on adapting FDD to many different types of projects.
I. FEATURE-DRIVEN DEVELOPMENT—CONCEPTS.1. Process Pride: The Pain and Relief.
Process Pride. The Search. Communication, Communication, and Communication. Complexity. Quality. Process Pain and Relief. Summary.2. Feature-Driven Development—Projects and People.
The Big Three. Process and People. The Roles People Play in FDD. Summary.3. Feature-Driven Development—Practices.
Integrating Best Practices. Domain Object Modeling. Developing by Feature. Class (Code) Ownership. Feature Teams. Inspections. Regular Build Schedule. Configuration Management. Reporting/Visibility of Results. Summary.4. Feature-Driven Development—Processes.
The Scope of Feature-Driven Development (FDD). FDD in Four Sentences. FDD in a Nutshell. FDD in Detail. Summary.5. Feature-Driven Development—Progress.
Time: A Scarce Resource. Estimating Progress. Track by Feature. Reporting to the Development Team. Reporting to the Chief Programmers and Project Manager. Reporting to Sponsors and Upper Management. Chief Programmer Plans. Feature Kills. Summary.6. Feature-Driven Development—Packages.
Chief Programmer Work Packages. When You Have to Produce a Mountain of Paper. Summary.
II. FEATURE-DRIVEN DEVELOPMENT—THE FIVE PROCESSES IN PRACTICE.7. Develop an Overall Object Model.
The Form the Modeling Team Task. The Conduct a Domain Walkthrough Task. The Study Documents Task. The Develop Small Group Models Task. The Develop a Team Model Task. The Refine the Overall Object Model Task. The Write Model Notes Task. Verification. Exit Criteria.8. Feature-Driven Development—Build a Features List.
The Form the Features List Team Task. The Build the Features List Task. Verification. Exit Criteria.9. Feature-Driven Development—Planning Feature Development.
The Form the Planning Team Task. The Determine the Development Sequence Task. The Assign Feature Sets to Chief Programmers Task. The Assign Classes to Developers Task. Verification. Exit Criteria.10. Feature-Driven Development—Designing by Feature.
The Form a Feature Team Task. The Conduct a Domain Walkthrough Task. The Study the Referenced Documents Task. The Develop the Sequence Diagram(s) Task. The Refine the Object Model Task. The Write Class and Method Prologue Task. Verification: Design Inspection. Exit Criteria.11. Feature-Driven Development—Build by Feature.
The Implement Classes and Methods Task. The Conduct a Code Inspection Task. The Unit Test Task. The Promote to the Build Task. Verification. Exit Criteria.
III. FEATURE-DRIVEN DEVELOPMENT—ADDITIONAL TOPICS.12. Feature-Driven Development—Technical Architecture.
Technical Architecture. Technical Architecture in an FDD Project. The PD Layer. The SI Layer. The UI Layer. The DM Layer. Layers and the Build. Reducing Dependencies between Components.13. Feature-Driven Development—Testing: Failures, Faults, and Fixes.
Kinds of Testing. Failures, Faults, and Fixes. FDD and Unit Testing. FDD and Integration Testing. FDD and System Testing. Customer/User Acceptance Testing. Finding Failures. Reporting Failures. Diagnosing Defects. Fixing Faults. The Defect Board. Summary.14. Feature-Driven Development—Other Surroundings.
Requirements Change Management. User Documentation. Data Loading and Conversion. Deployment. Summary.15. Feature-Driven Development—“All Change”.
People and Change. Technology and Change. Process and Change. Last Words.References.
Feature-Driven Development (FDD) is a process designed and proven to deliver frequent, tangible, working results repeatedly. This is the first book to spell out the day-to-day details of using FDD on a real project, giving development team leaders all the information they need to apply FDD successfully to their situations.
FDD is a straightforward approach to producing systems that uses simple, easy-to-understand and easy-to-implement methods; problem-solving techniques; and reporting guidelines providing every stakeholder of a project with the information they need to make sound, timely decisions.
Programmers are provided with the information and supporting infrastructure they need to produce applications. Team leaders and managers get timely information about their teams and projects that allows them to reduce the project risk. Project managers and executive sponsors see the current project status and trouble areas so that they can actually make timely, informed decisions in a controlled, planned manner (no knee-jerk reactions). Reporting becomes easy, relatively painless, timely, and accurate!
Users (customers, sponsors, end users) can actually see areas of their business automated as the project progresses and give early, constructive feedback about the system while it is being developed. At the same time, the development team has the tools and information it needs to control "scope creep!"What FDD Is Not!
FDD is not yet another process that takes up resources, time, and money but just doesn't produce the needed results. It is not another method whereby administrators, bureaucrats, and process-centric fanatics can focus everyone's time and energy on producing reams of printouts and signatures with nothing to show for it. FDD is not another set of process volumes that will sit on your shelf, collecting dust and impressing your supervisor, co-workers, and significant others with your knowledge of another less-than-useful set of directions for producing systems.Why Should I Read this Book? (What's in it for Me?)
If any of the following questions apply to you, you will find the answers you are looking for on the following pages:
Although FDD was first introduced in print in Java Modeling in Color with UML Coad 99, we give a more thorough coverage of the topic. We point out the critical tips for success, as well as the pitfalls that may not be apparent from a cursory glance. Contents include:
FDD blends a number of industry-recognized best practices used successfully by Peter Coad, Jeff De Luca, and others in their consultancies. These practices are all driven from a client-valued feature perspective. It is the potent combination of these techniques and practices that makes FDD so compelling.