北京
几乎所有跑敏捷的工程团队，每个冲刺结尾都得开一个会，叫冲刺评审。按最初设想，团队要在这里演示做出来的东西，收到利益相关方的反馈，把活儿跟业务在乎的成果勾连起来。现实呢，它通常沦为一场“展示与讲述”——工程师对着工单向一群想溜走的人描述自己干了什么。
开场两分钟，你就能判断这场评审有没有戏。如果演示者没提前想好要说什么，会议很快会滑向流水账模式：有人打开一张工单，解释它实现了什么，甩出一张截图，接着切到下一条。字越堆越多，时间一点点耗掉。房间里没一个人——包括做这些功能的人——能清楚讲出刚刚交付了什么价值。
坐在对面的业务伙伴从这场合里学到了什么？他们学会了一件事：冲刺评审就是来看工程师描述工作的地方。不是指针移动的地方，不是做决策的地方，只是一场他们不得不参加的仪式。
这其实不是冲刺评审本身的问题，是准备的问题。而准备的问题，根子上是思考的问题——一个没法把评审讲清楚的团队，从一开始就没搞明白自己到底想交付什么价值。
做得好的冲刺评审，最重要的一步发生在会议之前。团队里得有人——最好是干了活儿的工程师，产品经理从旁协助——在评审开始前，能说出这样一句话：“我们相信，如果做了X，就会看到Y——以下是我们这么认为的理由。”这句话就是整个演示的脊梁骨，其他所有内容都挂在它下面。
举个具体例子。一个做API可靠性的团队发现，有大量失败请求是暂时性的——那种再试一次就能成功的失败。他们形成了一条假设：如果在十秒窗口内对失败的API请求重试最多三次，成功响应的数量至少会提高25%。
这条假设同时干了几件事。它告诉利益相关方团队在解决什么问题；丢出一个他们可以做出反应的数字——25%到底算不算有意义，在座的人多半心里有数；它还把后面的演示架构成对一条具体主张的检验，而不是对已完成工作的观光巡礼。每个冲刺评审都该以假设开场：我们相信什么，想要证明什么，为什么觉得这事儿重要。
抛出假设之后，就该亮出证据了。你实际发现了什么？指标是按预期方向走的吗？幅度更多、更少，还是拐向了你压根没料到的方向？从这里开始，冲刺评审才成了真正的协作，而非一场困倦的展销会。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
