February 24, 2003
Agile Modeling and Feature-Driven DevelopmentScott Ambler
Feature-Driven Development (FDD) is a client-centric, architecture-centric and pragmatic software process. In FDD, the term client represents what Agile Modeling (AM) refers to as project stakeholders and Extreme Programming XP) calls customers. Significantly, FDD contains just enough process to ensure scalability and repeatability, all the while encouraging creativity and innovation.
Thinking Big
Who says agile techniques are only for small projects? Earlier this year, a more substantial description was published in Stephen R. Palmer and John M. Felsing's book, A Practical Guide to Feature-Driven Development (Prentice Hall, 2002).
As the name implies, features are an important aspect of FDD. A feature is a small, client-valued function expressed in the form: for example, "Calculate the total of a sale,", "Validate the password of a user" and "Authorize the sales transaction of a customer". Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to XP: They're a primary source of requirements and the primary input into your planning efforts.
Five-Step Process The second step is Build a Features List, grouping features into related sets and subject areas. Next, you Plan by Feature, resulting in a development plan, the identification of class owners (more on this in a minute) and the identification of feature set owners.
Roughly 75 percent of the effort on an FDD project is spent in the fourth and fifth steps: Design by Feature and Build by Feature. These two activities are exactly what you'd expect, including tasks such as detailed modeling, programming, testing and packaging of the system.
An FDD project begins by performing the first three steps in the equivalent of the RUP's Inception phase or XP's "iteration 0," aiming to identify the scope of the effort, the initial architecture and the initial high-level plan. Construction efforts occur in two-week (or shorter) iterations, similar to XP, although a little compressed for most RUP projects, with the team iteratively working through all five steps as needed. As with other agile software development processes, systems are delivered incrementally by FDD teams.
FDD Role-Playing FDD's five steps are supported by several best practices. The first is domain object modeling, the creation of a high-level class diagram and supporting artifacts that describes the problem domain. Developing by feature and individual class ownership are also best practices, as is grouping developers in feature teams. Inspections are an important aspect of FDD, as they are with the RUP. Similar to XP, FDD also insists on regular builds and configuration management. Finally, FDD promotes a best practice called reporting/visibility of results, similar to XP and AM's philosophy of open and honest communication.How would Agile Modeling (AM) be applied on an FDD project? The principles and practices can be clearly applied to FDD's two modeling-oriented steps: Develop an Overall Model and Design by Feature. The only apparent mismatch between the two processes is FDD's practice of class ownership and AM's practice of collective ownership, but I would argue that this isn't a discrepancy: FDD's practice pertains to coding, not to modeling. On an FDD project, people work together in teams to model along the lines of AM's Model with Others practice, and therefore, several people will be working on your shared collection of modeling artifacts. From the modeling point of view, you effectively have shared ownership of your models, but the way you manage source code is another issue.
Feature-Driven Development is a proven agile software development process, clearly a viable option for your organization, and one that you may wish to enhance with Agile Modeling.
Recently on the Agile Modeling Mailing List:
When to Hold a Model Review. This is a conversation that I started, a topic for a future AM newsletter, upon realizing that several of my company's clients struggled with this issue. Opinions varied widely. On communication-rich projects, Extreme Programming (XP) projects stand out, and reviews were seen as providing less value. For communication-deficient efforts, such as those where the customer isn't co-located or the team itself is distributed, reviews were considered quite valuable. Good rules of thumb to help you determine when to hold a model review include: You're at a major milestone, such as the initial identification of your project's scope, you believe you need an outside opinion (for example, an architecture review) to validate your approach, or you need to validate your work to date with a wider range of project stakeholders than those who are actively involved.
Process tailoring. Common advice from process gurus is to tailor your process to meet the needs of your situation. In fact, because the scope of AM is only modeling and documentation, you must tailor it into another process such as FDD, XP or the RUP. The difficulty of tailoring a process when you don't have any experience in it was noted. In fact, the XP community suggests that you first apply XP "straight out of the box" on a project and then consider tailoring it on future projects. One of the principles of the Agile Alliance is that you regularly hold retrospectives to learn from your experiences and to modify your software process accordingly.
Recommended Online Resources:
"Agile Development Joins the 'Would Be' Crowd, by Alistair Cockburn.
Agile Modeling Mailing List.
Agile Modeling Training Resources.
Feature Driven Development.
Java Modeling in Color with UML: Enterprise Components and Process.
A Practical Guide to Feature-Driven Development.
|
 |
|
||||||||||||||||||||||||||||
|
|
|
