迭代进化敏捷过程.ppt

敏捷原则 通过早期和持续交付有价值的软件来满足客户 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。 以两周到两月为周期，频繁地交付可运行的软件。 在整个项目的过程中，每一天开发人员都要和来自客户的业务人员合作。 依靠有干劲的个体推动项目的开发，为他们提供所需的开发环境、支持和信任。 在开发团队中获开发团队间传递信息的最为有效和高效的方法是面对面的交流。 衡量进度的重要尺度是可运行的软件。 敏捷过程提倡持续开发和集成。 发起人、开发者和用户应该步调一致。 关注技术和设计技能的提高。 简洁，这门减少工作量的艺术至关重要。 团队要定期反省如何使工作更有效，然后相应地调整行为。 什么是敏捷UP UP的创始人并没有为其赋予重量级或非敏捷的含义，尽管其有着庞大的可选活动集和制品集。 UP可以采纳和应用可适应性和轻量级的精神——敏捷UP 敏捷UP示例 推荐使用UP活动和制品的简集。所有的制品都是可选的，除非需要，否则避免。尽早编程，而非构建文档 UP是迭代和不断进化的。实现前的需求和设计是不完整的。 以敏捷建模实践应用UML。 对于整个项目不应有详细的计划。制定估计结束日期和主要里程碑的高阶计划。不对里程碑定义细粒度的计划。只能预先对一个迭代制定更为详细的计划。详细计划是由一次次迭代的调整而完成的。 敏捷的UP 从标准的UP活动中选取了一小部分活动和成果物，是UP的一个简集。 敏捷建模：建模的主要目的是为理解，而非文档。 不需要一个对于项目整体的详细计划。 测试驱动 重构 持续集成 什么是敏捷建模 采用敏捷方法并不意味着不进行任何建模 不对所有或大多数软件设计建模或应用UML 尽可能使用最简单的工具 不单独建模，而是结对（或三个人）在白板上建模 并行地创建模型 要知道所有模型都可能不准确 开发者应该为自己进行OO设计建模 建模（构件UML草图…）的目的主要是为理解、而非文档 图2-5 某项目中UML顺序图的草图 教材作者和4个开发人员，20分钟时间完成的UML草图 判断你是否理解迭代开发或UP 你是否认为 初始 = 需求 细化 = 设计 构造 = 实现 你是否认为制作UML图的设计过程是用来精确地定义系统，而开发和编码只不过是将他们机械地变换为源程序的过程 * * * * * 随着系统规模的增加，软件开发需要越来越多的，拥有不同技能的人员的参与，这些人往往还会分布的不同的组织中。这些人需要一个流程协调才能富有效率地完成系统的开发。 人成为了虚拟机的组成部分。卓别林的摩登时代 作为老板，如果他只考虑自己的利润(通常是这样)，那么他会希望能够开发一个过程，只要每个开发人员精确无误的执行这个过程的每一条指令，就能够按时保质地完成软件的开发。 * Agile严格意义上不是一个软件过程，只是给出了一个过程需要遵循的原则和倡导的做法 敏捷需要给具体的过程结合，或者有些过程里面具有敏捷所倡导的做法或原则，我就称之为XX敏捷过程 * 传统的瀑布模型究竟遇到什么问题了？我们为什么需要迭代式的开发 软件的变更率可达50% 瀑布式生命周期：试图引进一种简单有序的开发过程，建立一种可以依赖的次序，事实证明这不可行。 瀑布模型在现在看来几乎已经成为了一个贬义词，但是，实际上在理论上这个一个简单漂亮，容易理解和管理的模型，这也是为什么现在还有这么多的组织在实际上使用瀑布模型。 迭代式是一种相对复杂的生命周期 * * * * * * 阶段反映了项目的整体的进展情况。 如果没有阶段的概念，作为CXO，只能从项目经理处得到诸如当前是第12个迭代周期这样的报告。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 * * Refinement * * * * * * * * * 迭代、进化和敏捷 Iterative, Evolutionary, and Agile Grady Booch 说： “人比任何过程更重要。” “优秀的人加上好的过程（流程）在任何时候都比没有好的过程的优秀的人表现出色。” Software Engineering Process Methodologies RUP、XP、Scrum、UP… Techiques OO/UML、DFD、ERD… Tools Visio、StartUML、Eclipse… 议程 定义迭代(iter