I feel a recipe is only a theme which an intelligent
cook can play each time with a variation.
Madame Benoit
The ultimate judgment of progress is this:
measurable results in reasonable time.
Robert Anthony
I measure output, not input.
Lim Bak Wee
6 Feature-Driven Development
For enterprise-component modeling to be successful, it must live and breathe within a larger context, a software development process.
We've developed such a process in practice and detail it in this chapter. We present Feature-Driven Development (FDD) in these sections:
1. The problem: accommodating shorter and shorter business cycles
2. The solution: feature-driven development
3. Defining feature sets and features
4. Establishing a process: why and how
5. The five processes within FDD
6. Chief programmers, class owners, and feature teams
7. Management controls: Tracking progress with precision
6.1 The Problem: Accommodating Shorter and Shorter Business Cycles Despite the many advances in software development, it is not uncommon for projects lasting two or more years to use a function-driven process: from functional specs (in traditional paragraph format or in use-case format) to desig
n to code to test to deployment. Along the way, some have made minor modifications to the theme, allowing some influence from iterations. Nevertheless, many software projects exceed budget, blow schedule, and deliver something less than desired (something appropriate two years earlier, yet no longer).
As if that weren't enough pressure, the ever-increasing pace of technological advances makes it less and less likely that a project lasting more than two years will ever succeed.
In fact, more and more, we are mentoring projects with total schedules of 90, 120, or 180 day—or perhaps 9, 12, or 18 months. One market-leader we work  with considers any project longer than 180 days as high-risk. Why? Their business changes so rapidly and the supporting technology changes so rapidly that planning nine months out adds risk to the project.
That's quite a change in perspective.
The authors of BLUR: The Speed of Change in the Connected Economy put it this way:
Speed is the foreshortening of product life cycles from years to months or even
weeks…. Accelerated product life cycles and time-based competition have
become part of the business lingo…. The faster things move, the less time you
have to plan for them. You're much better off iterating and reiterating,
adjusting as you go.
Stan Davis and Christopher Meyer [Davis98]
The norm for fast-cycle-time projects is a feature-driven iterative process, beginning with features and modeling, followed by design-and-build increments.
In this chapter, we formalize the process we call "Feature-Driven Development" (FDD).
We've developed FDD in practice. Project teams apply it with significant success.
Developers like it. With FDD, they get something new to work on every two weeks. Developers love new things. With FDD, they get closure every two weeks. Closure is an important must-have element for job satisfaction. Getting to declare "I'm done" every two weeks is such a good thing.
Managers like it too. With FDD, they know what to plan and how to establish meaningful milestones.
They get the risk-reduction that comes from managing a project that delivers frequent, tangible, working results. With FDD, they get real percentage numbers on progress, for example, being 57% complete and demonstrating to clients and to senior management exactly where the project is.
Clients like it too. With FDD, they see plans with milestones that they understand. They see frequent results that they understand. And they know exactly how far along the project is at any point in time.
Yes, developers and managers and clients like FDD. Amazing yet true.
6.2 The Solution: Feature-Driven Development
What if you and your team adopted a process for delivering frequent, tangible, working results?
Think about it. You could plan for results, measure results, measure your progress in a believable way, and demonstrate working results.
What might this mean for you and your career, the morale of your team, and added business from your clients? Plenty of motivation!
FDD is a model-driven short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations.
The features are small "useful in the eyes of the client" results.
Most iterative processes are anything but short and "useful in the eyes of the client". An iteration like "build the accounting subsystem" would take too long to complete. An iteration like "build the persistence layer" is not (directly at least) client-valued.
Moreover, long and IT-centric iterations make life difficult. It's harder to track what's really going on during an iteration. And it's harder to engage the client, not having a steady stream of client-valued results to demonstrate along the way.
In contrast, a small feature like "assign unique order number" is both short and client-valued. In fact, a client knows exactly what it is, can assign a priority to it, can talk about what is needed, and can assess whether or not it truly meets the business need.
A small feature is a little tiny building block for planning, reporting, and tracking. It's understandable. It's measurable. It's do-able (with several other features) within a two-week increment.
As in any other development process, FDD prescribes a series of steps and sub-steps. Unlike other processes, FDD uniquely:
-
uses very small blocks of client-valued functionality, called features
(allowing users to describe what they want in short statements, rather
than having to force those thoughts into a "the user does this, the
system does that" format),
- organizes those little blocks into business-related groupings (solving the
dilemma of what level one should write use-cases for),
- focuses developers on producing working results every two weeks,
- facilitates inspections (making inspections best practice, easier to
accept and simpler to apply),
- provides detailed planning and measurement guidance,
- promotes concurrent development within each "design by feature, build
by feature" increment,
- tracks and reports progress with surprising accuracy, and
计算机专业java- supports both detailed tracking within a project and higher-level
summaries for higher-levels of clients and management, in business
terms.
6.3 Defining Feature Sets and Features
A feature is a client-valued function that can be implemented in two weeks or less.
We name a feature using this template:
<action> the <result> <by|for|of|to> a(n) <object>
where an object is a person, place, or thing (including roles, moments
in time or intervals of time, or catalog-entry-like descriptions)
For example,
- Calculate the total of a sale.
- Assess the fulfillment timeliness of a sale.
- Calculate the total purchases by a customer.
A feature set is a grouping of business-related features.
We name a feature set this way:
<action><-ing> a(n) <object>
For example:
Making a product sale to a customer
And we name a major feature set this way:
<object> management
For example:
Product-sales management
We start an informal features list while developing the overall model. We write down features we hear from domain members and glean content from documents we are working with.
We build a detailed features list after developing an overall model. Some features come by transforming methods in the model to features. Most features come from considering each pink moment-interval (business areas) and writing down the features.
For example, see the model snippet Figure 6-1:
Figure 6-1. A model snippet.
We could transform its methods into a:
- Feature set
Making a product sale to a customer
- Features
Calculate the total of a sale.
Assess fulfillment timeliness for a sale.
Calculate the total purchases by a customer.
Yet we can do even more, considering additional features that will better satisfy client wants and needs. Here's an example:
- Major feature set
Product-sale management
- Feature set
Making a product sale to a customer
- Features
Calculate the total of a sale.
Assess the fulfillment timeliness for a sale.
Calculate the total purchases by a customer.
Calculate the tax for a sale.
Assess the current preferences of a customer.
For each additional feature, we add corresponding methods to the model. Normally we don't do this right away, but rather during the "design by feature, build by feature" iterations.
In practice, we've seen again and again that building an overall model and an informal features list before developing a detailed features list:
- brings domain members together to talk with each other, listen to each
other, and develop a common model of the business—before developing
a fully- detailed features list,
- increases developer member's understanding about the domain and
how things interrelate within it (even if they have built systems in the
domain),
- fosters more creativity and innovation (visual models in color engage
spatial thinking, a creativity must-have before moving into linguistic
and mathematical-logical thinking),
- encourages exploring "what could be done, what might be done, and
what could make a real difference" before locking oneself into a fixed
system boundary ("the user does this, the system does that"), and
- leads to the discovery of feature sets and features that bring significant
business advantage, rather than passively scribing down the needs for
yet another system.
6.4 Establishing a Process: Why and How
This section explores these questions:
1. Why use a process?
2. Who selects tools for a process?
3. How might one describe a process?
6.4.1 Why Use a Process?
We think most process initiatives are silly. Well-intentioned managers and teams get so wrapped up in executing process that they forget that they are being paid for results, not process execution.
Process for process' sake alone, as a matter of "process pride", is a shame. Having hundreds of pages of steps to execute demoralizes the team members to the point that they willingly turn off their minds and simply follow the steps.
Process over-specification does far more harm than good. The process takes on a life of its own and consumes more and more time that could be otherwise spent actually developing software.
A decade ago, one of us wrote up a 110-page process for a large development team. No matter how hard he tried to defend every word of his process as something of great value, the team members always (always) looked at the four-page summary in the back and ignored the rest of what he thought was valuable content. He learned from that experience: no matter how much process pride you might have as a leader, short one or two page process guides are what developers really want and need.
No amount of process over-specification will make up for bad people. Far better: Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them along the way.
A well-defined and (relatively speaking) lightweight process can help your team members work together to achieve remarkable and noteworthy results. This is significant and worthy of additional consideration.
In this light then, let's take a look at the top reasons for developing and using a process:
1. Move to larger projects and repeatable success.
2. Bring new staff in with a shorter ramp-up time.
3. Focus on high-payoff results.
6.4.1.1 Move to larger projects and repeatable success.
To move to larger projects and repeatable success, you need a good process, a system for building systems.
Simple, well-defined processes work best. Team members apply them several times, make refinements, and commit the process to memory. It becomes second nature to them. It becomes a good habit.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。