我用周数做Sprint规划整整两年，直到一个实习生问我：你的第1周从哪天开始？

那是去年夏天的一个周五下午。我正准备收拾东西下班，新来的实习生小周走到我工位旁，手里拿着一份打印出来的Sprint排期表。

「组长，我有个问题，」她说，「Sprint 26是从哪一周开始算的？我看你的表上写着Week 26，但手机日历和Jira显示的周数不一样。」

我当时差点笑出来。Sprint 26当然是从第26周开始啊——这还用问吗？但我还是打开日历，准备给她指一下。

然后我愣住了。Jira显示7月3日那一周是Week 27，我自己的排期表上写着Week 26，而小周手机上的iOS日历显示的又是另一个数字。

三个设备，三个不同的周数。同一周。

我那天晚上没走成。我在工位上坐到了晚上九点，把团队过去两年的Sprint排期从头到尾翻了一遍。结果让我后背发凉：我们18个Sprint里面，至少有5个的起止日期和当初设想的周数对不上。不是因为排期改了——是因为每个人对「第几周」的理解从一开始就不一样。

是我把Sprint编号和周数混在一起了

事情要从两年前说起。当时公司开始推敏捷转型，我被指定为其中一个团队的Scrum Master。我跟你说实话，那会儿我连Scrum Master到底该干什么都说不清楚，但有一件事我觉得特别简单：把一年分成52个Sprint，用周数编号，清晰明了。

于是我设计了一套系统：Sprint 1 = 第1周，Sprint 2 = 第2周，以此类推。Sprint时长一周，每周五下午做回顾。

听起来很合理对吧？我自己也觉得特别聪明。简单，好记，不用想。

这个系统跑了整整两年，期间出过几次小摩擦，但我都没太在意。比如有一次，隔壁组的开发说「我们Sprint 15的交付物已经ready了」，结果我们发现他说的Sprint 15比我们说的早了整整一周。我以为是他搞错了，还专门发邮件纠正了他。

现在回头看，真正搞错的人是我。或者说，是我根本没意识到这个系统本身就有问题。

问题的核心很简单：第1周从哪一天开始？

三个人，三个答案

那天晚上我把团队的日历工具全部检查了一遍，发现了三件我之前完全没注意到的事：

Jira用的是ISO 8601标准。第1周是包含当年第一个星期四的那一周。如果1月1日是周五、周六或周日，它属于上一年的最后一周。所以Jira里有些年份的第1周其实从上一年的12月底就开始了。

我自己的排期表用的是「直觉法」。就是打开日历，找到1月1日，从那周开始往后数。1月1日在哪周，哪周就是第1周。至于这个1月1日是周三还是周五，我不在乎。这个方法其实接近美国标准，但我当时压根不知道还有「美国标准」这个东西。

小周的iOS日历用的是系统默认。iOS在中国地区的默认设置用的是ISO 8601，但她说她看着不对，又自己手动调整过——调整成了什么，她也说不清楚。

也就是说，我们团队在同一个项目里，同时运行着至少两种不同的周数系统。Jira说现在是Week 27，我的排期表说现在是Week 26，而团队里不同的人在沟通时用自己觉得对的那个数字。

两年。整整两年没人发现。

那些「对不上」的Sprint

发现问题之后，我把过去两年的Sprint逐一核对了一遍。以下是我发现的：

2024年的跨年期间，按照ISO 8601，2024年1月1日是周一——那一周恰好是ISO Week 1。但按照我的「直觉法」，1月1日所在的周也是Week 1。两个系统恰好在2024年对齐了。这也是为什么系统运行的前半年没人发现问题——它恰好是对的。

问题出在2025年。2025年1月1日是周三。按照ISO 8601，2024年12月30日（周一）到2025年1月5日（周日）是Week 1 of 2025。但按照我的美国式直觉法，2024年12月29日（周日）到2025年1月4日（周六）才是Week 1。

差了一天。一天。

到了2025年1月底，这个一天的差距还没有造成实质性问题——Sprint排期误差一天，大家不会注意到。但到了第二季度，当多个团队开始协作、共享Sprint交付计划时，差距被放大了。Jira上的Sprint deadline显示Week 16的周五，我理解的是Week 16的周五，但那是两个不同的周五。

最夸张的一次是2025年Q3，有一个跨团队的集成测试窗口。我们约定在Week 32进行。测试环境在Jira里对应的那周准备好，但我的团队认为的Week 32比Jira的晚了一周。结果测试环境空转了一周，我的团队忙了一周——两边都在等对方，谁也不知道为什么。

我现在怎么处理这个问题

发现这个问题之后，我做了一些改变。不是什么高大上的方案，但至少现在团队不会再出现「你说的第26周到底是哪周」这种问题了。

第一步：在团队Wiki里明确写了周数标准。我选的是ISO 8601，因为Jira本身就支持它，而且这是国际标准。这个决定不难。难的是让每个人都知道这个标准存在。

第二步：所有Sprint排期表同时标注周数和具体日期。以前我的表只写「Sprint 26」，现在写「Sprint 26（6月23日-6月29日）」。多打几个字而已，但省掉了之后无数的来回确认。

第三步：统一了团队的工具设置。Jira、Google Calendar、飞书日历，全部设置成ISO 8601周数显示。我跟IT要了半小时，把所有新人的设备也按这个标准配置。

第四步：每次跟外部团队合作，第一件事就是对齐周数标准。「你们用的周数标准是ISO还是US？」这句话现在是我的固定开场白。大部分人的反应是愣一下，然后说「应该是ISO吧...我看看。」看，这就是问题本身——大部分人都「应该」在用某一个标准，但从来没确认过。

说实话，我还是经常用 weeknumber.cc 来快速查日期的周数。不是因为我不信Jira，而是因为Jira有时候更新了配置我没注意到，或者某个自动生成的报告里周数用的不是ISO标准。花几秒钟在工具上确认一下，比花一小时去排查一个「Sprint为什么对不上」要划算得多。

这件事给我最大的教训，跟你讲，不是关于周数标准——而是关于「我以为」。我以为所有人都用同样的方式数周。我以为一个简单的东西不需要确认。我以为两年没出大问题就等于没问题。

直到一个实习生站在我工位旁边，问了一个我以为不需要问的问题。