敏捷开发基础课件.ppt

《敏捷开发基础课件.ppt》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

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

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

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

4、测试人员的事情。产品质量是由开发和测试共同保证。人工黑盒测试是必不可少的，特别是对于新需求的完善很有价值。为了保证已有功能的可用性，采用人工的方式成本太大。而目前我们大量工作花费在这一点上。目标依然是：减少重复工作量单元测试是开发人员的工作。手工做->自动做单元测试现状：开发人员手工做自测，没有单元测试代码写代码做单元测试，可重用，是自动测试的一部分在C++中，进行测试的基本单元是类必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中，都要可用。所有单元测试用例必须一直进行维护。下面我们来列举一些案例这些案例都有实际的原型作为对比，我设想了一些“完美世界”的场

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

6、测试：这个bug不是在上个版本已经修复了么，怎么这个版本又出现了？开发：Sorry,我忘记把这个bug的单元测试用例加入dailybuild脚本，本来单元测试应该能检查出这个问题的。测试：那下次这个bug不会再出现了？开发：Yes，如果又出现了，我会马上收到单元测试没通过的邮件。提问：如何避免重复犯相同的错误？。案例3测试：avatar功能是不是失效了？运维：服务器好像没问题，客户端能否帮忙联调一下？开发：OK。开始打开VC，开工程，设置断点，定位问题。找到原因，解决了！两天后：测试：avatar功能又失效了？开发:我再查下看看。开始打开VC，设置断点，手工确认协议是否正

7、常。找到原因，解决。完美世界：有avatar模块的针对业务关键点的单元测试用例，之后……问题：如何快速定位问题，避免重复的工作量？案例4PM:完成这个新需求工作量大么开发:挺大，原有的代码太乱了，修改这里导致1,2,3,4处要一起改。开发:这块可以考虑重构甚至重写，给出适应我们需求的架构测试:那是不是代表对于这块的测试需要全部重做？开发:是的，我们没有办法保证重构的代码不造成新的bug。完美世界：在新需求提出前，开发就发现单元测试的编写很痛苦。提出一些模块应该重构。问题：重构=代价大？我们离“完美世界”有多远？重构、设计模式听