“把书读薄”——刻当年高考时班主任老师曾经这样教诲过我。当时还不能完全理解这句话的内涵。现在想来，对于一种知识体系，当你对其达到融会贯通的境界之时，你就能做到这一点。
一些组织在编写软件工程体系时，有时候会将自己的体系和别人家的作一番比较：XX单位的CMMI三级体系，全部加起来也只有我们体系的一半厚。我们的体系太过“重量级”，人家的是“轻量级”。
这里的“量级”并没有一个准确的定义，它是一个比喻。“轻”和“重”是相对而言，并没有一个数值范围来衡量何为“轻”，何为“重”。像前面所说的“重量级”体系，可是是厚厚的一摞，“轻量级”体系可能是薄薄的几本。
这个词用于形容软件流程，也是一样。按照软件流程的定义：
一个软件流程是达到预定目标所需执行的活动和行为的总和。
所以软件流程的轻量级与重量级比较起来，流程要执行的活动数少一些。
随之而来的一个问题是，软件流程是轻量级好还是重量级好？
这里要借用一下敏捷开发的思想。在敏捷开发宣言中，这样描述：
个体和交互胜过流程和工具，可用的软件胜过完备的文档。
虽然不否认流程的作用，但是我们更应关注人的作用。对于流程，我们应当倡导“刚好够用”的原则。流程必须设计成轻量级的。因为重量级意味着正式的、非适应性的或官僚主义的，这就决定了站在了敏捷的对立面。
虽然我们不一定非要应用敏捷的开发方法，但是效率提升却是我们想追求的。如果能用更少的时间完成相同质量的任务目标，把节约下来的时间投入到其它的项目当中，为组织带来更大的利益，那又何乐而不为呢？
不过，轻量级的软件流程不是那么容易来的。如同“把书读薄”，需要对软件工程、组织的实际情况“融会贯通”才能做得到。
要获得轻量级的软件流程，必定要经历一个由厚到薄的过程。重量级的软件流程，要执行的活动较多，软件的质量更能得到保证。只有在质量得到保证的前提下，才能去谈效率问题。软件流程不可能也不应该一开始就是轻量级的，因为你不经历“厚”的过程，不经历这样的积累过程，难以保证软件的质量。
不会走，就学跑，一定会栽跟斗！
软件流程的量级问题也体现了价值导向。重量级流程似乎更能体现流程自身的价值，而轻量级流程来更能体现人的价值。
总之，只有在软件质量得到保证的前提下，要追求开发效率的提升，通过不断优化，使自己的软件流程逐步由重量级转变为轻量级。
参考书目：《软件开发之韵》
微信赞赏专用通道
联系客服
