敏捷开发-敏捷开发弊端

敏捷开发人员不会对一个预先设计应用原则和模式。相反，这些原则和模式被应用在一次次的迭代中，力图使代码设计流畅。

为什么使用设计模式，笔者的体会如下

l设计模式是为了使设计适应变化

l设计模式是重构的工具

l设计一开始就要保持流畅、简单，并具有持续性

l不能过度使用设计模式。

使用设计模式的目的是为了适应未来的变化，变化之所以存在是因为一切的事物都具有不可预见性，如果具有可预见性，则不能称其为变化。如何判断哪些需求可能变化，哪些需求可能不变，并且在最大程度上保持设计的流畅、简单，这些是工艺问题，而不是工程问题。既然是工艺问题，那么就只能给出原则，不能给出标准。使用设计模式的原则是对未来极有可能发生变化的问题进行简单的修改、降低成本。

1前言应用软件系统是事件驱动的软件系统，系统通过接口接受事件后，交由系统业务层处理，业务层处理完事件后将需要的信息存入数据库，整个应用软件系统分为三个子系统接口子系统，业务子系统，数据库子系统，业务子系统进一步分为三个子系统表示层，业务层，数据接入层。其中业务层是整个系统的核心，表示层负责通过接口子系统接收系统事件交给业务层处理，数据接入层供业务层使用完成数据的持久化。

每个层对编程人员的技术要求是不同的，表示层需要了解的技术根据接口子系统选择的不同而不同如界面，需要对MFC有比较深入的了解，web界面则要求对asp，，或jsp有比较深入的了解。数据访问层需要的技术则由数据库子系统的选择决定，另外还需要了解，等。

接口子系统的选择界面，界面，web界面，命令行接口，CTI，API等数据库子系统的选择关系数据库，普通文件等基于以上对应用软件系统的理解，软件开发流程的输入是用户的业务需求，输出就是系统的业务层、表示层、数据接入层的代码，以及接口和数据库以及各种文档。因此得到比较理想化的软件开发流程图，该图使用uml中的活动图描述。

2需求分析阶段需求分析阶段的常见问题是需求分析不够深入，对问题域没有仔细研究，急于进入设计阶段。造成这种问题一方面是因为项目管目赶进度以及存在于管理人员头脑中的根深蒂固的想法任何时候不能让任何人员闲着，另外很大的原因是很多人不知道如何进一步深入研究问题域。

需求分析阶段不仅要列出系统的，更重要的是要列出的输入输出和例外情况等，以及问题域中的对象之间的静态关系和动态关系，如对象间的包含关系，继承关系，调用关系等。需求分析阶段另外一个常见的问题是常常将需求分析等同于数据库设计，需求分析阶段定义的是系统作什么，而不是怎么做，需求分析的结果应该与具体的技术实现无关。

数据库设计是技术实现的细节，应该尽可能的推迟技术细节的决策，不应该使技术细节束缚了我们对系统需求的理解。需求分析阶段应该从用户的角度对系统建模，不应将大量的技术细节暴露给用户，导致系统易用性差。需求分析阶段可以进一步细分为业务需求分析阶段和系统功能需求分析阶段。在很多研发性质的系统中，不注重业务需求分析，只有系统功能需求分析，导致开发人员知其然不知其所以然。

系统功能规范文档与业务需求文档的重要区别有以下几点内容不同系统需求分为功能需求和非功能需求，功能需求进一步分为业务功能需求和非业务功能需求。

系统需求规范文档除了包括业务需求文档中的业务功能需求，功能规范文档需要增加以下内容系统的非业务功能需求，由于业务需求由计算机系统实现而产生的功能需求，如系统需要系统管理员管理，系统管理员的角度产生一些非业务功能需求，另外需要描述系统非功能需求数据量，性能要求，响应速度，可用性要求，可靠性要求，界面语言要求等等。

阅读的对象不同业务需求文档是用来与业务人员交流，功能规范文档是开发人员开发的依据使用的语言不同业务需求文档使用自然语言书写，而功能规范文档使用比较严谨的语言，如uml书写对编写人的要求不一样业务需求编写人员只需要对业务系统熟悉，系统规范由系统架构师完成体现系统架构师价值的地方是编写系统规范文档和业务层设计系统规范文档是下一步界面设计，业务层设计和数据库设计的依据，表示层，业务层，数据访问层之间是相互联系的，它们之间的关系应该在系统规范文档中找到。

3架构设计阶段架构设计阶段的常见问题是将架构设计理解为技术架构设计，实际上架构设计分为技术架构设计和业务架构设计。技术架构一般由系统软件商提供，可以在不同的应用软件系统中使用，例如微软的MFC，SUN的J2EE等。对于一个应用软件系统，更重要的是业务架构的设计，也就是将需求分析阶段中得到的各种关系，根据系统的非功能需求将需求分析转变为代码。

其实没有业务架构的设计也是可以的，很多项目中直接将对象之间的各种关系以数据库的方式实现，这样的系统不是面向对象的，因此面向对象设计的很多好处不能体现。由于在架构设计阶段中没有进一步细分，通常会导致不能准确估计任务量，造成项目计划变成摆设。4详细设计阶段详细设计阶段一个重要的任务是系统持久化设计。

对应用系统而言，持久化设计只是管理存储的机制，有多种技术手段可以选择可以是面向对象数据库管理系统，简单的文件，或者是关系数据库，也可以是使用ORM工具等。总之应该把它留到最后作为细节处理。我们不应该将我们的系统和任何特定的技术绑定在一起。我们可以根据需求自由选择需要的持久化技术，并且保留在将来需要时更改持久化技术的自由。5编码阶段编码阶段还处于小农经济，自给自足，没有分工合作。

编码阶段以为粒度安排工作，这样的安排方式要求每一个开发人员必须对表示层，业务层，数据接入层的所有技术都要有比较深入的了解，由于每个开发人员各自只对自己的负责，对别人的不了解，但是每一个会有功能重复的地方，导致大量的重复工作。

编码阶段工作安排的粒度应该是类，编码阶段工作的安排原则是先分层，再分割，按照表示层，业务层，数据访问层分开后，每一层内可以进一步分为不同类，使用测试驱动的编程方法，每个编程人员单独编写代码，并进行单元测试。每个层次的编程人员只需要对某一种技术有比较深入的了解。6测试阶段很多人分不清什么是单元测试，什么是集成测试，什么是系统测试测试的顺序是先单元测试，然后是集成测试，最后是系统测试。

单元测试是源代码级的测试，一般由编程人员自己使用各种工具测试，是白盒测试。集成测试是在单元测试结束后，将一个或若干个单元作为一个子系统的黑盒测试，测试子系统内的所有组件可以正确的交互，集成测试通过对子系统不断增加新的单元最后完成整个系统的测试，集成测试不应由开发人员完成。

7结束软件开发过程中，各种辅助工具以及很重要，但是使用工具和的最终目的是为了更高效的在开发人员之间沟通交流，记录存在开发人员脑子里的想法，不要为了而。不能以为会使用，就认为可以成为作家。最后引用的《敏捷软件开发原则、模式与实践》中的一句话作为本文的结束过渡信赖工具和过程以及低估智力和经验都是软件开发灾难的源泉。注本文摘自网络台州极速网络愿以雄厚的技术实力基础。

1、研究目的

从敏捷开发对软件项目的重要性出发，针对它的各种优势进行研究与分析，讲述如何将敏捷理念用于实践，从而让更多的人了解到它的实际价值与应用前景。

2、研究的意义

许多年以来人们一直使用瀑布方法进行软件的开发瀑布型方法的特点是在完成系统设计之后就进行构建并且在开始阶段就能够估算出具有参考价值的工作量和成本但一般情况是不去适应没有预定的变动的并且改动率也较低。敏捷开发作为一种面临迅速变化的需求，快速开发出高质量软件产品的新方法，自问世以来，对软件工业起着积极而又重要的影响，它吹响了软件工业的战斗号角颇受业内人士推崇。

它的主要特征是允许对过程进行自主调整并且强调软件开发中人的因素它克服了传统开发方法的缺点，和传统开发方法有着明显不同。由于软件在规模、复杂度、功能上的极大扩展和提高，以及在需求和技术不断变化的过程中实现软件自身开发的需求，敏捷开发正逐渐成为软件开发的新模式。因此，我们应当更好的利用这种方法，适应快速的需求变化，达到完善需求分析，改进开发过程，提高软件项目管理水平的目的扩展它的应用领域。

3、研究的依据

敏捷开发方法是一类软件开发方法的统称，其中包括极限编程、方法等，相对于那些“非敏捷”软件开发来说，更强调适应性而非预见性。这类方法重视软件开发过程中人的重要性，强调个体的竞争力，强调人与人之间的交流与合作，强调可以工作的软件。

不同的人对敏捷编程有着不同的理解，不过所有敏捷开发方法的核心都具有以下原则业务相关人员与独立的小型开发团队协调同步团队更多地依赖面对面交流，而不是前期需求和文档，这种交流为软件设计和测试提供了不断调整的机会。“软件开发之父”曾说过，“信息时代，唯一不变的就是变化。

”市场环境在变、科学技术在变、业务需求也在变，在搭建企业信息系统时如何能够在变化中迅速响应敏捷开发技术很好的回答了这个问题因为它是一种应对变化的方法，它的关键之处在于，能够“敏捷”地适应项目的变化，而不是在开发阶段去适应需求变化。敏捷编程把一个应用软件开发项目分成了诸多很小的模块化部分，每个部分在很短时间内逐个解决，然后添加到整个应用软件上，最后提供完整的功能。

公司可以根据这些指导原则开发出适合自己公司的敏捷方法或采用现有的各种敏捷方法例如著名的极限编程XP、自适应软件开发ASD特征驱动开发FDD等等。