敏捷软件开发93441.ppt

设计模式及软件工程新技术 敏捷软件开发 信息科学与技术学院 李晓航 xhli_scce@ 一、敏捷开发概述 敏捷软件开发—Agile Software Development Agile [?d?ail] adj. 敏捷的；机敏的；活泼的. —《21世纪大英汉词典》 敏捷方法 VS 工程方法 工程方法（Engineer Methodology) 借鉴了工程领域的实践，有着严格而详尽的规定，强调项目的可控性； 官僚繁琐，要做太多的事情从而延缓开发进程。 敏捷方法（Agile Methodology） 以客户的商业价值为最终目标，追求更低的成本、更少的缺陷、更高的生产率、更高的投资回报； 对繁文纑节的官僚过程的反叛，轻装上阵、卸下包袱； 只要求尽可能少的文档，认为最终的文档应该是“源代码”。 敏捷联盟（Agile alliance） 2001年初，在犹他州的Snowbird，由于看到很多软件开发团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为“敏捷联盟” 敏捷联盟是一个非盈利组织，其宗旨是推广敏捷方法的促进这方面的讨论。 在随后几个月，他们创建了一份价值观声明，也就是敏捷联盟宣言。 敏捷联盟（Agile alliance） Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas / 敏捷方法的两个核心理念 敏捷方法是“适应性”的而非“预见性”的 工程方法试图对一个软件开发项目在很长时间跨度内做出详细计划，然后依序开发。这类方法在需求和环境有变化时并不能发挥效力，其本质是拒绝变化的； 而敏捷方法则欢迎变化，它通过迭代获得反馈，目的是成为适应变化的过程，甚至允许改变自身来适应变化。 敏捷方法是“面向人”的而不是“面向过程”的 工程方法的目标是，定义一个过程，不管是谁用，都能运转良好； 而敏捷方法认为没有任何过程能代替开发团队的技能，过程所起的作用，是对开发团队的工作提供辅助支持。 敏捷联盟宣言 The Manifesto of the Agile Alliance 敏捷联盟宣言， 2001 个体和交互胜过过程和工具 人是获得成功的最为重要的因素 一个优秀的团队成员未必就是一流的程序员 优秀团队的成员可能是平均水平的程序员，但他（她）们能很好的和别人合作、沟通。 合适的开发工具（如IDE、Complier、版本控制系统）对于成功很重要，但工具的作用不宜被过分夸大 可以工作的软件胜过面面俱到的文档 没有文档的软件是一种灾难；然而，过多的文档比过少的文档更糟糕 编制文档需要花费时间，使文档和代码同步，需要花费更多时间。 对于团队，维护一份系统原理和结构方面的文档是一个好主意 该文档应该是短小并且主题突出的，应该仅描述系统的高层结构和概要设计原理。 为了培训新成员，应该通过团队交互和代码 代码和团队是最好的两份文档。 客户合作胜过合同谈判 不能向订购日用品一样来订购软件 如果客户仅仅写下一份他需要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它，用这种方式来对待软件项目的尝试都是以失败而告终的。 成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量地提供反馈。 响应变化胜过遵循计划 响应变化的能力常常决定着一个项目的成败 当构建计划时，应该确保计划是灵活的、并且易于适应商务和技术方面的变化 计划不能考虑的过远 计划没有变化快！ 较好的作计划的策略是： 为下两周做详细计划；为下三个月做粗略计划；再以后就做极为粗糙的计划。 这种逐渐降低的细致度，意味着仅仅对迫切的任务才进行详细计划，计划的其余部分仍然保持着灵活性。 原则（Principles） 1. Our highest priority is to satisfy the customer through early and continues delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the cus