第八章 敏捷开发方法.pptVIP

第七章 敏捷开发方法 第7章 敏捷开发方法 敏捷开发方法的核心思想 敏捷开发方法的原则 敏捷开发方法的代表——极限编程 第一节敏捷开发方法的核心思想 敏捷软件开发方法的思想是现代管理理念的延伸，其核心是以人为本，发挥人的主观能动性。 敏捷软件开发方法认为，对项目最重要的影响因素是人，而不是过程和技术。不能把人员当做由过程驱动的“可插拔替换的编程单元”，而要发挥人的能动性，建立紧密协作的、自组织的团队。 以过程为核心（而不是以人为核心）的软件组织为了少犯错误，保证项目成功，而从项目开发经验中总结和定义了许多过程，用于约束开发行为，避免重复相同的错误。由于项目的复杂性和多样性，这种过程定义会越来越多，最终形成一个庞大的、笨重的过程集合，这样的过程集合会降低开发效率和产品质量，增加开发成本。 敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 人和交互 重于 过程和工具 可以工作的软件 重于 面面俱到的文档 客户合作 重于 合同谈判 随时应对变化 重于 遵循计划 虽然右项也有其价值，但我们认为左项更加重要。 人和交互重于过程和工具 只有好的过程而缺乏合格的人员，不能保证项目不失败。 优秀的人员不一定是顶尖的技术人才，但一定能和其它人员良好地协作。 拥有一般的技术人才，但能够有效沟通、紧密协作的团队比那种虽拥有技术精英，但不能有效沟通的团队更有可能取得成功。 人和交互重于过程和工具 工具虽然重要，但那种最先进的、大而复杂的工具不一定适合组织的需要，而且可能会给组织带来负面影响。 先尝试小而灵便的工具。 首先要致力于建立团队，然后让团队根据自己的需要配置工具环境。 可以工作的软件重于面面俱到的文档 过多的文档会带来许多负面影响。需花费许多资源来产生这些文档并保持它们之间的一致性（特别是文档与编码之间的一致性）。如果不一致，文档将成为产生混乱的根源。 应该书写一些文档来描述系统的基本结构和原理，但文档一定要短而精炼，只用来描述总体设计原理和最高层次的系统结构。 代码已包含了最丰富的、且无歧义的系统信息。 可以工作的软件重于面面俱到的文档 当有新的成员加入项目团队，通过与他不断地交流和密切地合作来使他熟悉当前项目，而不是让他阅读大量文档。 不要去产生文档，除非有紧迫而明显的需求。 客户合作重于合同谈判 软件项目的成功依赖于客户频繁的反馈，而不是依赖于与客户达成的合同或协议。 合同中所规定的需求、进度和成本很容易变得没有意义，因为项目处在持续不断的变化中。 客户必须每天与开发团队一起工作，对开发团队的工作及时提供反馈。 随时应对变化重于遵循计划 由于项目中存在很多不确定因素，应对变化的能力常常决定了项目的成败。 计划必须是灵活的，能够适应业务和技术的变化。 一个比较好的计划策略是：对未来两星期的工作制定详细的计划；对未来3个月的工作制定很粗略的计划；对更远的时间段，则制定最初级的计划。 第7章 敏捷开发方法 敏捷开发方法的核心思想 敏捷开发方法的原则 敏捷开发方法的代表——极限编程 第二节 敏捷开发方法的原则 由敏捷软件开发宣言的思想衍生出敏捷软件开发的12条原则。 （1）我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户的需要。 有统计数字表明，越早、越频繁地向用户交付软件，软件的质量就越好。 敏捷开发方法力求项目开始几周后，就向用户交付一个最初的系统，以后每隔两周就交付一个增加了功能的系统。 敏捷原则 对于每次交付的软件，客户可以将其投入应用，如果软件的功能还不足以满足应用的需要，就只对其进行审查，并提出修改意见。 敏捷原则 （2）欢迎需求的变化，即使到了开发的后期。敏捷过程能够驾驭变化，为客户创造竞争优势。 使用敏捷过程的开发组织欢迎需求的变化，因为他们认为需求变化可以让它们更多地了解市场。 敏捷开发组织采用各种方法和技术，使软件的结构高度灵活，需求的变化对系统的影响被最小化。 敏捷原则 （3）频繁交付可以工作的软件，从几个星期到几个月，时间越短越好。 敏捷开发组织不满足于交付文档和计划，他们的目标是频繁地交付可以工作的软件，从而满足客户的需要。 敏捷原则 （4）在整个项目开发期间，业务人员和开发人员必须每天工作在一起。 软件项目必须被不断地调整和引导，这要求用户、开发者和其他利益干系人要频繁地交流。 敏捷原则 （5）围绕斗志高昂的人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成任务。 在一个敏捷项目中，人员被认为是最重要的因素，其它所有因素（过程、环境、管理等）都被认为是次要的，当这些因