Online Sample Chapter
Feature-Driven Development: Best Practices
Table of Contents
Acknowledgments.
Foreword.
Preface.
Introduction.
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. Index.
Preface
Preface
What FDD Is!
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:
- Are you in charge of a group assigned to deliver a critical system with limited resources and short deadlines, and need help to organize the project?
- Are you tired of filling out so many process forms and reviewing so many documents that you don't have time to do your real work?
- Are you frustrated at the unfulfilled promises of process initiatives that claim to provide a way to deliver quality results repeatedly?
- Are you looking for a more efficient way to organize your team to streamline productivity, cut down on unnecessary interruptions, and improve the accuracy of reporting for your projects?
- Are you currently working on a project that is in trouble because the team has failed to produce a system?
- Do you want to add to the tools and techniques in your project management or team leader toolbox?
Prego (It's in There!)
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:
- Who should use FDD
- The roles, artifacts, goals, and timelines
- Why FDD includes the practices and techniques that it does
- The driving forces behind the development of FDD
- Adapting the use of FDD to different styles of projects
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.