百度新首的敏捷转型故事.ppt

稳定性：99.99% 服务器端 50ms 浏览器端 700ms 产品构想 模块按业务小粒度拆分 产品构想 例行统计 - 超高速，全自动化产出 - 可通过基础库打印日志，生成基础日志 - 通过描述日志含义的XML文件，自动化产出 - 可完成基于ABTEST双实验组的快速数据对比 稳定性：99.99% 服务器端 50ms 浏览器端 700ms 分析原因 集群分离 - 保证百度首页最基本功能的可用性 支持并行串行调度模式 - 寻找更快速的访问方式 使用离线运算代替在线运算 - 保证用户访问速度 高性能分布式存储 - 1W+/S 随机读写(SSD+FLASHDB Eng) 静态资源外链、合并、压缩 背景图片优化 Png使用pngcrush Gif使用gifsicle Jpeg使用jpegtran 静态资源上CDN - 可以提速20%左右 支持Smarty的HTML压缩 图片延时加载 tangram最优定制 CSS极限压缩 鼠标移动行为 鼠标点击行为 交互行为 数据分析的加载方式 【绍鹏】 【晓冬】 【晓冬】 【晓冬】 【绍鹏】 【绍鹏】 【绍鹏】 【绍鹏】因为每个团队的人不一样，产品形态不一样，项目环境不一样，所以我们不能完全照搬别人的经验，我们需要自己在不断的探索和试错中总结出适合新首页的敏捷模式。 【绍鹏】讲解产品反馈环的特点 【绍鹏】 【绍鹏】据研究软件产品开发最大的浪费就是开发了很多没人用的功能；还有就是工程师多任务的切换；进行中的工作WIP；加班多； 【绍鹏】我们和RD的同学一起制定了技术优化项目的拆分原则 【绍鹏】 【绍鹏】安排专门的人力应对那些很小的需求改动，保证重点项目的进展以及参与人不受打扰 【绍鹏】小需求管理不分前后端，统一从产品角度排优先级， 小需求负责人采用按月轮值制度。 【绍鹏】这样有几个好处：1. 避免multi-tasking任务切换的浪费 2. 小需求团队负责所有模块，新人成长快 3. 是全功能团队的试验田 【绍鹏】同时我们也把每个职能团队的人的工作透明化，包括RD、FE、QA、PM。 【绍鹏】大家看每个人基本只有1-2个任务 【绍鹏】 采用每日站会，项目进展可视化管理，工作粒度拆分成小时级，使用燃尽图，工程师每天按照4-5小时有效工作时间做计划 【绍鹏】 由于项目小，项目迭代总结很频繁，每次都只列出下次迭代需要改进的1-2点，而不是一个很长的问题list 【绍鹏】 【绍鹏】介绍由此带来的改进 【绍鹏】由此也： - 增强和职能团队间的互信：目标一致了，大家也都清楚每一个在忙什么 - 带动了团队的密切合作： - 提升了沟通效率： 从把MRD需求文档当成团队间的合同，到一同在开发的过程中优化/细化需求 从书面沟通到面对面的沟通；从无序的项目优先级的争辩到规范化的项目规划会 【绍鹏】敏捷的一些实践能带来直接的收益，但是如果没有技术支撑，往往会导致改进停滞不前，在中间徘徊。 【绍鹏】还有，没有技术支撑，也没法实现产品快速迭代快速验证的目的 【晓冬】好吧，现在由我来介绍一下，我们在技术上如何能支撑快速迭代 【晓冬】内建质量、程序员的信心/修养、自动化测试的重要组成部分，迭代速度 【晓冬】降低测试成本，减少人力投入 【晓冬】降低环境部署和维护的成本：开发环境、自测环境、QA测试环境 一键上线 【晓冬】 分级可以有效的减少项目上线的影响，快速的发现问题 GOD机，公司内部，小流量，全流量 【晓冬】L/T是按产品功能即使功能划分的，0-2代表着不同的重要度，主页面的浏览就是0 BL代表功能的影响面，模块不能展示就是1，错字就是3 好处是： 建立维度更细的质量衡量标准和体系，然后有针对性的改进 按照修改的功能等级，决定项目等级，合理安排研发人力（尤其是QA） 【绍鹏】 【绍鹏】 【绍鹏】 【绍鹏】 【绍鹏】 【绍鹏】 【绍鹏】 做为新的上网入口，这有别于传统的上网入口（网址站和浏览器） 口述亚马逊的合作案例。 【晓冬】介绍新首页的基本功能 【晓冬】丰富最近4个月的上线内容 【绍鹏】既然讲敏捷转型，那我们再来看看敏捷是什么？晓冬，你觉得敏捷是什么？ 【晓冬】敏捷是个死人！敏捷已死啊 【绍鹏】这。。。 【晓冬】kidding...没死没死 【绍鹏】好吧，那就让我们在11岁的敏捷没死之前赶快见它一面 【绍鹏】敏捷就是团队每天开站会，快速同步进度、提早现场发现问题、识别风险。scrum master负责指导站会，哎，晓冬，你觉得这些帅哥里面哪个是scrum master？ 【晓冬】这个是啊！你看他若有所思的样子 【绍鹏】我觉得那个是scrum master，藏在团队的后面的 【绍鹏】敏捷是使用用户故事替代大而全的需求文档 【晓冬】这