What is Feature Driven Development (FDD)?

Asked

Viewed 1,373 times

7

I was researching about BDD, TDD and DDD and came across FDD (Feature Driven Development), after all:

  • What is FDD?
  • It has some relationship with BDD, TDD and DDD?

1 answer

7


It is one of many development models created in recent decades to make the software development process better. None of them has clear evidence of effectiveness and none is much different from using the general good sense about project management, each with its positive and negative bias. The only point that really differentiates it from other better known ones is not to have such a well done marketing and because/consequence does not have wide adoption, which generates a vicious cycle.

As the name says it focuses on specific features of the application. While preaching is an agile methodology, as everything seems to have to be to succeed, there is no clarity that is linked to small interactions, but it seems to follow the original basic precepts of what is agile, which almost anything fits.

It tries to compartmentalize the project more or less like it does with the code by making each Feature has an owner who is responsible alone. The other project members don’t need to understand anything other than the public contract they need to interact with the component. More or less like any project, including with frameworks and known public libraries. The question is who can get their hands on it. Which is cool, but depending on the size of the project this makes little sense and even is not feasible since teams are not stable, which ends up being a problem.

The important thing is that everything is thought of as Feature centrally. It has a flow chart of Wikipedia:

mostrando como vai decidindo como operacionalizar a metodologia

Directly has nothing to do with these other techniques or methodologies, but can be used together.

In general I do not like anything of these things that end in DD, by the way they are created. They may be useful, but they’re not as fundamental as people believe, and it changes little the way you develop software, if you know what you’re doing.

That is, it’s just another little manual of how you can manage your project, study it a bit and decide if it’s useful to you more than any other way. If you think so, dig deeper, apply, test, improve, and if you see that you have not given any benefit, that if you stop using it will have more benefits, do not hesitate to abandon.

  • 3

    The more I study these techniques/ methodologies, the more I understand "They may be useful, but they are not fundamental as people believe". I believe that each case is one, and in each of these cases some things will make sense and others not.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.