Feature driven design FDD


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Feature driven design FDD

  1. 1. Feature Driven DesignA whitepaper by John C Goodpasture, PMPNovember, 2009©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 1 of 12
  2. 2. Feature Driven DesignFeature Driven Design is an agile methodology that centersattention on small scale requirements—dubbed ‘features’—that can be rapidly deployed to create customer value.Everyone cant know everything about everything—that is brittle and it cant scale. Jeff De LucaFeature Driven Design, FDD,1 is one of the agile methodologies developed empirically in the late1990’s. In a word, a feature is a small scale functional need in the general format of<action><object><result>, like “calculate order total”.2 Jeff De Luca is the acknowledgedinventor of FDD, although De Luca himself credits others with significant contributions—peoplelike Peter Coad, a well known leader in object oriented [OO] coding, who introduced a prominentpractice to the methodology: fine grain object modeling.3The founding project was a troubled about the recommended methodology stepssoftware implementation at a large bank in that FDD can not be applied outside an OOSingapore in the late 1990’s. De Luca, an implementation. At a high level ofAustralian with a proven track record at abstraction, there is nothing that prohibitsIBM, was hired to rescue the project, an taking FDD ideas outside of software.endeavor that was foundering withtraditional software engineering methods. FDD is designed to be scalable; indeed theDe Luca’s rescue was a medium scale effort first project in Singapore was large by agilewith a few dozen programmers; it lasted for standards. One of De Luca’s scaling pointsmore than a year.4 is object ownership by individual developers. Unlike XP, there is notDe Luca organized the project around his collective ownership of development objectsideas that became known as FDD. He because collective ownership is not scalablebecame acquainted with Peter Coad when he in De Luca’s view.6 And another is therecruited Coad to assist with object emphasis on up-front modeling of themodeling on the project. In 1999, De Luca, business story or business domain led by anCoad, and Eric Lefebvre wrote a widely read architect or experienced modeler.book, “Java Modeling in Color with UML,”which, among other ideas, described FDD Domain modeling, as it is called in FDD, isand gave it a public introduction.5 equivalent to architecture commonly described in the literature. The model isDe Luca et al assume an OO practice intended to show all the major systemframework for FDD; consequently, much of elements and their interaction. De Lucathe jargon that surrounds FDD is from OO; proposes that there be architecture for eachhowever, there is nothing so fundamental ‘aspect’ of the system, like the presentation©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 2 of 12
  3. 3. layer or tier, application layer, data system, descending order: project, aspects, subjectservice layers, and so on.7 In some respects, areas, and business activities framed byDe Luca’s ‘aspect’ is much like a ‘view’. milestones to give a temporal dimension.What you see depends upon your point ofview. The idea that architecture – and a Otherwise, FDD is pretty minimal in itsdomain model is architecture – should have, prescription, consisting of five process steps,or could have different views is accepted a few key players, a minimum set ofdoctrine among system architects.8 required responsibilities, a high reliance on model diagrams to capture requirements,The ‘core structure’ of the model is loosely and spreadsheet pipelines and status grids tocoupled and hierarchical, as given in visually document project progress. FDD is very pictorial • FDD is intended to be scalable • Although FDD values personal communications over formal documentation, as do all agile methods, documentation is valued for its support for scalability A Project Management Tip • FDD values diagrams for domain models, fine grain object models, and supports a number of project management scorecards on a project dashboard and information portalFDD is defined by its process stepsMore so than SCRUM, XP, and Crystal, FDD is known for and characterized by its process steps.The original definitions of each step were published in “Java Modeling in Color with UML”.Subsequently, they have been refined with experience; De Luca has documented the updates onhis website.9 Within each step is a somewhat unique mix of conventional practices, although eachpractice has been picked for its effectiveness and reinforcement of the process step.Develop an Overall ModelThe first process step is perhaps the most to identify the ‘subject areas’ and ‘businesscontroversial and the one that separates FDD activities’ that comprise the business story.from other agile methods: “Develop an De Luca calls this step-one model a ‘modelOverall Model”. In this step, the business shape’; it’s more than a framework becausestory, which is called the business domain in the major object classes and theirthe FDD literature, is modeled ‘just enough’ interrelationships are defined, but it’s less than a complete model because all the class©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 3 of 12
  4. 4. methods, attributes, and data are notidentified and defined. The model is generally relational betweenFor purposes of simple presentation the business steps and classes: one business stephierarchy for the model for one aspect is feature can require several classes; one classshown in the panel below. The step-one may support more than one feature. Theremodel usually goes no farther than are usually many methods within each class.identifying business activities and the Indeed, moving the feature identificationclasses that will be building blocks for and feature lists to step two in thefeatures. methodology is one of the process refinements made since 1999. An example isModel hierarchy given in Table WP1-1:Business Domain Subject AreasBusiness Activities Business Steps[features] Classes Methods Table WP1-1 Model Example Model Level Example Business Domain In-bound Sales Subject Area In-bound Orders Business Activity Order Processing Business Step [feature] Calculate Order Total Class [person, place, or Order Line thing in the abstract] Method [behavior or calculateLineTotal action]Various modeling tools such as text, use do its own model; the model results arecases diagrams, data models, entity- combined in Delphi fashion to reach arelationship diagrams, user guides, and high- consensus.level sequence diagrams are applicable. Critics of the FDD approach liken thisTo develop a model, a Delphi-like approach modeling to a ‘big design up front’, BDUF.is recommended: led by a chief architect or a However, the domain model is not morechief modeler, the whole team is assembled than the minimally required architectureand given an explanation of the business needed to frame all subsequentstory—in effect, a domain walkthrough. development.Smaller multi-functional, business-developer teams are formed, and each is to©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 4 of 12
  5. 5. Build a Features ListThe chief programmer, CP, a prominent player in FDD, leads process step 2. In this step, all thefine grain business steps – that is, features – are identified. No prioritization is made of features;there are too many: typically hundreds, perhaps thousands, so no prioritization scheme ismeaningful. Table WP1-2 illustrates the FDD feature compared to the use case and user story: Table WP1-2 Feature Comparison Fixture Commentary Specifies actors, initial conditions, triggers, actions, extended Use Case actions, included actions, and results. Actor <name> acting in role <role label> according to action <action verb> with attributes <skills, security, time of day, etc> User Story has expectation <result of action> because <motivation for action, or reason for storyline, or dependencies or triggers> FDD Feature <action><object><result>Plan by FeaturePlanning is done for release milestones. Features are assembled into release packages accordingto a number of business criteria. The project manager is a key player in the planning, along withthe chief programmer.Rolling wave planning is applicable. In one class. Collective ownership, an XPbuilding the release schedule, features must practice, is not allowed because it limitsbe sequenced; consideration for customer scale.importance and urgency, impact on thebenefit stream, impact on market Planning is not time-boxed! Features arecompetitiveness, and other business factors, intended to be developed in less than twoas well as technical sequencing go into the weeks duration, however, there is no rigidityplanning. In this step, important ownership around the two week goal—the durationassignments are made that enable scale. could be much shorter or a little bit longer,First, business activities are assigned to but not much longer or else the featurechief programmers as the responsible requires more decomposition. Featuremanager for required development. Second, development duration is further dissectedeach class is assigned to a developer as its into six sequential development tasks,owner. Class ownership does not change beginning with a feature walk-though andover time; a developer may own more than ending with a promotion to production.10©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 5 of 12
  6. 6. Design by Feature:Borrowing the script from the WBS, features are assembled into work packages led by the CP.Generally, a work package is the smallest unit identified on a WBS.A Features Breakdown Structure—FDD’s consisting of the CP and class owners, withname for the WBS—is built up from all the business user subject matter experts aswork package content. Care is taken to not required. In a stark departure from othersplit classes between work packages that are agile methods, feature teams are situational:simultaneously in development since that they are formed from class owners just inwould split developers between chief time, and then adjourned when the feature isprogrammers. production ready. New teams are formed dynamically around each feature. Feature teams are formed withresponsibility to own the features—that is, As a construction step, actual design beginsto speak for the required functionality, in this step. The object model and sequenceinterpret business needs, and develop the diagrams are refined, and all the objectfeature into a product unit. The feature methods are defined, as well as attributesteams are multi-functional primarily and data requirements.Build by Feature:This process step is the second construction inspection. Integration testing of multiplestep; in this step the objects are coded, objects to prove and verify featuretested, and put into production. In another performance is planned by the chiefdeparture with other agile methods, and programmer and the developer.especially XP, code inspections by person-to-person walk-through are more valued Pair programming is not promoted, but notthan unit tests. That is, even though an prohibited. The material in Table WP1-3object has passed a unit test it is not sums up the process discussion.promoted to production until it passes a code Table WP1-3 Process Summary FDD Process Step Commentary Develop an Overall • Equivalent to architecture; identify the essential elements Model of the system and their interrelationships • Identify the business steps with business activities; features are functional and customer-valued. Build a Features List • Features are typically designed and built in less than 2 weeks • Organize sets of features into release packages according Plan by Features to technical sequencing constraints and customer priority©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 6 of 12
  7. 7. Table WP1-3 Process Summary FDD Process Step Commentary • Assign ownership responsibilities • Organize feature sets into work packages and assign work packages to chief programmers who are the team Design by Feature leads for feature development teams • Add detail and richness to the fine grain object model • Code, test, and inspect the product Build by Feature • Release product to production FDD is scalable • Documentation is valued for scalability • Class ownership is favored over collective ownership A Project Management Tip • The two construction processes are amenable to fixed price work order contracting • Rigid time-boxes are not imposed on the contractorFDD relies on key practicesIn the discussion so far, we’ve spoken to several of the key practices in FDD: domain modeling—what we call architecture—fine grain object modeling, development by feature, and classownership.Other practices are code inspections, sooner, recovering not only investment butwalkthroughs at every level from domain also adding value to the business.model to class methods, and dynamicfeature teams. Although not regulated by Of importance to the project manager are thetime-boxes, FDD does promote frequent, scorecards recommended by De Luca andresponsive product delivery, sequenced his disciples. At a high level, each processaccording to customer priority, and put into step is gated by the so-called ETVX—production as determined by business Entry, Task, Verify, and Exit—set of sub-preparation. Like all agile methods, processes that are scored for completion.frequent delivery starts the benefit stream There is, of course, a burn-down chart much©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 7 of 12
  8. 8. like that in SCRUM and as presented in objects, if not many more, this is a lot ofAppendix I. Scorecards keep up with the six scorekeeping! Table WP1-4 gives adevelopment stages for each object in each summarization of some of the key practices.two week iteration; these are called ‘parkinglot charts’. Obviously, with hundreds of Table WP1-4 FDD Practices Practice Commentary • Up-front architecture model of the system, its aspects, and the business activities Domain Model • Later refined to include classes and feature [sets of classes with a business relationship] • Peer review of models and design to achieve Walkthrough understanding and catch logical and functional holes Inspection • Peer review of developer deliverables • Developer assignment for design and development of a class Class ownership • Ownership is not changed during the course of the project • Set of classes to be developed into features in one Work package iteration; assigned to a chief programmer • Graphical or spreadsheet portrayal of object and Scorecard release status • Teams formed for the duration of an iteration to Feature Teams deliver work packages • Production of work packages every two weeks, or Frequent release sooner • Technique for independent thinkers to arrive at a Delphi consensusSummary and take-away points • Our theme is that Feature Driven Design is an agile methodology that centers attention on small scale requirements dubbed ‘features’ that can be rapidly deployed to create customer value. • There are five process steps that lead from a top-level model of the business story to the production deployment of packages of features. There are several key practices that make FDD work; for the most part, these practices are not new in the software industry. What is©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 8 of 12
  9. 9. unique is how the practices are used to support each of the five processes. • However, several practices common to other agile methods are missing: time-boxing, pair programming, collective object ownership, and user stories to name the most visible. • FDD is designed to be a scalable methodology although its focus on snips of functionality — that is to say, features—challenges cohesiveness in the larger picture. Documentation sufficient to support architecture and planning is valued for its support for scale. • Overall, FDD is a respected member of the agile family of methodologies with a track record extending back to the late 1990’s.©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 9 of 12
  10. 10. Endnotes1 Feature Driven Development, FDD, FDDI, and the FDD logo, are trademarks of Nebulon Pty.Ltd. FDDI is FDD Interchange, a library of tools and specifications2 See Palmer, S. and Felsing, J. “A Practical Guide to Feature Driven Design” Prentice-Hall,Upper Saddle River, NJ, 2002, pg 46.De Luca actually defines two feature formats: one identical to Palmer’s definition and one that isslightly more complex: <action> the <result> <by|for|of|to> a(n) <object> as given in “FeatureDriven Development Overview”, Nebulon.com, 2005,http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 20093 Interview with Jeff De Luca:Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it-agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 2009Other contributors: Stephen Palmer, editor of the COAD Letter, M. A. Rajashima who inspiredthe ETVX – entry, task, verify, exit – gates of the process steps, and Lim Bak Wee, Paul Szego,and Jon Kern. See: http://www.informit.com/articles/article.aspx?p=26055&seqNum=7,retrieved August 20094 See a short history in Jim Highsmith’s article in Crosstalk:Highsmith, J. “What is Agile Development?” Crosstalk, the Journal of Defense SoftwareEngineering, October, 2002,http://www.stsc.hill.af.mil/crosstalk/2002/10/highsmith.html, retrieved August, 20095 De Luca, J., Coad, P., and Lefebvre, E. “Java Modeling in Color with UML – EnterpriseComponents and Process” Prentice-Hall, Upper Saddle River, NJ, 1999, Chapter 66 Interview with Jeff De Luca:Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it-agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 20097 Editor, “FDD Interchange Specification 20060119”, Nebulon Pty, Ltd, January 19, 20068 See IEEE 1471:2000 “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems” IEEE, March 2006, Chapter 5.4Also known as ISO/IEC 42010:2007, “Recommended Practice for Architectural Description ofSoftware-Intensive Systems” July 2007.9 The latest FDD processes are documented at http://nebulon.com/articles/fdd/latestfdd.html,retrieved August, 2009©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 10 of 12
  11. 11. 10 See “Feature Driven Development Overview”, Nebulon.com, 2005, pg 13,http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 2009©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 11 of 12
  12. 12. About the authorJohn C. Goodpasture, PMP and managing principal at Square Peg Consulting, is a programmanager, coach, author, and project consultant specializing in technology projects, strategicplanning, project office operations. He is the author of books, articles, and web logs in the fieldof project management. He blogs at johngoodpasture.com, provides presentations atwww.slideshare.com/jgoodpas, and his work products are found in the library at www.sqpegconsulting.com.©Copyright 2009 Square Peg Consulting, All rights reservedwww.sqpegconsulting.comPage 12 of 12