敏捷开发基础.pptVIP

内部资料注意必威体育官网网址敏捷开发基础第1页，共23页，星期日，2025年，2月5日本次介绍的目标使大家对敏捷开发有一个基本的概念基于部门现状，我们能开始着手做什么更多的是洗脑+抛出问题可用的解决方案，正在探索中第2页，共23页，星期日，2025年，2月5日为什么要敏捷开发？价值观和核心理念敏捷开发的工具和方法我们如何起步？第3页，共23页，星期日，2025年，2月5日“价值”和”质量”产品的最终目的是实现用户价值和商业价值产品的质量包括外部质量和内部质量有质量的产品不一定有价值，有价值的产品必需有质量做保障。敏捷开发针对这两个维度都给出了方法和工具来保证。第4页，共23页，星期日，2025年，2月5日产品质量外部质量：与“价值”直接相关用户体验、bug数量、性能指标、killerfeature目前部门对这块较重视内部质量：难以直观衡量代码规范、可读性、架构、性能、重构、设计模式目前对这块不够重视，也没有成型的衡量方法技术债务：代码经过一段时间的修改，会越来越糟，除非我们花时间去解决代码的“坏味道”第5页，共23页，星期日，2025年，2月5日敏捷开发的价值观个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

虽然右项也有价值，但是认为左项具有更大的价值。第6页，共23页，星期日，2025年，2月5日我的理解可用的软件——应该始终处于第一优先级总是先做价值最大，优先级最高的事情加快交付-》反馈-》修改的循环。需求变化是必然的，但是可以保证一段时间内（一个迭代）不发生变化。一个功能完成了99%，但是无法给到其他人体验，价值为0第7页，共23页，星期日，2025年，2月5日持续集成-敏捷开发的核心第8页，共23页，星期日，2025年，2月5日持续集成核心理念：Don’tRepeatYourself重复劳动应该由计算机去完成。持续集成的周期可以作为“敏捷程度”的衡量标准 ZingChat的周期是2-3天。 业界的“完美”指标是15分钟。尽早测试尽早体验，解决“价值”的问题自动测试和部署，解决“内部质量”的问题对于IBG的客户端产品，难点在于自动测试自动部署与server更加相关，也有很大优化空间。第9页，共23页，星期日，2025年，2月5日自动构建加快版本发布的速度减少重复工作防止人为造成的错误ZingChat自动构建的时间： 0.5小时人工检查+1小时机器build静态代码检查：衡量“技术负债”ZingChat正在考虑后续引入检查工具。第10页，共23页，星期日，2025年，2月5日自动测试测试不只是测试人员的事情。产品质量是由开发和测试共同保证。人工黑盒测试是必不可少的，特别是对于新需求的完善很有价值。为了保证已有功能的可用性，采用人工的方式成本太大。而目前我们大量工作花费在这一点上。目标依然是：减少重复工作量单元测试是开发人员的工作。 手工做-自动做第11页，共23页，星期日，2025年，2月5日单元测试现状：开发人员手工做自测，没有单元测试代码写代码做单元测试，可重用，是自动测试的一部分在C++中，进行测试的基本单元是类必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中，都要可用。所有单元测试用例必须一直进行维护。

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