Feature Driven Development

I don't understand why Feature Driven Development is not as known as other agile methods. Maybe it's because there are not so visible things like 2 programmers siting behind 1PC (extreme programming), people standing while short meetings (SCRUM)...

It's based on small pieces of final product with real additional value for customer  which are called features. There are 5 basic activities. During the first three of them (Develop Overall Model, Build Feature List and Plan by Feature) you establish an overall model shape. And the rest (Design By Feature and Build by Feature) are repeated for every feature. There is a nice process model diagram for this activities.

Feature-Driven Development is built around a core set of industry-recognized best practices. Part of Wikipedia article follow:

1. Domain Object Modeling. Domain Object Modeling consists of exploring and explaining the domain of the problem to be solved. The resulting domain object model provides an overall framework in which to add features.
2. Developing by Feature. Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. This makes it easier to deliver correct functions and to extend or modify the system.
3. Individual Class (Code) Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class.
4. Feature Teams. A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen.
5. Inspections. Inspections are carried out to ensure good quality design and code, primarily by detection of defects.
6. Configuration Management. Configuration management helps with identifying the source code for all features that have been completed to date and to maintain a history of changes to classes as feature teams enhance them.
7. Regular Builds. Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early.
8. Visibility of progress and results. By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.

For me is it very well combined "old" (model-centered) and "new" (agile) concept of development process for middle-sized projects, but I haven't try it for any project yet.

I have a few question:

1. Do you know FDD?
2. Do you use FDD?
3. What do you thing about?
4. Which software do you use for support FDD?

Resources:

1. Feature-drive development (Wikipedia, EN)
2. http://www.featuredrivendevelopment.com/ (Community, EN)
3. Feature driven development (Chapter 6 of book Java Modeling in Color with UML, EN)
4. Feature-driven development and the ‘5 Ds of Done’ (Edward Kay, EN)
5. Metodika feature-driven development neopouští modelování a procesy... (PDF, Alena Buchalcevová, CZ)
6. Metoda FDD (překlad Jiří Sochor, CZ)