继产品规划、产品设计之后，本文继续分享产品研发中的一些实践：
搭建团队物理看板；
建立站会制度；
建立PM验收机制；
QA尽早进行功能测试；
建立小流量闭环机制；
持续收集各团队度量数据。
迭代开发的核心
按Story开发，同一时间尽可能只做一个Story；
Story在各角色间快速流动。
搭建团队物理看板
建议团队在迭代开发阶段使用线下物理看板管理研发过程，部分团队采取电子看板（百度内部为icafe） + “电子触摸大屏幕”；
看板的泳道可以根据产品线的具体情况进行设置，通常包括： 需求中、设计中、待开发、开发中、待验收、待测试、测试中、待上线、已完成等；
物理看板的跟踪对象建议只到Story级别（不建议团队进一步拆分到Task级别），可以使用不同颜色表示不同的类型，例如：蓝色：技术性Story或者预研类；黄色：功能性Story；红色：Bug；
根据团队的需要，可以在看板上增加一些其他的内容，建议从简单做起，确实有需要的时候再增加其他的。
团队物理看板示例：
物理看板用于直观展示当前团队的进度，通常从看板上可以读取到的一些信息：
当前Story卡片流动是否正常，比如示例中有大量的Story停留在联调中状态，并且没有人在这些Story上工作，可以推测应该是联调在等待中；
哪些角色的工作存在瓶颈、哪些角色的工作处于等待状态，比如示例中QA当前无Story可测试，属于不正常等待；
看板上可以采取一些小技巧，比如示例中使用每人一张照片，来标识当前工作，也提醒每个人同一时间尽可能只做一件事；
可以采取CFD图（在燃起图基础上发展而来）来度量研发过程。
Story卡片写作示例：
Story卡片可以根据团队的需要达成一致写哪些内容：
通常基本的内容包括：编号、Story标题（或内容）、估算、验收条件（如果有文档描述验收条件则可以不写在卡片上）；
责任人可以直接写在卡片上，也可以采取贴照片的方式，贴照片方式的优点可以提醒（控制）大家同一时间只做一件事；
打点的目的是看Story的历时，用于暴露Story以及团队进度风险，如果打点已经超过估算，SM需要介入关注；
还有一些团队会在Story卡片上写上一些关键时间点的约束，用于提醒与其他角色和团队的配合。
建立站会制度
站会的目的是让团队信息更透明，以便更好达成团队迭代目标。可以根据需要建立两级站立会制度：
Release层面：参与者为各个团队的负责人，主要用于同步团队之间协助问题的进展，频率可以根据需要决定；
团队层面：参与者为团队所有人（RD、QA、PM、UE），是实际参与到团队工作中的人，如果团队服务于多个Release，可分开Release开，频率为每天召开。
站会通常要解决的事情：
每位参与者介绍常见的三个问题（昨天做什么、今天准备做什么、是否遇到困难），提到的工作在看板上应该有对应的卡片，这个过程更多的是利用同行压力来促使团队成员更积极投入工作，组织者（scrum master）需要重点关注进度是否符合预期以及是否遇到困难，在讲述过程中尽可能就事论事，组织者需要引导站会讲述内容；
更新Story卡片的状态，如果有进入下一个角色的状态，需要提醒注意，比如开发完成要提醒PM验收；
Story卡片打点（如果有打点的团队）、绘制CFD图。卡片打点可以在各位同学讲完之后自己进行，不同角色可以采用不同图形打点。CFD图可以在站会结束后由一位同学负责绘制，团队同学轮流负责绘制。某产品打点示例：
关注常见的风险，例如：是否某一状态的卡片过于集中？是否某些卡片长期停留在某一状态？
建立PM验收机制
PM（UE）每天需要验收RD开发完成的Story是否符合预期，并给出明确反馈意见；
建立APP构建->推送到干系人（PM、UE、项目成员）的自动化流程，降低体验者获取最新版本成本，百度公司内有多种此类平台：花果山、百度尝鲜等；
PM验收建议放在QA功能测试之前进行，以防止QA测试完后PM觉得需要优化而返工。
QA尽早进行功能测试
Story/Feature的功能测试在迭代过程中进行，RD开发完成->PM验收->QA功能测试
建立自动构建系统，QA拿每日最新版本进行测试（对RD要求：移到PM验收的Story准入通过、合入SVN的代码不得对已有功能产生影响）
QA在站会上需要同步测试进展
QA发现的Bug，RD需要及时处理，影响QA继续测试的必须立即修复，级别较低的Bug可自行安排修复
建立小流量闭环机制
1、要建立产品小流量机制；
2、小流量期间问题的快速解决和闭环。
持续收集各团队度量数据
度量数据的收集可以以Release为周期
度量的目的是建立团队的参考基线以及发现团队可持续优化的地方，需要避免用于团队之间的比较（比较容易导致团队造数据）
移动APP的度量指标体系参考：
度量基础指标：需要直接采集的一些数据
度量观测指标：用于观测团队运行情况以及直接分析改进点的数据
