特性驱动的开发（FDD）比其它的与灵活开发相关的方法有更少的压力。这并不是说FDD比那些比它流行的方法弱。事实上，FDD证明是几个适合大型企业级项目的灵活方法中的一个。
Jeff De Luca 和 Peter Coad在Java Modeling In Color with UML中介绍了FDD的概念。在书中，他们把FDD描述为一个迭代方法，它包括五个围绕与领域对象模型相关的特性的列表（listing）、计划（planning）、设计（designing）、编码（coding）和实现的具有内在联系的五个过程。这五个过程是：
1． 开发一个总体模型：开发团队和其它领域参与者使用一个未经历过的架构来产生一个初始的高级模型骨架。团队然后再根据特定的模型元素分成几个子团队，然后他们再净化子模型。然后这些子模型再合作回到领域模型然后产生其轮廓。
2． 构建一个特性列表：使用在第一步获取的知识，这个过程净化出对象的主要特性。然后它们再根据功能相关的组织起来，根据优先权和权值分级列出来。重复迭代这个阶段，细化定义、净化细节。
3． 根据特性进行计划（plan by feature）：项目领导、开发领导和首席程序员共同工作，定义项目的接下来两个阶段的转折点。特性和项目转折点然后提交给首席程序员用于设计/开发。
4． 根据特性进行设计（design by feature）：在一个迭代过程中，每个首席程序员选择一个特性，定义支持那个特性的类，并与其它类的所有者联系。特性团队书写一个详细的序列图表，类的所有者书写类和方法prologs。（FDD过程将对象类分配给所有者。根据类的大小和复杂性，所有者可以是个人的或者一个小团队。）
5． 根据特性进行构建（build by feature）：一旦一个设计包（design package）完全以后，类所有者构建他分配的方法。这接在执行了单元和类特性测试之后。如果成功，代码提交给首席程序员集成到下一个构建版本中。
团队角色是FDD的一个基本元素。总体来说，需要六个角色：项目领导人、首席架构师、开发经理、首席程序员，类所有者和领域专家。项目领导人控制项目资源，时间期限等；首席架构师主要负责整体对象建模；开发经理负责开发资源的功能性管理；领域专家负责提供对象特性之“目的”的定义的输入。
FDD定义两个主要角色控制实现的开发流程；分别是首席程序员和类所有者。在FDD中，首席程序员领导和控制design-by-feature和build-by-feature阶段。一个项目中首席程序员的个数要根据正在考虑的对象的复杂性来定。类所有者负责他们分配的类的设计、构建、测试和实现。
由于FDD依赖迭代开发阶段，产生方向，和团队焦点，所以FDD通常与极限编程（XP）进行对比。然后FDD在很多方面不同于XP，包括：
灵活开发方法的一个首要目标是完全快速开发的同时能够快速地合并变化。FDD由于其能力，可以让应用开发经理管理中等大小的团队。
