每个月，四个客户组都要和微软 IT 部门一个小组（XIT 持续维护组）的经理们坐下来，把这个组手上所有的活排一遍先后。
单子上有 80 多个改动需求，积压每月最多还会再增加十个。这个组一个月只做完六七个。于是每次会上排好的，大多数到下次开会都没人碰，只好再排一遍。需求一拖再拖，交付日期错过了就重新商量，用后来写下这段经历的两个人的话说，「一次又一次」。
与此同时，每个新需求都得在 48 小时内给出粗估。一名开发、一名测试各要花大约半天。估算最多占掉组里四成产能，可估过的需求最后真做了的只有一半左右。而且估算常常在动手前几个月就做了，做估算的人也未必就是后来干活的人，等真开工时，当初弄明白的东西早忘了。
2004 年 9 月接手这个组的项目经理德拉戈什·杜米特留，把这两样都停了。接单时的粗估取消了，开发前面只能排固定几个已批准的需求。一个需求排进了空位，才给交付日期。空出一个位子，由客户们自己商量拿哪个需求补上。
按杜米特留和同事大卫·安德森 2005 年在会议论文里的说法，还是这六个人，一年之内，每季度完成的需求从 17 个涨到 44 个。需求排进空位后，通常 12 到 14 个工作日就交给用户验收。后来又加了两个人，开发环节的上限约为十二个：七个排队、五个在做。经过详见案例。
放进去的少，做出来的多
给在制品（WIP，开了头还没做完的活）设上限，听起来像是少干点。这个组自己解释为什么反而干得更多，归结起来有三点。上限让新活进来的速度，跟上「团队消化得了的速度」。它让每个人「一次只干一件事」，把手上这个需求推到下一步，再拿下一个。它还让客户把注意力放在「此刻最重要的事」上，因为空位是稀缺的。
快，背后也有一道算术。1961 年，运筹学者约翰·利特尔证明：一个长期平稳运转的系统里，平均有多少件东西，等于它们进来的速度乘以每件平均待多久。反过来看，只要完成的速度不变，系统里的活少一半，每件活在里面的平均停留时间就减半。这就是利特尔法则。
利特尔自己很小心，说清了这条法则管不了什么。它「不负责改变这些量」，他在 2011 年写道。只要产出不掉，上限能缩短活在受限环节里的平均停留时间。可它消不掉客户从提需求起的那段等待：挡在外面的活照样在等，只是等在开工之前，下面那位设计师就碰上了。上限本身也不会让谁干得更快。XIT 多出来的产出，来自上限腾出的空间：不再估算那些永远不会做的活，不再每月从头重排，又在看清测试有空闲之后把一名测试调去做开发。
同时开着九个项目
设想一位自由设计师，手上同时开着九个客户的项目。每个项目每周都推进一点，每个客户都发邮件来问进度。回这些邮件，再在脑子里把每个项目重新捡起来，大半个上午就没了。
她试了一条规矩：同时只做三个，其余的排队，写上开工日期。排在后面的客户要多等一阵才开工。可一旦开工，东西几天就能交回去，不用再等几个星期。一个月下来她是不是做完得更多，要看切换的时间是不是真省下来了，这个她自己数得出来。
智能体开工太快
AI 智能体让开工变得很便宜，这个问题在它们自己的设计里就冒了出来。Anthropic 的工程师 2025 年写道，他们的多智能体研究系统早期犯过这样的错：「为简单的问题派出 50 个子智能体」，还「用过多的进度更新互相打扰」。办法是把上限写进提示词。简单的查事实，用一个智能体、调 3 到 10 次工具；复杂的研究，可能用 10 个以上的子智能体，「分工划得清清楚楚」。
不过对多数用智能体干活的人来说，更紧的那道关在下游，就是你自己的审查。午饭前开了十个智能体任务，下午认真看完三个，剩下七个就是在制品，等着你。跟 XIT 的估算一样，你派活时脑子里的来龙去脉，会在它们排队时慢慢淡掉。
所以，数一数还没审的那一摞，给它定个上限。满了，下一步就是先审完一个，别再开新的智能体。