作坊离工厂究竟有多远

　　1. 作坊与工厂

　　所谓作坊式的开发方法是指完全的依赖于开发者的经验和喜好进行的软件开发。在一个组织里，一个软件和另外一个软件的开发过程可能完全不同，这种不同并不是建立在对具体项目仔细分析的基础上，而是建立在管理者或开发者的个人兴趣上，软件过程完全没有计划，没有阶段性目标，没有进程表，没有风险评测预警机制，没有…，也许有，但形同虚设，做到哪里算哪里。每个项目完成后，得到的只是一个软件产品，没有其他，没有总结，没有过程改进，没有源码管理，没有……。这种天马行空式的开发方式最容易实施，但什么时候完成，能否达到目标，质量能不能保证是完全无法预测和控制的。遗憾的是，中国的软件公司大多如此开发软件，即使有个别实行了软件工程管理，还通过了鉴定，但大多是得其形而未得其神。 理想的工厂式(工程式的)是指开发过程是有计划有章法的进行，整个开发过程是围绕一个基本目标—需求产开。一般分为几个大的phases,首先是需求获取和分析过程，然后是目标，资源以及其他约束条件的综合分析计划过程，包括选取合适的软件工程方法，设计合理的软件过程，然后是实施，最后是用户评价与验收或发布。每个phase内应用若干方法手段以提高效率。每个项目做完之后进行仔细的总结，吸取成功和失败的经验，对项目中采用的软件过程、以及具体的分析、设计、编码、管理、文档等过程中使用过的方法手段进行改进，以方便其他类似项目提高效率。同时，对源码，尤其对可重用的源码也进行有效的管理。这是一个不断重复的过程，随着组织的日积月累，(就像微软的发展历程)，软件过程知识的不断改进和积累，以及源码的不断积累，这将是一笔最宝贵的财富，在这样的“财富”基础上开发，软件开发也就会变得越来越快，是之谓“软件自生长过程”。实施这种开发方式的难点在于人才，必须各个关键岗位人员合格，在其位而不能谋其事，该位置设和没设没有区别，甚至会起反作用，这些岗位包括管理职位。“用人得其位”我相信这也是管理以人为本的本意。这种开发方式除了带来上述的长期利益外，在具体项目上，也可使开发过程变得可以控制，管理者可以预期项目的周期，质量和风险。这种生产方式也并不阻碍个人天才的发挥。另外由于软件过程是针对具体项目而设计，所以这种开发方式也并不一定会造成开发周期的加长。 从上述粗略的描述可以看出，作坊与工厂的距离主要由人才的多少来决定，有什么样的人才，决定了一个组织中的软件工程能实施到什么地步，其中必须具备的是必须有一个软件工程专家，因为很多实施操作中的琐事咨询公司并不能全部都作。

　　2. “用人得其位”与“用人用其力”

　　“用人得其位”是实施工厂式管理的先决条件。如果你没有合适的需求分析人员，那就不要试图使用需求工程里比较复杂的东东，因为那样只会给他增加负担，使他捡了芝麻丢了西瓜。如果你没有合格的分析设计人员，就不要试图使用UML和设计模式，使用的结果很可能是既浪费了时间，又过度设计。最后全体人员把主要的精力都用来学了UML，等到编码时才发现，每天的文档画图造句评审已耗尽了大家对项目的热情。如果你的软件工程专家是一个教条主义者，那完了，你最好小心使用他，否则你的项目一定会被“过度工程”。因此，实施工厂化开发的要点在于立足实际进行规划，有什么样的人才，有什么样的实力，这里的实力不单指编程实力，就设计什么样的软件过程，实行什么程度的工程化管理。

　　我们说，“用人得其位”是软件工程的基础，而“用人用其力”则是软件工程的目标(之一)。什么是“用人用其力”呢?就是使用每个人最专长的能力。每个人都有其与他人的比较成本，如果同一个组有另外一个人做需求和你一样牛，但他编程比你差很多，那么你一定是编程的命，而每天飞来飞去和用户聊天的一定是你的同事，这就是比较成本(但这一点实际执行有很多困难，实际执行时无法达到最优化配置)。软件工程的主要目标是使项目按时按质按预算完成，但怎么样才能达到呢?“曲成万物而不遗”，你需要先使每个人都能用其所长。

　　软件工程的选择也与公司的文化有关，如果公司(包括项目组内)是一个对立冲突的文化氛围，那么评审你就要小心一些了，最好不要公开评审，而改为一对一的私下讨论。

　　3. 持续的过程改进

　　软件工程一方面的目标是生产合格的软件产品，另外一个目标则是生产软件工程产品。软件工程也是一种产品，他的形式便是“过程模式”、文档模型、和重用代码库。后面两个容易理解，关键是过程模式，什么是过程模式呢?每一种软件过程都有其适用的范围和条件，而且也和不同公司的特殊性相关，可以由每个公司在实践过程中不断优化改进，形成公司的知识资产，这也是CMM能够实行的基础。每次开发新项目，首先要做的就是对目标和约束进行综合分析，然后从过程模式库中选取适合不同阶段的模式，进行一些修改，组成适合本项目的软件过程，选择的时候也不用考虑这个子过程或者这个想法是不是属于这种过程模型，只要好用，拿来就用，你要考虑的只是怎么和其他选择配合起来使用。大的方面，你是用增量还是演进，用XP还是净室(当然，如果你没有足够的足够牛的人和时间就不要使用它，呵呵)。小的方面来说你要不要完整的风险预警机制，要不要设计评审，等等。每个项目作完后进行总结，总结结果包括对模式的验证确认和改进建议，形成文档入库。这是一个不断重复积累的过程。当然，如果你的公司只是小公司而且也非常满足作一个小公司，那么我建议不用这么麻烦，就选定一种开发模式把它用熟用精用出丰富的不能再丰富的经验来，每个项目都用他就行了。反正小公司大多是专业公司，只做一类产品，人员也比较少，一般也都会有一两个牛人，比如XP我看就可以，又快又能控制风险，用户也满意，因为你是透明的：)，改造一下用到你们公司去，用完再改进一下，再用，再改进。这样也可以形成公司的资产。

原文转自：http://www.ltesting.net