对软件从业者来说，『敏捷开发』早已不是一个新名词。
相比瀑布模型，敏捷开发模型更强调演进式开发，快速灵活地应对变化，最终交付使客户满意的产品。这就要求研发团队内部、研发团队与产品乃至与业务、客户之间的密切沟通。当变化发生时，相关方可以快速获知并充分理解变化，及时校准目标协调解决。
落实到实践，密切沟通就意味着更多会议。敏捷开发中的典型会议包括需求评审会、迭代计划会、每日站会、迭代评审会、迭代回顾会。许多研发人员头疼会议太多了，甚至质疑这些会议是不是形式主义。
要发挥 Scrum 会议的真正价值，不仅要从理念层面引导团队成员接纳敏捷文化，从制度层面明确每个会议的目的和形式，避免顾虑和抵触情绪，也要从技巧层面思考如何将会议开得更有效率。
比如，我们是否能避免 2/3 的会议时间都花在基本信息的同步上？是否能将时间用于更有价值的倾听和讨论？
这篇文章将分享数据在迭代管理中发挥的作用。在迭代中进度跟进和迭代后回顾复盘两个环节，数据能帮助团队直观了解迭代中发生了什么，定位待改进的关键点，进而有针对性地讨论并提出改进措施。
文中的数据图表来自思码逸效能分析洞察产品的迭代表现模块。
进度跟进
每日站会是迭代进行中最高频的沟通协作机制。站会的主要目的是：
- 检视迭代目标的完成进度
- 及时暴露阻塞、冲突和逾期等风险
- 明确当天的团队目标，规划当天工作任务安排
看上去是老生常谈。但事实上，许多团队践行的仅是『每天开会』的形式，反而忽略了站会的本质。
本质上，每日站会是从团队整体出发，聚焦于迭代目标（一般是事务或故事）完成情况，共同回顾进度并规划工作。既不是每个成员各自汇报工作内容和时间花费，也不是任务细节的探讨。
关键问题1：迭代进度是否符合预期
这就引出了站会中最为关键、入口级的数据视图——燃尽图。燃尽图能直观展现事务或故事点的完成趋势，帮助团队判断进度是否正常。在此基础上，燃尽图还应提供下钻的能力，详细说明有哪些事务/故事已经完成，是否有需求变更导致事务/故事新增，哪些事务/故事已经逾期或存在风险。
靠站会上口头沟通，当然也能画出燃尽图。但一是浪费站会的宝贵时间，二是无法保证风险及时暴露：难免会有同学在站会时闷声不响，上线前才放个大招。
关键问题2：产能与饱和度如何？
站会主要聚焦于迭代目标的完成，主要思考问题如何解决，相对不关注人员产能或工作饱和度。但这不代表团队 Leader 可以弃后者于不顾。
当发生阻塞和逾期风险时，团队 Leader 可以将人员产能和工作饱和度可以与事务、故事交叉比对，分析问题为何产生，未来可以如何避免。
例如，代码当量（编码工作量）持续高位，而事务和故事点没什么进展，可能是方案设计出了偏差导致返工，也可能是需求拆分不合理导致需求涉及的工作过多。反之，如果代码当量偏低，则可能存在项目排期不合理，团队内忙闲不均的情况。
关键问题3：Bug 是否得到及时处理？
除了效率，迭代质量同样需要关注，因为 bug 大量积压也可能导致交付风险。
团队 Leader 可以在在迭代中持续关注累计新增和修复 bug 的数量。当高风险等级 bug 的每日新增显著高于修复，呈现积压趋势时，就可能需要相关成员抽调时间协调解决，甚至对项目节奏进行临时调整。毕竟，刚刚写出来的 bug 修复成本是最低的，如果拖到测试阶段才解决，可能需要投入数倍的时间和精力。
回顾复盘
紧张的迭代结束后是评审会与回顾会。迭代评审会的必要性很好理解：产品快交付了，包括产品方在内的全体成员一起来体验功能，评审本迭代的交付成果是否满足客户期望。
而迭代回顾的价值就没那么明确了——是互相推诿责任的甩锅大会吗？还是聊些不痛不痒的皮毛，你好我好大家好的茶话会？
实际上，迭代复盘会是 Scrum 中非常重要的环节。团队需要对迭代开发中的人员、流程和工具本身进行复盘，讨论哪些地方做得好、哪些地方出现了阻碍，背后的原因有哪些，进而产出一份具体的行动清单。
数据为迭代复盘会提供了客观、可靠的共识基础，也节省了团队成员靠记忆复盘，手动整理的工作量。在复盘中，我们可以将过往迭代的数据作为参考，更加准确地评价本迭代表现，尤其关注上一迭代提出的行动项是否确实带来了改进。
关键问题1：本迭代事务交付周期是否缩短？
和每日站会一样，迭代回顾会议也可以将迭代目标完成情况作为复盘的起点。与事务交付数相比，事务交付周期更能反映团队的响应速度，是更合适敏捷开发模式的北极星指标。
在统计事务交付周期时，研发团队可以更多关注 85% 分位值，而非均值或中位数。85% 分位值既排除了极端离群值造成的影响，又能够反映交付效率的普遍情况。
除了统计迭代整体的事务交付周期，研发团队还可进一步查看需求、缺陷、事故等不同类型事务的交付周期的差异。此外，还可以下钻到各个事务，尤其是交付周期异常的事务，复盘原因。这样对具体的 case 进行分析，回顾会也更容易言之有物。
关键问题2：如何提升交付效率？
回顾会上，团队成员们会基于主观感受，提出他们在本迭代遇到的各种障碍和相应改进措施。那么如何从中选出高优行动项？
借助数据，研发团队可以更客观地判断这些障碍的严重性，以及它们是持续性还是偶发性的。
例如，本迭代的需求交付周期显著偏长，有成员提出主要原因是本迭代关闭了一些存在已久的缺陷，那么可以通过事务吞吐率来验证——将本迭代完成事务的数量与历史基线对比，若假设成立，则本迭代完成事务数应当处于正常范围。有成员提出主要原因是在制品（WIP，Work in Progress）数量过多，反复切换上下文拖累了效率，那么可以观察 WIP 是否在本迭代内确有异常上升。
关键问题3：本迭代完成的事务是否符合预期？
除了回顾本迭代交付了多少个事务、交付得多快，另一个关键信息是『本迭代交付了哪些事务？』。
一同参与回顾会的产品经理可以通过事务类型分布，评估本迭代研发团队的工作重心是否与迭代计划、与更长期的产品规划相符。
研发团队可以通过事故比例占完成事务的比例，评估事故占用了团队多少精力。异常偏高的比例是个危险信号——研发团队可能正忙于四处救火，可能无暇顾及新功能的开发。
同理，事务变更也能反映团队被变更的需求或临时插入的需求牵扯了多少精力。如果这个数值高于往常，则提示需求梳理和评审环节可能出现问题。
总结
归根到底，敏捷开发模式的核心是人。数据无法取代人的判断，也无法取代人与人之间沟通。但数据能提供客观的事实基础，使人的判断与沟通都有据可依，也能让每一场迭代会议，都更高效、更愉悦、更有收获。
