项目管理师职业资格认证考试备考辅导作坊离工厂究竟有多远

作坊离工厂究竟有多远第一节1. 作坊与工厂 所谓作坊式的开发方法是指完全的依赖于开发者的经验和喜好进行的软件开发。在一个组织里，一个软件和另外一个软件的开发过程可能完全不同，这种不同并不是建立在对具体项目仔细分析的基础上，而是建立在管理者或开发者的个人兴趣上，软件过程完全没有计划，没有阶段性目标，没有进程表，没有风险评测预警机制，没有，也许有，但形同虚设，做到哪里算哪里。每个项目完成后，得到的只是一个软件产品，没有其他，没有总结，没有过程改进，没有源码管理，没有。这种天马行空式的开发方式最容易实施，但什么时候完成，能否达到目标，质量能不能保证是完全无法预测和控制的。遗憾的是，中国的软件公司大多如此开发软件，即使有个别实行了软件工程管理，还通过了鉴定，但大多是得其形而未得其神。 理想的工厂式（工程式的）是指开发过程是有计划有章法的进行，整个开发过程是围绕一个基本目标需求产开。一般分为几个大的phases,首先是需求获取和分析过程，然后是目标，资源以及其他约束条件的综合分析计划过程，包括选取合适的软件工程方法，设计合理的软件过程，然后是实施，最后是用户评价与验收或发布。每个phase内应用若干方法手段以提高效率。每个项目做完之后进行仔细的总结，吸取成功和失败的经验，对项目中采用的软件过程、以及具体的分析、设计、编码、管理、文档等过程中使用过的方法手段进行改进，以方便其他类似项目提高效率。同时，对源码，尤其对可重用的源码也进行有效的管理。这是一个不断重复的过程，随着组织的日积月累，（就像微软的发展历程），软件过程知识的不断改进和积累，以及源码的不断积累，这将是一笔最宝贵的财富，在这样的“财富”基础上开发，软件开发也就会变得越来越快，是之谓“软件自生长过程”。实施这种开发方式的难点在于人才，必须各个关键岗位人员合格，在其位而不能谋其事，该位置设和没设没有区别，甚至会起反作用，这些岗位包括管理职位。“用人得其位”我相信这也是管理以人为本的本意。这种开发方式除了带来上述的长期利益外，在具体项目上，也可使开发过程变得可以控制，管理者可以预期项目的周期，质量和风险。这种生产方式也并不阻碍个人天才的发挥。另外由于软件过程是针对具体项目而设计，所以这种开发方式也并不一定会造成开发周期的加长。 从上述粗略的描述可以看出，作坊与工厂的距离主要由人才的多少来决定，有什么样的人才，决定了一个组织中的软件工程能实施到什么地步，其中必须具备的是必须有一个软件工程专家，因为很多实施操作中的琐事咨询公司并不能全部都作。2. “用人得其位”与“用人用其力”“用人得其位”是实施工厂式管理的先决条件。如果你没有合适的需求分析人员，那就不要试图使用需求工程里比较复杂的东东，因为那样只会给他增加负担，使他捡了芝麻丢了西瓜。如果你没有合格的分析设计人员，就不要试图使用UML和设计模式，使用的结果很可能是既浪费了时间，又过度设计。最后全体人员把主要的精力都用来学了UML，等到编码时才发现，每天的文档画图造句评审已耗尽了大家对项目的热情。如果你的软件工程专家是一个教条主义者，那完了，你小心使用他，否则你的项目一定会被“过度工程”。因此，实施工厂化开发的要点在于立足实际进行规划，有什么样的人才，有什么样的实力，这里的实力不单指编程实力，就设计什么样的软件过程，实行什么程度的工程化管理。我们说，“用人得其位”是软件工程的基础，而“用人用其力”则是软件工程的目标（之一）。什么是“用人用其力”呢？就是使用每个人最专长的能力。每个人都有其与他人的比较成本，如果同一个组有另外一个人做需求和你一样牛，但他编程比你差很多，那么你一定是编程的命，而每天飞来飞去和用户聊天的一定是你的同事，这就是比较成本（但这一点实际执行有很多困难，实际执行时无法达到化配置）。软件工程的主要目标是使项目按时按质按预算完成，但怎么样才能达到呢？“曲成万物而不遗”，你需要先使每个人都能用其所长。软件工程的选择也与公司的文化有关，如果公司（包括项目组内）是一个对立冲突的文化氛围，那么评审你就要小心一些了，不要公开评审，而改为一对一的私下讨论。3. 持续的过程改进软件工程一方面的目标是生产合格的软件产品，另外一个目标则是生产软件工程产品。软件工程也是一种产品，他的形式便是“过程模式”、文档模型、和重用代码库。后面两个容易理解，关键是过程模式，什么是过程模式呢？每一种软件过程都有其适用的范围和条件，而且也和不同公司的特殊性相关，可以由每个公司在实践过程中不断优化改进，形成公司的知识资产，这也是CMM能够实行的基础。每次开发新项目，首先要做的就是对目标和约束进行综合分析，然后从过程模式库中选取适合不同阶段的模式，进行一些修改，组成适合本项目的软件过程，选择的时候也不用考虑这个子过程或者这个想法是不是属于这种过程模型，只要好用，拿来就用，你要考虑的只是怎么和其他选择配合起来使用。大的方面，你是用增量还是演进，用XP还是净室（当然，如果你没有足够的足够牛的人和时间就不要使用它，呵呵）。小的方面来说你要不要完整的风险预警机制，要不要设计评审，等等。每个项目作完后进行总结，总结结果包括对模式的验证确认和改进建议，形成文档入库。这是一个不断重复积累的过程。当然，如果你的公司只是小公司而且也非常满足作一个小公司，那么我建议不用这么麻烦，就选定一种开发模式把它用熟用精用出丰富的不能再丰富的经验来，每个项目都用他就行了。反正小公司大多是专业公司，只做一类产品，人员也比较少，一般也都会有一两个牛人，比如XP我看就可以，又快又能控制风险，用户也满意，因为你是透明的：），改造一下用到你们公司去，用完再改进一下，再用，再改进。这样也可以形成公司的资产。作坊与工厂距离多远，你只要设想一下你公司最理想的工厂式开发是什么样子，然后看看到那时需要哪些人才，什么样的公司文化，多大规模的软件工程库，再看看你现在的情况，你就知道有多远了。4. 过度工程的危害那么什么是过度工程呢？如果你的项目从现在开始编码一个星期内就可以完成，那么需不需要风险预警呢？一般是不需要的，因为项目周期越短，建立风险预警制度的代价就越高，这里的代价是指该项活动在这个项目周期中所占的时间比例。当警报出现时，已经半个星期过去了，但对于很多教条主义者来说，风险预警是必须的。而对于我来说，这就是过度过程，在一个项目中，做了这个项目完全不需要的工作。 再比如，使用RUP，每当我看到有人诚惶诚恐地按照RUP的步骤一个图一个图地画下来，我总觉得很可笑，他可能不知道，当他刚画完实体图的时候，其他工程师已经完全领会他的设计了，我不知道如果我用汉语表达完我的意思后，是否还需要再用英语表达一遍，对于很多经验丰富的程序员来说，有了实体图，最多再加一个状态转换图已经足够开始编程了。而且，使用图形和文档表达出的类的接口设计和关系是否比直接用程序表达出的更容易读，我看未必。XP的说：为什么要写文档呢？代码就是的文档。从一定程度上，我非常赞同这样的观点。现代软件工程发展的趋势之一，便是越来越承认现实，承认人类的有限理性。项目的主要目标是什么，是按时按质按预算地完成软件产品，所有的活动都应该围绕这个目标进行。所以，如果你以前已经做过很多类似的项目，你知道在这样的时间、资源约束下，要想完成目标必须采用什么样的开发过程，那么你是不是还需要引经据典地写报告证明你的想法，等待另一个并不比你经验更丰富的人花上一个星期来为你做评审，本来一个小时就可以做出的决定因为流程教条主义者的约束，连写报告你需要花上两个星期。还有评审活动，做评审的往往是一些不在你项目组织中的所谓技术，他们也许在技术上是，但对你的项目却一无所知，如何评审？走过场而已，但却为以后的责任推诿留下后门。一个活动是否应该保留或应该如何进行，要完全以是否有利于项目目标为准则。但遗憾的是，别看国内项目大多整体缺乏工程规划，但这种局部活动的过度工程却比比皆是。 那么过度工程有害吗？有害！软件工程书上讲了很多如何控制风险的工程化方法，却没有讲如何保持程序员的创造热情和工作激情。软件开发讲千讲万，离不开程序员的创造性活动，你可听说过哪个优秀的软件不是靠一些程序员主动加班加点的超常劳动作出来的？一个团队中，最重要的永远都是程序员的热情，这也是一切工程化方法需要注意的，也是所有项目管理艺术的主题之一。 因此，软件工程的实践程度对于项目来说够用即可。那么多少算够用呢？这要考虑项目可以承受多大的失败风险。也就是说对风险的控制做到什么样的程度。对于你的项目，你是准备跑还是走？如果跑，打算跑得多快？我认为，所有的软件开发，所有的项目管理，与其谨小慎微战战兢兢地向前挪动，远不如在可控的奔跑中把握平衡，那样会更容易一些。 大多数的软件工程方法，都是为了提前知道哪些以前担心发生的事情真的发生了，但天下没有免费的午餐，任何东西都有代价，为了这个“提前知道”，我们需要付出的是可能的过度工程以及其带来的副作用。因此风险控制也不能无限制，需要权衡。还有很多工程方法，比如说文档是为了交流，但是如果一个项目组中只有你和测试工程师，还需要使用“BUG