完美软件开发：流程尺度逻辑链2

软件是一种固化的思维→思维固化本质上不可能是例行公事→现场的人需要较大的自主空间→软件的流程粒度需要比较大，而不能规定工作细节和手册化。→可以把流程等价于一种打断，从这个尺度上可以度量当前流程的程度是否过于繁重。

必要的流程尺度与工作自身的特质有关。对于重复程度比较高的工作，明确定义流程细节，并确保执行力度，是保证结果的有效手段，比如，本地化工作等。对于全新的或者变化比较频繁的工作，过度详细的流程会增加额外工作量，导致不良结果，甚至可能比没有流程更差。大多的软件开发更像后者，而非是前者。

“究竟什么样的流程适合软件项目？”显然是一个尺度问题。既不是越细越好，也不是越粗越好。

对此，儒家讲：允执厥中。黑格尔曾在《小逻辑》一书中写道：上帝是万物之尺度。由此可见尺度问题是世界性的长期话题，并不是简单可以解决的，大多时候要基于人的判断。

我们来试着对判断基准做一点分析。

比如，我们说苏州8月份会下雨，那十有八九是对的。但如果我们说苏州8月1日20：00：00会下雨，则很可能是不对的。

上述两则推测之所以结果不同，实际上是因为尺度：8月和8月1日20：00：00在时间上的精确程度不同。

判断8月份下不下雨，只要知道8月份是梅雨季节，而梅雨季节一定下雨就够了。

判断8月1日20：00：00是否下雨则要使用卫星和超级计算机来预测，即使如此其结果也不一定准，因为时间上过于精确，各种偶然因素都可能会对结果产生影响。

流程要约束的也是未来会发生的事情。而上面的例子告诉我们流程中的步骤要尽可能基于有逻辑或数据支撑的必然因素（比如，梅雨季节一定下雨），而不是偶然因素。这就是判断流程尺度的基准。

下面，看一个具体的例子。比如，我们定义流程时可以定义每次Review都要有记录，因为没有记录必然不知道哪里错了，Review后没法修改。但要求任何Review的记录中都必须用完全相同的格式（记录下来对应的要求，是不是错误，错误的原因是什么，可不可能防止等）就有点过了，因为每次出的问题，问题的原因等皆不相同，会导致较多的争议。

上面的描述似乎仍然比较抽象，这里再补充另外两个可以间接度量流程尺度的视角。

一是对个人工作构成打断的频度。《人件》中曾经提到，人的思维在经过一小段时间（20～30min）的沉静后，会进入“顺流”状态，这时思考效率最高。一旦被打断，那么重新进入“顺流”状态需要花额外的成本。这意味着一个人在一天内不适合同时进行过多的不同类型的工作。如果每次进入状态需要（20～30min），那么不同类型工作数量的上限值似乎应该是2～3个。可以计算一下，每天中由流程导致的这种打断的频度。

●晨会。

●To-Do列表更新。

●时间管理。

●非每天发生的项目，如数据统计等。

●……(www.xing528.com)

由此可对流程是否已经过度进行一点判断。

二是间接的时间开销所占的比例，即在项目中估算，需求，设计，编码，测试这类直接和项目相关工作之外的时间开销，这背后所隐藏的是项目所能接受的生产率。

这可以用简单的公式推导来证明。

生产率：Productivity=Scale/MM单位：KSLOC/MM

其中，Scale代表最终软件产品的规模，我们用代码行来做度量规模的单位。

MM则是开发此软件产品所花费的人月。

而与此同时，Scale=Coding Speed×Coding MM。

Coding Speed是指一个程序员编写代码的速度（不是指生产率），而Coding MM则是指所有程序员用来编码的时间。

把这两个简单的公式合在一起，生产率的公式将变为：

Productivity=Coding Speed×CodingMM/Total MM单位：KSLOC/MM

对于成熟的程序员，编码速度（Coding Speed）总是相对恒定，这也就意味生产率最终和编码所占的时间比率有关。

从流程的角度看，可以要求很多，比如，所有的会议都必须有会议记录，会议记录也必须进行检查等，但当这类时间增加的时候，生产率无疑的会有所下降，而生产率可以下降到什么程度，也成为流程尺度判断的又一重根据。

用数据说话的是与非

一旦需要判断尺度时，很多人可能会想到用数据说话。

数据无疑是有用的，没有数据许多事情（如进度，收益等）都将变成黑箱状态。

但恰恰是在判断尺度时，数据并没有想的那么有用，它只是提供了一个支点，最终还是需要人来做判断。

必须做判断的根本原因是：待解决问题往往在时间和空间上是连续的，而数据大多时候只是一个截面。这个时候更需要的是先形成对连续问题的整体构图，根据其中的不清晰点有意采集数据，再使用数据。如果只是拼凑数据，那是不太可能形成整体构图的。