流程只是一个传说——敏捷方法论的理论基础

我这里说的流程是传统的串行软件开发流程。

 

做任何事情，我们最终想获得是一个结果。追女朋友，目标是追到手，成为情人，或老婆。做汽车，最终希望能够出来一辆能开的汽车。做软件，希望最后产出一个大家都能用软件的产品。

 

也就是说，我们想要一个好的结果。

 

那如何获得好的结果？

 

答案是要依赖于人。

 

为什么依赖于人？

 

因为这世界上的一切都是人创造的，人来获取信息，人用自己的头脑对信息进行加工，即思考，然后产生决策，最后，大脑驱动人的行为，创造价值，并对别的人产生影响。

 

一个人能搞定吗？

 

存在这种可能，但当今的社会对软件的需求，已经远非个人英雄主义时代。

 

这样，那就要分给多个人，也就是一个团队去做。

 

团队如何做一件事儿呢？

 

因为事情是一件事儿，但多个人做，他们之间的工作是关联的。这就需要确定先做什么，后做什么，具体谁做什么，每件事儿怎么来做。一开始，张三，李四，王五什么都做，效率很高。但：

 

事情越来越多，怎么办呢？

张三就专门负责A吧，李四就一直负责做B，王五就做C吧。

 

事情还是越来越多，越复杂，咋办呢？

发现张三的工作A可以分成A1，A2，张三1可以专门做A1，张三2专门做A2。同理李四做的工作也分了。

 

这时候，大家发现，由于分工比较细，做一件事情，需要好几个人，有点乱，咋办？

 

人类是最聪明的，大家发现做事的时候都是，先做A1再做A2，然后B1，B2，B3，C1，D1 。。。，有规律呀！

于是，嘎嘣!，流程，这个人类最伟大的发明就这样诞生了，

A1->A2->B1->B2->B3->C1->D1

 

哼着小曲，“oh，process，process，process，It ‘s so great，great，great。

I love you ，yes，that’s it....” :

 

我们每个人就是这样，像个木桩，蹲在那里，像一个守株待兔的猎人。眼一睁，一闭，一天过去了。收工，上工。作为B2，我只关心B1，B3，其它对我来说，就是雾里那朵花，那朵看起来很美丽，很朦胧的水仙。

 

这种方式一开始在传统的企业运转的很好。很明显，我们能看出其中的本质。 A1和A2，A2和B1，节点和节点之间边界是明确定义的，而且是看得见，摸得着的。就像造汽车，整车组装的时候，我能看见发动机是看得见，摸得着，可以测试的。

最最关键的是：这个发动机是我将来汽车产品的一部分。

回到软件开发场景下，也这么干，需求产出的是需求文档，系分产出的是系分文档，开发产出代码，测试产出测试测试用例，

 

但所有这些对最终用户使用的软件产品而言是什么？

像加工过程中的边角废料，副产品，中间产品，因为它最终没有成为提供给用户的产品服务的一部分。呵呵，不过用户使用说明书似乎可以认为是其中的一部分。我认为这就是区分软件制造过程与传统汽车等产品制造过程的最大区别。

 

流程在传统企业成功，还有什么原因吗？

拿造汽车来说，对于流水线的每个人来说，虽然，一开始没看过整个汽车，但是整个汽车在他的脑海里，是比较清晰的。这里面清晰有两点：一个是，没吃过猪肉，还是看过猪跑的。他已经看过很多过这样类似的汽车了。另外，大家对汽车制造的整个上下文，认识是清晰的，毕竟大多数都是标准零件，有严格的定义。这些标准就是隐含的知识，别小视这种隐含的知识，因为知识的残缺，可能造就的就是你行为受到影响，可能就造出残次品。首先是可标准化的，然后是可学习的。

 

这种标准化的做法，放在软件行业是靠谱吗？

看看我们标准化的是什么，是做东西的过程，而不是实际做的东西 ，这两个根本不是一回事儿，差别大了。

软件产品为什么不能标准化？

因为软件是软的，无需过多解释。

 

关于软件的标准化，也不是没有努力，但能够标准化的东西，实际标准化的东西，在整个行业的制造过程，在软件的实际应用场景去比，这个比例微乎其微。在Java领域，jdk，开源框架，组件都可以认为是标准化组件。在具体的业务应用领域，

erp只能算个半标准化，需要二次开发，三次开发，我说的二次开发是实施，三次开发，是围绕erp开发一些周边的应用。

 

软件产品不能标准化，本质在于其应用场景的多样性。

继续说流程，还有什么原因呢？

A1->A2->B1->B2->B3->C1->D1

 

在软件领域，流程节点之间的边界是不明确的，推演一下：

A1开始工作，交付给A2，B1，B2，B3，C1，D1等待

A2开始工作，交付给B1，B2，B3，C1，D1等待。

B1发现问题，反馈给A2，A2给A1，B1，B2，B3，C1，D1等待

A1反馈给A2，B1，B2，B3，C1，D1等待

A2反馈给B1，B2，B3，C1，D1等待

 

简单算个数：

第n个节点发生变更，变更经过的流程次数为2(n-1)，不妨成为流程损耗 。

 

因为软件是软的，大家一开始做的时候，两眼一抹黑，都是看不清的，变化是很正常的。

假设在每个节点只变化一次，在这种基于流程的软件开发模式下，总的流程损耗为：

 

n(n-1)

 

大家可以推算一下，这是我计算的结果.

 

也就是说，在流程节点为7的情况下，假设每个节点变化一次，则流程损耗为 42。

 

再算算浪费，就恐怖了，还是上面的假设，在加上每个人昨晚工作所花的时间是2个小时，每次变更花的时间是1个小时。

 

理想情况，n个步骤所需要的完成时间是2n。

 

理想情况，等待时间为

 

2(n-1), 2(n-2), 2(n-3), ....

 

结果也是n(n-1)，前提是平均每个任务当成2个小时算。

 

理想情况下，按上面例子，总时间为14h, 总的理想等待时间为42h。

 

再包含变更的情况下，数列的通项是n(n-1), 因变更引起的等待时间，求和就是o(n^3):

 

因变更引起的等待时间= n(n+1)(2n+1)/6 - n(n-1)/2

 

如果按照这个例子，因为变更增加的等待时间是119h

 

也就是说，因为这个例子，引起的理想等待时间是119 + 42 = 161h

 

那你又说了，后面的人不是干等着，还是可以做点事情的，如果利用的好，比如流水线，等待时间是没浪费的。

 

实际中，这种浪费肯定还是有的，等待时间可能是做别的事，造成任务并行，任务切换需要时间，人不是机器，损耗肯定是有的。

 

我们就按照50%的利用率好了，损耗时间为80.5h

 

总结一下：

假设：7个节点，每个节点工作任务是2个小时，每个节点变更一次，每次变更时间耗费1个小时。不考虑因变更引起的每个节点任务时间变更。

 

理想等待浪费时间： 161h

总的任务完成时间 = 工作任务时间 + 变更损耗： 14 + 42 = 56h

 

结论：

在这种简单模型下，总任务完成时间与节点数量的平方成正比，等待时间和节点的立方成正比。

 

实际情况就更复杂，工作本身的复杂性，不确定性，变更一般都会增加本身工作任务的工作时间，因为以前做的部分工作可能浪费了。

 

也就是说，想提高效率，最有效的就是缩短流程节点 ，否则最好结果就是也是局部优化而已。

 

这种情况，沟通成本怎么样？

n个人，沟通路径为n(n-1)/2, 每个成本为1小时，上面的情况，总沟通成本为21h

这个是理想情况，为什么要沟通呢？不沟通，信息理解不一致，理解不一致，实际行为就会有偏差。一起做事的人，必须共享信息上下文。

 

人月神话里，说在项目紧张时，加人也不一定能提高总体完成时间，也是这个道理。

 

从中可以推断出敏捷开发方法学的理论基础吗？

 

你可以说，敏捷也是有流程的，只不过，流程比较简单，节点少而已。通过坐在一起的紧密沟通，将变更从o(n^2)降低了一个数量级，变成o(n)。 通过及时的反馈， 缩短了等待时间的浪费。同时， 因为避免了在后期发生变更的概率。按照上面的模型，第n个节点，变更损耗是2(n-1)。

 

姑且就是为敏捷找个牌坊吧，大家也可以自己计算一下。

 

大家可能有疑问，没流程，不是全乱了？

从上面的计算可以看出，按照流程做事，是可以保证稳定的产出的，但效率肯定是低的。我们再进一步，看看事情的本质。拿风险控制流程来说， 表面上是走风险控制流程这个节点。但是，实际上，你的意思是想让流程背后面的那个人，对你的方案做一个风险评估，并给出结果。你可以直接到他面前，把你的问题讲清楚，说明白，或者电话。而不用流程来驱动，复杂的文档，他看理解文档都要花很长时间。经常情况是，他已经评估完了，流程还没走完。这些都是损耗。

 

流程必须有，必须从简，不应该让流程指挥人，而要人成为主宰。在任一时刻，只有人才最清楚，我们将往哪里去。

 

写道这里，仿佛听到流程在说：“不要迷恋哥，其实，哥只是个传说”

 

评论

1 楼 kong_desheng 2010-03-18  

同意博主！
2000年的时候，ChinaUML 就明确提出：项目成功，靠的是技艺，而非过程。
给了CMM、RUP、XP等的盲目推崇者当头喝棒！