当工作太多、人手不足时经验不足的管理者往往会让员工同时处理多项任务希望以此提高效率。但结果通常恰恰相反任务完成时间变得更长团队成员也更容易精疲力竭。对于软件研发团队来说合理设置 WIP 在制品限制是减少多任务切换、暴露流程瓶颈、提升软件交付效率的重要方法。更有效的做法是对工作进行优先级排序限制同时进行的工作数量集中精力完成少量高优先级任务。制造业长期以来一直重视限制在制品也就是 WIPWork in Progress 的数量。工厂不会持有大量库存。相反当客户下单后零部件会在工厂内部按需生产或根据需要从上游供应商处调拨然后企业及时完成组装。如果这一流程实施得当就可以缩短交付周期、提高产品质量、降低成本并减少浪费。如何实施 WIP 在制品限制使用看板让工作可视化在技术领域我们的“库存”通常是无形的。没有堆积如山的半成品也没有一条可以直观看到工作流动情况的装配线。一种简单的工作管理方法是把团队正在进行的所有工作写在卡片上然后贴到看板上。在敏捷方法中这通常被称为创建故事板或工作看板。一个典型的看板可以覆盖多个职能环节例如分析、开发、测试和运维并展示某个产品相关的全部工作。对于研发团队来说看板不应只停留在“任务展示”层面更应该连接目标、需求、开发、测试、发布和复盘等完整链路。借助PingCode这类研发管理工具团队可以把需求清理、评审排期、开发任务、测试验证、发布上线和 Wiki 知识沉淀串联起来并与代码仓库、CI/CD 等工具打通让 WIP 限制真正落到可追踪、可度量、可复盘的研发流程中。在使用看板时一个常见做法是每天在卡片上标记一个点表示这项工作又经过了一天。这样团队就可以很容易地看出哪些工作出现了阻塞或者哪些工作耗时过长。设定合理的在制品限制为看板上的每一列设定在制品限制也就是该列可以同时容纳的卡片数量上限。达到在制品限制后这一列就不能再添加新的卡片。团队必须等待其中某张卡片移动到下一列之后才能从上一列拉取优先级最高的下一项工作。只有当团队真正设定在制品限制并遵循这种拉动式流程时才算真正建立了看板系统。在制品限制应根据团队产能确定。例如如果团队有四组开发人员那么“开发中”这一列的卡片数量就不应超过四张。坚持执行 WIP 限制在制品限制有时会导致某些团队成员暂时空闲等待其他任务完成。此时不要轻易提高在制品限制。更好的做法是改进流程解决导致等待和延误的因素。例如如果团队正在等待测试环境与其继续增加开发任务不如主动帮助负责测试环境的团队改进或简化环境搭建流程。在制品限制的常见陷阱实施在制品限制时组织经常会遇到以下几个陷阱。陷阱一忽视看不见的工作团队需要从构思到客户交付完整可视化整个价值流而不仅仅是可视化自己负责的那一小段工作。否则团队就很难发现真正的瓶颈最终可能只是在解决一些看起来显眼、但实际上并不制约整体流动的问题。这也被称为局部优化。陷阱二在制品限制设置过高团队需要确保在制品限制不要设置得过高。如果团队成员经常需要把时间分配到多个任务或多个项目上这通常说明在制品限制已经过高。在制品限制的目的不是让每个人看起来都很忙而是帮助团队尽快完成真正重要的工作。陷阱三一遇到空闲就放宽限制当有人暂时空闲时不要立刻放宽在制品限制。相反这些人应该去价值流中的其他环节提供帮助解决导致瓶颈的问题。如果某个环节持续阻塞团队更应该关注的是为什么工作无法继续流动需要怎样改进流程而不是简单地给上游继续添加更多工作。陷阱四见好就收如果团队很容易达到当前在制品限制那就应该考虑进一步降低限制。在制品限制的目的就是暴露系统中的问题以便团队及时解决。另一个需要注意的信号是可视化看板上的列是否过多。如果流程被拆成太多列可能意味着交接环节过多流程本身过于复杂。团队应该寻找简化交付流程、减少交接环节的方法。流程改进才是提升效率的关键。相关 DevOps 研究表明在制品限制有助于提升软件交付绩效尤其是当它与工作可视化和监控反馈循环结合使用时效果会更加明显。如何改进在制品限制要改进在制品限制可以从以下几个方面入手。让工作公开透明尝试将所有工作展示给多个团队和关键利益相关者确保所有重要工作都能被看见。只有当工作被看见团队才有可能讨论优先级、识别瓶颈并做出有效取舍。设置与团队产能匹配的限制在制品限制应该与团队实际工作能力相匹配。流程中的任何一个环节在制品数量都不应超过能够完成这些工作的人员数量。同时团队还需要把生产支持、会议、技术债务治理等活动计算在内。否则看板上看起来工作不多团队实际却已经被各种隐性工作填满。避免让人同时处理多项任务不要要求团队成员在多项任务之间频繁切换。多任务切换会增加认知负担延长完成时间并降低工作质量。更好的方式是让团队集中完成少量高优先级工作。当某项工作完成后把代表该工作的卡片移动到下一列再从队列中拉取优先级最高的下一项工作。定期进行优先级排序可以每周召开一次利益相关者会议对所有待处理工作进行优先级排序。团队应明确告知利益相关者如果他们不参与优先级排序他们提出的工作就可能无法被及时完成。这有助于避免团队被大量“同样重要”的工作淹没也能促使业务方真正参与取舍。用周期时间衡量流程效率团队应衡量工作流动的周期时间。在每张卡片上记录工作开始日期和结束日期。基于这些信息可以创建周期时间分布图展示工作在系统中流转所需的天数。这些数据可以帮助团队计算平均周期时间和波动性。目标不仅是缩短平均周期也要降低波动性。高波动性通常意味着团队对工作范围规划不充分或者团队外部存在重大制约因素。高波动性还会让未来工作的估算和预测变得不可靠。持续改进工作流团队应持续减少交接环节简化并自动化任务并思考如何更好地协作完成工作。当团队排除了一些障碍流程运转变得顺畅后就可以进一步降低在制品限制以暴露下一批障碍。理想状态是单件流也就是一项工作从构思到交付给客户的过程中等待时间和返工时间都尽可能少。虽然这种理想状态可能无法完全实现但它可以像“北极星”一样指引团队持续改进。如何衡量在制品限制是否有效在制品限制本身是人为设定的并不是一个自然产生的度量指标。但围绕在制品限制开展持续改进非常重要。在定期回顾会议中团队可以提出以下问题我们是否了解从构思到客户交付的完整价值流我们是否知道整个价值流的平均交付周期和波动性我们是否找到了提高效率、缩短工作周期的方法当前的在制品限制是否暴露出阻碍产出的瓶颈我们是否正在采取措施消除这些瓶颈在制品限制的核心价值不在于让看板变得整齐也不在于机械地限制每一列卡片数量而在于帮助团队看见真实的工作流动状态。只有当团队能够发现瓶颈、主动协作、减少等待和返工并持续调整在制品限制时WIP 限制才能真正转化为更高的软件交付效率和更健康的团队工作方式。对于软件研发团队来说WIP 在制品限制不是一种简单的看板规则而是一种提升交付效率的流程管理方法。它通过限制同时进行的工作数量减少多任务切换暴露价值流瓶颈并帮助团队把注意力集中在真正重要的工作上。只有持续可视化、持续度量、持续降低不必要的在制品数量团队才能真正缩短交付周期提升软件交付质量。
)
