《大道至简》读书笔记

大道至简--软件工程实践者的思想(周爱民 著)

注:作者那么轻视工具和语言,估计和他所处的角色有关,从标题软件工程实践者的思想可以看出,他讨论的核心是软件工程

 

序二

......

因此我必须阅读大量的技术书籍,每天在Internet上不断地补充新知,以应付工作上的需要。长期的积累,虽然让我学习了许多技术,但是真正让我不断超越昨日自我的因素,并不是这些单点的技术,而是多参考业界大师级人物的思想,以及更实际地看看我们同X(单人旁加个齐)的思考,更重要的是,不时地停下来进行融合思考的结果。以前我非常享受在工作时与李匡正先生、苏国钧先生以及我的其他好友共同讨论的时光,盖因在这些好友的谈话和思考中,蕴藏了他们丰富的知识和智慧的精华,让我受益良多。

 

注:

大量的技术书籍,我估计没做到,我学的都是基础的,谈不上什么技术;

参考大师级人物的思想,好像也谈不上;

停下来进行融合思考,我思考过,但谈不上有什么感悟。现在我就停下来,不再看太多新的书,先复习以前的,思考思考!

 

前言

......

做了许多年的开发,其实很多的人并不知道“自己在做什么”。

注:

我自己在做什么呢,业务没多少长进,对行业测试工具行业、软件行业都没有什么了解;技术也没多大进步,整天都是在架构、多线程、C++语言上纠缠。以后再去找工作的时候,我能有什么定位,有什么亮点呢?

 

......

所以你需要认识“为什么做”。

这其实并不困难。例如我在工程中经常问的问题是“可不可以不做”--哈哈,看起来我很偷懒似的。其实不然,因为接下来我就会从不同的人那里得到“非做不可”的种种理由。

注:“可不可以不做”这个问题我倒经常在问自己,看起来我也很懒。我还是比较赞同这个观点的,在做什么事之前都问问这件事是不是我必须得做,如果不必我何必浪费精力呢?!!!

现在的项目(SIP+RTP),我就做了不少可以不做的东西,心里很不爽,要是我是组长肯定不会做,这些细节根本没有什么价值,还花那么多时间去搞,吃饱了撑着!

今天在SourceForge上查看sipp资料时,发现别人什么东西都有了:图形化流程封装、从抓包到场景,图形化界面等,我们现在做的,能比别人的好吗,做出来能有什么前途吗,上半年绩效沟通的时候,向项目经理提出我们的东西和sipp相比有什么优势,他的意思也就是让我忽悠,我们能一直忽悠下去吗?!不做,那么可能就没事可做,做,又做不好,此时问可不可以不做,该怎么决策呢?

答:在后面有答案,即不管什么时候,特别是你无法控制的时候,首先必须心态积极,虽然项目没成,但是得到上司的认可也不错!

 

第一章 编程的精义

第一节 编程的精义

......

在愚公的论述中,我们看到了编程的根本:顺序、分支和循环。庞大若“愚公移山”这样的工程,都是可以通过这样简单的编程来实现的。这,就是编程的精义了。

 

第二节 能不能学会写程序的问题

......

所以除了先天智障或后天懒惰者,都是可以学会写程序的。

 

第三节 程序 = 算法 + 结构

编程作为一种行为时,我们只需要知道其逻辑方法就行可以了。所谓编程实际上就是把一件事情交给计算机去做,你认为这件事该如何做,就用“程序语言”的形式描述给计算机。如果你原本就不明白如何去做,那么你也不要期望计算机去理解你想要做什么。

在SIP+RTP中实现mark拖动时,我对这句话深有体会,在编码以前,一定要先用自然语言描述好逻辑流程,否则到后面自己都搞不清楚哪儿有问题,到处都是缺陷!

所以编程的第一要务是先把事情分析清楚,把事件的先后逻辑关系和依赖关系搞清楚,然后再去写代码实现。一接到任务就开始Coding的程序员,通常就是加班最多的程序员。

记住:积极工作和勤于思考都要占时间。

 

第四节 语言

......

任何一门语言,你都可以在两周内掌握并开始熟练编程。因为任何一门语言,它们的底层函数库都是那样地相似,它们的API都是那样地依赖于操作系统。......

成天讨论这门语言好,或者那门语言坏的人,甚至是可悲的。......

 

第五节 在没有工程的时代

在没有工程的时代,上面所说的就是一个程序员的全部。他们掌握了一门语言,懂得了一些生活中最常见的逻辑,他们用程序的方式思考和学习了一些算法,并根据前人的经验,把这些算法运行在一些数据结构之上。最后,我们就看到了他们写的程序。

......

难道我目前就处于这个阶段?呜呜

 

第二章 是懒人早就了方法

第一节 是懒人早就了方法

 

第二节 一百万行代码是可以写在一个文件里的

......

勤快的愚公创造不了方法。这我已经说过了。对于要把“一百万行代码写到一个文件里”,并且查找一个函数要在编辑器里按5000次PageUp/PageDown键的勤快人来说,是不能指望他们创造出“单元文件(Unit)”这样的开发方法来的。

要是我够懒的话,我能把性能测试自动化起来吗?感觉要是做出来了的话,一定很爽,对于以后的测试很有借鉴意义,可以思考一下。

 

第三节 你桌上的书是乱的吗

......

我当时便反问他:“你既然知道如何把书分类、规整得整整齐齐地放在书桌上,那怎么没想到如何把所学的知识分类一下,归纳一下,整整齐齐地放到脑子里呢?”

我是不是也应该将学的知识分一下类呢?我目前也是不知道自己会些什么

答:

(1)知道boost这个库,但没真正用过

(2)看过几本C++语法类书籍

(3)看过几本C++经验类书籍,比如Effective C++

(4)会用STL

(5)会用VC6.0,VS2005等集成开发环境

(6)会用MFC库、BCGControlBar做界面编程

(7)了解COM

(8)稍微了解一点Windows操作系统

(9)稍微了解一点Linux,还未在Linux开发过项目

(10)了解一些测试常识,接触过单元测试框架CPPUnit

(11)有创业的想法,但是没有一点经验

(12)了解C语言

(13)看过《Windows核心编程》,在MSDN中看过一些API的用法,会使用DLL,多线程等Windows程序设计知识

(14)会调试自己写的程序

(15)了解一点架构知识,连EA都不会用

(16)了解一点面向对象设计知识,但都没有形成经验

(17)了解一点开发方法,比如极限编程等

(18)了解一点设计模式

(19)了解一点软件工程的知识,比如CMM等

(20)了解一点数据库知识

(21)了解一点网络和协议知识,会用基本的socket编程

(22)不会汇编、Java、Python等

(23)了解一点管理,但基本没有管理经验

(24)了解正则表达式

(25)了解一些商用测试工具

(26)了解一点电信知识

(27)基本没有和同事,客户,下属,领导之间进行沟通的技巧

 

如果一个人学了一年的编程,他的脑袋里还是晕乎乎的,不知道从哪里开始,也知道如何做程序。那想来只有一个原因:他学了,也把知识学进去了,就是不知道这些知识是干什么的。或者,他不知道各种知识都可以用来做什么。

......

 

第四节 我的第一次思考:程序 = 算法 + 数据结构 + 方法

......

我第一次提到我对程序的理解是“程序 = 算法 + 数据结构 + 方法”,就是在这一次与Soul的交谈之中。......

......

而与“面向对象”是否出现完全无关的一个东西,却因为“过程”和“单元”的出现而出现了。这就是“工程(Engineering)”。

 

 

第三章 团队缺乏的不只是管理

第一节 三个人的团队

......

做管理起码要能承担责任,这是最基本的素质。

谁都害怕承担责任,我也是!我能否习惯敢于承担责任呢?能否习惯敢于承诺呢?比如将sipp用C++改写,我为什么就是不敢承诺我一定能在1个月内完成呢,要是能这样,估计能在经理面前博得一个好的印象!承诺后我估计还有可能完成,不承诺,基本上没有完成的可能性。

......

同样的道理,你的项目经理职位又没有让给别人做,你拿的经理级工资又没有分给别人,那项目失败了,你为什么要把责任推到别人头上呢?

三人团队中的那个领导,不是要程咬金一样的牛人,而是要李离一样的死士。项目完成不了,切脑袋的事倒不必做,递交辞呈的那点勇气总是要有的。

 

第二节 做项目 = 死亡游戏

......

从管理的角度看,项目失败与否与项目经理的经验直接相关。我曾经听过一个澳大利亚的讲师说软件工程。她说项目的成功是由两个方面来评估的:

项目完成质量;

项目完成时间。

由于项目的完成时间是在项目前期对项目工期的设定,因此我问这个讲师:什么方法能保证预期的工期是正确的,或者说是可以完成的。

讲师的回答很有意思:经验丰富的工程师能尽可能接近地预估工期,但没有办法保障(预估的)工期是绝对合理的。

......

项目经理的需要时间来成熟的。他需要机会来承受错误,而不是一开始就享受成功。

这稍稍对我的sip失败找到了一点逃避责任的借口,呵呵!

 

第三节 做ISO质量体系的教训

......

皮之不存,毛将焉附。没有确定的组织机构,又如何能指望做出来的管理制度“合用”呢?

 

第四节 谁动摇了你的制度

......

我们先来看看,如果员工在工作中出了纰漏,那么:

没有制度,你没有办法和依据来惩戒员工,因此是管理者的过失;

有了制度而没有惩戒他,是执行者和监督者的过失;

一而再、再而三地犯错,又一而再、再而三地被惩戒,那就是教而不改,就真正是员工的品性和素质的问题了。

.....

所以,在更加普遍的情况中,动摇了制度的人往往不是犯错的员工,而是管理者自己。如果在制度面前,既做得到“人性化”,又做得到“公平性”,那么当管理者的便可以多做几次黑脸的包龙图,而脖子上的脑袋便可以比李离顶得长久一些。

如果是在sip项目中,具体应该怎么操作才好呢?

 

第五节 “那我们就开始开发吧”

......

现在,有了会“比较快速地”编程的愚公,而且有了公司,我们完成了组织机构建设,我们还找到一名(或好多名)项目经理,他们一不怕死,二不怕苦,更为可喜的是我们还有了开发部:对内,我们订了一套规章制度;对外,我们还拿到了单子。

“那我们就开始开发吧”--你就这样跟我说。

很久以前,很久很久以前,人们都是这样做的。......

做了这么多年项目,我现在一听到这句话,就哆嗦。

 

第六节 组织的学问:角色

......

如果非要精简到两个角色的团队模式,那么在这种情况下,通常是开发经理兼任项目经理。因此这位开发经理一定要能清楚地区分这种双重角色的身份:在任何时候,明确自己是在进行“团队内协作”,还是“团队管理(和组织)”,还是在与“团队外交流”。

如果这个开发经理总是混淆自己的角色,那么,我建议,换人吧。

 

第七节 跟随蚂蚁,但不要栽进蚂蚁洞里

......

秉性难移,要改变一个人都难,何况是改变一个团队的既定习惯。

如果有一群开发人员像蚂蚁一样辛勤的工作着,那么,请先不要打扰他们。你应该跟随他们,看看他们是如何做的。发现规律,分析这个规律的价值,最后再尝试改变他们(的一些负面价值的规律)。

所以你要紧紧地跟随他们--除了一个地方。那么地方是你去不得的,那就是蚂蚁洞。

显然,你不是开发者,你是管理人员。所以尽管你也是团队中的角色,但千万记得离蚂蚁洞远点。你在洞外张望,可以发现问题;你在洞内,就只有做“循规蹈矩”的蚂蚁。

管理者是那个可以在洞外放木棍的人。

这段话是啥意思呢?

 

第八节 “什么是增值税发票?”

现在你已经足够地观察了你的团队,你知道这个团队存在问题,你也知道这必须被改变。当然,你也知道这种改变并不是放一根木棍那么简单。

.......。所以,作为项目经理,你需要先分工。

被优先考虑的是弹性分工。

蚂蚁的分工模式之一就是弹性分工。一只蚂蚁搬着食物往会走时,碰到下一只蚂蚁,会把食物交给它,自己再回头;碰到上游的蚂蚁时,将食物接过来,再交给下一只蚂蚁。

确定被“弹性分工”的员工需要可以快速地转换新的角色。但首先要考察的并不是他是否“有能力”胜任这个角色:能力可以通过学习来增强,而角色的转换,则首先是思想的转变。

1997年,......

尽管弹性分工非常有效,然而真正做弹性分工却并非易事。蚂蚁的角色转换是本能的,而P&J却不得不花两天时间来说服我。因而更应当留意团队成员“自激”式的角色转换,知道他是不是真的想(而不是需要)转变一下角色,这样起码可以省去你两天的功夫。

更好的选择是明确分工,而不是弹性分工。你应该明白,重要角色的更替通常极具风险的,例如项目经理或开发经理;频繁的开发人员的调度也会直接影响到工程的质量和进度。

如果所有人都在思考“什么是增值税发票”,那么你的组织结构将立刻溃散。

因此,明确分工是你的管理职责。做管理不等于做伯乐。

 

第四章 流于形式的沟通

第一节 客户不会用C,难道就会用UML吗

我们总是要先接触客户的。......

......

因此在前面提到的R模型中,开发人员最好不要直接面对客户。项目经理有这样的一种优势:他可以不用了解C语言,也可以用一种非C的语言来与客户交流。

或者你更愿意开发人员尽早地进入状态,那么,你可以让开发人员以需求调研的身份出现在客户面前。但是,请注意这个人员的角色将变成“需求调研”,如果他不能适应这种转变,那就别让他去--那会是灾难的开始。

......

到现在为止,你应该看到,咨询公司除了把问题搞得更加复杂之外,他们仍然需要面对最直接的问题:如何与客户交流?

他们的解决之道是建模语言。

有什么差别吗?

程序员不能要求客户会C,难道需求分析师们就能要求客户会UML吗?!

 

第二节 项目文档真的可以用甲骨文来写

......

UML图在一些客户眼里无异于盲人的世界,如果需要向他们做需求调研,你只能使用一种这些客户能够理解和接受的方式,例如表格、流程图以及......更深入的交谈。

你要确认你的沟通方式是否有效,而不是去追求这种方式是不是UML,以及你用UML是否正确。客户是因为他认为你理解了他们的需求,而在“需求确认书”上签字,而不是因为你的UML图画的是否精确。

现在来思考:为什么非要让客户看UML图呢?如果有能够满足“极限编程”所要求的“现场客户”,那当然可以不用画用例图;相反,如果客户雇佣了一些专家组来评审需求,那么你就老老实实地画用例图好了。

 

第三节 沟通的三层障碍

......

所以沟通的第一层障碍,并不在于你要表达的内容,而在于你如何表达。换个说法:就是“不知所云”。这种情况下,你需要“组织语言、学会说话”。

......

仔细理解这两句话,前者在说的是“我们没有”,因而责任在我;后者在说的是“您想要的”,因而责任在您。看起来这两句话是在表述同一件事,但因为语言组织得不同,前一句的语气是在“致歉”,后一句则是在“推诿”。

......

由此看来,从叙述中揣度结果,那么他们都一定会像分析这两句话的差异一样,无比细致地去分析对方的描述。因此,(注意!)他们事实上都会关注对方的措词、语气、句法,或者分析表达的前后逻辑与关联。而这样做,通常有两个目的:

找到对方表达的潜在含义与目的;

找到对方叙述中的逻辑错误。

第一个是支持者的心态,第二个则是反对者的心态。然而你应该知道,这两种心态就是一个会议的全部内容。

所以你会发现,重要的人很少说话,而重要会议所需要的发言也很少。这样的角色,或者这样的场合下的言论都是经过充分组织的。--只有这样表达,才会更加有效。

我的老朋友Soul有一句名言:“对于两个聪明的人来说,正确的结论通常只有一个。因此如果出现了争执,那么讨论的一定不是同一问题。”

......

所以沟通的第二层障碍出现在跟聪明人的讨论中,让人觉得“不知所为”。这种情况下,你应当预设前提,并尽早阐述结论。

......

用尽可能少的人、在尽可能短的时间内做出决策,这是降低沟通成本的关键。正是因为有了人和时间这些成本因素的约束,所以“我们讨论清楚”再做这个设定可能就会很荒谬。所以第三层障碍的主要表现是:不知缓急。解决之道,则是不要把沟通目标设定为“让对方认同”。

在我们的确没有办法把一件讨论“讨论清楚”的时候,就是“旁观的人最重要”了。--作为管理者,应当去观察、理解和发现问题(或者由专人向你汇报)。你要尽量去听、去思考。因为作为这个角色,你总是有机会纠正问题的。

但是,不要急于去纠正--在一个会议上即使某种想法有问题,也决不是在你发言的三分钟里就能纠正的,而是在最后你做出的决策里去纠正的。这种决策通常有两种:

给出明确答案;

存而不论。

看起来,让你“给出明确的答案”是职责所在。反过来说,“存而不论”就似乎是在推卸责任了。但是可能在某些情况下,“存而不论”才是最好的决策。

项目经理不是理论家,所以并不是“一定”要把一件事情理论清楚才能实作。“论理”是要以沟通成本(人力和时间为代价的),也可能以牺牲“事件”本体来做代价。因此作为管理者,你应该“适时终止讨论”。

沟通不过是手段、是工具之一种,管理者的目标是项目本身。因此讨论不清楚就暂不清楚,让需要讨论的人“而不是整个团队”继续去讨论。于你而言、于项目而言、于整体而言,“有的‘异’无关宏旨,无碍大局,可以存而不论”。

 

第四节 最简沟通

......

在大多数项目中,这样的问题都是存在的。真正能满足极限编程所提出的“现场客户”的情形并不经常出现。即使能将程序员送到客户现场中去,沟通问题仍然是不可避免的。

因此在D项目中我提出了“最简沟通”。

我们开始在网络上查看相关的软件系统的特征,以抽取客户所关注的内容;了解该客户的公司、经营理念、组织结构形式以及工作模式;了解同类公司的成功经验和优秀的管理模式,以及客户的竞争对手再做什么和在关心什么......

其实我们了解sipp,abcus就是走的这一步。

......

我们开始设计提问,每一个提问涵盖尽可能多的信息点,尽可能多的具有发散性以便形成更多的推论和假设。

......接下里就是设计需求条目。

我们从数百条的需求条目中,整理出系统结构和模块,需求条目被映射到各个模块。我们很快就画出了模块间的相互关系图,......

我们对用户角色、原始数据和系统结构进行梳理之后,我们花了很短的时间实现了第一个系统模型。......

这一次的沟通我们使用了面对面的模式。而正好我们有一个模型......

接下来的分析设计是顺理成章的事。......

应该清楚的是,保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会,都是向客户了解更深层次的需求的机会,因此最好在见到客户之前,你就已经设计了所有的问题和提问方式。

 

第五节 为不存在的角色留下沟通的渠道

......

项目的中断和中止,与历史产生断层的内因是一致的。--我发现很多的项目(尤其是产品计划)在负责人员离开后,就自然而然地死掉了。我把这一切的原因归咎于“没有History”。

我们做项目的时候,如果也不留下历史记录(History),那么以后别人来看这个项目,也会是两眼一抹黑,.....

维护项目比做新项目更难,许多人深有同感。然而这些“有同感”的人又何曾想过,自己再做“新项目”的时候,要为“项目维护”这种还不存在的角色,留下一个沟通、对话的渠道呢?

......而History是为整个项目而记录的。一些参考的记录内容有:

需求阶段:与谁联系、联系方式、过程、结果以及由此引发的需求或变更;

设计阶段:如何进行设计、最初的设计、最初的架构、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性);

开发阶段:每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测;程序的单元测试框架;每一个设计和架构变更所导致的影响;

测试阶段:还记得测试用例和测试报告吗?那是最好的History之一。

其实我也比较有同感,但是这样是不是和敏捷开发有冲突?

 

第六节 流于形式的沟通

在很多的时候,我所听到的沟通,都是一种形式。例如与客户吃饭或这打回访电话。

......

流于形式的沟通,可能是使你的项目不断推翻和延迟的最直接原因。

沟通问题不仅仅存在于你跟客户交流中,还存在于项目的各个角色中间。.....

 

UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它,那么强求的结果必然是痛苦的--要让UML在一个没有经过相关培训的团队及其各个角色之间用起来,几乎是不可能的事。即使用得起来,也存在经验问题。千万不要指望仅仅一个项目,就能让你的组员深刻理解UML的思想。

......

使用与不使用UML,其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的,就是好的沟通方式。

 

第五章 失败的过程也是过程

第一节 作过程不是做工程

......

换而言之,无论是用RAD模型还是RUP模型来做工程,即使是亦步亦趋,也做不好工程。

如果工程可以那样做成的话,只需要有瀑布模型就够了。因此“做过程”并不是做工程的精义。

也不是目的。

 

第二节 作过场

 

第三节 实现,才是目的

......

这样的结果是:我们做完了工程(的每一个过程),却没有完成项目(的每一个“实现目标”)。

为工程而工程的人,都迷失在项目中了。就像开发人员迷失在一个技术的细节上一样。专注于RUP或者RAD之间区别的人,可以把每一个过程的流程图都画出来,却也被这每一个流程给捆绑得死死的,再也没有力气挣扎一下的力气。

 

第四节 过程不是死模型

试着跳出大师们的身影,再仔细地看一下那些所谓的“经典”过程,不过是瀑布模型的一再变形。瀑布模型描述了开发的主要环节,于是一群人把这些环节扭来扭去或者反复迭加,就成了RAD、螺旋、RUP......

......

因此,我们应该去思考瀑布模型到V模型这种变化的真实意图。

V模型的每一个环节中都强调了测试(并提供了测试的依据),同时又在每一个环节都做到了对实现者和测试者的分离。由于测试者相对于实现者的关系,是监督、考察和评审,因此测试者相当于在不断地做回顾和确认。

......

更进一步想,如果瀑布模型可以变成V、W和M,为什么它不能更关注于其中某个具体的环节(例如实现和设计环节)?如果在这些环节引入RUP的思想,哈哈,你看看,是不是出现了勋章模型和烟斗模型。

.....

 

第五节 “刻鹄类鹜”与“画虎类狗”

.....

同样,以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质;学习后者而不成,可得文字的架子。--用不好RUP的人,总会说自己终归还有一堆文档模板可以抄,便是这个缘故。

过程理论中,如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时、应需、因地制宜、择善而从了。本质的东西若能理解得透,架子还不是随手搬来就可以用的吗?

越是简单的东西,往往越是接近于本质。

......

你到底是选择架子还是骨子?

 

第六节 工程不是做的,是组织的

......

所以我们当然不能“做”工程,而是要“组织”工程。项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目。

 

 

第6章 谁是解结的人

第一节 是谁的问题

......

可见,在通常情况下,一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。特质的形成,是管理者的问题。他或者是主观地培养,或者是在不经意间形成,或者这根本就是管理者个人特质扩散开来的一种群体特征,但无论如何,维护有益于团队整体的特质,是管理者的责任。

 

注:团队特质可以简单的理解为企业文化。

 

第二节 正视你的成功

......

虽然发掘、彰显和维护这种特质是管理者的责任,但是并不是一个管理者来到一个团队大喊一声“我有特质”,于是团队就有特质了。一般情形下,管理者有个体特质,是管理者的问题,不是团队的问题。因此我们也注意到,很多人反对“空降兵”式的管理者。因为(大多数情况下)这些从天上掉下来的人,一开始就拿着自己的特质或以前团队的特质来“主动地”影响新的团队。他们最经常说的话是“我通常习惯这样这样”,或者是“我们以前怎样怎样”,又或者是“我原来所在的部门如何如何”。

......

成功的经验往往最不可信,因为一方面,成功者沉醉于成功的喜悦,并急于与人分享快乐与荣誉,而不关注这些成功的前提与背景;另一方面,听取这些经验的人则因为那些“既有的成功”而丧失了应有的警惕。

经验,是源于对过去的思考,而不是对过去的复制。面对那些在你面前说“我们曾经这样成功做过”的空降者,不妨先把他们想象成一条条肺鱼。只有提得出质疑,才能换个角度看到那些成功经验所依赖的背景,也才能看到某些成功背后的偶然的或者关联的因素。

每个走上管理者角色的人都无可置疑地拥有非常多的辉煌。对于这些,无论你是空降还是地面进攻,也许在你还没抵达这个团队的时候,大家就都已经知道了。但你是来解决问题而不是来分享成功的。你的那些成功经验,未见得都是可以或应该与团队分享的。如果需要,对失败案例进行分析,并与团队中的成员分享可能要好得多。

千万不要把自己的经验直接拿到项目中来套。“我曾经做过”、“我这样想过”、“对这个问题我思考过了”,这些言论只能把问题的根苗填实在团队的缝隙里。

 

第三节 总得先做点儿什么吧

......

团队特质如此重要,但看起来,它无论如何都会是较长远的事。管理者既然不能一开始就照搬某种模式,也不能立即着手去建立一种未知的团队特质,那么我们总得先做点儿什么吧?

首先,你的团队无论如何都需要有一个远期的目标(然而我发现事实上很多管理者并不善于描述远景)。团队的远景与目标不一定非得是“特定项目的特定结果”,例如远景不见得是你现在正在做或准备完成的项目。举一个例子来说,远景可以是“打造公司的精英团队”,或者“挖掘某项目技术在某某行业中的应用”这样的描述。前者以精神形象约束团队,后者以技术方向引导团队。远景的具体设定,取决于团队的结构、项目的特性和管理者的个人素养。

远景更多地侧重于方向的描述,而阶段性目标的确也是必须的。这至少有三个原因:

明确阶段性目标以便于团队实施和检测;

细化的设定目标更加灵活,便于修正;

阶段性成功能充分激励团队的士气。

但是无论对大的远景,还是小的目标,在团队中并不需要每个人都予以密切关注。所以对目标进行阶段性设定与回顾,是使这些“并不时时关注方向的人”也能体会到方向感的最佳方法。阶段性的目标在微软的工程中被称为“里程碑”,可见这是一种卓有成效的、实践性很强的工程方法。而我在Y公司工作的七年时间里,最终、也是最失望地离开的首要原因,是在那样长的时间里,我都只知道为谁工作,而不知道工作的目标--更高层的管理者从来都没有告诉我“整个公司(或我所在的团队)在未来的方向是什么”。

无论一个人是何等的努力与敬业,七年(或更短)的时间都不知自己在为什么努力与敬业,他也必将失去激情。

......

如果每个人都必须不断地调校方向与留心脚底才能跑到“正南方10公里”,那么“企鹅队列”是必然的结局。所以第二限定应当被分解成这样:最前面的人去看看有没有墙,其他人则关注脚下有没有坑--方向与远景不妨让大家都知道,但“保障方向”这件事,应该只交给头羊。

现在我们有了一个“起码像个样子”的团队。基本上来说,这个团队有三点特性:

方向和目标明确;

团队并分工协作;

能意识风险并有规避策略。

 

第四节 你不是团队的腿

.....

无论他如何陈述理由,产生这个结果的内在因素只可能有两个:

他根本不再对10公里之外的风景抱以期望,甚至认为那不过是望梅止渴的幻想;

我现在就有点这种思想,老是认为我们的SIP不如sipp,做起来没意思,不抱希望!!!

他消耗了相当的体力,接近极限而无法再坚持。

.....

如果“头羊”是技术经理,或者是团队中的某个“精神领袖”,那么(作为项目经理的)你就是教官。你的工作主体是:协调、督促、激励、监督和凝聚。--当然你还可以做些别的事,例如去操场外给大家买些冰水。然而有一件事你绝对不能做:试图帮那个说“跑不动了”的人跑下去。

你不是团队的腿。

大凡是从技术出身的管理人员,总会有愚公那种本能的“实现欲望”。如果一件事自己能做而别人不能或者做得不够好,那么他总是恨不得自己去做。的确,对于一些技术细节来说,你“也许”能立即着手去解决。但是,一方面你根本不可能通过“亲力亲为”解决掉“团队行进”的问题;而在另一方面,你至少为团对带来了下面这四重危险。

首先,你应该让团队的每一个人清楚:“我”必须跑到终点,否则“团队”倒不了终点。这是每个个体的责任,没有人可以替代--这是培养责任心和树立价值观的事。假使你真能成为这个人的腿,“跑”到终点,那么这个团队的成员将会质疑自己的价值和能力,也会忘记自己的责任。一个人如果在团队中没有价值,也没有责任,那么他离辞职也就不远了。

接下来,培养一个最怕的是“教而不习”:你教他,他要么不学,要么不用。但是,事情的真相,不见得就是这个“懒”到不学习,而是你过于勤快,让他失去了“习”的机会。所谓学习,就是让他在过程中看到问题,并了解到解决问题的方法,最后解决之。例如“累得跑不动了”的问题,你应该告诉他,可能是因为:

呼吸没有调匀;

使用嘴而不是鼻呼吸,伤到了肺;

出汗过多,导致缺盐;

脚与地面的摩擦过多,无谓消耗;

.....

你现在应该注意到:如果你真的帮他跑到了终点,那么他将无法知道这些;或者他即使“学”过这些知识,也无法将现在的疲劳与它联系起来。正是因为你愚公式的勤奋,使团队成员失去了“习”的机会。另外一方面,事事亲历亲为虽然容易服众,却也容易滋长集体的惰性:团队成员如果只能把你、把项目、把公司当成学习观摩的场所,自然于项目无益,于团队无益。然而,你还愤愤不平:这些人怎么又懒又笨,什么事都要我动手。--如果团队在你面前只是愚公的集合,那么可能是你出了问题:不会教习,或过于自负。

在sip项目中我是否犯了这个错误?

今天看到鲁这儿管那儿问,我心里有点不舒服,好像这样显得自己在项目中重要性降低了似的,实际上,当初我也不是这样么,现在终于能理解当初小泉和刘海寅对我的那种微妙态度了,其实我必要这样嘛,找到自己的位置好好干就行,没必要在意是谁在那儿打杂!再说了,鲁在项目中的时间也比我长,也应当由他负责,机会均等嘛!

在接下来,于一个人而言,“成功”的激励远大于其他。一个人从来没有享受过登顶的乐趣,那么他一定不会喜欢登山的过程。而你帮他跑到终点,事实上也剥夺了他作为团队成员来分享成功的权利(虽然项目奖励可能不会少,然而这只是形式的,而非内心的所得)。让一个人总是去做“没有成就感”的工作,他必将渐而生厌,你也无异于自毁长城。

最后,你过于强调的个人能力,这会助长团队的惰性。团队管理是促进整体行进的过程,因此基本上来说,你的行为事实上是在暗示其他的团队成员“你们也可以不跑到终点”。这种暗示的结果,是管理层变成了执行层。由此,原来的执行层变得效率地下,而管理层疲于奔命。你忽略了管理自身的价值,以及你作为管理者的工作内容,因而为整个的管理过程种下了恶因。

对于团队来说,“解决掉一个技术问题”,远比“团队的整体行进”次要,因此你不要冲在前面披荆斩棘--把这件事交给技术经理去做,或者教而习之,由成员去做。你首先要明确自己的责任是“整个团队的目标”。

如果你真是好的教官,如果你关注于“整体的目标”,那你应该早早地发现这个团队或某个个体存在问题的“原因”(例如奔跑时的姿势不正确这种技术问题,或者某个成员垂头丧气这种情绪问题),而不是等到有人倒下,才去解决“跑不动了”这种问题的“结果”。大多数管理者并不是因为能力不够而做不到这一点(哪怕这看起来好像是“未卜先知”的神术),而正是因为你过度陷于实施,无法履行你的监督职责--因为你不可能监督自己。

应该记住管理者的责任也包括“监督,发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题,在问题出现之前定位它、分析它,并组织人力去解决它,而不是:

等到问题出现之后再去冲到前面;

然后在还没有清楚地意识到问题的根源时就试图解决之;

最后刚解决了表面问题或者侧面问题,又发现更多的问题挡在前面;

最后之最后,你垮掉,团队也垮掉。

.....如果需要,你不妨去真的买几杯冰水。你也不妨从这杯冰水开始,思考管理一个团队的方法与技巧。

 

第五节 三鼓而竭

......

“三鼓”这样的傻事大家都经常在做。例如老板请吃饭,几次下来大家就都习以为常了;又如月奖、年奖、项目奖,到后来就都成形式了;......

这还是外力的“鼓”(激励),打不了是让人觉得厌烦或者无视而已。我们下面来说另一种情况。

我知道有很多管理者习惯否定别人的想法,而不是肯定之。这个问题的根源,一般是由于管理者从技术出身,因而总是主观地认为自己“有更加绝妙的想法”。但是,不管你的想法是否真的“绝妙”,从管理的角度来说,这种“否定别人”的做法,其实是一个非常愚笨的主意。

这源起于不同角色“做事”的态度:管理者做事是不怕不做,怕一步错,步步错;而开发者做事,则不怕做多,不怕做错,最怕不做。这种差异,形象地说,就是“管理这是绵羊,开发者是愣头青”。然而,如果老绵羊又正好是摔了一头包的愣头青,或者自认为比别的愣头青更有思想的愣头青,那么他通常就会站在别人面前,说:“你这样不行”。

然而这样的管理者无形中忽略了两个问题:

如愤青一样,愣头青之所以“楞”,多是因为激情之故。然而少了激情,再正确的决策也难以有效实施;

“行不通”只是你对事情的评估,而不是实施过程中的观察。因此“行不通”三个字难以说服于人,也未必真就如此。

这两个问题,一个是说“情当如此”,另一是说“理当如此”。为什么这么说呢,我们先来看看这个愣头青在做这件事时的情绪因素:

首先,他与你讨论,就证明他积极地关注这件事,这比漠不关心,人浮于事要好;

其次,他能够“有想法”,这证明他已经主动地在事件过程中发现问题,比视而不见的人要敏锐;

接下来,他敢于向你“提出”想法,这证明他能够打破管理边界,向上层管理层主动沟通,这是团队中的良好品质;

再下来,他能够“主动”寻求解决问题的手段,这证明他能独立思考,并且比别人更有主见。

一个人如果具有“积极、主动、敏锐、主见”这些良好品质而不被认可,那么无疑是令人沮丧的。久而久之:

他会自我否定,并学会放弃,再也没有勇气提出任何东西,变得人浮于事;

你将继续听到更多的意见,他勉力抗争直到你改变或者他离开。

第一种情况:你牺牲了一名优秀员工,而成就了你的自负。第二种情况,鱼死网破。

根本上说,“怎么做一件事”是一个人的态度问题、性格问题、品性问题。团队成员能有点想法,本身就是值得提倡的:想法成熟,则对工程进展有推动(如改进工程技术、方法);想法不成熟,善以用之,则可以对团队建设有推动(如进行团队教育、激励)。因此,万不可拒“意见(或想法)”于千里,把团队“自下而上”沟通的道理给堵死了。--你在牺牲团队成员的同时,是失去了建设团队特质的机会,二者之任意,都是你作为管理者的失职。

现在开始,你不妨把这个愣头青看作愿意“贡献集体智慧”的表率,从他开始,为团队内部的积极沟通带个好头。至于接下来如何讨论:认同他、引导他,或者说服他,那才是“理”问题。

态度可以认可,至于“想法好不好”是技术问题。你不宜急于表态,因为团队中还有头羊,还有“精神领袖”,实在不行,还有“聚师而谋曰”。

即使所有的讨论都倾向于对这名员工的否定,你仍然可以给出一个机会来让这名员工去自我证明。这种机会可能只是几个小时或者一两天的技术探索。这种情况下,如果他能够证明他的正确,那么他会感激这次机会;如果结论是他错了,那么你无形间树立了自己的威信--这件事,只是说“不”,是做不到的。

 

第六节 先人后己

......

让一个管理者向别人说“忙”,是一件很惬意的事。“有得忙”才证明重要,成天无事可做的人,存在的价值(起码看起来)也就小得多。所以多数管理者试图从一早到公司,就让自己显得“很忙”。然而,先不论这种状态背后的心理因素,管理者一定不要忘记在开始“忙”之前做一件事情:驱动你的团队。这就是我所谓的“先人后己”。

......

如果他先人后己,在开始自己的工作之前就来招呼大家了:安排每个人的工作,或者解决某些人的问题,那么这会是美好的一天。然而,如果他总是等到发现很多人无所事事时,再来找大家的茬儿,那么这个项目经理离离职也就不远了--当然,也有可能团队会面临解体,他的项目经理自然也做不成。

这个“让影响到别人的事先做”的思想,与“团队高于个人”的观念是一致的。然而有很多人、很多时候不能分辨一个问题是自己的问题,还是团队的问题,因此也不能正确地决策其先后。这种情况下,我只建议你装得很闲,或者希望忙里偷闲,问问自己:“如果这件事不做,会如何?那件事不做,又会如何?”找到影响面最大的一件,交给别的人(或者)大家去做,而自己做“不是太重要”的那件事就可以了。

更退一步说,即使你什么也不做,也比整队人马停下来要强得多。

即便如此,也还有一种“先人后己”是你容易忽略的:奖励,也要先人后己。

......

Soul随后谈了他认为“不错的”原因。他说:我们的工作量未见得多于程序员,而薪水可能比人家高,并且重要的是,我们站在管理的前端,能得到的机会自然就比别人要多。团队成员其实比我们付出得更多,而得到的更少。因此,我们应该把荣誉真实地反馈给团队,而不是贪为己有。

......

做事时固然要“先人后己”,面对成功与荣誉时也要“先人后己”。前者得以完成团队建设的重任,后者则表达你对团队价值的认可。

对于像外包这种情况,我如何先人后己呢?交给他我不太放心,毕竟他的责任心可能没有我的强。

答:看了第七节就可以找到办法了,因为它不是个问题。你想做一个优秀的管理者,连一个外包都利用不好,谈什么管理呢,好机会呀!

 

第七节 自相矛盾

看看我们都说了些什么?我们在说你有了一个团队,然后从团队的特征开始,我们谈到了组织、沟通、激励和执行。是的,这些都很重要。但我们还漏掉了一个重要的环节,那就是“问题”。如果团队中没有“问题”,那么看起来就不需要管理者了--你大多数时候是被找来解决问题的,不是吗?

......

乔丹认为这是一种主观与消极情绪的区别。而我看来,这就是问题的定义。伟大球员和普通球员的差别,就在于伟大的球员总说:这不是个问题。

......

所以温伯格是对的:你认为这是个问题,它就是个问题

......

我不知道我所呆过的那么多团队,为什么总是存在这样那样的矛盾。例如,员工与员工的、员工与老板的、进度与质量的、技术与市场的.....你会发现,你总是在利益、正误等这样的问题之间权衡,这些选择带来了你的痛苦:也就是我们所说的矛盾。

换而言之,你的“认识”决定了问题,你的“选择”导致了矛盾。

之所以“矛盾”看起来也是一种“问题”,是因为矛盾通常是你无法取舍、无从选择的感觉--这种感觉来自于“你期望选得更正确,但你感觉你无法做到”。

是的,我正要说:温伯格又对了,这是你的预期与体验的差异。温伯格接着说:“要想解决问题,要么改变期望,要么改变体验。”是的,你现在就可以“放下”,改变你的体验(的需求),不要认为这个矛盾是问题开始,重新设定条件。例如:不要用矛来击盾,而是用矛、盾以击敌。如此,岂不是可以尺长寸短,尽可用之。

所以学会否定矛盾、消化矛盾,看到矛盾产生的内因外因,转而借之用之,才是解脱的方法。

比如我现在碰到的问题--我们自己做sip根本没有sipp好,所以我有消极情绪,认为是决策者调研的败笔你认为这是个问题,它就是个问题)。照作者的意思,是不是该这样,首先我不要认为这个矛盾是问题,这仅仅说明我们还有相当一段路要走,心态要积极不要认为这个矛盾是问题开始)。现在我们可以把我们做的sip当作盾,sipp当做矛,我不要用sipp来击我们的sip。而是分析sipp的优势、劣势,以及sip和它的差距、优势等等方面看到矛盾产生的内因外因),把这些东西考虑到我们的sip中,即转而借之用之不要用矛来击盾,而是用矛、盾以击敌;转而借之用之)。这才是解脱的方法吗?

还有最近遇到的让我改周的问题单,我对他的方案不认可,写得那么复杂还让我改,我认为其是个问题。但是,为什么我一定要认为它是个问题呢,我干嘛不当做是了解别人思想,练习看复杂代码的好机会呢?确实,你认为这是个问题,它就是个问题,你认为它不是个问题,它就不是。

 

第七章 从编程到工程

第一节 语言只是工具

......然而,这是我自1997年接触到管理,以及1998年接触到工程以来,第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系!

对于一个程序员,或者以程序员自命的人来说,看清楚这一切的第一步,竟是一句“语言只是工具”。

......

 

第二节 关注点

......

从这个模型中可以看到,在“程序”与“方法”层面,是关注于“(具体的)实现”的;而在“过程”和“工程”层面,更首要考虑的是团队问题。从角色的角度上来说:开发经理思考项目的实施方案和管理具体的开发行为;而项目经理则保障团队的稳定性和一致性。

以前我当的小组长算是什么角色呢?我看可能还是偏重与开发经理一点,毕竟是负责具体的开发行为。

 

第三节 程序

EHM模型图中,在最内层的环里,是“程序=算法+结构”。这是编程的本源定义,也是原始的状态。与代码相关的任何工作,最终仍旧会落足于这样的一条规则。

......

 

第四节 方法

......

你看不到你做事的行为,也就不能理解“模式”作为一种方法的价值。所以大师们众口一词:模式需要一定的编程经验才能理解。

同理,理解过程也需要编程经验,理解对象也需要编程经验,理解MDA(模型驱动架构)与SOA(面向服务的体系架构)还是需要编程经验。

--这可能就发生在你去回顾你的上一行代码编写的经过,或者上一个项目失败经历的那一瞬间。经验来源于回顾、理解与分析,而不是你将要写的下一行代码。

 

注:方法指面向过程,OOP,MDA等

 

第五节 过程

过程伴生工程而出现。过程解决的是工程中角色间的关系问题。

.....

因此过程中的问题,就是角色、沟通和环节的问题。

哪些环节重要,取决于具体的编程行为,也就是具体的项目。

......

分不清玩家与客户的区别,对项目经理来说,是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。

角色的确定,以及角色间的沟通问题,在项目过程中也同样重要。工程组织是否合理,相互的协作是否紧密,是这个项目能否成功的保障。

......

 

注:过程指RUP,XP,模型与模型语言等

 

第六节 工程

......

过程伴随工程而出现,解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的呢?

很显然,软件规模的不断增大是根本的原因。.......

 

注:工程指需求管理,过程管理,配置管理,文档化等

 

第七节 组织

......

所以回顾每一个项目,或者项目中的每一个阶段,以及与每一个团队成员交流的细节,是你的日常工作。

 

注:组织指管理,计划等

 

第八节 BOSS

很多人以为BOSS是给自己发钱的那个人,这其实是错误的。发钱的决策通常是由以下三个角色来做出的:

部门/团队经理:你的直接上司,他是雇佣你的人,是他用薪金的多少来衡量你的价值,或者反之。

绩效经理:如果你的公司有这个角色的话,那么他总是盯着你的错误以决定你薪水的扣除比例。

财务经理:有钱?没钱?没钱?有钱?

是不是应该在日常工作中有意识地在直接上司面前表现表现?比如主动承担工作,而不是被动地等着上司安排!我对外包也是希望别人主动,那么我的上司肯定也希望我主动,这段时间看起来鲁比我表现得好一些,他主动替标哥分担问题单,我看来得找点措施弥补一下,比如功能测试计划。

......

BOSS在公司中解决的是“经营”问题。这其实是在比“组织”更靠外侧的一层--在前面的图例中并没有给出,这也意味着“经营者”与“工程”基本上没有关系。

......

 

第九节 上帝之手

......

软件工程的体系中,“实现”作为软件开发的本质需求和基本动因,如同上帝之手在推动这几十年来的软件工程理论体系的形成。

 

 

第八章 你看得到工具的本质吗

第一节 利器何以为先

......

由此可见,使用工具的方法,比工具本身更关键。所以“欲善其事,先利其器”这样的言论,未见得是全对的。

 

第二节 神乎其技又有什么用呢

......

秦无剑技而一统天下,宋有康肃而痛失半壁!不知用法,不知用处,如同那习得屠龙之术者一般,神乎其技又有什么用呢?

 

第三节 工具的本质

......

如同工程与编程,单以编程而论,讲究技法之精妙,追求细节与枝节是可以的;单对于工程来说,能让团队理解、统一执行、迅速有效的实战技法,才是真实所需的。就像战争一样,团队化的工程中,技法的优劣并不是关键。关键在于某种技法是否能为团队带来整体的成效,而不在于某个人是否喜欢,或者深谙于此。如同陈康肃公,有当世无二之技,不能用于“群战”,也是无益。

......

工具之于工程,本质在于关注并发挥得益于工程全局的那些特性。一人一技,一器一物,又岂能是工程的要义?因此,我们最终看到拥有利器巧技的六国都不在了,最后只剩下一个强秦统一了天下。

 

我对作者本章的观点严重不敢苟同,照作者的意思,好像是因为六国有了利器巧技才导致其被秦所灭的,六国就什么都不干,就专注于造剑了?我拥有利器巧技有什么错,只是无善用者而已。六国被灭,主要是和人相关,和它拥有利器没有任何的关系。二战时的德国,最先拥有潜艇等先进武器,为什么战败了呢,是因为它拥有先进的武器吗,不是。在抗战中,为什么新四军那么喜欢三八大盖,那么喜欢重机枪,在《人间正道是沧桑》中,为什么杨立青要造那么多大炮?所以啊,这个地方是作者为了迎合写书而硬是牵强地贬低工具。

我认为欲善其事,先利其器是没有一点问题的,你不能因为工程的重要性就贬低工具的作用!

 

第四节 唯手熟尔

很多的高手,对于工具的本质并不是了解的。他写程序快,只是记忆中读过的、写过的代码多于别人;他思考问题比别人细致,只是因为他有过比别人更多的错误;他能带领项目团队,只是因为他经历过足够多的项目团队。

这样的人可以算是能人:有能力的人。但未必真有识见,真有才略。

......

“尔安敢轻吾射!”当我在论及RUP(Rational统一过程)、UML(统一建模语言)这些具体的工具只是“工程之末”的时候,很多人愤而所言,与当时陈尧咨说过的话,又是何其相近?

 

我还是不敢苟同作者,手熟,不就是我们平常所需要的经验么?!没有经验,看你哪来的真知灼见!!

 

第五节 鲁班带了坏头

......

鲁班这种典型的“工匠思想”,总结下来有三个问题:

以良匠之名为目标,而不是以做工程为目标;

以工具之利为恃仗,却不关注工具用在哪里;

以技法之巧为较量,却不知技法应为团队所用。

现在来看,这不都是大多数软件开发人员(和技术人员)的问题吗?

 

不敢苟同。鲁班就想成为良匠,这有什么错吗,他的角色就是这样。比如造大炮的人一定要去关注大炮在哪儿用吗,如果人人都去想大事,想管理去了,谁来做这些基本的工作!!简直是瞎扯淡嘛!

 

 

第六节 工匠思想

软件开发圈子中,持有这种“工匠思想”的鲁班门生历来不缺(很遗憾,其中也包括我)。

只不过大多数人把这种“工匠思想”的来源看成“八九十年代的个人英雄主义”。他们认为这种思想是一种现象的延伸,而不认为是一种“开发人员的本质特性”。

鲁班的虚名,给工匠们设定了用以安身立命的目标:成为良匠。我尽管要说,这是一个坏的表率;但也要说,这的确是好的品质。

为什么呢?

我曾经在给CSDN的一篇文章中写过:

“如今业界天天都在讲的,除了模型分析就是架构设计,再远一点的就是管理的艺术与实践。诚然,这些都是好东西,都该逐一细论。然而如果连程序员都去思考模型、架构与管理艺术了,那么个体终将是个体,每个人都是分析师、设计师与项目经理,则项目自然做不成了。”

所以在我看来,不同的工程角色的确应当有他自己的关注点。这个角色能考虑到别人想不到的问题,固然不错;但如果他格尽职守,只关注自己的那一部分,也是本分。

我们在EHM图中说,工程体系的第一个关注点是“实现”。也就是说,你可以是“关注于自己能否成为良匠”的工匠,但是作为工程角色,你起码应该关注“如何实现”。放在项目中,具体的要求其实就是:一项技术是以完成工程需求为目标的,而不是彰显个人技术为目标的。

对于管理者来说,重要的并不是“让大家都关注工程的每一个方面”(这事实上也做不到)。工程管理者应当认识到开发人员的“工匠思想”的本质,并善用之。如同我们前面说的,你认为工匠思想“是个问题”,它才是问题。

我在Y公司和N公司都遇到过这样的例子。某些开发人员是编程高手、技术尖子,因此一些管理者想“发挥他们更大的作用”。于是将他们提上高位,许以“经理”、“副总”这样的职位和职责。但这些人要么工作不得力,要么工作不开心。最终工作没有做好,员工也没有得到激励,反倒破坏了组织结构。

在很多公司看来,“当官”可能是对员工的最大激励。然而身处官场的人又如何能理解技术人员的思想呢?其实很多的开发人员,无非是追求更宽松的工作环境、更好的学术研究氛围。换而言之,他们根底上就是关注于工具与技法的。

如果公司不能利用这些“本质特性”,非要设定他们的“仕途”。那与以矛击盾有什么区别呢?--我们说过,大多数矛盾都是自找的。

公司应当给出员工“在技术方向上的发展路线”。很多大公司在这一点上其实做得不错。他们把技术职级与管理职级分开,使得技术人员可能通过技术提升来得到与管理者相近的薪酬。但事实上,管理者整体的薪酬总是高于技术群体的,因此薪酬的激励终归有限。对于开发人员来说,吸引他的是无限的发展空间。例如当初微软打算用三百万年薪和数万股票从Borland挖走AndersHejlsberg,未果。后来,盖茨提出给他一个小组和极多的资源,“让Anders尽情地发挥”。Anders这才动心,从此就有了VS.NET。

Anders显然是无可争议的、最优秀的程序员,

 

 

第七节 化而用之,融通与融同

......

“融通”与“融同”的区别在于:前者以一通十,有运用变化的能力;后者则知工具之大同,信手而得,随心而用。

--无所谓是什么,只在乎它能不能用。

......

于某时某事,适用的就是最好的。前提是你要看明白这些工具实质的能力。只要能够分辨出所需部分、适度地用在你的工程中,就可以了,......

明白这些工具实质的能力也是要花时间的,白痴!

 

第八节 南橘北枳

......

然而对于确定的项目来讲,只有对这个项目有用的那些“功能”,才是这个工具的价值所在。所以,识见到工具“设计”所满足的那些“确定的需求”进而明确工具与项目的关系,才是解脱之法。

......

 

第九章 现实中的软件工程

第一节 大公司手中的算盘

......

大公司在标准、理论、语言上的争来争去,未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企

图,其最终目的是在整个软件工程体系中的全面胜出。

在整个软件工程体系中的全面胜出能获得什么益处?

 

第二节 思考项目成本的经理

......

愚公如果停下来,思考的问题可能是碎石的“方法”。而项目经理从细节中跳出来,思考的问题就应当是完成工程的“方法”。评价这个方法的好坏的标准只有一个:节约成本。

......

--思考成本,这是D先生给我的教训:

不计成本的项目计划不会得到经营者的支持;

毫无目的地消耗成本是项目中的慢性毒药;

最致命的风险是成本的枯竭。

 

我经常注意到的成员因素包括时间人力资金客户成本。而大多数情况下,人们不会把客户的数量及耐心当作(客户)成本来计算。而在我的项目规划中,这是成本。

 

第三节 审视AOP

......

AOP不是语言。AOP首先是方法论,这就像OOP是“面向对象的编程方法”这种方法论一样。......

.......

所以接下来AOP的三个概念我们就明白了。

指示/拦截器:考察这些对象以“达到什么样的目的”(即需求);

引导:在目标上实现这些需求时,目标所需要表现出来的公共特性,引导特性可能需要配合编译器来实现;

元数据:如果需要,为即有对象实体再补充一些参考数据。

......

 

第四节 审视MDA/MDD

MDA(Model Driven Architecture)也是一个方法论层面上的名词。它讨论的是“创建出机器可读和高度抽象的模型”的方法。受MDA影响的开发活动被称为MDD(ModelDriven Development)。

TDD

FDD

BDD

R-TDD

CDD

RDD

......

我不厌其烦地罗列这些名词,只想告诉读者一个事实:什么都可以“驱动开发”。

......

回到软件工程的过程环节来吧,你会看到“以什么驱动开发”只是一个“以哪个环节为中心(或导引)”的问题。

......

抛开实现的技术细节不论,在工程中,“以什么驱动开发”其实是一个过程问题。而你应该明白,过程的选择(或制定)取决于你的工程需要,以及它在相关领域的适用性、过程工具的充备性和这个过程理论的完善程度,而不是大公司们的鼓吹。

......

也就是说,MDA架构作为一个新的软件开发方法的架构,即使在技术研究、底层协议和软件实现方面经过了持续地完善地而渐直成熟,然而如果没有同样成熟的软件过程理论支持,那么它在工程中的实用价值一就有限。

仔细审视一下这个MDA,如果你现在就决定将下一个项目建立在这个架构的基础上,或者用MDD的方式来开发BIOS,那么你离精神病院就不远了。

 

第五节 审视AP和XP

......

因此,AP以及它的核心思想“敏捷软件开发宣言”,是以实现、实施、实践为主要手段,以体现人本为主要内涵的行为

准则。主要表达在:

一个人本化的、共有的团队特性与气质;

一个契约式的团队组织结构和领导风格;

一些以“解决问题”为中心的思想方法。

XP实质上是使团队遵循这些“行为准则”的一些“形式化的方法”。当然,XP在对一些工程要素的权衡上,也给出了建议和实践结果。但这并不是具体的过程方法,也就没有逾越或颠覆瀑布模型。

“敏捷”,其根本的思想就是用最快捷、有效的方法完成工程。因此,你可以把在“包含瀑布模型在内的”任何过程模型上,基于上述表达进行的开发实践都叫做“敏捷工程”。

......

AP是啥玩意?

 

第十章 是思考还是思想

第一节 软件工程三个要素的价值

“牛粪图”中描述的工具方法过程也被称为软件工程的三个要素。在本书中他们被分解开来思考,并不是要孤立这三个层面--他们实际上是相互作用的。

例如“过程”问题,就既有实施过程的工具,也有相关的过程方法理论。......

......

你能把每一个“管见”拼合起来,你得到的才能是“豹”,而不是“斑”。所以尽管本书割裂了软件过程的各个要素,并从每个孤立的层面来审视。然而实质上,你应该回归到软件工程的本体上来思考问题,而不是仅关注于每一个局部的要素。

工程的整体问题仍旧是“实现”。

 

第二节 其实RUP是一个杂物箱

我或许总是在批评RUP,但是我不得不承认它是对前人在软件过程思想方面的高度包容。

请注意我用“包容”这个词,而不是按照语言习惯那样用“概括”。因为如果是“高度概括”,那你应该把目光投向瀑布模型,而RUP其实就像是一个杂物箱一样“包容”了全部的已知理论。

......

RUP能不能被用起来,将取决于你刚才那个挑挑拣拣的行为,以及现在你在拿到钓竿后的辨别能力与组织能力。

啥意思?

 

第三节 UML与甲骨文之间的异同

在你真的打算用甲骨文来写项目文档之前,请先明确UML与甲骨文之间的异同。

在这本书里,他们都被作为沟通的工具。因此目标是沟通,而不是“选用工具”这件事本身。更进一步的推论是:即使你因为个人喜好而选择了甲骨文,也不要试图在结绳子记事的原始人面前去用它。

......

所以在工程中使用UML图,应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了,那么下一个阅读UML图的人所面对的,将是无异于甲骨文出土时的困境。

 

第四节 经营者离开发人员很远,反之亦然

......EHM真实地反映了“老板不懂技术”的合理性,同样也真实地反映“开发者转型为老板”的道路将是相当漫长与艰难。

于是,项目经理这个中间角色就有了一种使命:协调经营者与开发者之间的沟通。

......

你要理解这种根源:角色的关注层面完全不同。

 

第五节 矛盾:实现目标与保证质量

......

需求人员会把所有的责任归咎到开发人员,而开发人员又不停地埋怨需求的不清不楚,或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的,那么他们便会开始埋怨客户的苛刻及工期的紧张。

总之一件事,没有人会跳出来说:我们原本就错了。然而事实上问题可能真的处在源头:我们把目标定错了。

我们看到,在项目的平衡三角(时间、资源和功能)中讨论的是目标问题,但并不讨论质量问题。......

......

如果原定的目标(的整体)本身就过大,那么无论如何平衡这三者之间的关系,其结果仍旧是保证不了质量。

问题是:又有谁愿意在最初签订协议的时候,就降低或者放弃协议的标的呢?

那我们该咋办嘛?

 

第六节 枝节与细节

刚才说到目标与质量的问题时,提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说,它是一个具体的方法,而不是目的。

......

大多数情况下,管理人员有责任去审核、评估其他成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题,因为这决定了产品的最终质量,而质量是工程的目标之一。

而在另一些情况下,例如管理人员做事件的决策的时候,就必须要学会忽略枝节问题。

比如在做架构设计决策时,像按钮图标好看不好看这些细节估计就得忽略,而在具体地实现这个按钮时,估计就得关注了,否则版本一发布,可能就因为你的一个图标而显得不够专业。

......

因此我只好用最笨的方法提示管理者:别管它是细节还是枝节,只要你感到你的脚趾已经沾上了泥淖(chuo),就快点回头。

沾上了泥淖(chuo)是什么意思?回头是什么意思?

用脚趾去感觉,有时比用头脑去思考来得有效。

 

第七节 细解“法”与“式”

软件工程学科中的很多思想与其他传统的工程学科既有的思想、方法和理论有紧密的关系。所以甚至有些软件工程角色被推荐去阅读类似于《建筑的永恒之道》这样的书。......

我得找找这本书翻翻?

由此看来,《营造法式》中所解决的问题,与我们今天的软件工程中所遇到的问题如出一辙:

工程管理者不能兼通各个工种;

不同的开发人员对设计和只做的理解不仅相同。

那么《营造法式》是如何解决上述的两个问题呢?

这就回到了“法式”这个词的含义上来了。法式二字,是宋代官方文件的常用词,法指“律令”、条例,“式”指定式、方法。所以《营造法式》颁行的初衷,是希望能有办法将工程中所用的元素:

“按类分别排出,有条例规章作为依据”;

“按照条文画成图样,对将来的工作有所补助”。

......

那么,我们怎么能指望在某种(或几种)过程理论,以及一些模式方法之上,找到一个能一成不变的办法去实施我们的软件工程呢?

相较于《营造法式》,我们的软件工程实践类学术专著仍然非常粗糙,未必能像“法式”那样值得趋从跟随。当然我们也不应当因噎废食,妄论优劣。因此对于“某某模式”与“某某模型”之类,我们的态度仍然是“与式不同,比类增减”。

与式不同,比类增减是啥意思?

 

第八节 灵活的软件工程

“未蕴而变,自欺也。知律而变,智者之道也”,实为良言。

“知律”的另一层意思,是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题,大多数人不知就里地使用着技巧和方法,而一旦出了问题,则归咎于这些技巧和方法的不好。而真正的问题在于,这些人(我们通常叫做Copy&Clear)并不知道这些技巧,技术和方法的原理,因而不知道变通,也不知道回避错误。

有时确实是这样,比如我可能会简单地使用多媒体定时器,但是上次关闭定时器引起程序崩溃的问题,我就抱怨是多媒体定时器没设计好,实际上我知道,应该是我没使用对,为什么没使用对呢,那就是我对其原理理解不够。但是,有时我们确实没有那么多时间去研究透一个东西,我们该如何选择呢?

所以死读一本《软件工程》的人不会做真正的软件工程。

所以我写《大道至简--软件工程实践者的思想》。

 

 

这段时间的郁闷终于解决了:

答:首先要有积极的心态,把麻烦和困难当做学习、锻炼、挑战!比如今天胡家凯让我搞每日构建,我就觉得没有把握搞定,就有点想推脱,我干嘛不当做是公司提供机会让我学习,好机会啊!你不认为它是问题,它就不是问题!哈哈!!!!!!!

 

  • 1
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论 1

打赏作者

backard

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值