Home :: Books :: Computers & Internet  

Arts & Photography
Audio CDs
Audiocassettes
Biographies & Memoirs
Business & Investing
Children's Books
Christianity
Comics & Graphic Novels
Computers & Internet

Cooking, Food & Wine
Entertainment
Gay & Lesbian
Health, Mind & Body
History
Home & Garden
Horror
Literature & Fiction
Mystery & Thrillers
Nonfiction
Outdoors & Nature
Parenting & Families
Professional & Technical
Reference
Religion & Spirituality
Romance
Science
Science Fiction & Fantasy
Sports
Teens
Travel
Women's Fiction
A Practical Guide to Feature-Driven Development

A Practical Guide to Feature-Driven Development

List Price: $39.99
Your Price: $34.58
Product Info Reviews

<< 1 >>

Rating: 5 stars
Summary: Packed with good advice on Software Development Process!
Review: Feature Driven Development is a lightweight iterative software development process promoted by TogetherSoft that occupies the middle ground between heavyweight, high ceremony processes like RUP and lightweight programming-focused processes such as Extreme Programming.

This book is packed with good advice for developers and those involved in managing software development, and is clearly written by people with real world experience. The authors do a good job of explaining the issues in software development and how FDD helps address them.

The book is highly readable and should be accessible to those who currently have a limited understanding of formal software development processes. One of the themes carried through the book is an ongoing dialogue between the two authors and several other persons, including the project manager of a software project for a car dealership that is worked through in the book. At first I found this dialogue distracting, I guess because they were initially dealing with material I am already familiar with, but by the end of the book, I looked forward to these sections, and felt they gave the book an overall coherence.

FDD is most radical, in its approach to management (reporting), by dispensing with Gannt charts and estimates of task completeness (most people are aware of the 90% complete, 90% of the time, syndrome), replacing them with measuring features complete (as in 100% complete!) as a percentage of all features to be built. I am familiar with why Gannt charts and Microsoft Project style planning doesn't work for software projects, but the book would have benefited from a more detailed discussion of what will be the hardest part of FDD for many to accept. The book's only real fault is several digressions into software quality and online help, that it was hard to see the relevance of.

I recommend this book to people, including managers, who want to understand why we need software development processes and the issues involved in selecting one. The book, naturally enough, points out the issues with widely used processes such as RUP - too heavyweight, and XP - questionable scalability, and these criticisms are IMO largely valid. The book explains in a straightforward way, how FDD works and how it satisfies all the main requirements of a development process, especially scalability, manageability and getting the domain model (shape) right as early as possible, minimizing the need to refactor later.

Rating: 5 stars
Summary: Excellent book on a topic long over due.
Review: I have been doing feature driven development for over 3 years. It is an effective, efficient process. Many times I wished that I had a definative source on that topic. Finally one has arrived.

The three part approach to the book makes it easy for you to find the topics you need to get your job done. Part 2 defines each of the processes in detail. Chapter 5, which covers reporting/tracking progress gives a good feel for the control you have in producing project deliverables, and reporting on the true progress of the project. Realistic, acurate reporting.

I would recommend this book to anyone who is a slave to their process, or even those that are new to process. This one works!

Rating: 5 stars
Summary: Excellent book on a topic long over due.
Review: I have been doing feature driven development for over 3 years. It is an effective, efficient process. Many times I wished that I had a definative source on that topic. Finally one has arrived.

The three part approach to the book makes it easy for you to find the topics you need to get your job done. Part 2 defines each of the processes in detail. Chapter 5, which covers reporting/tracking progress gives a good feel for the control you have in producing project deliverables, and reporting on the true progress of the project. Realistic, acurate reporting.

I would recommend this book to anyone who is a slave to their process, or even those that are new to process. This one works!

Rating: 4 stars
Summary: Lower your risk on large business software development
Review: Since there already three very complete customer reviews, I just wanted to add a couple of points for people who, like me, haven't used this approach to project management before.

The authors stress that feature-driven development, as they describe it, is intended for a very specific type of project. There's nothing new in the book, except the way the authors have combined tried-and-true techniques to handle very large business application development in a consistent and low-risk manner. The smallest headcount that could justify the overhead is about twenty, although it could scale up almost indefinitely. Palmer and Johnson describe their methodology as light but, on a scale of five (heavy) to one (agile), FDD rates about a four.

The second point is that the techniques used assume very heavy customer involvement and clearly understood business rules. For example, the original project that inspired the book was a banking system in Asia. The procedures wouldn't be well-suited to innovative product development in a competitive environment. This is no alternative to extreme programming.

Lastly, the methods used aim to get good results from inexperienced employees. Despite a reminder that highly-ranked programmers are better value than entry-level personnel, this type of project often relies on an army of tightly-controlled programmers, led by a few experienced team leaders. Although the authors differentiate the FDD organization from the old Chief Surgeon model, this is still basically just a variant on that theme.

There are also more than a few hints that the book is not intended solely, or even primarily, for US readers. We are abjured to speak in English and leaders are advised to use a soccer whistle to control meetings. As beautifully as the authors describe how to divide up a large project by feature (and it is beautifully clear and simple), some of the advice in handling personnel leads me to hesitate before recommending it without reservation to every potential reader, which is the criterion Amazon requires for a 5-star rating.

Rating: 5 stars
Summary: Elegant, Effective and Powerful
Review: The Feature-Driven Development (FDD) method proposed and described in this book is elegant in that it combines simplicity and power, and effective because it will deliver applications that support business requirements.

Although the approach is based on object-oriented development, and the book is focused towards that approach, it can be refactored into function- and procedure-oriented programming environments. Moreover, the book is written to fit within agile methods, but the approach can be fit to any development life cycle approach. This is because the focus is on features, which translate into what the business *needs* from an application. This is where elegance and simplicity comes in. By focusing on the features needed applications are less apt to be 'gold-plated' with unnecessary features that developers may think is nice, but add little business value. In this respect the time to deliver is shortened and what is delivered is going to reflect genuine business requirements.

The power of FDD comes from the highly structured approach that i based on the ETVX (entry-task-validation-exit) framework. Entry criteria is typical: requirements, authority to proceed and other 'quality gates' that must be passed before a development project is initiated. The tasks follow a five-step process as follows:
(1) Develop the model, including scope, validation in the form of walkthroughs, and peer reviews. The approach described in the book assumes an object model, but in a non-OO setting this can be realigned to first cut system diagramming in the form of block- and data flow-diagrams,and first-cut design.
(2) Build the features list. The OO approach is domain partitioning based on the model; in a non-OO setting this is where the team maps functional requirements to features.
(3) Plan by feature. This step, in my opinion, shows FDD to be a legitimate software engineering method. Feature prioritization, dependency analysis and effort estimation occur here. Done properly this step will make the difference between success or failure. I do have one issue with the book at this point: the prioritization is done by the technical team - it should be done with the business stakeholders.
(4) Design by feature. This is an iterative step that feeds back into step 1 (build the model) wherein class ownership is determined and the original model is refined based on the design approach. In non-OO environments this would loop back into the first-cut design and trigger trade-off analysis and design refinement.
(5) Build by feature. This is where the application is actually developed on a feature-by-feature basis within the context of the defined architecture (model).

Verification is accomplished using traditional methods. The authors introduce what they call 'feature-based testing' which is no different than product test (also called functional qualification testing, and in some circles, acceptance testing). Verification procedures are thoroughly covered in the book, further adding to the software engineering approach that is incorporated into FDD. Exit criteria is when the sponsors accept the system.

What makes this book important is that is gives a straightforward approach that is based on deliverables (features) within a process context (ETVX). This approach is consistent with best practices in software project management and has the additional benefit of assuring that what gets designed and built is what the customer needs. Bolt FDD onto your favorite methodology and you'll probably see quality increase, and costs and time to deliver decrease.


<< 1 >>

© 2004, ReviewFocus or its affiliates