敏捷开发方法在软件开发中的应用探索论文.pdf

i 目录 摘要.iii abstract.iv 第一章绪论.1 1.1 本文研究目的和意义.1 1.1.1 我国软件行业现状.1 1.1.2 研究的目的与意义.2 1.2 敏捷开发方法应用现状.4 第二章敏捷开发方法基础理论介绍.7 2.1 敏捷宣言.7 2.2 敏捷开发方法的基本原则.8 2.3 敏捷开发的面向对象设计原则.11 2.4 敏捷开发的最佳实践方法.13 2.5 小结.14 第三章敏捷开发方法应用分析.15 3.1 在某对日外包税务系统项目中的应用分析.15 3.1.1 项目的开发特点.15 3.1.2 项目背景.17 3.1.3 项目组织架构分析.20 3.1.4 敏捷方法在项目中的应用实施.22 3.1.5 敏捷方法在实施前后项目数据分析.30 3.1.6 项目应用分析.32 3.2 敏捷开发方法在某走访管理项目中的实践应用.33 3.2.1 项目背景.33 3.2.2 项目组织构成.33 3.2.3 发布计划与用户故事.35 3.2.4 敏捷方法实践.40 3.2.5 产品框架总结.43 3.2.6 绩效评估.51 ii 3.2.7 项目应用分析.52 3.3 小结.52 第四章总结与收获.53 4.1 总结.53 4.2 收获.53 致谢.55 参考文献.56 附录.58 原 创 性 声 明.59 iii 敏捷开发方法在软件开发中的应用探索 摘要 敏捷开发是近些年兴起的一种软件开发与管理的思想，以其灵活性，易操作性得到 软件行业的广泛关注。 为加快软件开发速度， 提高项目组工作效率， 提升软件开发质量， 尝试将敏捷开发方法引入项目后期软件开发工作中。采用敏捷开发中极限编程的方法， 通过完善系统开发流程，调整项目开发人员的结构，实施配对编程等方式，进行软件开 发。 利用对项目开发中不同时期使用不同开发方法后的单体测试结果进行深入细致的分 析和科学仔细研究，得出结论，引入敏捷开发方法后，在软件开发阶段，单体测试中的 不良个数明显提高，大量错误代码和问题代码被发现并解决，系统测试和验收阶段不良 单体明显减少，软件开发质量得到提高，有效降低软件后期维护成本；同时，传统的软 件开发流程得到优化，使得软件开发效率大幅提升，减少了项目实施成本，提高了项目 收益，保障了项目利用的最大化。 本文进行研究的两个实际案例，覆盖了软件外包项目组，与贴身客户服务型的小型 项目组。着重讨论了敏捷开发方法在两种类型项目中如何提高软件质量，如何更加灵活 的响应客户需求，提升客户满意度。针对它的各种优势进行研究与分析，讲述如何将敏 捷理念用于实践，从而让更多的人了解到它的实际价值与应用前景。 关键字：敏捷开发、极限编程、软件开发、项目管理、应用 iv abstract agile development falls on the calendar of software development and administration at its fast speed in recent years. characterized by its easy practicability and agility, agile development draws great attention from the software industry, contributing to the speed of software development, the improvement of working efficiency as well as the quality of the software. it has been introduced to post period of software development.by using the extreme programming, improving the completeness of system development, adjusting the structure of programmers, the quality and effectiveness of software will be guaranteed. conclusions can be drawn from test results of using different methods in different periods that agile development is able to identify the errors and problematic data and correction will be made immediately. improvements are made on the quality of software and the costing on the post maintenance is largely reduced. also, the procedure of traditional software programming can be optimized, enabling maximizing the effectiveness of the software programming, profits of the project as well as minimizing the costing of the project. in this paper, two real cases are studied, including software outsourcing projects and small personal customer service projects. from that we can see how the a.d. can improve the products in these two types of projects, and how it can affect the customers demands and promote the customer satisfaction. by studying and analyzing the advantages of a.d., showing the way of how to pull the agile concepts into practice, in order to make more people understand its value and application prospect. keywords：agile development、 extreme programming、 software development、 project management、application 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 1 第一章绪论 传统的软件开发管理模式脱胎于建筑及机械设计等传统行业，在传统建筑行业中， 一旦图纸设计得到认可，建筑的修建必须按照图纸的设计执行。传统的软件开发模式也 是在假定图纸（软件的设计）不会改变的情况下进行开发。在早期的软件开发中，由于 硬件资源、网络资源的匮乏，以及面向的用户范围并不广泛，这种传统开发模式能够适 应并促进软件行业的发展。但是到了今天，硬件、网络资源已经逐渐不再是制约软件发 展的条件，软件与用户交互的模式及范围越发的复杂与多样，传统开发模式中假定设计 不变的前提条件越发站不住脚。敏捷开发是近些年兴起的一种软件开发与管理的思想， 以其灵活性，易操作性得到软件行业的广泛关注。本文从敏捷开发方法在两种完全不同 开发团队的实际应用出发，针对敏捷开发方法的实施过程与实施效果进行了全面的分 析，从而让更多的软件开发团队看到敏捷方法的优势，改善开发产品的质量，降低软件 开发的成本，提高用户的使用体验。 1.1 本文研究目的和意义 1.1.1 我国软件行业现状 我国软件公司如果按照 cmmi 【能力成熟度模型】 来进行分类大部分企业都处于 1 初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个 人努力。管理是反应式的。 2 已管理级：建立了基本的项目管理过程来跟踪费用、 进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验， 只有少数几家大型软件公司能够达到。3 已定义级：已将软件管理和工程两方面的过 程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的 标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。4 量化 管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理 解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 如果按照经营方式来看，又分为软件外包企业，集成商，行业应用软件企业等。 我 国的软件产业在 2000 年到 2009 年十年间，2009 年软件产业收入为 9970 亿元，是 2000 年的 16 倍；软件出口 196 亿美元，是 2000 年的 49 倍。但是纵观各种软件企业的管理 状况还处于初级阶段，软件从业人员的人员流失率一直居高不下，软件工作者的工作时 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 2 间也高于整个社会的平均工作时间，长期处于过劳状态。 接 单 谈 需 求谈 需 求 设 计 开 发设 计 开 发 需 求 变 化需 求 变 化加 班 加 点加 班 加 点人 员 流 失人 员 流 失 延 期 交 付延 期 交 付 图 1.1 软件开发的怪圈 如图 1.1 所示，软件开发过程往往陷入客户指责项目经理为何延期交付，项目经理 责令开发人员加班加点开发，开发人员指责设计人员设计不合理，设计人员指责需求分 析人员不能稳定需求。最后人人都在加班，人人都不满，人员逐渐流失，但是还是迟迟 无法满足客户的需求。 1.1.2 研究的目的与意义 传统的软件开发模式对软件开发管理中不变的部分与可变的部分的定义是这样的： 首先假定软件的特性是不变的，在软件特性不变的基础上去安排开发的时间周期，开发 的人员安排。但是软件特性不变这个前提在如今的软件开发中已经慢慢的不再适用， 在 特性会发生重大变化的情况下，传统模式已经走入了无解的怪圈，就像图 1.1 显示的那 样。而敏捷开发方法不同，敏捷开发方法认为，在软件开发的过程中时间，资源相对时 稳定的，例如每个迭代的开发周期是不变的，开发人员也是相对稳定的，但是软件的特 性是会发生改变的，如图 1.2。 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 3 固定 可变 特性特性 特性特性 时间时间资源资源 时间时间资源资源 传统开发模式传统开发模式敏捷开发敏捷开发 敏捷开发 是拥抱需 求变化的 图 1.2 传统模式与敏捷模式对比 “软件开发之父”martin 曾说过，“信息时代，唯一不变的就是变化。”市场环境 在变、科学技术在变、业务需求也在变，在搭建企业信息系统时如何能够在变化中迅速 响应？敏捷开发技术很好的回答了这个问题！因为它是一种应对变化的方法，它的关键 之处在于，能够“敏捷”地适应项目的变化，而不是在开发阶段去适应需求变化。敏捷 开发作为一种面临迅速变化的需求， 快速开发出高质量软件产品的新方法， 自问世以来， 对软件工业起着积极而又重要的影响，它吹响了软件工业的战斗号角，颇受业内人士推 崇。它的主要特征就是允许对过程进行自主调整，并且强调软件开发中人的因素，它克 服了传统开发方法的缺点，和传统开发方法有着明显不同。由于软件在规模、复杂度、 功能上的极大扩展和提高， 以及在需求和技术不断变化的过程中实现软件自身开发的需 求，敏捷开发正逐渐成为软件开发的新模式。因此，我们应当更好的利用这种方法， 适 应快速的需求变化， 达到完善需求分析， 改进开发过程， 提高软件项目管理水平的目的， 并扩展它的应用领域。敏捷方法从来不会责怪客户为什么总是在改变需求，应为需求变 化本来就是软件的一个重要特性。通过小版本的发布，每次迭代提交给客户最有价值的 可用的软件，与客户一起完善软件，最终满足客户的需求。 本文进行研究的两个实际案例，覆盖了软件外包项目组，与贴身客户服务型的小型 项目组两种类型。并通过这些研究，着重讨论了敏捷开发方法在两种类型项目中如何提 高软件质量，如何更加灵活的响应客户需求，以及如何提升客户满意度等问题，最终充 分体现出在软件开发中应用敏捷方法的优势所在。 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 4 1.2 敏捷开发方法应用现状 近几年，敏捷软件开发在软件业有了良好的发展势头并逐渐被推广开来。一些著名 的公司如 google, microsoft 和 yahoo 和众多的中小公司都已经开始采用敏捷开发。它们 中的许多已经有了较长时间的经验。 中国的许多开发团队这几年也在逐渐接受并应用这 种开发模式。 一种软件开发方法被业界普遍接受并流行起来可能需要十年或二十年的时间。从 scrum 和极限编程诞生以及被应用到现在已经有 20 多年的历史了。精益软件开发模式 也有已近 10 多年的历史。现在，这些敏捷方法正在取得良好的发展，越来越多的人开 始关注它们。 scrumalliance 是敏捷开发发起人之一 ken schwaber 创办的一个 scrum 咨询公司。 除了组织会议和提供关于 scrum 的相关咨询服务外，scrum alliance 公司的最大的特点 是开创了 scrum 认证系统， 用以对 scrum 人员进行认证。 该系统分别有培训和认证两个 过程。 它有五种类型的证书： scrum 专家 （certifiedscrum masters） 、 产品所有者 （product owners） 、scrum 行业者（scrum practitioners） 、scrum 教练（scrum coach）和 scrum 培 训师 （certifiedscrum trainer） 。 scrum 培训师证书是提供 scrum 顾问给团队进行 scrum 培训和认证的。scrum 专家产品所有者和 scrum 行业者证书则是侧重于对团队进行 scrum 项目的实际应用培训和认证。这些证书已经获得软件行业的广泛接受。每年有成 千上万的人在培训和认证过程中获得提高并为公司带来效益。 另一个主要的有关敏捷开发的组织是敏捷联盟（agile alliance） 。敏捷联盟是一个 由对敏捷开发感兴趣的个人和公司组成的联盟。该组织的主要活动包括出版刊物，组织 讨论小组，组织会议等。其中一个比较重要的会议是一年一度的敏捷会议（agile conference） 。它已经成为一次著名的会议，吸引着世界各地从事敏捷开发的研究人员、 项目经理、 开发者、 公司和顾问团等。许多在会议上提交的文章都被收入并发表在 ieee 相关刊物上。 另一方面， 各种类型， 各种规模的公司都逐渐开始关注敏捷开发。 科技巨头如 google, yahoo, ibm 和 microsoft 使用敏捷开发已经很多年。 他们通常选择某几个开发团队来试 用敏捷开发模式，然后将开发经验推广到其他的开发团队中去。中小型软件公司以其灵 活创新的特点，更加适合敏捷开发。许多公司都已经把开发团队完全转型到敏捷开发模 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 5 式下。根据 forrester 公司，“dr. dobbs journal” ，和 methods and tools 针对 2005 到 2008 年的行业调查报告显示，在美国和欧盟，对敏捷的认识和采用率以每年 50%左 右的速度增长。如果用杰弗里摩尔（geoffrey moore）的技术采纳生命周期理论 （technologyadoption life cycle theory）来分析这一数据，我们会发现敏捷方法已经过 了创新（innovators）和初期采用（early adopters）阶段，目前已进入早期多数（early majority）阶段。很显然，敏捷方法将在早期多数（early majority）阶段加速采用率的增 长势头，并被更广泛的企业所接受。 为方便敏捷项目的管理，许多公司推出了针对敏捷开发的项目管理软件。其中比较 流行的商业软件有 scrumworks, versionone, rally 等等。 这些工具的出现已有一段时间， 他们遵循传统的软件产品发展模式因而积累了繁多的功能， 大多数敏捷团队可能只会用 到 其中 少数的一 些功能。 其它还有很多种类 似的工具 , 比如 extremeplanner, targetprocess, scrum for team system, jira 等等。相信读者在互联网上会很容易找到它 们的相关资料。 敏捷在中国刚刚开始被采纳。中国的软件开发群体在近几年开始使用敏捷方法， 所 以只有很少的一些有关组织和公司。 而且大部分使用敏捷方法的公司都集中在外资跨国 企业如 ibm，sun，以及一些软件外包公司如文思创新等。同时也有一些比较前沿的国 内公司如腾讯等率先推广了敏捷开发。 可以说中国的敏捷采用率仍然停留在技术采纳生 命周期的初期试用（early adopters）阶段。尽管如此，中国的软件工业中存在着敏捷方 法迅速发展的契机 首先，在中国，大规模的软件公司只有少数几个，剩下的大多数开发团队规模都不 大，开发团队都不会超过 200 人。这些团队大多采用手工作坊的工作方式，没有正规的 开发方法，许多事情的处理往往取决于他们技术领导的个人风格。这有时被称为“实用 主义” 。 “实用主义”看起来很高效，没有任何管理开销和束缚。但这种方式有几个缺点。 首先，这样的团队效绩和产品的质量不稳定，往往时好时坏。其次，这样很难形成有凝 聚力的自我管理的团队。如果团队的核心人物离职或出了其它问题，整个团队就立即丧 失了组织力，或整个团队就要去适应另一种开发风格。再有，这种团队往往也缺少一种 有序自觉的学习和自我提高机制，而开发效率的停滞就是对人才的浪费和不负责任。 总 之，这种方式的最大缺点就是质量和效率的随机性和不稳定性，很难和职业化的软件开 发竞争。显然，这些并不是什么好事。但另一方面，在转向使用敏捷开发模式的过程中 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 6 这些团队比其它团队面临更少的障碍， 消耗更少的资源。 换言之， 他们没有成型的模式， 没有过多的包袱，采用敏捷开发模式让他们失去的很少，但能获得很多。这些公司的规 模也有利于敏捷方法的实施。他们规模较小并且在同一个地方工作， 采用敏捷开发更 容易、风险更少，敏捷也更适用于他们。 中国文化中存在许多适合敏捷开发的元素。 敏捷宣言的第一条便把人和人们的 协作放在了规程和工具的前面。在中国文化的深层，无论政府机关，企业或家庭，更多 的是以人为核心，而非规程和条例。这符合敏捷重视人多于过程的精神。如果这一点能 被仔细的研究和应用于整个团队，将更容易激发团队成员的积极性和创造性，提高软件 开发的质量和速度。还有，敏捷开发对传统的西方式由上至下多层次的职业管理提出了 挑战。现在，很多人都在关心和讨论管理层需要如何改变以更好地适应敏捷模式。其中 一点是，敏捷要求管理层更简洁并更注重服务于团队。在中国，公司和项目管理并不是 很职业化。从这种起点转向敏捷可能更直接、简单。另外，中国的很多软件开发人员习 惯于几乎无计划的随心所欲的代码编写。这在西方被称为牛仔编码（cowboy coding） 。 这种风格离敏捷的距离似乎比应用瀑布模型或 cmmi 标准的专业开发风格更小。 许多其 他的中国文化因素，比如关注细节，节俭，以及面对变化的适应能力等都为敏捷开发在 中国软件业的发展提供了有力的支持。 这些独特的中国文化元素和业界特点为敏捷开发的发展和实施提供了先天的条件。 如果中国的软件业界能够在敏捷开发的理论与实践方面迎头赶上并有所创新， 敏捷开发 一定能为中国的软件产业效率和质量的提高， 和进入甚至领先国际市场起到决定性的推 动作用。可以预见，敏捷在中国将很快会迎来一个迅猛的发展时期。 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 7 第二章敏捷开发方法基础理论介绍 2.1 敏捷宣言 敏捷方法是一种能够容纳变更的软件工程框架。比如，通常对于复杂的软件开发工 作，需求在项目开始的时候尤其是未知的或含糊的。所以，敏捷框架必须要有内建的机 制使项目得以处理并减少这些不确定因素。这些机制在本章中将作为关键实践列出。 如 果将这些关键实践中的任何一个丢弃，那么敏捷项目都将是不完整的。 而敏捷也意味着框架本身也是灵活的，并可以适应许多情况。这就是说将相同的框 架应用在两个项目上将有两种不同的解释。把敏捷方法描述为“经验性” （empirical） 的 方法更为合适，因为项目本身必须适应其环境，这并不是机构应该做的，而是各个项目 的事情。敏捷不是一种“一体皆适用” （one size fits all）的解决方案。 敏捷宣言是 2001 年在犹他州的 snowbird 滑雪胜地召开的一次会议的结果。在这之 前，各个敏捷过程被称为“轻量” 。尽管对名称有一些小的疑虑，但在滑雪胜地参加会 议的所有 17 个与会者定义了敏捷过程并签署了宣言，这些成为了今后几年人们对敏捷 的衡量标准。 这份宣言的发布立即给业界一个关于敏捷的明确定义以及将来添加新思想 时的基本规则。时至今日，这份宣言仍然提供着清晰的方向，我们使用它来讨论、比较 敏捷方法。更重要的是，这份宣言为所有敏捷实施者提供了一个共同的基础，无论他们 所钟爱的敏捷方法是哪种。以下是这份宣言的核心价值： 我们正通过亲身实践以及帮助他人实践，揭示更好的软件开发方法 通过这项工作 ，我们认为（图 2.1） ： 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 8 图 2.1 敏捷宣言 虽然右项也有其价值，但我们认为左项更加重要。 2.2 敏捷开发方法的基本原则 1 1 1 1我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭 代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交付具 有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写 详细的需求，敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术， 它没有固定的形式和强制性的语法。 但是有一些固定的形式可以用来参考还是比较有益 的。敏捷估算中使用了这个模板：“作为【用户的类型】 ，我希望可以【能力】以便【业 务价值】 ” 。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工 作重点更多的转移到了口头交流。 2 2 2 2即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争 优势。优势。 敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们 更了解市场需求。 3 3 3 3经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间 间隔越短越好。间隔越短越好。 迭代是受时间框限制的，意味着即使放弃一些功能也必须按时结束迭代。只要我们 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 9 可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密， 对产品质量就更有益。 虽然我们多次迭代， 但并不是每次迭代的结果都需要交付给用户， 敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功 能，增加的每个功能都是经过编码、测试，达到了可发布的质量标准的。 另外敏捷开发项目中对开发阶段没有什么重要的分割，没有先期的需求阶段，然后 是分析阶段，架构设计阶段，编码测试阶段等，在项目真正开始后，每次迭代中都会同 时进行所有的上述阶段工作。 4 4 4 4在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案 肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、 频 繁 的交互，这样就可以在早期及时的发现并解决问题。 5 5 5 5围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信 任他们能够完成工作。任他们能够完成工作。 业务和技术是引起不确定的二个主要方面，人是第三个方面。而业务和技术又必须 由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标 和团队的目标一致，我们就需要鼓舞起每个人的积极性，以个人为中心构建项目，提供 所需的环境、支持与信任。 6 6 6 6在团队内部在团队内部，最具有效果并且富有效率的传递信息的方法最具有效果并且富有效率的传递信息的方法，就是面对面的交谈就是面对面的交谈。 在十几或者二十几个人组成的大团队中， 文档是一种比较合适的传递知识和交流的 途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队 ） ， 所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 7 7 7 7工作的软件是首要进度度量标准。工作的软件是首要进度度量标准。 一般的工作都比较容易衡量任务进展，比如让你去搬运 1 吨的石头，我只要去称一 下你已经搬运的石头重量就知道你完成多少了。而对于软件来说，在软件没有编码、 测 试完成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功 能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来 说已经可以应用了。 8 8 8 8敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期 的、恒定的开发速度。的、恒定的开发速度。 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 10 很多人都认为软件开发中加班是很正常的， 不加班反而不正常， 我对此有点不理解， 这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发，开发速度不会随着迭代 的任务不同而不同， 不欣赏所谓的拼一拼也能完成的态度， 开发工作不应该是突击行为。 我们不能指望说突击这个项目后就可以轻松了， 因为完成一个项目后会接踵而来下一个 项目，而只要还是拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有 人会不会说，那我们就一直加班，也是“持续的开发速度”啊，这时可要注意了，持续 加班智慧导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。 9 9 9 9不断地关注优秀的技能和好的设计会增强敏捷能力。不断地关注优秀的技能和好的设计会增强敏捷能力。 敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可 以增强敏捷开发能力。 10101010简单简单 我们不可能预期后面需求会如何变化， 所以不可能一开始就构建一个完美的架构来 适应以后的所有变化。敏捷团队不会去构建明天的软件，而把注意力放在如何通过最简 单的方法完成现在需要解决的问题。这时有人会说，我已经预计到了肯定存在哪些需求 扩展点，我们在一开始是否需要考虑呢？这时团队需要根据自己的理解去决定是否考 虑，如果深信在明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。 11111111每一个成员都具有项目中所有方面的参与权每一个成员都具有项目中所有方面的参与权，最好的构架最好的构架、需求和设计出自于需求和设计出自于 自组织的团队。自组织的团队。 敏捷中有很多种实践，大家都知道，迭代式开发是主要的实践方法，而自组织团队 也是主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最 佳的工作方式来完成工作。要形成一个自组织团队其实比较难。自组织团队的第一个要 素就是必须有一个团队，而不仅仅是一群人。一群人是一帮在一起工作的人，他们彼此 之间并没有太多的沟通，他们也并不视彼此为一体。项目一开始，我们就会组建“团 队”，但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。 他 还认为，团队的形成必须经历几个时期。在经历了初期的磨合后，成员才会开始对团队 共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些 规矩是不言而喻的。比如，每个人都知道上午九点来上班，都会主动询问别人是否需要 帮助，也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这 个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 11 率非常高。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次 的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。 虽然敏捷开发小组是以小组为整体来工作的， 但是还是有必要指明一些承担一定任 务的角色。第一个角色是产品所有者（product owner） 。产品所有者的主要职责包括： 确认小组所有成员都在追求一个共同的项目前景， 确定功能的优先级以便总是在处理最 具有价值的功能，以及作出决定使得对项目的投入可以产生良好的回报。可以对应为以 前开发中的“产品经理”。另一角色是开发团队（developer） ，这里的开发人员包括了 架构师、设计师、程序员、需求人员、测试人员、文档编写者等，有时产品所有者也可 以被看作是开发人员。还有一个重要角色就是项目经理（project manager） 。敏捷开发的 项目经理会更多的关注领导而不是管理。在某些项目中，项目经理可能同时也是开发人 员，少数时候也会担任产品所有者。 12121212每隔一定时间每隔一定时间，团队会在如何才能更有效地工作方面进行反省团队会在如何才能更有效地工作方面进行反省，然后相应地对然后相应地对 自己的行为进行调整。自己的行为进行调整。 由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户 需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。敏捷不是基于预定义 的工作方式，而是基于经验性的方式，对以上这些变化，小组通过不断的反省调整来保 持团队的敏捷性。在敏捷之中更加敏捷。 2.3 敏捷开发的面向对象设计原则 1srp 单一职责原则 就一个类而言，应该仅有一个引起它变化的原因。职责即为变化的原因。 2ocp 开放封闭原则 软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开 放的,对于更改是封闭的。 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。 开发人员应该 仅仅对程序中呈现出频繁变化的那些部分作出抽象.拒绝不成熟的抽象和抽象本身一样 重要。 3lsp liskov 替换原则 子类型必须能替换掉他们的基本类型。 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 12 4dip 依赖倒置原则 抽象不应该依赖于细节。 细节应该依赖于抽象。hollywood 原则: dont call us, well call you.程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。 任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。 任何方法都不应该覆写他的任何基类中的已经实现了的方法。 5isp 接口隔离原则 不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于他所在的类层次结 构。多个面向特定用户的接口胜于一个通用接口。 6rep 重用发布等价原则 重用的粒度就是发布的粒度。 7ccp 共同重用原则 一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包 中的所有类。相互之间没有紧密联系的类不应该在同一个包中。 8crp 共同封闭原则 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影 响，则将对包中的所有类产生影响，而对其他的包不造成任何影响。 9adp 无依赖原则 在包的依赖关系中不允许存在环。细节不应该被依赖。 10sdp 稳定依赖原则 朝着稳定的方向进行依赖.应该把封装系统高层设计的软件 （比如抽象类） 放进稳定 的包中，不稳定的包中应该只包含那些很可能会改变的软件（比如具体类） 。 11sap 稳定抽象原则 包的抽象程度应该和其他稳定程度一致。一个稳定的包应该也是抽象的，一个不稳 定的包应该是抽象的。 12dap(default abstraction principle)缺省抽象原则 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作。 13idp(interface design principle)接口设计原则 规划一个接口而不是实现一个接口。 14bbp(black box principle)黑盒原则 贵州大学计算机科学与信息学院 2007 级工程硕士毕业论文 13 多用类的聚合，少用类的继承。 15dcsp(dont concrete supperclass principle)不要构造具体的超类原则 避免维护具体的超类。 2.4 敏捷开发的最佳实践方法 1完整团队 xp 项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场 所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以 及其他一些显示他们进度的东西。 2计划游戏 计划是持续的、循序渐进的。每 2 周，开发人员就为下 2 周估算候选特性的成本， 而客户则根据成本和商务价值来选择要实现的特性。 3客户测试 作为选择每个所期望的特性的一部分， 客户可以根据脚本语言来定义出自动验收测 试来表明该特性可以工作。 4简单设计 团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重 复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 5结对编程 所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。 6测试驱动开发 编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的