百度商业变现创业产品快速交付的故事
2019-12-26
来源： 百度敏捷教练
RD进行CI时也会关联code review的issue，rd会自觉将代码提交他人Review，并在通过后check in。
这些敏捷工程实践很好地帮助团队实现了快速的端到端交付Story，降低了项目后期的变更风险以及质量风险，这也说明工程实践同样适合于创业型项目。
制定合理的测试方案
这个项目上线时间很紧，QA和RD人力比为1：5，如果QA只是按照传统方式介入后期的系统测试是远远不够，我们需要将质量风险提前，并尽量缩短后期系统测试的周期。因此，端到端的测试并交付story是至关重要的，我们将测试分为了三层：RD的单测、QA的API接口测试（QA在RD前期确定接口的同时开始编写API自动化case）、全员参与的集中测试，并且确定了每层的测试职责和目标：
项目后期，我们统计了单测、api接口测试bug在发现总bug数中的占比——接近70%，项目质量风险在集中测试前消灭了一大部分，最终项目在一期二期需求重大调整的情况下保证了前期端到端交付story测试的有效性，系统测试周期极短（RD开发1.5月，测试仅6天）。
变更控制
项目的变更是不可避免的，这个项目也经历了数次变更。因为一开始需求和设计前期考虑的比较清楚，所以因为需求和设计产生的变更非常少；由于外部依赖很多，外部情况变化导致的变更有多次，这也是我们无法控制的地方，但如何应对我们需要重点考虑。
问题风险的挖掘
问题风险的识别和全局把控，这是我们一开始进入项目的初衷，因为产品跨团队协作，需要一个人来推动整体进度，并站在全局的角度审视业务风险，项目风险等。下面是我们在这个项目中挖掘风险的一些方法：
嗅出团队badsmell
不管是哪支团队，都有badsmell，作为交付经理角色我们一开始就要保持着敏锐的嗅觉，随时嗅出这些问题，这点和做改进是是相同的。
项目一期做了一半的情况下，团队部分成员对于项目的真正目标和收益不太清晰；检索端同学由于长期关注日志、ctr、cpm等指标，对项目上线收益有大概的认识。业务端由于是广告主使用的系统，不直接和金钱打较大，因此部分同学对项目目标和方向不太清晰。这时让团队统一目标并明确方向是很重要的，因此建议老大召集了一次全员目标、收益、团队价值、成员自我介绍的动员会，会上PM明确阐述了项目起因、价值、目标，RD介绍了业务系统和检索架构，进一步提升了团队战斗氛围。
业务端长久以来前端FE、后端RD、QA分离，很难做到统一排期和规划，因此无法做到资源最大化、以最快的速度交付，前端FE对项目的参与感不如RD强烈，项目进展也是向自己的前端经理汇报；基于此，建议老大将业务端
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
