作坊离工厂究竟有多远(1、2)

《作坊离工厂究竟有多远(1、2)》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

作坊离工厂究竟有多远(一）smilemac1.作坊与工厂所谓作坊式的开发方法是指完全的依赖于开发者的经验和喜好进行的软件开发。在一个组织里，一个软件和另外一个软件的开发过程可能完全不同，这种不同并不是建立在对具体项目仔细分析的基础上，而是建立在管理者或开发者的个人兴趣上，软件过程完全没有计划，没有阶段性目标，没有进程表，没有风险评测预警机制，没有…，也许有，但形同虚设，做到哪里算哪里。每个项目完成后，得到的只是一个软件产品，没有其他，没有总结，没有过程改进，没有源码管理，没有……。这种天马行空式的开发方式最容易实施，但什么时候完成，能否达到目标，质量能不能保证是完全无法预测和控制的。遗憾的是，中国的软件公司大多如此开发软件，即使有个别实行了软件工程管理，还通过了鉴定，但大多是得其形而未得其神。理想的工厂式（工程式的）是指开发过程是有计划有章法的进行，整个开发过程是围绕一个基本目标—需求产开。一般分为几个大的phases,首先是需求获取和分析过程，然后是目标，资源以及其他约束条件的综合分析计划过程，包括选取合适的软件工程方法，设计合理的软件过程，然后是实施，最后是用户评价与验收或发布。每个phase内应用若干方法手段以提高效率。每个项目做完之后进行仔细的总结，吸取成功和失败的经验，对项目中采用的软件过程、以及具体的分析、设计、编码、管理、文档等过程中使用过的方法手段进行改进，以方便其他类似项目提高效率。同时，对源码，尤其对可重用的源码也进行有效的管理。这是一个不断重复的过程，随着组织的日积月累，（就像微软的发展历程），软件过程知识的不断改进和积累，以及源码的不断积累，这将是一笔最宝贵的财富，在这样的“财富”基础上开发，软件开发也就会变得越来越快，是之谓“软件自生长过程”。实施这种开发方式的难点在于人才，必须各个关键岗位人员合格，在其位而不能谋其事，该位置设和没设没有区别，甚至会起反作用，这些岗位包括管理职位。“用人得其位”我相信这也是管理以人为本的本意。这种开发方式除了带来上述的长期利益外，在具体项目上，也可使开发过程变得可以控制，管理者可以预期项目的周期，质量和风险。这种生产方式也并不阻碍个人天才的发挥。另外由于软件过程是针对具体项目而设计，所以这种开发方式也并不一定会造成开发周期的加长。从上述粗略的描述可以看出，作坊与工厂的距离主要由人才的多少来决定，有什么样的人才，决定了一个组织中的软件工程能实施到什么地步，其中必须具备的是必须有一个软件工程专家，因为很多实施操作中的琐事咨询公司并不能全部都作。 2.“用人得其位”与“用人用其力”“用人得其位”是实施工厂式管理的先决条件。如果你没有合适的需求分析人员，那就不要试图使用需求工程里比较复杂的东东，因为那样只会给他增加负担，使他捡了芝麻丢了西瓜。如果你没有合格的分析设计人员，就不要试图使用UML和设计模式，使用的结果很可能是既浪费了时间，又过度设计。最后全体人员把主要的精力都用来学了UML，等到编码时才发现，每天的文档画图造句评审已耗尽了大家对项目的热情。如果你的软件工程专家是一个教条主义者，那完了，你最好小心使用他，否则你的项目一定会被“过度工程”。因此，实施工厂化开发的要点在于立足实际进行规划，有什么样的人才，有什么样的实力，这里的实力不单指编程实力，就设计什么样的软件过程，实行什么程度的工程化管理。我们说，“用人得其位”是软件工程的基础，而“用人用其力”则是软件工程的目标（之一）。什么是“用人用其力”呢？就是使用每个人最专长的能力。每个人都有其与他人的比较成本，如果同一个组有另外一个人做需求和你一样牛，但他编程比你差很多，那么你一定是编程的命，而每天飞来飞去和用户聊天的一定是你的同事，这就是比较成本（但这一点实际执行有很多困难，实际执行时无法达到最优化配置）。软件工程的主要目标是使项目按时按质按预算完成，但怎么样才能达到呢？“曲成万物而不遗”，你需要先使每个人都能用其所长。软件工程的选择也与公司的文化有关，如果公司（包括项目组内）是一个对立冲突的文化氛围，那么评审你就要小心一些了，最好不要公开评审，而改为一对一的私下讨论。3.持续的过程改进 软件工程一方面的目标是生产合格的软件产品，另外一个目标则是生产软件工程产品。软件工程也是一种产品，他的形式便是“过程模式”、文档模型、和重用代码库。后面两个容易理解，关键是过程模式，什么是过程模式呢？每一种软件过程都有其适用的范围和条件，而且也和不同公司的特殊性相关，可以由每个公司在实践过程中不断优化改进，形成公司的知识资产，这也是CMM能够实行的基础。每次开发新项目，首先要做的就是对目标和约束进行综合分析，然后从过程模式库中选取适合不同阶段的模式，进行一些修改，组成适合本项目的软件过程，选择的时候也不用考虑这个子过程或者这个想法是不是属于这种过程模型，只要好用，拿来就用，你要考虑的只是怎么和其他选择配合起来使用。大的方面，你是用增量还是演进，用XP还是净室（当然，如果你没有足够的足够牛的人和时间就不要使用它，呵呵）。小的方面来说你要不要完整的风险预警机制，要不要设计评审，等等。每个项目作完后进行总结，总结结果包括对模式的验证确认和改进建议，形成文档入库。这是一个不断重复积累的过程。当然，如果你的公司只是小公司而且也非常满足作一个小公司，那么我建议不用这么麻烦，就选定一种开发模式把它用熟用精用出丰富的不能再丰富的经验来，每个项目都用他就行了。反正小公司大多是专业公司，只做一类产品，人员也比较少，一般也都会有一两个牛人，比如XP我看就可以，又快又能控制风险，用户也满意，因为你是透明的：），改造一下用到你们公司去，用完再改进一下，再用，再改进。这样也可以形成公司的资产。作坊与工厂距离多远，你只要设想一下你公司最理想的工厂式开发是什么样子，然后看看到那时需要哪些人才，什么样的公司文化，多大规模的软件工程库，再看看你现在的情况，你就知道有多远了。4.过度工程的危害那么什么是过度工程呢？如果你的项目从现在开始编码一个星期内就可以完成，那么需不需要风险预警呢？一般是不需要的，因为项目周期越短，建立风险预警制度的代价就越高，这里的代价是指该项活动在这个项目周期中所占的时间比例。当警报出现时，已经半个星期过去了，但对于很多教条主义者来说，风险预警是必须的。而对于我来说，这就是过度过程，在一个项目中，做了这个项目完全不需要的工作。再比如，使用RUP，每当我看到有人诚惶诚恐地按照RUP的步骤一个图一个图地画下来，我总觉得很可笑，他可能不知道，当他刚画完实体图的时候，其他工程师已经完全领会他的设计了，我不知道如果我用汉语表达完我的意思后，是否还需要再用英语表达一遍，对于很多经验丰富的程序员来说，有了实体图，最多再加一个状态转换图已经足够开始编程了。而且，使用图形和文档表达出的类的接口设计和关系是否比直接用程序表达出的更容易读，我看未必。XP的创始者说：为什么要写文档呢？代码就是最好的文档。从一定程度上，我非常赞同这样的观点。现代软件工程发展的趋势之一，便是越来越承认现实，承认人类的有限理性。项目的主要目标是什么，是按时按质按预算地完成软件产品，所有的活动都应该围绕这个目标进行。所以，如果你以前已经做过很多类似的项目，你知道在这样的时间、资源约束下，要想完成目标必须采用什么样的开发过程，那么你是不是还需要引经据典地写报告证明你的想法，等待另一个并不比你经验更丰富的人花上一个星期来为你做评审，本来一个小时就可以做出的决定因为流程教条主义者的约束，连写报告你需要花上两个星期。还有评审活动，做评审的往往是一些不在你项目组织中的所谓技术权威，他们也许在技术上是权威，但对你的项目却一无所知，如何评审？走过场而已，但却为以后的责任推诿留下后门。一个活动是否应该保留或应该如何进行，要完全以是否有利于项目目标为准则。但遗憾的是，别看国内项目大多整体缺乏工程规划，但这种局部活动的过度工程却比比皆是。 那么过度工程有害吗？有害！软件工程书上讲了很多如何控制风险的工程化方法，却没有讲如何保持程序员的创造热情和工作激情。软件开发讲千讲万，离不开程序员的创造性活动，你可听说过哪个优秀的软件不是靠一些程序员主动加班加点的超常劳动作出来的？一个团队中，最重要的永远都是程序员的热情，这也是一切工程化方法需要注意的，也是所有项目管理艺术的主题之一。因此，软件工程的实践程度对于项目来说够用即可。那么多少算够用呢？这要考虑项目可以承受多大的失败风险。也就是说对风险的控制做到什么样的程度。对于你的项目，你是准备跑还是走？如果跑，打算跑得多快？我认为，所有的软件开发，所有的项目管理，与其谨小慎微战战兢兢地向前挪动，远不如在可控的奔跑中把握平衡，那样会更容易一些。大多数的软件工程方法，都是为了提前知道哪些以前担心发生的事情真的发生了，但天下没有免费的午餐，任何东西都有代价，为了这个“提前知道”，我们需要付出的是可能的过度工程以及其带来的副作用。因此风险控制也不能无限制，需要权衡。还有很多工程方法，比如说文档是为了交流，但是如果一个项目组中只有你和测试工程师，还需要使用“BUG报告->修改意见->评审->反测报告”的方法确认吗？遗憾的是，这样的例子在国内的一些软件公司，甚至是外企，在真实地发生着。而很多程序员认为软件工程太虚也恰恰是因为这个。软件工程书上讲了很多方法，但没有让你每个环节不分重点地执行啊！你可以把它当做教科书，可以把它当做技术词典，但就是不能把它当做操作手册！现在的RUP应用就有这种趋势，为RUP而RUP，为“规范”而“规范”。什么都全了，唯一没有的却是目标。5.“流水线”的误区传统的大规模工业化生产是采用按既定的流程流水线的制造产品。最初的软件工程的理想大概也是向此方向靠拢。但问题是，软件能否按照流水线方式大规模的生产？如果你认为长城不能被批量制造，金字塔不能被大规模生产，那么软件也不能被流水线开发。对于软件开发来说，任何两个项目都不会完全相同，不完全相同的功能集，不完全相同的非功能性目标，不同的时间资源约束，不同的公司文化，不同的用户，新的技术，新的开发工具等等，所有这些都为软件开发制造了不确定性。为什么软件开发要以项目的方式进行，因为项目这种工作方式恰好就是专为那些具有唯一性和不确定性的工作所设立。 但现在很多软件组织的开发方式却是挂“项目”之羊头，卖“流水线”之狗肉。以为流程重于一切，以为只要按照RUP或其他类似的过程一步一步走下来，就一定会得到一个合格的产品。不错，如果仅以产品的功能来衡量，确实从统计意义上说会的，但别忘了，项目目标的是一个三维向量—质量，时间，预算。（后面的章节中会陆续谈到质量之于软件的重要性和开发速度之于软件的重要性，相比之下，因为软件产品边际收益的不确定性，预算反而有可能成为最不重要的一环。）。如果从统计意义上说，完全按照RUP或其他类似的软件工程方法亦步亦趋地做下来，进度表一定会失控的。为什么呢？从根本上说，项目管理实际上是风险管理，项目管理的过程基本上是基于风险控制表进行的。而对于软件开发来说，大部分的风险警报只有在编码和测试的时候才会出现。也就是说，编码开始的时间越晚，风险警报出现的时间也就越晚。而风险警报出现的晚意味着什么呢？意味着你在设计阶段做的无用功多，意味着你浪费的时间多，意味着你的项目延期多。所以这可能就是XP为什么一出现就受到热烈的讨论，为什么会有增量开发，演进开发等这些尽量提前编码开始时间的方法的原因。人类的有限理性是什么？就是人们本来知道吸烟有害健康，但还是要去吸烟。对于程序员来说，没有什么比早早地看到程序运行的结果更重要的了，也没有什么比得到同行的一两句赞扬更重要的了，尽管他知道这些赞扬既不会为他带来加薪，也不会为他带来女朋友，但他还是会为此去熬一俩个通宵把程序尽早做出来。对他们来说，用UML,VISIO每天拿着鼠标在纸上谈兵远没有直接用程序把自己的想法表达出来更有意思。这就是程序员的激情，这也是软件项目赖以成功的根本保证。将设计与编码截然分开，既愚蠢又可笑，更有甚者，将设计人员与编码人员也截然分开，由两组人去做。而这却是现在中国软件业新唐僧们从西天印度取经的结果，软件蓝领，一个有意思的词。记得有一次我和一位从事市场工作的同事谈起了“知识工人”时，他说，对，其实知识工作者也是工人。唉，大势如此，夫复何言。我不了解印度，不敢对印度说三道四，但我直觉地认为，中国软件行业的特点更像美国：有强大的内销市场，软件种类多，覆盖面大，小公司繁荣，新生类软件多等。这样的情况下，每一个软件的开发过程实际都是一个研究探索学习的过程，而在这样的过程中，设计人员只在大脑中想象自己的设计怎么样怎么样运行，我不能设想这样是否可行。工厂与作坊的区别在哪里，不是指工厂有严格的分工，由明确的流程，而是指工厂能针对目标定制合理的软件过程，并在一次又一次的项目实践中改进它，积累它。不仅仅改进这个软件过程，而更重要的是改进选择合适软件工程的定制方法。在更高一级的抽象中重复，在更高一级的抽象中实现流程。                                                                               <节一完> 作坊离工厂究竟有多远(二）smilemac1.   软件大规模定制在这个市场越来越起主导作用，定制的产品广受欢迎的时代，软件是否也可以做到大规模定制呢？首先看什么是软件的大规模定制。规模与产品的开发速度有关，如果一个定制的软件能够在一个月内交付，如果定制软件的交付数量可以与程序员数目成正比，我们可以将这种开发模式叫做大规模定制，如果这种结果能够出现，那一切将是多么美好！但这种开发模式可行吗？大家还记得那句著名的话吗：给再多的女人，生一个孩子也需要9个月。那么，这个答案应该是否定的。但是我们如果将软件生命周期用显微镜观看，也许会发现，我们不能够提高第一个版本的交付速度，但我们也许有可能提高第二个，第三个版本的交付速度。我们先看看软件的生命周期曲线：图中②表明的是这样一个事实，任何体系结构均有一个扩展的上限，一旦达到这个上限，软件将变得难以重构，这时必须重新开发新的体系结构，有时这种开发可能会完全codingfromscratch. 而基于每个体系结构的重构周期取决于该体系结构的设计是否有比较强的灵活性以及包容性。这也说明了体系结构设计的重要性。然而，需要注意的是，体系结构并非只有一层，一个软件的功能事实上可以划分出若干闭包，也就是说，不同功能之间的关系并非杂乱无章或随意组合的，如果去研究它，你会发现有一些功能是相关的，另外一些功能也是相关的，而不同组功能之间相关程度则弱一些，通过对其分解，可以得到若干个闭合的子空间，而对每个子空间作正交分解，可以得到若干稳定灵活的子框架。这说明了什么呢？说明即使每一次小规模重构定制版本，在定制开发新功能的时候，也可以丰富整个体系结构，为后面的重构活动修桥铺路，这是即使小的重构活动也可以产生的边际效益。这样的生命周期，也体现了软件的这一商品的盈利方式，即高沉没成本，低边际成本。第一个版本，或重新开发体系结构的成本很高，但每一次小的重构则成本很低，但条件是什么呢，就是重构必须快。如果软件开发不以这样一种盈利方式来进行，则即便能存活一年半载，也可能难以为继，所以，如果你不能实现大规模定制，那就最好只作产品，而不要定制。如果我们能真正实现上面一种软件生命周期，那么软件大规模定制则并非空想。但是这里依旧有一个组织架构问题需要解决，这正是下面要阐述的内容。2.         非对称双螺旋组织架构在现实世界中，定制软件的开发组织往往是针对每一次定制需求成立一个项目组的方式来应对，这是一种单层的结构，其缺点是显而易见的，项目组既是负责产品未来发展的唯一组织，也是直接应对当前客户，需要对当前客户负责的组织，这二者之间是有矛盾的。尤其当不同用户的要求有极大差异甚至截然相反的时候，项目组在疲于奔命，产品也在摇摆不定，这样每次的重构周期和产品质量都将是无法预测也无法管理的。那么如何解决这样的一个矛盾呢？效率来源于分工，定制开发与长线规划是价值取向完全不同的活动，理应交给不同的人去做。我们再增加一层组织，叫做产品组，她专门作长期的产品规划和开发，但她又不是闭门造车，而是与项目组构成一种类似双螺旋结构的互动关系，但这种双螺旋是非对称的。 项目组在产品组开发的基础上为用户定制开发，而产品组的工作包括：1）将项目组作的有较好应用前景或对基础架构有较好加强作用的代码集成到基础架构中；2）基于来自项目组的反馈，预测未来可能有用的功能，基于此预测作日常的常规开发；3）或对来自项目组的预研要求提供支持。这样，产品的方向及保证是来源于市场，也可保证以相对稳定的方式发展。只是这个产品并非最终产品，而是最终交付给用户的定制产品的开发基础。而最大的好处在于她最大限度的保证了一个稳定的可预测的产品质量。软件到底什么最重要？当前版本最重要，那么是否就不考虑未来了呢，也不能，那么就都去做吧。其实这也是很多公司管理层与程序员之间的分歧，每个程序员都希望自己的代码漂亮，而漂亮的标准是什么呢？是耦合度低，可重用，可扩展性强，但很少程序员认为，漂亮的标准是可靠稳定。学校在培养程序员的时候也并没有告诉，当前版本的质量才是第一位！<节二完>