First came TDD (Test Driven Development), then came BDD (Behavior Driven Development) and finally DDD (Domain Driven Design)...and now FDD. Are we craizy ?...Probably ;).
I will not explain in deep the concepts TDD, BDD and DDD (you can googling about that), but note that each concept is related to a different detail level of the development. Let me explain you with a simple example.
If you have to implement a technical design, for example a simple class called HelloWorld, you can use TDD to assure that your technical design is well implemented, in other words your class HelloWord covers all the requirements specified in the technical design, parameter preconditions, exception handling, and so on. After that, if this class is used to implement some features, you can use BDD to assure that all acceptances criteria are achieved. Finally you can orchestrate the growth of your software using the paradigm exposed by DDD.
Once we are in situation, we can think about the magic question. Where FDD fit with all of this? Sometimes an image says more than thousand words.
Your development is FDD complaint when you assure that your CTO, Product Owner, software architecture, software analyst or software developer are working well focused, and this correct focus is well propagated to the different software stages.
FDD is like a good smoothie with TDD, BDD and DDD as ingredients.
No comments:
Post a Comment