|Title:||A Practical Guide to Feature-Driven Development|
|Authors:||Stephen R. Palmer, John Mac Felsing|
Feature-Driven Development (FDD) is Jeff De Luca's pragmatic, agile approach to developing software. It combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership. It also happens to be one of the most satisfying ways of working in a software development team that I have experienced.
In 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.
The book 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, 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.
You can ask questions about and discuss FDD at Jeff De Luca's FDD Community website.Jeff's company, Nebulon, also provide workshops, mentoring and certification in FDD .
Table of Contents:
- Chapter 1: Process Pride
- Chapter 2: Projects and People
- Chapter 3: Practices
- Chapter 4: Processes
- Chapter 5: Progress
- Chapter 6: Packages
- Chapters 7-11: Five Processes in Practice
- Chapter 12: Technical Architecture
- Chapter 13: Testing
- Chapter 14: Other Surroundings
- Chapter 15: All Change
The introduction describes the origins of the Feature-Driven Development process and introduces the key people involved with its beginnings. Read more on this...
The foreword expands a little more on the history and the people involved. The foreword is written by Peter Coad who is also the series editor
The introduction also introduces the example used throughout the book and explains why the authors slip into role playing dialogues every now and again.
Chapter one seeks to answer the question, "Why do we have to manage software development?".
The first half-dozen pages seek to describe how we arrived at where we are today in terms of software development processes. It looks at the rise of so-called heavyweight processes and methods, contrasting that with the recent popular rebellion against them in favour of what we now call agile processes.
The chapter then proceeds to explore the major challenges facing significant software development projects and derives a mission statement and list of values for a good software development process.
The chapter also contains a strong warning about concentrating on process definition and process compliance at the cost of real results.
I actually regret making this the first chapter. If I had my time again, I would probably start with chapter four and work back to the material in chapter one. This way the reader could quickly become immersed in FDD without having to wade through a largely theoretical chapter before doing so.
Being the first chapter I wanted to have a little fun so Tolkien's Lord of the Rings and my favourite poem from my high school days are put to good use to describe process extremes that I have unfortunately experienced both before and since writing the book. Incidentally the Crimea War, of which the Charge of the Light Brigade is a part, is a fascinating subject for those who like military history.
Managing communication, complexity, and quality are the three major challenges listed in the chapter. I have recently added the more nebulous project momentum or, conversely, project inertia to my list. I frequently encounter projects stalled in certain activities unable change gear, or change direction without disproportionate amounts of effort. Analysis paralysis is probably the most obvious where a project does not seem to be able to get beyond the writing of use case descriptions or functional specifications. Conversely, projects where development succeeds in making it through the first few iterations build a momentum that makes it harder to knock the project off course. In other words, another argument for short value driven iterations like those used in FDD.
An early draft of part of this chapter was published as CoadLetter #84.
This chapter seeks to address the question, "Who do have to manage in software development"?
The chapter first discusses project roles in general.
It then takes a step back and explores the impact of people on process. It criticises project management approaches and tools that treat people as interchangeable software producing machines. A large sidebar introduces some ideas for attracting, recognising and keeping good developers because good developers can be many time more productive than average developers.
I remain firmly convinced that an organisation is better off working on attracting, recognising, and keeping good people than spending enormous amounts of money and effort on defining and enforcing a mandatory, all encompassing process.
This is not to say that every developer needs to be some sort of superhero-programmer. Often the superhero programmer are poor team players and cause as many problems as they solve. A good developer understands that he or she is incapable of developing the software on their own, values being part of a successful team, and can apply their talents to the success of the team.
Finally, the chapter reaches its ultimate goal of introducing the roles played in a FDD project.
An early draft of part of this chapter was published as CoadLetter #85.
Any good process is the cohesive blend of a number of industry best practices, techniques, strategies and patterns. FDD is no exception. FDD includes the use of the following best practices:
- Domain Object Modelling
- Developing by Feature
- Component/Class Ownership
- Feature Teams
- Configuration Management
- Regular Builds
- Visibility of progress and results
Most, if not all, of the best practices in the list have had whole books written on them. Chapter 3 in A Practical Guide... is intended to very briefly introduce each practice and explain just a little why that practice is part of the FDD processes. It is also the first really contentious chapter in the book because it advocates upfront domain object modeling and class ownership; practices that eXtreme Programmers reject, sometimes vehemently. Use case fans may also be disturbed by the lack of a mandatory use case writing activity and the emphasis instead on a hierarchical list of tiny client-valued functional requirements (features).
An early draft of part of this chapter was published as an issue of the old CoadLetter newsletter.
Covers the progress tracking built into FDD and the status and progress reporting opportunities that it makes available.
To steer a project, a manager needs to know the current status of a project (where am I), the ultimate end of the project (where are we going) and the velocity of the project (how fast are we moving forward). FDD enables a manager to:
- Define a set of sharp milestones for the development of each feature.
- Assign a percentage weighting of effort to each milestone.
- Add up percentages of milestones complete to calculate the percentage complete for a feature.
- Roll up the percentage complete for all the features in a set, area and project to summarize status.
- Compare with previous results to show progress.
- Collect results regularly to calculate rate of progress.
Some of this chapter was based on an issue of the CoadLetter #70 .
This is my main FDD claim to fame. I came up with the idea of using card folders to store all the output of a feature team iteration and the cover sheet to make sense of it all. I also worked with our toolsmith, Herman, to produce an initial electronic version. Chief Programmer work packages were especially handy when working on multiple feature teams at one time.
Some of this chapter was based on an issue of the CoadLetter #72
Each process in FDD is examined in detail in turn, one process per chapter.
The processes are shown as a UML activity diagram and hints and tips given for every role involved in every step.
Why 3 and only 3 layers in the feature list hierarchy? Well, 20 feature areas each containing 20 feature sets, each containing 20 features is 8000 features or in other words, a very big system by today's standards. Ten areas, each with 10 sets, each with 10 features is 1000 features, a very significant system of the order constructed by the 20+ developers in Singapore over a period of 18 months (total project team size including domain experts, testers and tech. writers, system admins. data conversion team, peaked at about 50). So I think 3 levels is more than good enough in the vast majority of cases. This is especially true if you split features out into UI, PD and SI features as described in A Practical Guide... chapter 12 on Technical Architecture.
Lessons Learnt from Fred was first published as a CoadLetter #40
Seeks to at least partially answer one of the most frequent questions about FDD ... what about architecture?
The software components purchased by the project, any wrapper, adapter and interface code created to reduce the dependency of the system on a specific purchased component, and the patterns used to translate analysis results onto those components.
This needs to be largely in place before starting feature design and implementation iterations. It may be already defined externally to the project or it may need to be defined by a task performed before, immediately after or in parallel to the initial modelling, and listing and planning of features .
Takes on another of the frequently asked questions about FDD ... Why does FDD not talk about testing?
FDD aims to make formal system and customer acceptance testing a formality through emphasising high quality in the design and construction processes. It also enables testing to start early, as soon as the first few features are complete
Requirements Change Management: If features increase by 10%
either scope, schedule or budget will have to give by 10% to
Up to 10% can usually be absorbed without too much extra effort.
End User Documentation:Look to:
- Embed helpful information into spare space and panels in the user interface so that it is immediately available to a user.
- Use tooltips/flyover help to display truncated information in full, to explain icons and to briefly display more pertinent details of items quickly.
- Ensure information/warning and error messages are helpful and have an easy to use mechanism to display further explanation of the message including examples.
- Check context sensitive help is written at a useful level of granularity.
- Enable on-line guides and tutorials to easily be published as printed manuals.
Data Conversion: Look for:
- Business data
- Reference data
- Configuration data
Clean data at the source; do not propagate data errors and
omissions. Convert paper-based data into an intermediate electronic
form in parallel with feature development and create programs to
convert to final electronic form once all required features are
Deployment: Start it early. Practice on partial systems,
creating pilot schemes. Repeat training at regular intervals adding
new training on new features.
Briefly discusses handling change. Change is emotional, causes
stress, and is often introduced based on a naive mental model of
Knowing more about introducing change enables us to introduce FDD more easily.
Some comments from Latin America:
|I've just finished reading your book. Great reading. It only
took me 3 days to devour the information contained in it. We will
start implementing FDD right away in my organisation.
de Software Development Center at Convergys Latin America
I'm finishing reading your book (A Practical Guide...) and
already trying some of the processes in a customer. Very