敏捷开发基础.ppt

敏捷开发基础介绍 国际业务部Larryhu2010 3 12 本次介绍的目标 使大家对敏捷开发有一个基本的概念基于部门现状 我们能开始着手做什么更多的是洗脑 抛出问题可用的解决方案 正在探索中 为什么要敏捷开发 价值观和核心理念 敏捷开发的工具和方法 我们如何起步 价值 和 质量 产品的最终目的是实现用户价值和商业价值 产品的质量包括外部质量和内部质量 有质量的产品不一定有价值 有价值的产品必需有质量做保障 敏捷开发针对这两个维度都给出了方法和工具来保证 产品质量 外部质量 与 价值 直接相关用户体验 bug数量 性能指标 killerfeature目前部门对这块较重视 内部质量 难以直观衡量代码规范 可读性 架构 性能 重构 设计模式目前对这块不够重视 也没有成型的衡量方法 技术债务 代码经过一段时间的修改 会越来越糟 除非我们花时间去解决代码的 坏味道 敏捷开发的价值观 个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划虽然右项也有价值 但是认为左项具有更大的价值 我的理解 可用的软件 应该始终处于第一优先级 总是先做价值最大 优先级最高的事情 加快交付 反馈 修改的循环 需求变化是必然的 但是可以保证一段时间内 一个迭代 不发生变化 一个功能完成了99 但是无法给到其他人体验 价值为0 持续集成 敏捷开发的核心 持续集成 核心理念 Don tRepeatYourself重复劳动应该由计算机去完成 持续集成的周期可以作为 敏捷程度 的衡量标准ZingChat的周期是2 3天 业界的 完美 指标是15分钟 尽早测试 尽早体验 解决 价值 的问题自动测试和部署 解决 内部质量 的问题 对于IBG的客户端产品 难点在于自动测试自动部署与server更加相关 也有很大优化空间 自动构建 加快版本发布的速度减少重复工作防止人为造成的错误 ZingChat自动构建的时间 0 5小时人工检查 1小时机器build 静态代码检查 衡量 技术负债 ZingChat正在考虑后续引入检查工具 自动测试 测试不只是测试人员的事情 产品质量是由开发和测试共同保证 人工黑盒测试是必不可少的 特别是对于新需求的完善很有价值 为了保证已有功能的可用性 采用人工的方式成本太大 而目前我们大量工作花费在这一点上 目标依然是 减少重复工作量 单元测试是开发人员的工作 手工做 自动做 单元测试 现状 开发人员手工做自测 没有单元测试代码写代码做单元测试 可重用 是自动测试的一部分在C 中 进行测试的基本单元是类必须是可重复的 无论是在软件修改 或是移植到新的运行环境的过程中 都要可用 所有单元测试用例必须一直进行维护 下面我们来列举一些案例这些案例都有实际的原型作为对比 我设想了一些 完美世界 的场景 如果我们把敏捷做到极致 事情是否会不一样 案例1 经过几天的开发 提交了一个客户端转测试版本 经过2个小时的测试 发现该版本有严重问题 协议号不正确 测试被打回 而协议号设置是开发手工操作 新的版本提交还是要靠人工手段确保协议号正确性 完美世界 自动编译脚本每半个小时就自动编译一次 并且跑一遍自动化测试脚本 脚本中包含了检查协议号正确性的用例 一旦出现错误 就会发出邮件知会相关人 提问 如何尽早的发现严重问题 案例2 测试 这个bug不是在上个版本已经修复了么 怎么这个版本又出现了 开发 原因是blablabla测试 有没办法避免这种情况 不然测试老是做重复工作 完美世界 测试 这个bug不是在上个版本已经修复了么 怎么这个版本又出现了 开发 Sorry 我忘记把这个bug的单元测试用例加入dailybuild脚本 本来单元测试应该能检查出这个问题的 测试 那下次这个bug不会再出现了 开发 Yes 如果又出现了 我会马上收到单元测试没通过的邮件 提问 如何避免重复犯相同的错误 案例3 测试 avatar功能是不是失效了 运维 服务器好像没问题 客户端能否帮忙联调一下 开发 OK 开始打开VC 开工程 设置断点 定位问题 找到原因 解决了 两天后 测试 avatar功能又失效了 开发 我再查下看看 开始打开VC 设置断点 手工确认协议是否正常 找到原因 解决 完美世界 有avatar模块的针对业务关键点的单元测试用例 之后 问题 如何快速定位问题 避免重复的工作量 案例4 PM 完成这个新需求工作量大么开发 挺大 原有的代码太乱了 修改这里导致1 2 3 4处要一起改 开发 这块可以考虑重构甚至重写 给出适应我们需求的架构测试 那是不是代表对于这块的测试需要全部重做 开发 是的 我们没有办法保证重构的代码不造成新的bug 完美世界 在新需求提出前 开发就发现单元测试的编写很痛苦 提出一些模块应该重构 问题 重构 代价大 我们离 完美世界 有多远 重构 设计模式 听起来很好 但是似乎和我没关系 项目进度都赶不急 哪有时间去重构 我们的开发工作都是对已有系统的改造 似乎很少需要设计模式 谁来提重构的需求 怎么平衡 设计 和 过度设计 是否在新开发一个功能之前就要尽量做好设计 敏捷开发的观点 能很容易编写单元测试用例的代码 质量是较高的 当单元测试不再容易编写的时候 说明代码需要重构 在业界 重构是有较为成熟的方法 可以系统学习的 设计模式为重构过程提供模板和思路 自动测试是基础 否则难以进行 现在 我们能做什么 自动构建 初步成型 继续优化挑战 如何自动化给出代码的修改点 自动提交测试 Checkin 自动编译 自动提交体验测试 自动测试 自动测试 长路漫