Feature-Driven Development
|
Jeff De Luca's, Feature-Driven Development (FDD) process is pragmatic, model-centric, client-valued-requirements-driven, and applicable for larger project teams than generally recommended for other agile processes. The Five FDD Process Descriptions... Recently a number of major organisations have decided to adopt agile processes with good results. Others have found that deciding to adopt an agile approach is not a guarantee of success and can be used as an excuse by immature development teams to deliver badly designed, poorly tested, undocumented software. Other organisations have chosen to adopt more formal, traditional, software engineering processes. While some of these organisations have had significant success, others have found their teams bogged down in the production of large specification documents, or delivering software that is not what the client needs or expected. No process can guarantee success but the disciplines imposed by FDD can help where other agile processes are insufficient or are simply too extreme to be a good fit for an organisation. It can also help where the delivery cycle times of more traditional processes are too long or the process is simply not flexible enough. However, FDD is not a silver bullet. It can never replace a good team of people. More about Process and People... FDD differs from Scrum and eXtreme Programming, the two most popular agile processes, in demanding that just enough effort be invested at the beginning of the process in exploring the structure of the problem usually by building an object model of the problem domain. This model has just enough detail to form a shared understanding, vocabulary, and conceptual framework for the project. Rather than the derogatory BDUF (Big Design Up Front) term, I call this the Jedi approach (Just Enough Design Initially) to software design. Knowing how much is 'just enough' is obviously the key and usually takes real experience (just as in the StarWars movies, you do not become a Jedi Master overnight!). FDD also differs in assigning ownership of code to individuals instead of the collective ownership practiced in eXtreme programming. Individual code owners dynamically form small teams called feature teams to design and implement a feature under the guidance of a lead developer (chief programmer). This self-organising approach of dynamic teams addresses the problems that require collective ownership in other processes while retaining all the tried and trusted benefits of code ownership, and enabling FDD to scale to larger team sizes. While not belittling the role of testing in the slightest, FDD recognises that peer reviews or inspections are a better means of removing defects and have significant secondary benefits. Some of the challenges of running effective peer reviews are reduced by the feature team ownership. In a design or code review in FDD it is not just one person's work being reviewed but work owned by a feature team. This is far less intimidating than being the only one on the hot seat which can prevent general acceptance of the practice by developers. Within reasonable bounds, the level of formality of the inspection is the feature team's call. For complex or high-impact features, the team's chief programmer will want to involve other members of the wider team. For straightforward and low-impact features only the feature team members need be involved, reviewing each other's contribution to the feature's implementation. More about FDD best practices... Jeff De Luca's Nebulon company provides FDD training courses and seminars (www.nebulon.com). You can ask also questions about and discuss FDD at the FDD Community website. |
A Practical Guide to Feature-Driven DevelopmentIn the spring of 2001, Peter Coad asked Mac Felsing and myself to write a book about Feature-Driven Development for his new Coad Series published by Prentice Hall. It was published in 2002, translated into Chinese, Japanese, and Russian, and is still the only book solely about using FDD. It would have been far better if Jeff De Luca had written it but he has always been too busy on other projects. Therefore, with Mac's help, I had a crack at writing up my understanding and experiences of FDD at that point in time.
A Practical
Guide to Feature-Driven Development Amazon links: www.amazon.com, www.amazon.co.uk, www.amazon.de, www.amazon.co.jp, www.amazon.ca, www.amazon.fr FDD was originally developed for a software development project at a leading regional bank in Singapore. More on where FDD came from... FDD defines six main roles and a number of supporting roles. More on roles within FDD... FDD comprises five processes, each described on one double-sided, letter sized (A4/B4) piece of paper. More on the five FDD processes... Like all good processes, FDD is built on, and blends together, proven industry disciplines, and best practices. More on the practices used... Communicating status and progress information meaningfully and accurately to all levels of leadership in a development is important in FDD. More on reporting progress... Requirements and design documentation is also important in FDD but the emphasis is on producing good results rather than good formatting of results. More on documentation ... People encountering FDD for the first time frequently ask about Technical Architecture and Testing. Other frequent questions are covered here. There are a number of books referred to A Practical Guide to Feature-Driven Development. This is a list of those referenced ...
|
Other related
web sites