读后感 (I) 驱动和责任_梦断代码书评-查字典图书网
查字典图书网
当前位置: 查字典 > 图书网 > 编程 > 梦断代码 > 读后感 (I) 驱动和责任
xinz 梦断代码 的书评 发表时间:2009-01-25 15:01:32

读后感 (I) 驱动和责任

几个星期前,我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》,要求写读后感。这本书讲了这样的故事:一群很有经验的代码牛人在先进软件开发模式的指导下,没有资金压力,在更多大牛的带领下,原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM),后来花了七年时间才完成这一创举,但是已经无人喝彩。我是9月份读的英文版,后来又翻阅了中文版,也有一些感想如下。



1)驱动

到底是什么驱动程序员和管理人员,测试人员长年累月投入到一个软件项目中去?

有理论认为,传统的软件公司用工资,职位,绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作(大教堂/Cathedral模式)。其实,用开源,社区,共享的模式会更好(集市/Bazaar模式)也许更好。正如在第26页所说的 [所有页码都是指英文版]

... it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26]

这理论听起来很好,但是我想起了两个故事:

1) 美国的一个肥皂剧Seinfield里有一集,讲了一个混混Kramer 热心地加入了一家公司,义务打工,起初他的口头幽默和热情感动了团队,领导委以重任,不料Kramer 根本没法儿把事情做好。最后领导只好找他谈话,Kramer 承认自己不行,他说- 但是俺是义务给你们打工的! 领导说,对,这就是让我们为难的地方。。。
项目中来了一位“义务打工的”,照理说,对项目只有帮助,而且别人是“义务”,你怎么好意思把别人赶走?

2) 我以前在西雅图的时候参加过一个非营利组织,成员们都是有热情为社区服务,而且义务付出。但是后来有些成员就逐渐找不到了,一些事情也不了了之。 由于大家都是义务贡献,你没法如何要求别人。

在Chandler 项目中,Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" -

They don't know whether to count on you or not. And because you're not getting paid, there's lack of control. [p167]

后来这位Hertzfeld 也拍拍屁股走人了,大家可以为 fun 和 Ego 一起工作,但是如果fun 和 ego 都得不到满足,那motivation 也会急剧下降。

2)责任
和驱动紧密相关的,是责任 - Accountability.

在 Hard Drive 这本书中,讲了这样的故事 - 由于Windows 一再拖延,BillG 最后跟 SteveB 说 - 如果今年下雪之前Windows 还没出来,你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么,但是第二天一个员工背着睡袋进驻了办公室。

很多年以后,Windows Vista 也经历了很长的拖延,在又一次宣布拖延之后,人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。

我们回过头来看,在Chandler 项目长达7年的拖延中,有没有发生过各位项目管理者引咎辞职的事? 好像没有。 [有不少人离开,但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚,那我为什么一定要拼了老命要避免下一次拖延呢?

在传统意义上的软件公司,如果项目延期,那项目原计划的收入就拿不到,拖延的时间再长一些,员工就得走人,否则整个公司都被拖垮了。在“集市”,社区,共享的模式下,大家都是义务,大家都在玩票,大家都做贡献,但是对最终项目不直接负责任,那到底谁负直接责任呢?

在《移山之道》 中,我讲了下面的例子:

阿超:我今天在“顶球”网吧看到大牛他爹在下棋,围观者支招的不少,有的说上马,有的说拱卒,有的说出车。大牛他爹一会儿招法就乱了,眼看局势不灵了,围观者一哄而散,老崔后来也没法,只好认输了。

一个围棋国手在一次重要的对局后,听到旁观者对棋局的进程有很多不同的看法,他也没有过多争辩,只是说:“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。

无责任的旁观者在支招后,如果不灵,他可以面不改色地继续支招,甚至可以给另一位对局者支招,不管最后谁输谁赢,旁观者随时都能安心地离开,回家吃饭。有重大责任的当局者在走了损招或败招之后,他很可能就要认输下台,丢掉比赛的奖金和头衔。
 

我在清华大学的这一次《现代软件工程》课,我发现有些学生好像不是特别投入,后来了解到,由于申请学校用的GPA只计算前三年的成绩,第四学年课程的分数就和申请学校没有什么关系了,所以比较“鸡肋”。有一个同学说,如果这门课是在第三学年,那许多同学们会非常计较分数,排名。现在,只要能过就可以了。怪不得一两个项目中出现了 “花最少的努力,能过就行” 的心态。

一个软件团队可以制定出动人的远景/Vision, 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任,那Vision只是一句话而已。

展开全文


推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读

对“读后感 (I) 驱动和责任”的回应

黑枪王荣格 2009-03-24 21:01:55

我觉得您好象没有明白我的意思。
我说的“即插即用”,指的并非在标准化方法下实现的“即插即用”,而是在冗余的方式来实现即插即用,也就是说,团队当中的个人可以随时离开,但是这个个人的离开并不会改变团队的知识结构,也就是说离开的这个人所掌握的能力被冗余到了其他人身上,这当然也可以包括打交道甚至是“潜规则”。这是另一种增加团队鲁棒性的办法。

xinz 2009-03-22 21:09:19

很多很有意思的观点,先谈一个:

>其实我更喜欢主刀的医生是一个“即插即用”的

我敢拿你的生命来打赌,你不会更喜欢的。
我们假设你要做一个小手术,在医院住了两天,和主刀医生已经打过几次交道,双方并且可能还“潜规则”了对方...
然后你躺在手术台上,麻醉剂开始起作用,恍惚中,你注意到上台的是一个陌生的医生, 他一边听护士对你病情的剪报,一边对你说 - bigboss,别担心,我是即插即用的。
这时候你会怎么想呢?

最喜欢“即插即用”的,是在"红海"中的企业,他们竞争的主要方式是价格。 一个卖快餐的全球企业公开说,他们希望他们的员工不需要任何培训,就可以即插即用地开始工作。

黑枪王荣格 2009-03-22 15:53:45

其实我更喜欢主刀的医生是一个“即插即用”的,这样问题到解决了,任何人都是不重要的,同样任何人也都是重要的。我大胆的预测一下,您似乎对现有的软件工程中的开发方法比较欣赏啊,呵呵。

其实软件开发最早的模式应该是“自己自足”模式,所谓“主治医师/手术台”模式只是“自己自足”模式的变种而已。“自己自足”的模式的优点是,自己需要什么自己都知道,而且自己有非常擅长利用各种技术来实现自己所需要的东西。但是“自己自足”的模式无法回避一个问题:如果我需要一个我不擅长的技术怎么办?主治医师/手术台”模式中,假设的是主治医师什么都懂,经过了长期的检查,细致的准备和规划。这个假设是不是有点苛刻了?如果主治医师对全局缺乏足够强大的掌控力,那怎么办?

模型很多时候都是理想的,是对现实的简化,而现实往往要残酷很多。往往理想模式给出一个苛刻的条件,然后在给出一种方法,在满足苛刻的条件下,按照方法就可以达到目的。现实往往是,我们没有达到苛刻条件的能力,我们也要达到相同的目的,怎么办?
现代的软件开发规模越来越大,各种工作分类越来越具体化,这使得很难在好到一个理想的对全局有足够掌握力的人。这就好象在几十年之前,人们认为瀑布模型是他们的救星,结果实现证明了,不可能有人在最开始把一切都能规划好,瀑布模型甚至连最开始的需求获取部分都很难做好,所以才出现了后来的原型法,迭代模型等。最开始,大家都不喜欢变化;而到今天,是行业的发展使得所有人不得不去拥抱变化,甚至不得不去期望在早期变化来得越多越好。

温伯格在90年代之前做的统计结果,软件开发的成功率大约是30+%;就前几年,又有人去做了统计,发现还是30+%。要知道,这么多年,我们经历了CMMI,UML,UP,XP,敏捷,结果没有明显的效果。这仅仅是责任的问题?那么这又如何解释那么多成功的开源项目?我想这只能解释为我们沿用的开发方法存在根本上的问题,也就是瀑布模型存在的问题一直被继承到今天也没有被解决。

另:标准化是否要执行,看的是标准化所需要达到的目的。如果标准化模块不是增加团队鲁棒性的唯一办法,甚至存在新的办法在其他方面有更好的效果,标准化模块很可能就被淘汰掉或者没有向现在这样那么的被重视了。比如,如果每一个人都在项目开发过程中逐渐变成了多面手,那么标准化真的就那么的重要吗?
其实很多时候,多去了解一下敏捷方法背后的含义和作用,还是蛮好玩的。

xinz 2009-03-21 20:33:19

我对于奥匈帝国不了解。

你的观点给我一些启发,先草草写几条:
1) 没有唯一成功的模式,软件团队很早以前就有“主治医师/手术台”模式,主刀医生对问题的关键非常了解,非他动手不可,其他的人员(麻醉,护士)也确一不可,但是他们的目的就是让主刀医生专注于解决问题。 如果你是一个病人,你希望上台主刀的医生是一个“即插即用”的么?

2) 3人一组 - 很像 Jazz 的小乐队。 如果我们比较交响乐团/民乐团的演出, 和 Jazz 乐队的演出, 我们会发现有很多不同。
你的项目,是交响乐,还是Jazz?

3) 技术可以分两种 sustaining technology, disruptive technology. (参见 innovator's Dilemma)

如果技术处于 sustaining 阶段,这时的竞争从 features, reliability, convenience, 转移到 price. 这时候,标准化很重要。 如果你的项目是写一个内容网站,千万人都已经做过的事,你考虑的重点是。。。

如果是disruptive technology, 例如全新的人机界面,多点触摸的手机, 你考虑的重点也不同。

就先写这么多。

黑枪王荣格 2009-03-20 23:56:15

我知道您说的这个问题,这个是从奥匈帝国横扫欧洲起就被开始奉行的模式,现在也有很多人还很崇拜这个思想.但是现在也确实存在一些思潮在反思这个问题.

1.在敏捷运动中,很多地方在打破这个思,团队的中心化现象会越来越严重,新人加进去的话会需要更多的努力.结对编程增加了团队队员的可替代性,但是这是通过冗余的方式来增加的安全,以及辅之以一套对内开放的学习环境,而非传统的那种新人可以随意替代旧人的方式.

2.http://yeka.blogbus.com/logs/36765121.html
这篇任正非的讲话,在一定程度上也对传统的那种组织结构进行了否定."前线3人一组,包括一名信息情报专家,一名火力炸弹专家,一名战斗专家。他们互相了解一点对方的领域,紧急救援、包扎等都经过训练。"达到这种级别,新人真的很容易接手吗?

3.在<设计心理学>里面,提到了,万不得已,不要使用标准化.


PS:谢谢您的 读后感 (II) ,那篇关于交流的内容给了我很多的灵感,提示了我以前一个我一直 没有考虑到的地方.

xinz 2009-03-20 22:33:25

>将人向插件一样直接插进来就用,这是否不够人性化?

老板希望员工都是可以替代的,标准化的模块,代码风格,文档,都为了后面的人可以很快接上手。

黑枪王荣格 2009-03-19 23:45:03

“先进软件开发模式”是个很模糊的概念,因为CMMI本身也承认,就算达到了5级,也不能保证就能开发出好的软件,1级也不是说就不能开发出好的软件。当然还有更激进的,温伯格自己定义了一个0级,这个0级到貌似是最好的。
  
关于后面两个,说一下我个人的观点
  
驱动是否是不可替代的?或者说,相对于FREE来说,利益驱动是否就是唯一不可替代的?学习敏捷,利用小迭代来增加成就感的次数,是否同样的也有效果呢?我一直在考虑这个问题,在敏捷方法中,究竟是因为小迭代缩短了每次开发的时间,减少了躲猫猫的时间;还是说因为小的迭代增加了开发人员的成就感次数;又或者两者都有呢?
进而,我也一直在怀疑,是否传统的软件开发方法,忽视了对人的重视,而过多的考虑了去建立一套结构和制度,妄图将人向插件一样直接插进来就用,这是否不够人性化?