第六章 第一次 Sprint Review

一

时间过得很快。

王志远入职的第一个 Sprint，两周，十个工作日，眨眼就到了尾声。

Sprint Review 定在周五下午两点。赵北辰在周三的站会上提醒大家："周五 Sprint Review，每个人准备一下自己负责的任务演示。能跑的功能就现场演示，没做完的说清楚进度和原因。"

王志远回到工位上，打开 Jira 看了看自己这个 Sprint 领的任务：

1. ✅ BUG-2847：金额显示精度问题（已完成）
2. ✅ PROJ-148：用户导出功能优化（已完成）
3. ✅ PROJ-156：批量删除功能（已完成）
4. 🔄 PROJ-162：操作日志模块（进行中，完成约 60%）
5. ✅ PROJ-165：数据清洗脚本（已完成）

五个任务完成了四个，第四个只做了六成。操作日志模块比他预想的复杂，涉及到 AOP 切面、异步写入、日志存储策略，他光是理解现有的日志框架就花了两天。

第五个任务是一个数据清洗脚本——把数据库里一批格式不规范的手机号统一成标准格式。功能不大，但他写得很用心，做了完善的异常处理和回滚机制，还加了一个 dry-run 模式，可以先预览要修改的数据再真正执行。

他心里有点慌。Sprint Planning 的时候，他承诺了五个任务都能完成。现在操作日志模块明显做不完了。

周四晚上他紧张得翻来覆去睡不着，脑子里一直在想：Review 上怎么说？

二

周四中午，马德华端着咖啡晃到王志远工位旁边。

"小胖，Sprint Review 准备得怎么样？"

"还行吧……有一个任务没做完。"王志远叹了口气。

马德华想了想，压低声音说："我教你个办法。你把已经做好的部分包装一下——AOP 切面和异步写入，这两个听起来就很高大上。你在 Review 上重点讲这两个，讲得详细一点，技术含量拉满。至于没做完的部分，你就说'剩余工作量不大，下个 Sprint 第一周就能收尾'。"

"但实际上查询接口和前端页面加起来还有不少工作量……"

"你别管实际多少，Review 上说得好听就行。"马德华拍了拍他的肩膀。"小胖啊，Sprint Review 就是一场演出，观众是经理和产品。你把演出效果搞好，大家都开心。"

王志远将信将疑。但他确实不想在第一次 Sprint Review 上就暴露自己"完不成任务"的事实。

三

周五下午两点，会议室。

整个小组加上产品经理李想、经理周旋，十来个人围坐在一起。投影仪打在白墙上，赵北辰打开了 Jira 的看板。

赵北辰先做了一个整体概述："这个 Sprint 我们计划了 28 个 Story Point，实际完成了 22 个，完成率 79%。有几个任务延期了，待会儿各自说明原因。下面每个人演示一下自己的成果。"

苏薇第一个上。她演示了用户鉴权模块的重构——新的鉴权流程比旧的快了 40%，代码量减少了三分之一。她的演示干净利落，PPT 只有三页，但每一页都有数据支撑。

马德华第二个。他的演示一如既往地"高效"——用两分钟讲完了三个任务，每个任务都是"已完成，没什么问题"。周旋也没追问。

然后是陈锐。

四

陈锐站起来，打开了他准备的演示文稿。

"这个 Sprint 我做了两个任务。第一个是数据看板的前端页面——"他点开一个页面，图表做得很漂亮，配色专业，动画流畅。周旋看了连连点头。

"第二个，"陈锐切到下一页，"是一个数据清洗脚本。这个脚本可以批量修复数据库里格式不规范的手机号，支持 dry-run 预览模式，还有完善的异常处理和回滚机制。"

王志远的心猛地一沉。

那是他写的脚本。PROJ-165，数据清洗脚本，Jira 上指派给他的任务，他一行一行写的代码。

陈锐继续滔滔不绝地讲着脚本的设计思路："我的设计理念是先做 dry-run，让用户确认要修改的数据范围，避免误操作。异常处理方面，我用了事务回滚加上逐条记录错误日志的方式，确保即使中途失败也不会产生脏数据……"

王志远的手在桌子下面攥成了拳头。他看了一眼 Jira 看板——PROJ-165 的负责人写的是"王志远"，但陈锐正在台上把它当成自己的成果来讲。

他张了张嘴，想说什么，但话卡在喉咙里。他不知道该怎么办——当众拆穿？太尴尬了。不说？那自己的成果就被抢了。

他的脸涨得通红，手心全是汗。

就在这时，苏薇开口了。

五

"等一下。"苏薇的声音不大，但会议室里瞬间安静了。

她看着陈锐，语气平淡得像在说今天天气不错："陈锐，这个数据清洗脚本，我前两天 Review 过。Git 提交记录显示，所有的 commit 都是王志远的。你讲讲你改了哪里？"

会议室里的空气凝固了。

陈锐的笑容僵在脸上。他愣了大概两秒钟，然后说："我……我在他的基础上做了一些优化。"

"什么优化？"苏薇追问。"我看了最新的代码，跟王志远提交的版本没有任何区别。你的 Git 记录里也没有这个文件的任何提交。"

陈锐的脸色变了。他张了张嘴，想说什么，但什么都说不出来。

会议室里一阵尴尬的沉默。马德华低头喝咖啡，假装自己不存在。李想左看右看，不知道该说什么。周旋的表情从欣赏变成了困惑，又从困惑变成了一种微妙的不悦。

赵北辰坐在角落里，一言不发，但目光锐利。

沉默持续了大概五秒钟——五秒钟，在那种气氛下，长得像五分钟。

六

所有人都在等王志远的反应。

按照正常的剧本，这是他反击的最佳时机。陈锐抢了他的功劳，被苏薇当众揭穿，他只需要顺势说一句"这个脚本是我写的"，就能把场面扳回来。

但王志远没有这么做。

他深吸一口气，开口说："其实这个脚本我也只完成了一半。"

所有人都看向他。

"dry-run 模式和基本的清洗逻辑是做好了，但还有几个边界情况没处理好——比如手机号带国际区号的情况，还有一些历史数据的格式太乱，正则表达式覆盖不全。这些是我的问题，下个 Sprint 我会补上。"

他说完，低下了头。

会议室里又安静了几秒。

苏薇看了他一眼，眼神里有一种王志远看不太懂的东西——不是同情，更像是一种……认可。

赵北辰轻轻点了一下头。

周旋清了清嗓子："好，继续吧。志远，你的其他任务呢？"

王志远站起来，开始演示自己的其他任务。他没有再提脚本的事，也没有看陈锐。

陈锐坐在椅子上，脸色铁青，一直到 Review 结束都没再说话。

七

Sprint Review 结束后，紧接着是 Sprint Retrospective——回顾会。

赵北辰在白板上画了三列：

😊 做得好的          😐 可以改进的          💡 行动项

他让每个人在便利贴上写下自己的想法，贴到对应的列里。

王志远写了三张：

• 😊 完成了四个任务，导出功能优化得到了客户好评
• 😐 操作日志模块估算不准，实际工作量超出预期
• 💡 下次估算前先做技术调研，搞清楚复杂度再承诺

赵北辰带着大家逐一讨论了每张便利贴。讨论到"估算不准"这个话题时，他说：

"估算不准是正常的，尤其是新人。你没做过的事情，当然估不准。但关键是——发现估不准的时候，要尽早说出来。志远，你是什么时候发现操作日志模块做不完的？"

"大概……周二。"

"周二就知道做不完了，为什么不在站会上说？"

王志远低下头。他知道答案——因为不好意思。

赵北辰说："你要是周二就说'这活儿比想的复杂，可能干不完'，咱能做的事就多了：调调 Sprint 范围，看看有没有人能搭把手，至少让产品和经理提前有个数。越早说，回旋余地越大。"

他顿了一下，环顾了一圈会议室，目光在陈锐身上停留了一秒：

"完成比完美重要，但诚实比完成更重要。"

陈锐低着头，没有抬起来。

八

回顾会结束后，大家陆续离开会议室。

王志远正在收拾东西，苏薇走过来，把一个 U 盘递给他。

"这是什么？"

"上个 Sprint 我做鉴权模块重构的时候，写了一份估算文档。你看看，学学怎么估算工作量。"

"谢谢薇姐。"

"别叫我薇姐，叫我苏薇。"苏薇翻了个白眼。

她走了两步又回头："刚才 Review 上，你那个反应……还行。"

王志远知道她说的是什么——他没有趁机反击陈锐，而是选择了承认自己的不足。

"我不是不想说那是我写的。"他老实说。"我就是觉得……当众撕破脸没意思。而且脚本确实还有没做好的地方。"

苏薇看了他一眼："你比我想的成熟。"

说完她就走了。王志远站在原地，觉得这大概是苏薇对他说过的最好听的话了。

走出会议室的时候，好几个同事路过跟他打招呼，有两个人小声说了句"小胖，你人不错"。王志远笑了笑，没多说什么。

他注意到陈锐已经不在了——大概是回顾会一结束就走了。

九

那个周末，王志远打开苏薇给的估算文档，认真看了一遍。

苏薇的估算方法很系统。她把一个任务拆成了几个维度：

1. 需求理解：读需求文档、跟产品确认细节（0.5 天）
2. 技术调研：调研技术方案、评估可行性（0.5-2 天）
3. 设计：写设计文档、画时序图（0.5-1 天）
4. 编码：核心逻辑实现（1-5 天）
5. 测试：写单元测试、自测（编码时间的 30%-50%）
6. Code Review + 修改：根据 Review 意见修改（0.5-1 天）
7. 联调：跟前端或其他模块联调（0.5-1 天）
8. 缓冲：不可预见的问题（总工作量的 20%）

王志远回想了一下自己估算操作日志模块的过程——他当时的想法是："AOP 切面嘛，网上有现成的，配置一下就行。异步写入也不难，用线程池就行。查询接口和前端页面，照着现有的模块抄一个。总共三天差不多。"

他完全没有考虑"技术调研"的时间——他以为自己了解 AOP，实际上对 Spring AOP 的代理机制、切点表达式、通知类型这些细节一知半解，光是搞清楚这些就花了一天半。他也没有考虑"缓冲"——异步写入的时候遇到了一个线程安全问题，排查了大半天。

三天的估算，实际上需要六天。差了一倍。

他用苏薇的框架重新估算了操作日志模块的剩余工作量：

• 查询接口编码：1 天
• 前端页面：1.5 天
• 线程池压测 + 参数调优：0.5 天
• 测试：0.5 天
• 缓冲（20%）：0.7 天
• 总计：约 4 天

他把这个估算发给了赵北辰确认。赵北辰回复："估算合理。下个 Sprint Planning 的时候按这个报。"

十

周一上班，王志远发现陈锐的态度变了。

不是变好了，是变得微妙了。陈锐不再像以前那样当面冷嘲热讽，而是绕着王志远走。站会上两个人挨着发言，陈锐说完就低头看手机，不再像以前那样故意在王志远发言时露出不屑的表情。

苏薇在 Review 上的那一句"Git 提交记录是王志远的"，像一把刀，精准地切开了陈锐精心维护的形象。在一个技术团队里，抢别人的代码成果，是比写烂代码更严重的事情。

王志远没有追究，但团队里的人都看在眼里。信任这种东西，建立起来需要很久，毁掉只需要一瞬间。

陈锐大概也意识到了这一点。之后一周，他异常低调，主动承担了几个别人不愿意做的任务，代码提交也比以前认真了。

王志远不知道这种改变能持续多久，但他觉得——至少在这件事上，自己做了正确的选择。

他没有趁人之危，没有落井下石，甚至没有当众说"这是我写的"。他只是承认了自己的不足。

但有时候，承认自己的不足，比证明自己的优秀更有力量。

十一

那天晚上，王志远在笔记本上写下：

Day 38

第一次 Sprint Review，出了不少事。陈锐拿我的脚本去演示，被苏薇当场揭穿。我没有反击，而是承认了脚本还有不足。不知道这样做对不对，但心里很踏实。

苏薇说我"比她想的成熟"。这大概是她对我说过的最好的话了。

赵哥说：完成比完美重要，但诚实比完成更重要。

信任这东西，建立起来很慢，毁掉很快。不管是写代码还是做人，都是这样。

他合上笔记本，躺在床上。

窗外的路灯透过窗帘，在天花板上投下一片昏黄的光。他想起 Review 上那几秒钟的沉默——所有人都在等他的反应，他选择了不攻击别人，而是审视自己。

他不确定这是不是最聪明的做法。但他确定，这是他能做到的最诚实的做法。

在这个充满竞争和算计的职场里，诚实也许不是最锋利的武器，但它是最耐用的。

:::{admonition} 小胖的笔记 :class: tip

本章知识卡片：Sprint Review、Retrospective 与估算

1. Sprint Review vs Sprint Retrospective

很多人分不清这两个会议，其实它们的目的完全不同：

2. Sprint Review 的正确姿势

做： - ✅ 演示可工作的软件（不是 PPT） - ✅ 展示真实的进度，包括未完成的部分 - ✅ 收集利益相关者的反馈 - ✅ 讨论下一步的优先级

不做： - ❌ 把 Review 当成汇报表演 - ❌ 过度包装进度 - ❌ 隐瞒未完成的任务 - ❌ 把别人的成果说成自己的

3. Sprint Retrospective 的常用格式

三列法（最简单）：

😊 做得好的    😐 可以改进的    💡 行动项

海星法（更细致）：

⭐ 继续保持    ⬆️ 多做一些    ⬇️ 少做一些    🚀 开始尝试    🛑 停止做

关键原则：回顾会是无责的。不是追究谁的错，而是找到团队可以改进的地方。

4. 工作量估算方法

任务拆分法（推荐新手使用）：

Story Point 估算（团队常用）： - 用相对大小而非绝对时间来估算 - 常用斐波那契数列：1, 2, 3, 5, 8, 13, 21 - 1 Point = 团队公认的"最小任务" - 超过 13 的任务应该拆分

5. Definition of Done（完成的定义）

一个任务什么时候算"完成"？团队需要有统一的标准：

没有满足 DoD 的任务，不能算"完成"。

6. 估算的常见陷阱

核心原则：估不准不丢人，不说才丢人。发现偏差，尽早同步。

:::