爱爱小说网 > 其他电子书 > 微软研发致胜策略 >

第3章

微软研发致胜策略-第3章

小说: 微软研发致胜策略 字数: 每页3500字

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!



用的,函数朝令夕改,别的小组会无所适从,根本不知道
程序应该是什么模样才对。
如果这位组长稍微花点时间,从别的组的角度来看看
这个函数库,他就会明白放入新版程序时,与旧版能兼容
是多么重要。大家都希望既用到新的程序代码,希望所有
的程序都能链接成功,没有任何失败。
于是,我们把项目的目标再更具体化一些,那是:
目标是为MS…DOS 的应用程序提供像
Windows 环境的使用者界面函数库,只包含对
每个小组都有用的程序,而且必须和其他部分
的程序版本一致。
现在我们理清了影响这个函数库的重要相关因素,我
和组长一起定出了清楚而明确的项目目标。我们发现,只
要用心考虑各因素之间的关系,考虑一项行动会造成什么
影响,很多细节就会变得显而易见,而且是可以事先建立
正确的规范,避免事后再来花更多时间收拾残局。只要在
做出决定之前想一想,“我要这个函数库能做到什么?项
目的目标是什么?”很多问题都能迎刃而解,组长可以轻
28
微软研发
致胜策略下载
易决定什么是该做的,以及该如何做。
如果做得更彻底一些,组长可以花几个小时,甚至几
天来订出详细的项目目标,这些目标不一定要博大精深,
只要目标能够写下来贴在容易看见的地方,随时提醒、随
时指引,让项目朝着正确的方向进行就可以。
如果函数库中都是全部小组需要用到的,函数库就会
体积小些、精简而标准化,新增的功能特色就比较容易做
出来,开发小组就不必拼命加班做一大堆只有少数人用得
到的函数。想想看,只要把目标稍微理得清楚些,整个项
目的方向就会有惊人的改变。
理清详细的项目目标,可以避免在不必要的工作
上浪费时间。
相互依赖
项目失控最有可能的原因是小组之间工作上的相互依
赖:一方必须依赖另一方把工作做完才能进行自己的工作,
而且若是彼此的配合或沟通不够好,整体工作必然受到不
29
微软研发·致胜策略
奠定基础下载
利的影响,依赖愈多,愈容易失控。使用共享函数库有很
多好处,这是人尽皆知的事。但是身为组长的人,必须衡
量是否该把这部分的程序代码放进函数库,所获得的好处
与必须忍受的缺点—让其他的工作依赖于它,孰轻孰重。
任何领导者,必须牢记并且实践以下的座右铭:
尽可能减少项目中小组彼此间的依赖。
想想看,万一函数库的开发工作进度落后了,又未能
及时采取改善措施,对其他的小组有多大的伤害!负责函
数库开发的小组会拖累大家的进程,使大家不由自主地一
起延误,若不能及时挽救,项目就真的失控了。
另一方面,如果依赖函数库的小组听说开发函数库
的小组无法在规定时间内完成要求的工作,也不该强迫
他们。因为函数库的开发是很多其他工作的基础,绝不
容许发生丝毫错误。如果强迫开发函数库的小组必须在
某个期限内完成过多的工作,等于是不恰当地依赖开发
函数库的小组。
以上所谈的道理似乎简单浅显,但是做起来可不然,
我看过很多重复发生的错误,有许多小组真的耗费了大量
时间在函数库的依赖性问题上纠缠。
30
微软研发
致胜策略下载
努力要有代价
有些管理学的书喜欢把设定目标看成一种神秘的哲
学,让您读起来会有这样的感想:“我不知道究竟为何要
设定目标,只知道经过研究证实,有明确目标的团队,会
比目标模糊的团队更有生产力。”
我不知道这些管理学书籍为什么把设定目标这件事
弄得这么玄,设定目标只不过是把“你要完成的事”用
清晰的语言描述出来,让每个人都有明确的概念。如果
您的目标是买一栋这样的房子: 2 0世纪初期的维多利亚
式三彩建筑,有四间卧室两间浴室,后院还要一尊法兰
西斯雕像,您大概会先看过一大堆的房子,然后才确定
自己想要的是哪一栋。目标越是明确,达成目标的过程
就会越有效率,因为您能马上拒绝不符合脑中未来景像
的事物;明确的目标之所以带来效率,正是由于它能帮
助您挡掉别的项目丢过来的不相干的垃圾,让您专注在
本项目的策略性事项上。
不幸的是,在软件开发过程中,没有任何事件能迫使
领导者停下来想一想,却有庞大的压力迫使领导者没有时
间思考,反而忽略了设定目标这么重要的事。当项目已经
落后了一大截,都快失控了,谁还有时间去设定详细目标
31
微软研发·致胜策略
奠定基础下载
呢?有些主管不设定目标则是基于完全不同的理由:别人
都没有设定目标,我们为什么要这样做?不论理由是什么,
凡是没有明确目标的小组,必定遭遇额外的挫折。
如果您希望项目进行顺利,就一定要花点时间设定详
细的目标,这不是什么有趣的事,但这一两天的功夫让您
的项目不会偏离方向,相对的报酬是非常值得的。组员的
努力应该有代价,而长期加班、饱受压力的小组,多半是
工作漫无目标的后果。
不要因为制定目标需要花很多时间,或是别人
都没有做,就省略了目标的制定。制定明确详
尽的目标所花的时间,绝对会让团队得到更大
的好处。
程序设计的优先考虑
如果您请三位朋友顺路到超级市场帮您买些芦笋、绿
豆、玉米,结果其中一位买了罐头蔬菜因为最便宜,第二
位买了冷冻蔬菜因为最容易煮,第三位买了新鲜蔬菜因为
32
微软研发
致胜策略下载
最健康也最美味,您会觉得惊讶吗?至少,您觉得这样的
事情会发生吗?
这三位朋友买了不同的蔬菜,因为在他们心目中,强
调的优先考虑不同,程序设计也是一样的道理:即使同一
个程序,由三位程序设计师写出来的程序代码必定不同,
第一位程序设计师强调程序代码应该越简炼越好,第二位
认为容易使用最重要,第三位则喜欢追求执行速度。
假若您的产品必须快得让人目不暇给,而程序设计师
却认为写程序的第一要点是轻薄短小,那么做出来的成品
不太可能会使用特别的加速方法,执行速度也不太可能令
人惊喜。假若您的主要目的是在最短的时间内做出高稳定
性的软件,但是您的程序设计师却喜欢追求执行速度,而
不太在乎稳定性,结果一定无法令人满意。如果程序设计
师心目中理想的考虑顺序和项目目标并不一致,想得到满
意的产品就好比缘木求鱼。
项目目标和程序设计的优先考虑并不相同,但二者常
会发生部分重叠,主要是因为项目目标能帮助考虑顺序的
确立,以下是重要的基本观念:
◆ 项目目标引导项目进行的方向。
◆ 程序的考虑顺序影响程序设计的过程。
33
微软研发·致胜策略
奠定基础下载
假定项目的目标是做出世界上最快的M a n d e l b r o t
plotter (一种画几何图形的程序),效率就是程序设计时的
第一优先考虑。
暂时不谈程序设计的优先考虑有何重要性,在我的
经验中,主管很少注意到这个问题。程序设计究竟该以
什么为最优先考虑?速度?体积?稳定与坚固性?可移
植性?可维护性?每一位程序设计师对于程序设计的优
先考虑看法不同,并且反映在他们的作品中。如果大家
各自随意,就很容易出现不一致的情况:有些人为了容
易维护而坚持写干净漂亮的程序,另一些人认为速度是
最重要的,所以写了一大堆别人看不懂的程序代码或汇
编语言。
如果您希望小组工作有效率,能够精确地达成项目目
标,您就得建立最适当的程序设计优先考虑顺序,并且让
所有的程序设计师确实遵守。最低限度,您应该为以下的
程序设计考虑点排出一个优先级表:
◆ 体积大小(size)
◆ 速度(speed)
◆ 坚固性(robustness)
◆ 安全性(safety)
34
微软研发
致胜策略下载
◆ 可测试性(testability)
◆ 容易维护(maintainability)
◆ 简洁(simplicity)
◆ 再用性(reusability)
◆ 可移植性(portability)
这张顺序表中唯一需要解释的是安全性,如果您认为
安全比速度重要,您就得选择重安全而轻速度的方式,优
先要求程序中没有b u g。比方说,程序有两种方法可以选
择,一是表格扫描( t a b l e … s c a n n i n g )、一是逻辑判断( l o g i c …
d r i v e n ),前者比较慢,但也比较安全,既然安全比速度优
先考虑,那么除非有别的重要理由,您应该选择表格扫描
的方式。
除了程序的优先考虑顺序之外,您还应该建立各项
考虑点的质量规范指导。例如您认为坚固性是第一优先
考虑,那到底要多坚固才算合格呢?最低限度,程序在
输入资料正确时绝对不该发生错误,但万一输入资料不
正确时,程序会怎么办?程序应该很聪明地处理错误的
输入资料,在某程度内自动更正它(那就得付出体积和速
度的代价) ?或是在程序中加入检查输入的动作,尽可能
督促使用者输入正确的资料?或是就让错误的资料进入
35
微软研发·致胜策略
奠定基础下载
处理,干脆一路错到底?这个问题没有标准答案,全看
您对品质的要求。
大致上,如果是操作系统,在不死机的前提之下应该
尽可能接受输入值,如果是应用软件,应该尽量能更正不
合法的输入资料,对无法更正的输入应该提出警告。但是,
如果纯粹就程序的质量而言,也许该考虑强调性的失败信
息,例如一个函数库中的程序,遇到部分不正确的输入值
时,虽然可以做下去,但无法预料会有什么结果,此时不
如当成错误的状况处理而中断执行,以免错用这个函数的
程序误以为一切安好。总之,在一般情况下都应该对不正
确的输入作某种程度的处理,只要别让程序代码过度庞杂
就好。
这里的重点是,如果事前就决定了最合适的优先考虑
顺序,以及各考虑点的质量规范,团队就不会浪费太多时
间把程序改来改去,程序的整体风格比较容易一致。
事前决定最合适的优先考虑顺序,以及各考虑点
的质量规范,能够指引开发团队的工作。
36
微软研发
致胜策略下载
安全性或是可移植性?
以我个人的观点,我通常把安全性放在比可移植性优
先的地位,也就是说,我喜欢安全的程序甚于可移植的程
序,这听起来有点含糊,那是因为可移植性高的程序通常
表现出的安全性也高,事实上,这两种特性没有真正的关
连,只是可移植性高的程序碰巧也是安全性高的程序罢
了。
写C 程序时,宏(macro) 是很好用的,它可以用来当
作子程序的定义,但事实上它跟函数(function) 不同,每
一次启用宏,会被展开成一段一般的程序代码。但如果写
得不够小心(例如同一名称重复定义),它会造成潜在的
b u g,这一点C 语言程序设计师都非常清楚。用宏的方式
来做函数,很好用但容易有危险。
如果您愿意利用某些C 语言编译器特别提供的inline
指令,就可以充分享用宏的好处,而不必冒潜在的风险,
惟一的问题是, i n l i n e不具有可移植性,在不同的编译器
之间未必兼容。对我而言,安全比可移植性重要,所以我
宁愿选择用inline 的方式来保护宏函数。
37
微软研发·致胜策略
奠定基础下载
当机立断
您可能听过很多极为成功的人士都有当机立断( s n a p
dicision) 的倾向,事实上,一般人如果过快做决定,大都
是颜面尽失的悲惨下场。差别是在于,那些成功人士早就
已经设定好清楚的目标和优先考虑的顺序,遇到任何问题,
或是要裁决某个建议时,只要把它放到脑海中的决策“尺”
一量,立刻就会有答案。另外,成功人士不会轻易改变主
意的,改变主意等于是背叛了自己的信念。
事实上,成功人士并不是未经思考就草率决策,只不
过他们把目标和优先级订得非常清楚,所以他们不必想太
久,也不必为无关紧要的事情浪费时间;结果是:他们不
必花太多时间来做决定,而是花时间去做已经决定的事。
严守基本原则
回顾本章的讨论内容,我们可以总结出软件开发的基
本观念:“确定您要达成什么样的目标及如何去做,让每
位组员都明白目标,并专注地朝这个目标努力,设定程序
的优先考虑顺序,以及相对的质量规范指导。”这些都是
很基本、很简单的观念。
现在,回头看看您公司内的各个部门,有多少个部门
38
微软研发
致胜策略下载
有清楚的项目目标?有多少程序设计师接到关于程序优先
考虑顺序的明确指示, 以及质量规范指导?然后问问自
己:“程序设计师真的全力投入在改善软件的工作中吗?”
再看看您公司内的项目主管们,他们是否习惯在会议
中讨论一些芝麻小事,或是在讨论真正重要的事情?他们
是否常常扔些与产品无关的工作给程序设计师,例如写报
告等等,或是认真为程序设计师清除所有阻碍工作的障碍
呢?
本章所讨论的全都是相当基本的概念,但在我的经验
中,很少人对基本的东西认真思考。而我相信正因如此,
您随手抓起一本《信息世界》( I n f o World) 或《M a c周刊》
(MacWEEK) 之类的专业杂志,里面就充斥着“某个项目
已再度落后六个月”之类的报导,或是某位程序设计师为
了工作连家都不能回的故事。
重点提示
公司聘请程序设计师,是为了开发高品质
的软件,但如果经常被杂事打扰、分心,
就无法保持专注在真正该做的事情上。主
39
微软研发·致胜策略
奠定基础下载
管必须确定程序设计师能专心投入在具有
策略价值的工作上,而不是打杂,凡是会
阻碍软件开发的东西,主管应该毫不犹豫
地把它排除。
然而,有很多杂事其实是无法避免的,大
公司尤其如此,那就只好将它的负面效应
尽量减少,方法是不断自问:“我到底想要
完成什么?”“我该怎么做才能既保持这件
工作的好处,又能避免它的坏处?”要满
足实质上的需求,而不是表面上的作业程
序。
拥有明确目标所带来的好处虽然不是立竿
见影,但没有明确目标所造成的混乱绝对
是显而易见。没错,建立明确目标是一件
费时又无趣的工作,但比起项目延误或失
控的危险,肯定是值得付出的。请记得使
用者界面函数库的实例,项目目标只要稍
微改好一些,就会明显地减轻压力,项目
目标再修正一次,问题就几乎都迎刃而解
40
微软研发
致胜策略下载
了。
每一位成员都必须有一致的程序优先考虑
顺序,程序的可维护性是最重要的吗?可
移植性?体积?速度?为了让软件产品符
合项目的目标,必须让程序设计师明白本
项目的程序优先考虑顺序,他们在程序设
计时才知道该如何取舍。同时,您还得对
每一项优先考虑点事先建立质量规范指导,
以避免到时候质量不合格又得重写部分程
序,导致时间浪费和项目延误。愈早定出
质量规范指针,愈能省时省力。
41
微软研发·致胜策略
奠定基础下载
下载
第2 章
策略性的
作业方式
2
Chapter Two
虽然我从事软件

返回目录 上一页 下一页 回到顶部 1 2

你可能喜欢的