源于精益的生产节拍是否能够适用到软件开发？

源于精益的节拍时间是什么？

节拍时间代表着客户的需求进度以及随之而来的理想中的生产进度，另外一个说法就是生产节拍，节拍一词是来自德语中用来演奏的节奏(Takt)。精益里面的生产节拍是指在一定时间长度内，总有效生产时间与客户需求数量的比值，原理公式如下：

节拍时间=可用时间/每日的客户需求。

常见具体计算公式如下：

节拍时间 = 可用工作时间（单位：分钟数 / 天 ）/ 客户需求（单位：件数 / 天）

举例：以每天有且只有一个常日班来说，总计有8小时(480分钟)。减去30分钟午餐，30分钟休息(2 x 15 分钟)，10分钟交接班和10分钟基本维护检查。那么可用工作时间 = 480 - 30 - 30 - 10 - 10 = 400分钟。当客户需求为每天400件时，每个零件的生产时间应控制在一分钟以内来保证客户的需求。

根据客户需求量与工厂可供时间所得之节拍时间，可以用来识别生产环节的瓶颈，进而进行调整，获得更加经济的安排，释放多余生产能力，进而提升生产效率。

从节拍时间的定义可以看出，节拍时间与前置时间或者响应时间不同，生产节拍实际是一种目标时间，是随需求数量和需求期的有效工作时间变化而变化的。节拍反映的是需求对生产的调节，如果需求比较稳定，则所要求的的节拍也是比较稳定的，当需求发生变化时节拍也会随之发生变化，如需求减少时节拍就会变长，反之则变短。

这在精益生产中已经获得成功验证。

为什么一个软件从业人员开始关心生产节拍？

在《精益的转变》一书中，作者亚特-伯恩识别了如下4个敏捷转变实施原则：

按节拍时间工作

创建单件流水作业

确立标准化作业

通过拉式系统把你的客户同你的车间联系起来

按节拍时间工作被列为第一条，精益实践者在谈到“节拍”时想起用节拍器来形容稳健的步伐，而稳健的步伐是精益中最重要的元素。

从字面上看，这与敏捷开发当中的迭代时间箱工作方式极为接近。

而同样在《精益的转变》一书中，作者反复强调了精益不仅仅适用于生产型企业，同样使用于非生产型企业，包括服务型企业等等任何企业。按这个推论，作者显然认为也能适用到软件开发当中，但是作者并没有从事或者领导软件开发企业的经历。是作者不了解软件开发，进而误判了精益适用范围？还是作者得到的普遍规律其实是适用于软件开发，只是还没有充分进行探索？

在精益生产的例子中，节拍时间所使用的单位是分钟或者秒，其相应的交付响应时间从8周降低到2天，不禁让软件从业人员遐想软件开发能不能做到交付响应时间降低到数天。

本文试图来初步探讨下这个问题。

如果软件使用节拍时间，软件节拍时间是什么样？

对于软件开发，显然在数量级上与工厂生产是有巨大差异的。可行的一个调整方案是采用小时和月度作为节拍的计算窗口。这样的话，计算公式如下：

Takt Time = 可用工作时间 （单位：小时/月）/ 客户需求（单位：个数/月）。

举例：假设普通月份有22个工作日，那么分支是 22 * 8 = 176 小时/月。

当每月需求有20个，那么生产节拍就是 176/20 = 8.8 小时/个。

为简便计，以下采用“软件生产节拍”这个提法，来区别于常见精益里面的节拍时间。

还有一个很有意思的要点是对比精益的其它度量，节拍时间的计算是可以在没有精益准备下处理计算的，只需回顾下过去三个月上线了多少个需求（或者讲是项目，要点是对客户有意义）。

这也是笔者看到节拍时间之后马上感兴趣的原因之一，在文末提出了一个问题，请读者留意下，自己思考看看。

软件生产节拍的前提是什么？

留意上一节软件生产节拍的计算，其中分子上的可用工作时间在软件开发中也是存在的，而其中分母上的客户需求却是在传统软件开发中没有的。传统的瀑布生命模型或者软件生存周期方法，一个软件开发项目历时6个月，按各个生命周期阶段来开发，不进行每月需求的度量。而在Scrum里面，有类似的概念，比如冲刺速率，一个迭代完成了多少个故事点。但与精益的生产节拍也并不完全对应。显然的，瀑布生命周期的大批量分阶段的特征离精益生产节拍更加遥远，为对接分析软件开发和精益生产节拍，本文余下采用Scrum来对比分析这样的软件生产节拍的前提有没有可能满足。首先来看差异。

比较Scrum的冲刺速率和软件生产节拍

简单分析

说明1：一般的，Scrum里面的development team判断故事的点数，PO没有发言权，客户可能不知道故事点数。

说明2：假设迭代长度正好是一个月

综上表，两者存在一些相似的地方。在精益起源的行业里，客户需求往往是各种各样的零件或者组装好的零件，客户所需要的东西与生产流水线上的工件存在自然的对应关系。而对于软件开发而言，软件开发团队处理的工件在瀑布生命周期里和RUP里有各类文档，这类比到精益，显然更加遥远。在Scrum里面常见有用户故事，体现对于用户的价值，这看起来离客户需求更加接近。

而两者最大的区别在于故事和故事点是Scrum团队自身定义的，而客户需求是客户或者业务方定义的。

软件的客户需求与生产型工厂的客户需求存在巨大差别。除了极为少数的特殊工厂（比如火箭、航天飞机），工厂的客户需求自然而然已经划分成了小颗粒度（比如轮胎，灯泡，钢珠，各种各样零件）。而软件的一个客户需求，既可能只需修改10行代码，也可能需要10000行代码，甚至更多代码。

软件的客户需求能否与工厂的客户需求那样？

显然的，经历了这么多年的纷纷扰扰，已经清楚的看到，不经过加工的客户需求与工厂的客户需求显然不一样。经过加工的客户需求也许可以像工厂的客户需求那样来处理，在探讨具体如何加工之前，如下问题先来，有没有必要对客户需求进行加工，以便获得精益所宣称的那些好处？

事实上，虽然生产型工厂处理的工件自然是小颗粒度，但已经发生了对客户需求进行加工的例子。比如不惜重写销售条款，限制订购三个月的需要量，比如每月最后一周只能订购月度需求量的50%，不实行量大优惠政策，着眼于平衡订单。

以上的做法在工厂里已经得到了验证，明显的好处是双方共赢。

时基竞争时代早就已经开始

时基竞争是指产品被生产出来，运到市场，并提供给客户的速度上的竞争。这个概念在上世纪90年代初流行，现在已经被大多数生产型企业接受。波士顿咨询集团的乔治-斯托克和托马斯-豪特在《与时间竞争》一书中强调了这种理论的重要性。

IT界也早就有“快鱼吃慢鱼”的共识，不再是“大鱼吃小鱼”。

有人说，敏捷已经17年，貌似也在成为传统了，它的速度范围标签大概在每周到每月发布一次，但多数敏捷实践并没有度量实际的客户需求响应时间，极有可能是在2周的发布间隔之后掩盖着长达3个月的需求响应时间，某些潜在可交付物对应在精益视角里，可能就是属于应当降低的库存。

为了赢得时基竞争，敏捷的用户故事是时候考虑向前到业务方去加工客户需求了？

对于已经提出蛮多时间，但至今貌似还没有较为完善理论整理的“业务敏捷”而言，加工客户需求相信是业务敏捷里面最优先考虑的重要部分。

如何加工客户需求？

理想的情况是业务提出小颗粒度的需求，既能独立的实现业务价值，又能够得到快速软件开发实现上线。但这样谈何容易？ 业务方与IT方在最近30年，已经演出了一幕幕互相抱怨的鲜活剧，业界的段子已经累积不少，产品经理作为其中的交接点，受尽了夹板气。

是不是应当从精益节拍时间的启发中尝试新的方法？笔者正在采用一个方法，有初步的成效，看到了客户需求响应时间的下降。此方法要点如下：

收集来自业务、客户及各相关方的原始需求，也称为客户声音，记录提出日期；

初步分析后分拆、再写和包装这些原始需求到客户需求（不同公司采用不同说法，有仍然叫项目，也有称为Feature，或用Epic），要点是达成业务所需价值的最小颗粒度，这与MMF是完全一致的，这需要基于业务的判断，因此对产品经理提出了更高要求，不再只是理解业务需要翻译给IT团队，这里有个实践是业务方和软件开发方组成联合产品经理团队。这也就是集中体现了之前提出的“向前到业务方加工客户需求”

各方联合判断客户需求是否采纳，判断采纳日作为采纳日期

分析采纳后的客户需求得到用户故事

根据IT方内部系统子系统和团队划分，为中后台团队/系统，分析用户故事到系统故事

协调多团队，联合排期

上线，记录上线日期，减去采纳日期，得到客户需求响应时间

建立客户需求看板，在团队级建立故事看板，可视化上述过程

度量月度客户需求吞吐量，以及其它所需度量

计算整体和各个团队的节拍时间，联合对比各项度量，以此来调整客户需求看板的WIP，并协调各个团队的资源能力平衡（诸如前台-中台-后台，不同系统子系统，开发-测试等等）。这里要说明的是，软件开发毕竟与工厂零件生产不一样，零件生产各个环节往往是自动化过程，时间可以精确提前知道，而软件开发不具备这样的条件，根据节拍时间在精益里面的应用在软件开发中不能直接使用，需要综合更多度量来一起观察。

小结和展望

有一个启示是可以得到确认的，就是以客户需求为目标导向，真正关注到价值交付到客户，而不是停留在价值观和口号里面。

利用秒级的节拍时间精确的调整具体工位和工序分工等等在精益工厂里面发生的事情，估计在未来较长时间内不会在软件开发中发生（未来的AI编程会不会？），那么小时级如何？以天为计的节拍时间呢？

下面请读者根据当前实际情况来算算看，先不管当前需求是否提前加工过，可以简单粗略来计算下，以支持最小完整业务为范围，这个范围是能够独立完整的响应业务需求，对应IT人员规模一般少于100人，回顾下过去1个月上线了多个业务提出的要求，不计新接的要求（或者叫需求）和正在做的要求，只看上线后得到使用的要求数量，以此来计算精益生产节拍的粗略值。

如下是个简单的例子，比如一个月交付了2个需求，简单粗略计算可以得到的节拍时间长达11天（一个月22工作日除于2，得到11）。

这如何看，会不会担心竞争对手基于时基优化后只需要10天？如果竞争对手只需要1天的话，如何？

而软件生产节拍1天的含义就是每天都有业务新东西上线。

互联网企业天生敏捷，假设某互联网企业在其原来业务领域已经建立了节拍时间为1天的能力，如果牌照放开，或者其它原因，其进入到某个传统领域，会不会给传统领域企业带来降维打击？

这在零售领域是不是已经发生？ 其它领域如何？保险？金融？基金？

另外一个情况是业务角度出发的客户需求虽然经过加工，但其颗粒度仍然可能是超出单个敏捷小团队的处理范畴，比如不同系统，不同分工，这样就涉及到多个团队之间的协调。

早期敏捷给出了敏捷小团队一级的不少实践，缺失了对于多团队协作的指导，需要参考规模化敏捷的实践指导，而规模化敏捷领域的探索应当说还正在进行。业务敏捷与规模化敏捷必然需要结合在一起来处理。