拒绝996：如何使用“单件流”概念来提高软件项目交付的准时性？

本文主要是介绍拒绝996：如何使用“单件流”概念来提高软件项目交付的准时性？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

做项目总是感觉时间不够得 996，有没有好办法解决这个问题呢？

“单件流”是精益思想中非常重要的概念之一。和“单件流”相对的概念是“批量生产”。和普通人的直觉不一样，使用“单件流”的模式生产效率显著地高于“批量生产”，而且还具有“批量生产”所不具有的其他优点。

如果读者想对比“单件流”和“批量生产”的效率，可以玩“装信封”游戏或者“折纸飞机”。从游戏结果可以看到单件流方式会比批量生产方式所花的时间要少1/4到1/3。这其中的原因和是不是熟练工无关，而是因为“单件流”的特性。

为什么“单件流”比“批量生产”更有效率？

单件流为什么生产效率会高于批量生产呢？我们以装信封为例先来看看批量生产的做法。

1. 取出 10 张 A4 纸
2. 依次把 10 张 A4 纸折好
3. 把折好的A4纸张放好
4. 取出10个信封
5. 依次把折好的A4纸放入信封中
6. 把已装好A4纸信封整理好
7. 依次封好信封
8. 把封好的信封整理好
9. 依次给装有A4纸的信封盖戳
10. 完成

单件流的做法如下：

• 取出 10 张 A4 纸
• 折好一张A4纸
• 把折好的A4纸放入信封
• 封信封
• 盖戳
• 重复上述步骤直到完成

从以上对比中可以发现单件流有以下优点：

1. 不需要库存
   做好的零件直接进入下一工序，不需要找地方堆放。

2. 没有额外的运输任务
   在批量生产中，生产完成以后需要把零件放到仓库备用，在需要的时候再取出来组装，这都需要运输过程。

3. 可以提前交付
   由于每次都是生产出来的完整的产品，所以可以直接交付给客户使用，而批量生产需要最后一刻才有完整的产品出来交付

4. 提前发现问题
   如果在某一个工序发现问题，可以立即停止，待修复后再继续下一工序。在批量生产时可能会在最后交付时才发现问题，损失大，也可能会在产品组装的时候才发现设计的问题，导致整个批量都得推倒重来。

“批量生产”是如何组织生产的

批量生产的典型方式是“人机合一”，一个人负责一台机器，不停地生产，生产的零件需要仓库来存储以备将来组装时使用，因此会产生很多 WIP （work in progress）。注意 WIP 是一种中间状态，不是制成品，无法交给客户使用。工人的技能单一，只会操作和维护一类机器。

上图是典型的批量生产方式，一个人负责一台设备，不过上图没有表示出来加工后的零件都需要堆放到仓库，形成库存。

单件流是如何组织生产的？

在单件流生产中，机器按照工序组织，生产好的零件直接进入下一道工序，因此可以极大地降低库存，减少零件在仓库和加工车间的运输。单件流中，工人需要照顾整个流水线，管理者根据生产负荷调整工人人数，因此在单件流中要求工人掌握更多的技能。

软件开发中存在“批量生产”吗？

在软件研发中，管理者比较习惯的做法是根据软件模块的划分让一个组员负责一个模块，分别开发，最后集成。这种做法的好处是责任明晰，出了问题直接找负责人就行。但是这种做法就类似于批量生产，需要每个模块都完成以后才能组装，不能提前交付，往往只能在最后一刻才能发现问题，就像批量生产中每个人负责一台机器，会产出许多 WIP。

在这里，还在开发中的软件模块就是库存，而把已开发好的模块取出来跟其他模块集成就是运输，因为开发团队需要重新熟悉模块进行组装。

软件是知识产品，使用软件产品是需要一个学习过程的。一次性交付客户大量功能的产品，客户也需要一步步的学习才能学会使用，因此在做软件项目时可以和客户一道通过单件流的方式分批交付，一方面可以让客户提前获得收益，另一方面还可以获得通过提前获得反馈得到改进产品质量的机会。

“单件流”概念是否有助于提高软件开发效率？

首先如何衡量软件开发的效率呢？通常我们可以用下面的两个标准来衡量软件的开发效率：

1. Lead Time
   Lead Time 指的是从需求的提出到把需求变成可运行的软件的时间。

2. Cycle Time
   Cycle Time 是指从开始开发某个需求到完成这个需求所花费的时间。

下图是某个团队的 Lead Time 和 Cycle Time 指标：

显然这两个指标都是越短越好。时间越短客户为了得到某个功能需要等待的时间也就越短。

那么这个等待时间是由什么决定的呢？下面的公式是利特尔法则(Little’s Law)的变形，它可以帮助我们理清决定等待时间的关键因素。

上面的公式中 W 表示某个团队用户故事的平均等待时间，L 表示正在处理的用户故事队列，Lamda表示团队的用户故事平均处理率，用每天能处理的用户故事数表示。

通常来说团队的用户故事平均处理率是相对恒定的，因此降低 L 是唯一的选择，理论上 L = 1 会得到最低的等待时间，对于软件开发来说就是降低同时进行的用户故事数。

为什么需要全栈工程师？

降低同时开发的用户故事数就要求多人一起开发一个用户故事，问题是用户故事中的任务拆解后，不同类型的任务数量和团队成员的技能人数可能会不匹配。比如前端、后端、持续集成、测试等任务和团队中前端、后端以及测试工程师的人数不匹配，这就会造成团队成员的工作量分配不均，有些人忙死，有些人因为在一段时间内没有匹配的任务而闲死。

怎么解决上述问题呢？这需要团队成员都有全面的技能，也就是以下两点：

1. 培养全栈工程师
2. 需要团队成员积极主动地承担任务

全栈工程师才能承接不同类型的任务，不会因为任务不合适而等待合适的任务。管理者还需要鼓励团队成员自己主动承担任务，这样才能降低团队成员的等待时间。

如何帮助团队成员积极主动地承担任务？

除了管理者的鼓励以为，团队要做到以下几点：

1. 拆分好任务，每个任务的时间最好不要超过1天
2. 使用看板或者 Scrum Board 让所有人都能看到所有任务的状态
3. 经常回顾 Lead Time 和 Cycle Time 这样的指标提示团队降低等待时间

用户故事的设计需要改进吗？

前面提到 WIP 是一种中间状态不是可以交付的产品。单件流的目标是在流程结束后提供的是客户可以使用的产品。这启发我们在设计用户故事时也应该是在做完以后，可以交付给客户立即使用的功能。

以多个用户故事组成的每次迭代也应该以可交付为目标，让客户尽早使用到团队开发的产品，提前得到用户反馈，改进质量。这也可以让客户渐次学习产品的使用，尽早获得产品的收益。

在处理“单件流”时遇到缺陷怎么办？

单件流的每一个产品进入下一个环节都应该有质量检测标准，当遇到缺陷时应该立即停下来检查缺陷对整个产品质量的影响，是否需要立即修复，以免扩大缺陷的影响。要知道缺陷处理的成本随着工序的增加是递增的，缺陷到达客户手中再修理的成本是最大的。

结论

批量生产方式让每个人只负责一件事情，因为有太多的 WIP （Work In Progress）而不是客户能用的产品，而造成大量的库存，而运输和重新组装又造成了新的浪费。批量生产在集成的时候才发现缺陷，会提高解决缺陷的成本。

在软件开发中使用“单件流”模式可以降低开发中的 WIP，提高交付效率，同时也降低客户的等待时间，但是“单件流”模式要求开发工程师更全面的技能，更积极主动的承担任务，同时要求产品经理在定义用户故事时以可独立交付为标准，这就对软件开发团队提出了更高的要求。

参考资料：

• 拒绝加班：如何避免开发完成了但是不能交付的困境？
• 拒绝加班：是不是只有“全栈”工程师才能实现软件开发的“单件流”
• 折信封游戏
• Lean Manufacturing : What is Single Piece Flow?
• http://www.agilebuddha.com/kanban/one-piece-flow-alternate-of-kanban-in-software-development/

这篇关于拒绝996：如何使用“单件流”概念来提高软件项目交付的准时性？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---