The Feature pattern diagram shown here uses a quite traditional view of the tasks required to deliver a feature with the emphasis on Specify (the "design by feature" part) and Develop (the "build by feature" part).
We can see more detail of this task pattern by using "Go
Into" in the pattern editor. Here the specific artifacts and quality
gateways that are associated with each task, as well as the number and
types of roles required to carry out the task, can be reviewed and
Clearly other ways of breaking these tasks down are
possible, and some of the FDD literature (for example Palmer and
Felsing's book Feature Driven Development) provide
alternative schemes that place stronger emphasis for example on design
and code walkthroughs rather than the test-driven approach implied here.
The beauty of xProcess is that the task patterns are all
easily and graphically editable so you can make this method match
exactly what you want the FDD teams to carry out. As all plans, tasks,
artifacts, processes and time records are stored in the xProcess
versioned data stores, the compliance with your process can be monitored
at any time, either to improve the process patterns where teams have
discovered better ways of working, or to improve the teams' approach by
following the best practice captured in your process patterns.
FDD has a three-level hierarchy of functionality: Features, Feature Sets
and Major Feature Sets (also referred to as Business Areas). So far
we've seen where Features and Feature Sets appear within the hierarchy
of a project. Major Feature Sets (MFS's) are handled slightly
differently. MFS's are created by an xProcess pattern in a similar way
to the other patterns we've looked at, but they result in categorized folders rather
than tasks which are part of the project hierarchy. This is so that the
Feature Sets are visible within the Gantt charts and release schedules.
Because of the scope of major Feature Sets, they generally do not have
such a clearly delineated start and end date and so it would not make
the project schedule clearer to include them in that way. So opening a
MFS folder shows you all the feature sets and features in that category.
You can then review and prioritize the features in just this one
business area. Here's an example of a MFS in a particular project with
its corresponding Gantt chart.
Finally in this brief review of xProcess FDD, the pattern for a Release
is also instructive. Again a prioritized folder is used for the Release
pattern, rather than a task in the project task hierarchy (see the Scrum
method for an example of a process that uses this alternative). By
default just one release will be created in the project (with a target
close to the end of the project). However the Project Manager can create
as many additional interim releases as he requires. The "scope" of the
release is defined by moving the required features/feature sets/tasks
into the release folder. The scheduler of xProcess uses the implied and
defined priorities of these tasks to calculate completion dates and
provide alerts if targets are unlikely to be met. As the project
progresses, the scheduler uses the input from team members completing
and possibly re-estimating the required effort for tasks to give
immediate visibility of targets' status and costs providing all
stakeholders of the FDD projects timely and detailed information to
support decision making and further planning.