敏捷开发讲稿.pptxVIP

敏捷开发交流敏捷联盟 2001年初，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷(Agile)联盟。在随后的几个月中，他们创建出了一份价值观声明。也就是敏捷联盟宣言(The Manifesto of the Agile Alliance)。敏捷宣言我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为： 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划虽然右项也有价值，但我们认为左项具有更大的价值。成员优秀过程好坏敏捷宣言个体和交互胜过过程和工具人是获得成功的最为重要的因素。合作、沟通以及交互能力要比单纯的编程能力更为重要。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。一个优秀的团队成员未必就是一个一流的程序员，一个优秀团队的成员可能是一个平均水平的程序员，但是却能够很好地和他人合作。优秀团队敏捷宣言可以工作的软件胜过面面俱到的文档没有文档的软件是一种灾难。过多的文档比过少的文档更糟。代码文档同步代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来描述系统原理、结构、设计和决策的依据等。敏捷宣言客户合作胜过合同谈判指明了需求、进度以及项目成本的合同存在根本上的缺陷。成功的项目需要频繁有序的客户反馈。为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。敏捷宣言响应变化胜过遵循计划计划赶不上变化。响应变化的能力决定一个项目的成败。较好的做计划策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。敏捷实践原则我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。敏捷实践原则围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。工作的软件是首要的进度度量标准。敏捷过程提倡可持续的开发进度。责任人、开发者和用户应保持一个长期恒定的开发速度。敏捷实践原则不断关注优秀的技能和好的设计会增强敏捷能力。简单——使未完成的工作最大化的艺术——是根本的。最好的构架、需求和设计出自于自组织的团队。每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。敏捷实践总结每一位软件开发人员、开发团队的职业目标，都是给雇主和客户交付最大可能的价值。虽然在项目中采用过程方法是出于好意，但是膨胀的过程方法对于项目的失败至少应该负一些责任。敏捷软件开发的价值观和原则构成了一个可以帮助团队打破过程膨胀循环的方法，它关注的是可以达到团队目标的一些简单的技术。已有的敏捷过程XP(eXtreme Programming)：[Beck 1999], [Newkirk2001]。SCRUM：。Crystal Clear： http:// 。FDD(Feature Driven Development)：Java Modeling In Color With UML: Enterprise Components and Process, 1999。ADP(Adaptive Software Development) ：[Highsmith2000]DSDM：Dynamic System Development Method；UP：Unified Process，OpenUP、Rational UP；极限编程实践 极限编程(eXtreme Programming,简称XP)是敏捷方法中最著名的一个。它由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个敏捷开发过程。极限编程实践完整团队XP项目的所有参与者(开发人员、业务分析师、测试人员等等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。客户测试作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。极限编程实践简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不