敏捷软件开发之特性驱动开发FDD介绍
2022-11-13
来源：CSDN老曲_敏捷
”，而是做“ 恰好够用的设计”。同时还应注意，在FDD中的这个第一项活动不但包括高层次的设计，也包括需求及需求分析。
Ozzzzzz：
1. FDD 是迭代开发，这一点必须加以强调。
2. 整体模型更大程度上是分析模型，而不是需求模型。更多的涉及的是会出现什么东西，而不是会实现什么能力。这个模型是更多的是从业务分析角度出发，而不是从软件系统实现角度出发。这个整体模型不是构架，而只是部门内容是构架的一个部分。这一点非常重要，基本上FDD处理复杂问题的强大，就是从这里开始的。
3. 按照《 action 》《 result 》《 object 》创建特征列表。习惯上我们将feature翻译为特征，这里更加体现了这个feature是《object》的一些能力，而不是软件的一些功能。软件的功能往往需要一些特征集体发生作用。 实际上在操作的时候，如果整体模型按照正确的原则进行了构造，那么出现一个肥胖的 feature 的机会是很少的。基本上每一个feature的完成都会在2-3天以下，有很多可能就是几个小时，更少的只有几分钟。
4. 主程序员所负责的往往是自己熟悉的和有兴趣的分析类，项目经理没有权利去去给他们分配工作，而不能去指定他们去负责什么类。实际上FDD存在3个主要的关键的管理方面的角色，项目经理、主设计师、开发经理。这3个角色可以由3个人负责，也可以由2个人负责，当然也可以由一个人负责。但是不管如何，这3个角色的任务和工作都是不同的，必须加以注意。而feature必须有具体的人负责，但是注意这必须是在类都有了主人的情况下。
5.上一条我已经表明类的所有者的来历，关键是大家必须理解，任何的agile都不会存在什么详细设计。其实这个阶段的所谓设计，更多的是要找出一个feature是会涉及到什么类，而各个的类主人会按照什么协议参加到这个feature的建造中来，什么时间这些人可以参加到这个feature中来，以及他们之间的协议如何可以得到检查实施。
6.这个阶段相对任务比较明确，但是切记不要把所谓的传统软件工程的方法影响到其中，所谓的复审和评审都是不应该进行的，而是应该使用tdd和pp这样更加有效率的做法。特别是由于存在主程序员，pp完全可以在上一个阶段的头脑风暴中进行。可以说设计和构造阶段其实更多的时候不是没有明确的区分界限的，或者说设计阶段更多的时候是没有一个明确的阶段的。这其实体现了agiler一般喜欢的持续设计风格。
至于作者最后问的问题，根本就不是问题，是他对于FDD的角色和迭代不理解造成的误解。 至于里程碑，在 FDD 中是很容易确定的，每一次迭代都应
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
