c敏捷软件开发方法简介.ppt

敏捷软件开发方法简介 以极限编程为例 参考资料 统一软件开发过程 IvarJacobson GradyBooch JamesRumbaugh 敏捷软件开发 原则 模式与实践 RobertC Martin 微软开发过程与案例 微软中国研究院项目经理和开发人员 高级软件开发过程 金敏 周翔 软件开发的过程与管理 张湘辉 微软中国研究开发中心总经理 面向对象的系统分析 邵维忠 杨芙清 面向对象的系统设计 邵维忠 杨芙清 主要内容 第一节敏捷方法的含义第二节软件开发过程的比较第三节极限编程 eXtremeProgramming XP 简介准则法则活动实践讨论应用实例常见问题 第一节敏捷方法的含义 敏捷 轻巧 机敏 迅捷 灵活 活力 高效 敏捷开发是一种面临迅速变化的需求快速开发软件的能力敏捷过程很容易适应变化并迅速做出自我调整 在保证质量的前提下 做到文档 度量适度 注重事后总结 适用于各类软件企业 敏捷方法产生的背景 现代软件的特点 复杂性 软件越来越复杂可变性 需求越来越多变一致性 过程越来越规范 软件开发过程敏捷化趋势 据国际著名咨询机构CutterConsortium对全球200位IS IT经理所做的调查 3个占优的重载方法 51 RationalUnifiedProcess27 CMM26 ISO9000 大约50 的被调查者预计到2003年其50 以上的项目会使用敏捷方法 14 的被调查者认为其所有的项目会使用敏捷方法FromTHEDECISIONISIN AGILEVERSUSHEAVYMETHODOLOGIES VOL 2 NO 19 byRobertCharette SeniorConsultant CutterConsortium 敏捷价值观 注重个人及互动胜于过程和工具 注重可用的软件胜于详尽的文档 注重客户协作胜于合同谈判 注重响应变化胜于恪守计划 www agilemanifesto org 敏捷宣言 12条原则 1 最优先的目标是通过尽早地 持续地交付有价值的软件来满足客户2 欢迎需求变化 甚至在开发后期 敏捷过程控制 利用变化帮助客户取得竞争优势3 频繁交付可用的软件 间隔从两周到两个月 偏爱更短的时间尺度4 在整个项目中业务人员和开发人员必须每天在一起工作 5 以积极主动的员工为核心建立项目 给予他们所需的环境和支持 信任他们能够完成工作6 在开发团队内外传递信息最有效率和效果的方法是面对面的交流7 可用的软件是进展的主要度量指标 8 敏捷过程提倡可持续发展 发起人 开发者和用户应始终保持稳定的步调 9 简化 使必要的工作最小化的艺术 是关键10 持续关注技术上的精益求精和良好的设计以增强敏捷性11 最好的架构 需求和设计产生于自我组织的团队12 团队定期地对运作如何更加有效进行反思 并相应地调整 校正自己的行为 第二节软件开发过程的比较 瑞理统一开发过程 RationalUnifiedProcess敏捷建模 AgileModeling极限编程 eXtremeProgramming自适应软件开发 AdaptiveSoftwareDevelopment水晶方法体系 Crystaletc 微软过程 需求 设计 实现 测试 分析 核心工作流程 先启 精化 构造 转移 精化过程中的反复过程 初步的反复过程 反复序列 RUP RationalUnifiedProcess RUP是Rational公司的改进过程的规范 它被设计成一种由用例驱动的 以体系结构为中心的软件开发过程 它以迭代的方式前进 通过执行工作流程递增地产生结果它的主要四个阶段 先启 精化 构建和转移 五个核心工作流程 需求 分析 设计 实现和测试由于RUP是一种框架 你可以以不同的方式来使用它 如象非常传统的 瀑布 式开发方式 或敏捷式 如dX 你可以把用得轻捷灵便 也可把它弄成繁文缛节 这取决于你如何在你的环境中对它裁剪运用 CRC卡片 Class Responsibility Collaborator类 职责 协作 XP到RUP的映射 AgileModeling AM是一种最近才出现的软件思想AM是一种轻方法论XP实践既给了AM灵感 也是AM的一种具体实现 AM核心原则 主张简单拥抱变化你的第二个目标是可持续性 简单的说 你在开发的时候 你要能想象到未来递增的变化令投资人的投资最大化有目的的建模多种模型高质量的工作快速反馈软件是项目的主要目标轻装前进 AM补充原则 内容比表示更重要三人行必有我师了解你的模型了解你的工具局部调整开放诚实的沟通 自适应软件开发 ASD的核心是三个非线性的 重迭的开发阶段 猜测合作学习 水晶方法体系 水晶方法体系与XP一样 都有以人为中心的理念 但在实践上有所不同水晶方法体系考虑到人们一般很难严格遵循一个纪律约束很强的过程 因此 与XP的高度纪律性不同 水晶方法体系探索了用最少纪律约束而仍能成功的方法 从而在产出效率与易于运作上达到一种平衡也就是说 虽然水晶系列不如XP那样的产出效率 但会有更多的人能够接受并遵循它 ISO9000 PDCA循环 即由计划 PLAN 实施 DO 检查 CHECK 处理 ACTION 这四个密切相关的阶段所构成的工作方式持续改进 面向对象软件工程概念模型 第三节极限编程 eXtremeProgramming 轻量级敏捷软件开发方法 极限编程 XP 是一种全新而快捷的软件开发方法 XP团队使用现场客户 特殊计划方法和持续测试来提供快速的反馈和全面的交流 这可以帮助团队最大化地发挥他们的价值 XP诞生了大概有8年XP是以开发符合客户需要的软件为目标而产生的一种方法论XP是一种以实践为基础的软件工程过程和思想XP认为代码质量的重要程度超出人们一般所认为的程度XP特别适合于小型的有责任心的 自觉自励的团队开发需求不确定或者迅速变化的软件 3 1XP准则 XP软件开发是什么样的 沟通简单反馈勇气有益的潜在补充准则 尊重谦逊 沟通 XP认为项目成员之间的沟通是项目成功的关键 并把沟通看作项目中间协调与合作的主要推动因素 简单 XP假定未来不能可靠地预测 在现在考虑它从经济上是不明智的 所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急 反馈 XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据 系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段 勇气 代表了XP认为人是软件开发中最重要的一个方面的观点 在一个软件产品的开发中人的参与贯穿其整个生命周期 是人的勇气来排除困境 让团队把局部的最优抛之脑后 达到更重大的目标 表明了XP对 人让项目取得成功 的基本信任态度 3 2XP的法则 一项实践在XP环境中成功使用的依据 快速反馈假设简单性递增更改提倡更改优质工作 快速反馈 XP提倡尽可能早地 迅速地每天反馈 让编程人员始终把注意力放在最重要的软件功能上 促使系统快速演进 XP迭代过程 假设简单性 XP试图把注意力集中在能工作的尽可能最简单的实现上 另一方面 可以根据给定的项目资源条件 最优地分配项目资源 递增更改 XP认为首次更改就尝试重大更改绝对不会成功 提倡以重构概念为基础做小改动 用期望的功能逐步增强系统 提倡更改 最佳策略是在实际解决最重要的问题的前提下保留最多选项的那一个 在交付最需要的东西上保留选择余地 优质工作 3 3XP活动 XP软件开发的基石 编码测试倾听设计 编码 作为一种轻量级方法论 XP明确放弃了系统建档和分析以外的任何外在活动分析保留为一种相当简单 但是在和客户的日常沟通中发生的持续活动文档则明确不予鼓励 所以编码成为XP最主要的活动 测试 为了确保编写好的代码能实践工作 XP提倡编写大量测试来检查代码是否正确 倾听 XP编程人员倾听客户和其他编程人员的需求和意图 设计 从日常的编码中返回来进行一些一般性设计 小的设计成为XP编程人员日常事务的一部分 3 4XP的实践 项目成员用户成功执行XP活动的技术 1 现场客户 On siteCustomer 2 计划游戏 PlanningGame 3 系统隐喻 SystemMetaphor 4 简单设计 SimpleDesign 5 代码集体所有 CollectiveCodeOwnership 6 结对编程 PairProgramming 7 测试驱动 Test driven 8 小型发布 SmallReleases 9 重构 Refactoring 10 持续集成 Continuousintegration 11 每周40小时工作制 40 hourWeeks 12 代码规范 CodingStandards 过程 团队实践 编程 现场客户 测试 计划游戏 小型发布 简单设计 测试 重构 编码标准 代码集体所有 持续集成 隐喻 编码标准 每周40小时工作制 结对编程 小型发布 XP层次结构 1现场客户 始终在开发团队中有一位客户现场客户的工作 回答问题编写验收测试运行验收测试指导迭代接受版本 2计划游戏 以业务优先级和技术估计为基础 决定下一版本发布的范围 3系统隐喻 在XP中 隐喻是一种概念框架并提供名称的描述系统 类似于其他方法中的体系结构 或体系结构基准 共识共享的术语空间例子 Windows风格的界面 网上购物站点的购物车 4简单设计 系统应设计得尽可能简单 5代码集体所有 整个团队拥有所有代码任何人都可以更改他们需要更改的部分没有唯一对代码有所有权的人 题外话一 编程的乐趣 FP Brooks 创造的快乐开发对他人有用的东西整体过程的魅力持续学习的快乐来自于易于驾驭的介质上工作编程的快乐在于它不仅满足了我们内心深处进行创造的渴望 而且还唤醒了每个人内心的情感 题外话二 编程的苦恼 FP Brooks 来自追求完美来自由他人设定目标 供给资源 提供信息陷入琐碎的重复性劳动无用功这 就是编程 一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动 6结对编程 结对编程是让两个人共同设计和开发代码的实践 结对者是全职合作者 轮流执行键入和监视 这提供了持续的设计和代码评审不是两个人做一个人的事情 积极影响 经济性满意度提高设计质量 分享不同的先验知识 理解和角色持续复查问题解决更快 集思广益和配对接力学习 耳濡目染团队建设和沟通有利于人员和项目管理 卡车问题 一个项目组集体外出 不幸被卡车撞上 有多少人受伤使项目不得不停止 最坏的情况是一个 结对编程工作区 一般工作区 学到的经验 程序员和设计人员 协调人结对编程更有效键盘输入效率自愿结对编程 我们行业的主要问题实质上更侧重于社会学而不是科学技术 人件 结对和简单设计 常见问题和解答 测试 编码 重构 集成或者丢弃 7测试驱动 8小型发布 XP推荐小而频繁的有意义发布 9重构 重构是XP的一个重要组成部分 所谓重构是指在不改变代码外在行为的前提下对代码做出的修改 以改进代码的内部结构 重构是一种有纪律的 经过训练的 有条不紊的代码整理方法 可以将整理过程中不小心引入错误的可能性降到最低 从本质上说 重构就是在代码写好之后改进它的设计重构的节奏 重新推理 小的更改 重新推理 小的更改 重新推理 10持续集成 持续集成的思想是任何时候只有一项任务完成 就集成新代码 构造系统并测试 持续集成是每日构建 每晚构建的一种极限形式 是XP的重要基础每日构建 每晚构建是将一个软件项目的所有最新代码取出 从头开始编译 链接 用安装软件包将链接好的程序安装好 运行安装后的软件 使用测试工具对主要功能进行测试 发现错误并报告错误的完整过程 每日构建是项目的心跳 如果一个项目的心跳停止了 这个项目就死亡了Treatthedailybuildastheheartbeatoftheproject Ifthereisnoheartbeat theprojectisdead 让开发人员在第一时间了解到软件的错误 并迅速排除错误 是每日构建 每晚构建最重要的目标之一每日构建 每晚构建必须出日志和报告 并发布构建结果的有关信息 最好能够使用自动化工具发出电子邮件通知 作用 降低集成风险加强错误诊断降低不确定性加快开发速度增强团队合作对项目参与者是重要激励 11每周四十小时工作制 在这里40是一个概数 不是确数如果能够努力地工作8小时 超过这个时间后就不适于有效地工作了 8小时燃烧再学习你无法改变时间 但是可以改变你的任务 12代码规范 不变的只是愿望 变化才是永恒 如果你聆听代码 好的设计就会出现 3 5XP讨论 XP和软件设计 XP提倡循序渐进的软件设计方法 以避免在前置设计中花费巨大的精力但这不是回到编码加修正 CodeandFix 的开发方式 初始设计不可能面面俱到受人员变动影响设计人员和编码人员之间存在协同问题设计人员和编码人员之间存在技能差异不能适应变化的需求 计划设计 缺乏整体性设计可能不可控潜在的缺陷可能会引起其它缺陷修正缺陷的代价可能会呈指数增长对设计和编码人员要求更高 柔性设计 计划设计 重构 XP中对柔性设计的支持 简单设计测试先行持续集成重构 做可能有效的最简单的事情DotheSimplestThingThatCouldPossiblyWork你将不会需要它YouAren tGoingtoneedit 简单的价值 效益轻装上阵 做且仅做一次OnceandOnlyOnce不要自我重复Don tRepeatYourself XP衡量简单的标准 通过所有的测试代码体现所有设计意图 CleverCode避免重复类或方法的数量最少 模式 反模式和XP 模式反模式对初学者重构的目标之一 模式选择使用模式的时机模式和简单性 UML和XP 最好的UML图也不是产品 3 6XP应用之一 XP在高校科研中的应用 高校研究室 组人员的一般构成 一名以上的教授 副教授博士生硕士生附属工作人员临时教学或研究的学生临时合作人员 高校科研用例图 理工类 高校科研项目中的一些问题 高校软件 原型 项目 往往显示很差的软件工程质量 需求不明确缺乏客户参与人员的持续波动或突变没有一个适用于高校的质量体系总是处于人员培训阶段研发过程不连续 积累困难往往没有激励机制 高校中的XP 首选结对编程 学习 指定核心 知识流动的不确定性 吸引力随着团队规模的减小而下降高年级低年级 不太有效高年级高年级教师学生 不太有效持续集成代码集体所有重构设计和文档重要性上升 XP应用之二 XP在大型项目中的应用 层次结构的XP 用清晰而且微小的接口分割系统每个子项目 子课题的目标是整个项目的一个子目标递增改进有一个集中管理机制充分利用辅助手段进行交流 3 7常见问题 1 敏捷软件方法适合中国吗 虽然敏捷软件开发方法体系的形成主要基于国外的软件开发经验 体系的创建人和归纳人也是外国人 但是绝大多数内容国内都可以借鉴 可能某些内容不能照搬 在报告中没有特别区分这些内容同时敏捷软件开发方法本身还在不断发展和完善 国内也可以结合国内的实际情况对其发展做出贡献 2 ISO9000体系的文档量比较重 在实际中如何操作 ISO9000文档数量比较多 国标中主要文档有14个 但是这些文档工作也是穿插在软件开发过程的各个周期 比如代码开发前后都是文档工作量较大的阶段 3 XP和传统软件开发过程的差异 XP来自于传统软件开发过程 比如XP的12个实践在传统软件开发过程中都有 但是XP把它们有机地组合了起来 取长补短 最大限度地发挥了它们的作用另一方面 XP和其他敏捷方法和传统方法有很多不同 比如对人的作用 传统方法只是把人作为一个螺丝钉 没有很好地调动开发者的主观能动性同时敏捷方法和开源软件有很深的关系 所以在许多地方带有自下而上的色彩 重构就是其中的典型代表 4 XP有和ISO等其他传统方法一样的具体操作规范吗 目前敏捷方法还没有具体的操作性强的规范 更多的是一种指导架构和思想 就像AM 5 采用传统开发流程的软件组织如何引入XP 这方面XP的领导者如KentBeck都有很多建议 在XP网站也有很多经验介绍