敏捷开发基础.ppt

1、敏捷开发基础介绍,国际业务部 Larryhu 2010.3.12,本次介绍的目标,使大家对敏捷开发有一个基本的概念 基于部门现状，我们能开始着手做什么 更多的是洗脑 + 抛出问题 可用的解决方案，正在探索中,为什么要敏捷开发？,价值观 和 核心理念,敏捷开发的工具和方法,我们如何起步？,“价值”和”质量”,产品的最终目的是实现用户价值和商业价值,产品的质量包括外部质量和内部质量,有质量的产品不一定有价值，有价值的产品必需有质量做保障。,敏捷开发针对这两个维度都给出了方法和工具来保证。,产品质量,外部质量：与“价值”直接相关 用户体验、bug数量、性能指标、killer feature 目前部门

2、对这块较重视,内部质量：难以直观衡量 代码规范、可读性、架构、性能、重构、设计模式 目前对这块不够重视，也没有成型的衡量方法,技术债务：代码经过一段时间的修改，会越来越糟，除非我们花时间去解决代码的“坏味道”,敏捷开发的价值观,个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值，但是认为左项具有更大的价值。,我的理解,可用的软件应该始终处于第一优先级,总是先做价值最大，优先级最高的事情,加快 交付-反馈-修改的循环。,需求变化是必然的，但是可以保证一段时间内（一个迭代）不发生变化。,一个功能完成了99%，但是

3、无法给到其他人体验，价值为0,持续集成-敏捷开发的核心,持续集成,核心理念：Dont Repeat Yourself 重复劳动应该由计算机去完成。 持续集成的周期可以作为“敏捷程度”的衡量标准 Zing Chat的周期是2-3天。 业界的“完美”指标是15分钟。,尽早测试 & 尽早体验，解决“价值”的问题 自动测试和部署，解决“内部质量”的问题,对于IBG的客户端产品，难点在于自动测试 自动部署与server更加相关，也有很大优化空间。,自动构建,加快版本发布的速度 减少重复工作 防止人为造成的错误,Zing Chat自动构建的时间： 0.5小时人工检查+1小时机器build,静态代码检查：衡

4、量“技术负债” Zing Chat正在考虑后续引入检查工具。,自动测试,测试不只是测试人员的事情。产品质量是由开发和测试共同保证。,人工黑盒测试是必不可少的，特别是对于新需求的完善很有价值。 为了保证已有功能的可用性，采用人工的方式成本太大。而目前我们大量工作花费在这一点上。 目标依然是： 减少重复工作量,单元测试是开发人员的工作。 手工做-自动做,单元测试,现状：开发人员手工做自测，没有单元测试代码 写代码做单元测试，可重用，是自动测试的一部分 在C+中， 进行测试的基本单元是类 必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中，都要可用。 所有单元测试用例必须一直进行维护。

5、,下面我们来列举一些案例 这些案例都有实际的原型 作为对比，我设想了一些“完美世界”的场景，如果我们把敏捷做到极致，事情是否会不一样?,案例1,经过几天的开发，提交了一个客户端转测试版本。经过2个小时的测试，发现该版本有严重问题：协议号不正确，测试被打回。而协议号设置是开发手工操作，新的版本提交还是要靠人工手段确保协议号正确性。,完美世界： 自动编译脚本每半个小时就自动编译一次，并且跑一遍自动化测试脚本。脚本中包含了检查协议号正确性的用例。一旦出现错误，就会发出邮件知会相关人。,提问：如何尽早的发现严重问题？,案例2,测试： 这个bug不是在上个版本已经修复了么，怎么这个版本又出现了？ 开发：

6、 原因是 bla bla bla 测试： 有没办法避免这种情况，不然测试老是做重复工作,完美世界： 测试： 这个bug不是在上个版本已经修复了么，怎么这个版本又出现了？ 开发： Sorry, 我忘记把这个bug的单元测试用例加入daily build脚本，本来单元测试应该能检查出这个问题的。 测试： 那下次这个bug不会再出现了？ 开发： Yes，如果又出现了，我会马上收到单元测试没通过的邮件。,提问：如何避免重复犯相同的错误？。,案例3,测试： avatar功能是不是失效了？ 运维： 服务器好像没问题，客户端能否帮忙联调一下？ 开发： OK。 开始打开VC，开工程，设置断点，定位问题。找到原

7、因，解决了！ 两天后： 测试：avatar功能又失效了？ 开发: 我再查下看看。 开始打开VC，设置断点，手工确认协议是否正常。找到原因，解决。,完美世界：有avatar模块的针对业务关键点的单元测试用例，之后,问题：如何快速定位问题，避免重复的工作量？,案例4,PM: 完成这个新需求工作量大么 开发: 挺大，原有的代码太乱了，修改这里导致1,2,3,4处要一起改。 开发: 这块可以考虑重构甚至重写，给出适应我们需求的架构 测试: 那是不是代表对于这块的测试需要全部重做？ 开发: 是的，我们没有办法保证重构的代码不造成新的bug。,完美世界： 在新需求提出前，开发就发现单元测试的编写很痛苦。提

8、出一些模块应该重构。,问题： 重构 = 代价大？,我们离“完美世界”有多远？,重构、设计模式,听起来很好，但是似乎和我没关系？,项目进度都赶不急，哪有时间去重构？,我们的开发工作都是对已有系统的改造，似乎很少需要设计模式？,谁来提重构的需求？,怎么平衡“设计”和“过度设计”？是否在新开发一个功能之前就要尽量做好设计？,敏捷开发的观点,能很容易编写单元测试用例的代码，质量是较高的,当单元测试不再容易编写的时候，说明代码需要重构。,在业界，重构是有较为成熟的方法，可以系统学习的。,设计模式为重构过程提供模板和思路。,自动测试是基础，否则难以进行。,现在，我们能做什么？,自动构建：初步成型，继续优化 挑战：如何自动化给出代码的修改点，自动提交测试？ Check in-自动编译-自动提交体验测试-自动测试,自动测试：长路漫漫 从单元