敏捷软件开发之特性驱动开发FDD介绍
2022-11-13
来源：CSDN老曲_敏捷
该是一个里程碑，而每一次提交给客户更加应该是一个大的里程碑。所谓的计划，其实就是确定 feature 优先实现级别，而这个优先实现级别其实就是来着客户的功能优先列表。这里的两个列表都是动态的，是会经常性的做出调整的，并且很多复杂情况下分析模型也是会有调整的，可能会出现更多的分析类，也就是说主程序员的负责的类会根据情况进行调整。
FDD其实是一个比较复杂的体系，至少我认为比RUP并不简单。FDD中有许多策略和技术方面的问题，不是那么容易理解。可以说FDD是为职业程序员预备的专业开发方法。其实任何一直agile都是职业程序员的开发方法，一般情况下应该存在一个教练的角色，主设计师往往就是承担这个角色。
我强调整体模型不是需求模型，是基于几点考虑。
1、一个项目是否允许你在开始的时候能从容的建立一个整体的模型？至少从我面前对于国内的软件开发行业的客户来看，他们是不会给你这个机会的。因此绝大多数情况下，是在你开始进行这个项目前，这个模型就应该已经存在了。那么这个模型显然不是来自于具体化了的“需求”，而是来自更加宽泛化的“领域”。实际上我更加愿意称他为领域模型或者领域分析模型。
2、由于1的观点，同时再考虑到大多数的开发团体，都是在一个比较固定的领域范围内部进行工作。他们的工作应该能，也应该进行一定程度的积累。而这个领域分析模型，就是一个很好的介质。
3、由于领域分析模型非常强调于领域中出现的概念，因此以此为基础可以更加好的而简单的建立其对于领域的认识。而如果过多的从更加关注流程的需求入手，则复杂性和可认识性会大幅度降低。同时也应该明白，由于领域分析模型是FDD团队组织结构的基础性依赖，保持一个相对稳定的模型是非常必要的。
而这里一个关键的容易产生错误认识的点就在于， 将这领域模型系统化到具体的软件结构系统中去，也就是你说的所谓“系统模型图”。
而在我们具体的实践中，往往开发团队的所使用的系统构架architecture是另外一个相对稳定的体系，并且这个体系也如同那个领域分析模型一样有很多类似的特点。因此完全可以在他们两个的基础上进行总计和提炼，建立一个更加针对化的快速开发框架。而一旦将两种结构混淆，那么本已经复杂的业务和系统结构，将会变得更加复杂和难于认识。同时也应该明确，如果业务同具体的技术实现过于紧密的耦合在一起，将会在今后的开发过程中造成业务的改变必须调整技术结构的后果。
而如你看我上面关于FD
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
