百度商业变现创业产品快速交付的故事

ic（愿景）拆分为feature，将feature拆分为story，以story级别建立需求地图（story map），分别确定检索端和业务端的MVP，找出每个story的内部依赖和外部依赖（下图直线和箭头代表story间的依赖关系）。通story map、mvp以及依赖关系的梳理，团队对整个项目的story优先级有了清晰的认识，对story内部外部的依赖也有了了解。在梳理出关键依赖后，我们在项目进行中逐步完成了外部依赖的打通：

FLASH上传控件依赖：全公司范围内搜索flash资源，为业务端节省20天左右的时间；

部署平台和日志依赖依赖的推动：平台化角度推动问题解决，为检索端节省5天的时间；

公共云存储资源、分片方案依赖的推动：保证项目最关键路径无延期。

梳理出产品MVP和依赖关系后，我们再将story拆分为更细粒度的task，完成task的估算，根据story map确定团队整体的排期，再根据团队整体排期确定项目的关键路径；下图红色部分是我们识别出来的检索端和业务端分别的关键路径。

通过关键路径的识别，我们提前预警了项目进度上的风险，并推动管理层做出决策（增加前端开发资源），最终为产品上线节省了6天。

在项目实施过程中，我们也同时引入了单测、code review、持续集成流水线等这些工程实践，并发挥了重要作用：

业务端后端代码以产品维度进行主干CI，Pipeline配置包括三个stage，其中第一个stage是quick job，qucik job跑的是编译以及RD单测，每次RD check in代码时会触发整个产品的编译和单测，如果构建失败，RD会及时进行修复，目前quick job控制在8min以内，产品的单测覆盖率已经接近70%+（函数覆盖）；第二个stage分为两个job，分别是quick失败通知job以及slow job，失败通知job会在quick失败后第一时间将失败消息发送到hi群，要求rd及时响应解决，slow job跑的是QA的API测试case；最后一个stage是deploy job，会将slow通过的代码部署到QA的测试环境，三个stage之间的产出会进行传递。

项目一期二期一共149个story+task（无其它需求文档），实体看板管理非常不方便，容易混乱，因此我们辅以电子看板管理卡片，在这个电子看板空间中，所有泳道的卡片移动都是通过PM、RD、QA的动作自动触发（story录入、code review、CI、拉rb分支等），几乎没有任何管理成本，因此卡片的流转状态良好，并且替代了部分实体看板的功能，团队可以根据流转信息产出开发周期、测试周期、发布周期等数据。

代码评审方面继承了商业产品研发团队非常好的传统，执行的很到位，每次