代码之道
点此进入淘宝搜索页搜索分类: 图书,计算机/网络,程序设计,其他,
作者： （美）布莱什纳 著，陆其明 译
出 版 社： 机械工业出版社
出版时间： 2009-1-1字数：版次： 1页数： 192印刷时间：开本： 16开印次：纸张：I S B N ： 9787111251675包装： 平装编辑推荐
《代码大全》姊妹篇！
微软公司内部所有工程师的必读之书！
——Peter Isensee，微软公司开发经验
“我能肯定，I.M.Wright不会听我的话，试都不用试。”
——Jon DeVaan，微软公司高级副总裁
“尽管我绝不会从这家伙手里买二手车，但在软件开发方面，他确实也对他自己的东西知道得一清二楚。”
——Ian Ellison-Taylor，微软公司工程部总经理
“微软公司内部所有工程师的必读之书。”
——Peter Isensee，微软公司开发经理
揭示关于编码、测试和项目管理的残酷现实——一位微软的内部人士如实地向你述说。I.M.Wright的“Hard Code”故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。
本书收录了49个栏目。Eric Brechner重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他解剖了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式——自始至终充斥着机灵的幽默和讥讽的风趣。他的想法并不总是很受欢迎（他也不关心那个），但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。
了解未经掩饰的真相：
怎样提高软件的质量和价值——从设计到安全；怎样切合实际地管理项目的时间表、风险和规范书，怎样为常见的低效率开发瘦身，怎样应用过程改进方法——避免固执盲从，怎样驱动一个成功的、令你自己满意的职业生涯，怎样不变成暴君——发展并管理一个欣欣向荣的团队！
内容简介
本书以一位微软内部人士的视角，揭示了关于软件编码、软件测试和项目管理中的方方面面问题。作者文笔犀利，见解独到，对软件行业内的很多常见问题提出了解决方案，并提供了最佳实践。本书详细介绍怎样提高软件的质量和价值；切合实际地管理项目的时间表、风险和规范书；为常见的低效率开发瘦身；应用过程改进方法，避免固执盲从；规划一个成功的、令人满意的职业生涯；发展并管理一个欣欣向荣的团队等。
本书是作者对过去在软件行业6个不同的公司、28年的工作经验的一次总结。
本书不仅是微软内部员工的必读之书，也同样适合于软件行业内其他所有工程师和管理者阅读。
作者简介
Eric Brechner，微软公司“卓越开发”部门的总监，在软件行业已经积累了20多年的经验。他从2001年开始写“Hard Code”栏目，作为一种资源提供给微软的员工。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。
目录
序
简介
第1章 项目的不当管理
2001年6月1日：“开发时间表、飞猪和其他幻想”
里氏震级估计
风险管理
客户赢了
2001年10月1日：“竭尽所能：再论开发时间表”
软件工程绝对是含糊的
相信一半你看到的，别信你听到的
激励：不能光靠比萨和啤酒
在日期上沉沦
2002年5月1日：“我们还开心吗？分诊的乐趣”
战争是地狱
这不是个人的事情
分诊的5条黄金法则
魔鬼藏在细节里面
很难进行下去，不是吗？
谨小慎微
2004年12月1日：“向死亡进军”
暗箭伤人
对失败的连祷
转折点
很少有人走过的路
2005年10月1日：“揭露真相”
遭受错觉之苦
拿把叉子扎进我的身体
给我个坦率的回答
给猪抹口红
看看所有这些传言
我想知道真相
第2章 过程改进，没有魔法
2002年9月2日：“六西格玛？饶了我吧！”
啊！这是什么巫术？！
召集骑兵
在混沌之外建立秩序
2004年10月1日：“精益：比帕斯雀牛肉还好”
任何事情都要适中
俭则不匮
过量生产
走向深处
运输
多余动作
等待
过程不当
库存
缺陷
合作共生
2005年4月1日：“客户不满”
但愿不知道
太过分，太迟了
敏捷错觉
回退你的步伐
更多用武之地
使用正确的工具
布基胶带和打包钢丝
客户满意
2006年3月1日：“敏捷子弹”
真理的敌人
拨乱反正
准备改变了吗？
让他说话
你完善我
有点极端
准备玩橄榄球！
最后你要知道的
第3章 根除低下的效率
2001年7月1日：“迟到的规范书：生活现实或先天不足”
对于每次变更，搅动，搅动，搅动
走廊会议
委员会议
规范书变更请求
预防是最好的治疗
2002年6月1日：“闲置人手”
宝宝做了件极坏的事情
告诉我该做什么
俭则不匮
2004年6月1日：“我们开会的时候”
为什么我们会在这里？
我们正在试图做什么？
为什么他们会在这里？
为什么我现在才听到这个？
接下去要做什么？
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
你失去理智了吗？
在那里进退两难
特殊要求
我不记得了
坚持做一件事情
你准备好了吗？
2007年2月1日：“糟糕的规范书：该指责谁？”
树立靶子
沟通分解
保持简单容易
变得稳健
获取反馈
集成质量检查
差别在哪？
第4章 跨越工种
2002年4月1日：“现代临时夫妇？开发与测试”
我怎么爱你？让我来数一下有多少种方式
必要的邪恶或珍贵的伙伴？
每个人都要知道自己的弱点
你完善我
2004年7月1日：“感觉性急——测试者的角色”
高级保护
改变一下对你有好处
黎明时分
充分利用数据
非常酷——我保证你
2005年5月1日：“模糊逻辑——君子之道”
包罗万象
他们跟我们不一样
通过安检
着手去改变
更好地在一起
2005年11月1日：“废除工种——有什么理由搞专业化？”
历经未来的日子
考察它的极限
足球是门科学
两者之间的距离
你深陷其中
第5章 软件质量不是梦
2002年3月1日：“你对你的安全放心吗？”
小心晃动的钟摆
做正确的事
安全受制于最薄弱环节
领导、跟随或者离开
2002年11月1日：“牛肉在哪里？为什么我们要质量”
情况变了
足够好还不行
艰难的选择
终于有足够的时间了
再检查一遍
医生，治好你自己的病
步步为营
太多疑问？
2004年4月1日：“软件发展之路——从手工艺到工程”
工艺制桌子，工程造汽车
其实你知道
真实面对自己
数字的含义
各人有各人的习性
大处着想，小处着手
从优秀到卓越
2005年7月1日：“复审一下这个——审查”
糟糕的混合
完美风暴
谁来负责？
你有什么想法？
正是这个形式
孩子，准备好了吗？
再检查一遍
神奇的汇总会议
审查的诀窍
走上正道
2006年10月1日：“对质量的大胆预测”
谜？我不这么认为
邪恶双煞
嫌疑惯犯
你会喜欢它的
停止卖弄愚蠢
质量就是没有意外
第6章 有时间就做软件设计
2001年9月1日：“错误处理的灾难”
恐怖，恐怖
使用异常
别丢弃，用上它！
2002年2月1日：“厨师太多烧不好菜——惟一权威”
一幅图片抵得上一千个字
有人确切知道现在几点了吗？
只能有一个
万物皆有联系
2004年5月1日：“通过设计解决”
如何才算足够好？
设计完成
细节，细节
让我看看你是由什么组成的
当心缺口
成功处方
2006年2月1日：“质量的另一面——设计师和架构师”
你必须比那做得更好
改变一下对你有好处
他这么做不对
正确的做法
下一次，试试雕塑
关键要有正确的工具
打破这些壁垒
2006年8月1日：“美妙隔离——更好的设计”
分解难做
正确的做法
团队不需要“我”
循序渐进
猫狗不分家
第7章 职业生涯历险
2001年12月1日：“当熟练就是目标”
每个人都要知道自己的弱点
享其成但不坐等
我希望他们尊重我
我们都牵连其中
2002年10月1日：“生活是不公平的——考核曲线”
我不想再逆来顺受了
知识就是力量
关注业务
前进，让我快乐
伸出手去接触某人
有了柠檬？制作柠檬水
改变你的主意
方向盘后面的人
2006年11月1日：“职业阶段中的角色”
一个人同时扮演很多角色
搞清楚职业阶段
我是有抱负的
资历过高
我是特殊的
只能选一个
你想成为什么？
2007年5月1日：“让你自己与世界相连”
你认识的人
我利用习惯
难道你不好奇？
你得到了我们的感谢
我回头再找你
欢迎来到这个世界
第8章 自我完善
2002年12月1日：“要么听我的，要么走人——协商”
一个你无法拒绝的方式
逐渐长大
我脑子里闪过的阴影和凶兆
不要伤害Messenger
皆大欢喜
2005年2月1日：“最好学会平衡生活”
平衡是关键
光说不练
我甚至不能平衡我的支票簿
平衡好，一切都好
2005年6月1日：“时间够用了”
直接告诉我
免受打扰之苦
找到你的乐园
我们谁也不笨
我们必须共同承担
告诉我必须做什么
他还是个孩子
你应该休息一下
这里秩序井然
坦诚相待
大有可为
2005年8月1日：“有理有节地控制你的上司”
我没辙了
知彼知己
他们能自我适应
把水卖给鱼
势利的眼睛
付诸行动
敢于做梦
2006年4月1日：“你在跟我说话吗？基本沟通”
为我着想一下
告诉我你想要什么
你什么时候想要？
缩小注意力跨度
就这样完了？
2007年3月1日：“不只是开放和诚实”
那不是理由
我会对你诚实
那不容易
他们似乎有个开放政策
无处隐藏
跟我想的不一样
走上正道
第9章 成为管理者，而不是邪恶的化身
2003年2月1日：“不只是数字——生产力”
小心你希望得到的东西
扮演一个角色
卓越开发者的素质
你要做法官
2004年9月1日：“面试流程之外”
抱怨得不到帮助
90%是准备
那就是问题
白板编译器
帮招聘专员准备
再次帮面试官准备
友情提醒
最后的难题
2004年11月1日：“最难做的工作——绩效不佳者”
你期望什么？
知难而进
寻求专业援助
没人想失败
目标是成功
无所求，则无所获
你不会总能如愿
2005年9月1日：“随波逐流——人才的保持和流动”
我只是想环球旅行
不错的水坝？
像河水一样流动
新鲜血液
分享就是关爱
成长空间
我必须要旅行
放任自流
2005年12月1日：“我能够管理”
持续送出的赠品
优秀就够了
草率行事
我想要工作
我不是东西
从优秀到卓越
我服务于人
2006年5月1日：“不恰当的比较——病态团队”
想要挑起战争
这不是竞争
我会给你些提示
团结在一起
第10章 微软，你会喜欢它的
2001年11月1日：“我是怎么学会停止焦虑并爱上重组的”
沿着巴别塔下来
地狱里的生活
很少有人走过的路
容忍问题还是主动去解决？
2005年3月1日：“你的产品单元经理是个游民吗？”
有计划的人
我等不及要去实施了
魔鬼藏在细节里面
道路规则
回到正确的跑道上
2006年9月1日：“有幸成为Windows的主宰者”
你还有别的要求吗？
准备轮船
设置路线
启航
导航
责任
下一代Windows
2006年12月1日：“Google：严重的威胁还是糟糕的拼写？”
他们步伐踉跄，我们手舞足蹈
注定要失败
聪明人需要智能客户端
保持警惕
一马当先
2007年4月1日：“中年危机”
你已经变了
日子照过，只不过要掌握一点窍门
不轻易冒险
我认为他们还不能胜任
不再年轻了
不要惊慌失措
没有人是完美的
术语表
书摘插图
第1章项目的不当管理
本章内容：
2001年6月1日：“开发时间表、飞猪和其他幻想”
2001年10月1日：“竭尽所能：再论开发时间表”
2002年5月1日：“我们还开心吗？分诊的乐趣”
2004年12月1日：“向死亡进军”
2005年10月1日：“揭露真相”
我的第一个栏目是在2001年6月刊的微软内部网络杂志《Interface》上发表的。为了进入I.M.Wright的人物角色，我需要一个真正能让我伤脑筋的主题。而工作的时间安排和进度跟踪再好不过了。
项目管理的伟大神话至今都让我疯狂，它的威力远胜过其他任何主题。这些神话是：
1.人们能够按期交付被要求实现的功能（事实上，项目可以按期交付，但人们按期交付功能的概率不会高于击中曲棍球的概率）。
2.有经验的人估计日期比较准（事实上，他们能够较好地估计工作，但不是日期）
3.人们必须按照项目预定的日期按时交付项目（事实上，因为人们不能按期交付被要求实现的功能，而你若想你的项目能够按期交付的话，你必须进行管理风险、范围和通过沟通来减轻人性的弱点可能给项目带来的负面影响）。
在本章中，I.M.Wright讨论了如何通过管理风险、范围和进行沟通，来保障你的项目能够按时完成。前两个栏目专门讨论开发工作的时间安排，接着讨论善后事宜的管理（我们称之为“Bu9分诊”），最后是一篇对死亡行军的声讨，以及一个关于人们为什么要撒谎的哲学栏目。
不得不提的是：通过我在微软多年的工作经历，以及对我所在组织的观察，我发现，项目管理行为和方法在不同规模和抽象层次的组织中，其表现大不相同。这些层次包括：团队或功能层次（10人左右），项目层次（50～5000人，他们一起致力于某个特定的产品发布），以及产品层次（由高层人员主管的多次产品发布）。敏捷方法在团队这个层次能够很好地发挥作用，组织方法在项目这个层次比较适用，而长远的战略规划方法在产品这个层次功效显著。然而，一个人几乎不可能同时在多个层次上工作。时间长河为每个人将这些经历错开了。当一个人从一个层次转到另一个层次工作的时候，他可能会想，在以前那个层次上有效的方法在其他层次上应该也同样有效。灾难就这么产生了！原因很简单：小型、紧凑的群体跟大型、松散的机构在运转方式上是不同的。因此要因地制宜，选择最适合的方法。
——Eric
2001年6月1日：“开发时间表、飞猪和其他幻想”
一匹马走进酒吧，说道：“我能在两天内完成那个功能。”开发成本计算和时问安排是个玩笑。相信它的人，要么是傻瓜，要么是初出茅庐的项目经理。这不是模糊科学，纯粹是杜撰。不错，的确有人相信编码可以被分割成一个可预见进度和质量的可重复的过程，那我儿子至今还相信牙仙子呢！事实上，除非你只需编写10行那么长的代码，或者代码可以直接从以前的工作中复制过来，否则你不可能知道编码会花费你多久时间。
作者注：项目经理（Program Manager，PM）有很多职责，其中最主要的是负责说明最终用户体验和跟踪项目的整体进度。这种角色是必要的，但他们常常不讨开发者的喜欢，因而也很少得到开发者的尊重。真遗憾，项目经理是一份很难做好的工作。但是，对于Wright先生来说，做好项目经理仍然是一个有趣并且容易达到的目标。
里氏震级估计
当然，你可以估计，但估计出来的时间是成对数比例的。有些事情需要花费几个月，有些事情需要几周，有些需要几天，有些需要几个小时，有些则只需几分钟。而我跟我的部门项目经理（Group Program Manager，GPM）一起给一个项目做时间安排时，我们对每个功能使用“困难／中等／容易”3个等级来评估。“困难”意味着一个全职开发人员需要花费整个里程碑时间；“中等”意味着一个全职开发人员需要花费2～3周时间；“容易”意味着一个全职开发人员需要花费2～3天时间。这里没有中间等级，也不做精确的时间表。为什么呢？因为我们俩知道，我们已经不可能知道得再精确了。
在我的记忆里，除了一系列里程碑、测试版、正式版发布等“项目日期”外，我没有在开发时间表上为各个功能规定交付日期。一个好的开发时间表应该是这样的——它只是简单地列出在每个里程碑期间需要实现的功能。那些“必须有”的功能放在第一个里程碑内，并且标上开发人员的数量和“困难／中等／容易”等级；“最好有”的功能放在第二个里程碑内；“希望有”的功能放在第三个里程碑内。除此之外的所有功能统统不做。通常情况下，如果到了第三个里程碑内的第二周，你仍然有较多“最好有”、“希望有”的功能没有实现，这时候大家都很惶恐，你就要把所有“希望有”的功能扔掉，并且将“最好有”的功能也只保留一半。
作者注：里程碑的设定因团队而异，也因产品而异。典型情况下，一个里程碑跨越6～12周不等。它们被认为是“项目日期”，是组织（50-5000人）用于同步工作和复审项目计划的时间点。在里程碑期问，各个团队（3-10人）可能使用他们自己的方法来跟踪具体的工作，比如简单的工作条款清单或bum-down图。
风险管理
这才是我要引出的主题。开发成本计算和时间安排不能只盯着日期或时间不放，而应该关注的是风险管理。我们通过软件的功能和特性来取悦客户，而不管这个软件产品是零售包还是网络服务。这里的风险是，我们否能在合适的时间、将包含必要的功能集合、并且达到一定质量要求的软件产品交付到客户手中。
一个好的开发时间表通过优先处理关键功能来管理风险。这些关键功能是能让客户满意的最小功能集合。通过“困难／中等／容易”这种评级方法，可以判断出在这个最小集合中包含哪些功能才是切实可行的。其他功能按照优先顺序和一致性原则依次加入。
然后你开始编写代码，并且选择功能实现从困难转向容易，或者从容易转向困难。你通过平衡资源，以降低不能按时交付高质量的“必须有”的功能的风险。其他都是次要的，有则锦上添花，没有也无妨，况且你还可以设立不重要、但又不失挑战性的项目交给实习生去做。
作者注：具有讽刺意味的是，几乎所有工程师和经理都赞同要优先处理“必须有”的功能，但事实上很少有人真的这么做，因为“必须有”的功能通常是乏味的，比如安装、建造、向后兼容性、性能和测试套件等。然而没有这些功能，你的产品根本就发布不了。
因此，产品发布往往是因为这些领域的问题一拖再拖。
一定要破除“功能交付日期”的神话，因为开发人员专注于这种日期的时候会破坏风险管理。真正要关心的日期只能是“项目日期”，比如各个里程碑、测试版发布等，而绝不应该是“功能交付日期”。项目日期之间一般都有较长时间的间隔，而且不会很多。管理这几个日期要容易得多。如果要求开发人员在某个日期之前一定要实现某个功能，当他们不能按时完成时他们往往不会告诉你，而是对你说“我正在加紧做……我会加班……”之类的话。
在软件开发过程中进行风险管理，我们还要特别注意以下几个因素：一个是过度劳累的员工，一个是匆匆忙忙实现的、质量很差的功能，再一个就是你花费几周的时间、动用2～3位甚至更多的高级开发人员去解决一个棘手的问题。如果你的开发人员是在围绕“功能交付日期”付出大量的努力，而不是帮助你在产品的关键功能上实现降低风险，那么那些时间真的就被浪费了。
客户赢了
一个产品的成功与否，取决于你对关键功能的风险管理能力。当你给开发团队解释清楚这一点之后，情况就完全不一样了。当然，额外的功能可以锦上添花，但最关键的还是要专注于存在风险的领域，充分沟通，并一起努力把它们解决掉。
当所有人都理解了目标，所有人都能比以前工作得更好。每个艰巨任务的完成都能鼓舞士气，即使新员工也会因为成熟的决议而得到回报。最终，我们的客户是大赢家，因为他们得到了真正想要的功能，并且产品质量也是他们当初所期望的，而不是一些勉强实现的、质量不能保证的垃圾。
顺便提一句，我对开发时间安排的所有论述，对于测试时间安排同样适用。
2001年10月1日：“竭尽所能：再论开发时间表”
该对我6月份的那个栏目（“开发时间表、飞猪和其他幻想”）的评论做出一些回应了。其实，大部分评论都是恭维之词，这里就不再赘述，因为没有必要再次证明我有多么正确。我这里要做的是，去帮助一下那些对那个栏目还在无知中徘徊、但又非常热情的读者朋友们。
软件工程绝对是含糊的
我对关于不能也不应该对一个功能的开发做时间安排的论断表示怀疑。文中的论述精确地描绘了“编码”活动。不幸的是，这是初中生干的事情，类似于他们拼凑一个VB程序来解密信息、相互通信。我们可是软件工程师啊，不是电脑苦工。
——一个充满怀疑的无知者
作者注：这是我仅有的一个“邮件箱”栏目，收集了我对一些读者来信的回复。我还在持续不断地收到读者对我的栏目的大量“反馈”，但一旦一个栏目很受欢迎，很多新的话题便会涌现出来；讨论那些新话题的价值要远远超过对一个老话题邮件的回复。不管怎么样，当我回顾这个早期的栏目时，我意识到，可能Wright先生应该再次清空他的邮件箱了。
我经常听到这种说法，但请就此打住。银行经理并不管理银行，软件工程师也不在软件上做工程。他们开发软件，定制软件，通常随意性很大，对所谓的操作范围、公差、故障率、压力条件等没有明确的度量标准。的确，我们的系统有这些标准，但这些标准不是为软件编码准备的。
我曾到一个工程学校进修过。我的朋友当中也有很多是电力、基建、航空、机械等方面的工程师。工程师做的项目，其建造模块和建筑流程都经过了很好的定义和提炼，而且都是可预测的。虽然有时候为了达到客户的要求需要一个优雅的设计，像写小说一样把各个模块创造性地组合在一起，但最标新立异的建筑也会符合一定的公差要求，并且具有严格的可控质量和功能。
但对软件开发来说，情况就不一样了，尽管很多人竭力想让这两者达成一致。软件的各个构造模块太底层了，变数太多。它们之间的交互影响太难预料了。像Windows、Office、Visual Studio、MSN等大型软件系统的复杂度，已经远远超过了工程的正常范围，以至于哪怕只在这些系统中做微小的功能改动，也无法粗略估计出这些改动所引起的“平均失效时间”。
因此无论好坏，还是抛开痴心妄想和崇高理想，回到现实中来吧！我们必须承认，我们是开发者，而不是工程师。我们不能奢望轻易得到传统的工程领域积累了成百上千、甚至成千上万年的经验才能做到的“可预测性”。这无异于我们奢望：不跟电脑说什么，而电脑却能按照我们心里的想法去做事。我们还办不到！
作者注：在我写下这个栏目6年后的今天，微软已经对其很多软件进行了“平均失效时间”的评估。除此之外，把编程当作工程看待的各种方法也逐渐出现了。这个我会在第5章的“软件发展之路”栏目中再次介绍。纵然如此，我仍然认为本栏目很好地见证了软件开发作为一个领域，他已经走过了幼年，但跟他早已长大成人的传统工程兄弟相比，他还只是个10几岁的小朋友的现状。
相信一半你看到的，别信你听到的
如果我在某个功能或者一段代码上依赖于另外一个团队或产品组，我肯定不想听到像
“你要的东西应该可以在这个里程碑内完成”这样的说法。我需要一个很具体的交付日期。
——一个需要日期的人
我想写几个关于依赖关系和组件团队的栏目，也许将来会吧，但眼下我只想讨论依赖方的开发时间表。首先，假设你的依赖方确实有一份开发时间表，你会相信它吗？你也许会说：“当然要信，我有其他选择吗？”建议在你的溃疡恶化之前赶紧吃一点Pepcid（一种胃酸抑制剂）。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。
但我并不是说你不能同依赖方合作。相反，你可以同他们合作，因为依赖方可能给你的团队、产品和客户带来大量的经验和意外的收获。我只是告诫你要高度警惕当前正在发生的事情。要向他们提出定期多次交付的要求，并对交付的东西进行自动化测试。获取他们对RAID（Redundant Aarry of independent Disk，独立冗余磁盘阵列）进行读和写的RDQ，观察它们的数量以及存在问题的地方。派你的项目经理去参加他们的分诊会议。熟悉他们的E.mail别名。
作者注：查一下本书最后的“术语表”，以便理解这些用于Bug跟踪的词汇。
基本上，你需要像鹰一样盯着依赖方。他们是你的团队和产品的一个扩充。你跟他们接触、沟通得越多，你在规避他们的短处以及促进他们改变方面的能力就越强。至于他们承诺的功能什么时候能够完成，你必须依赖你在如下3个方面上的影响力：提高优先级；沟通渠道；接收测试（为了知道他们的功能是否真正可用了）。
激励：不能光靠比萨和啤酒
总的来说，你的观点用在项目早期的计划上还行，但对于产品发布前的最后一个里程碑就不那么合适了。时间表怎样提供最后期限和时间约束，让团队遵照执行，使得它能作为一种日常管理工具去驱动团队的绩效？你必须要解决诸如之类的问题。
——一个找不到（汽车）油门的人
首先我要重申：如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。如果你不想你的开发团队这么对你的话，你必须建立起一个更好的激励机制。我已经实践了3种不同的方法；如果把它们配合使用，效果更佳！
第一种，也是最基本的方法，就是应用里氏震级估计。我的开发人员知道，我期望的是每个功能在大致那么多的时间内完成。如果一个原先估计需要2周的任务实际上花了2周半，可能关系不大。但如果花的时间比原先估计的要长得多，那么通常是有实实在在的原因的，那个开发人员必然会让我知道这个原因。缺乏充分的理由去延期交付，足以对开发人员形成一种鞭策。然而，因为没有卡得很死的日期，大家几乎不会去想到隐瞒和欺骗。
第二种激励工具是瞄准里程碑日期。这有招致大家走捷径的危险，但总体的效果是鼓励开发人员从一开始就努力工作，并且让他们对自己是否落后于进度做到心里有数。“功能交付日期”和里程碑日期关键的不同在于，后者是给整个团队设置的日期，需要整个团队一起努力去达到它。因此，个人抄近路的压力就会小很多。然而，这种危险性仍然无法杜绝，逼得我使出最后、也是最有效的一招。
作者注：一个自我导向的团队向着一个清晰的共同目标一起努力，这是很多敏捷方法的核心概念，尽管在2001年我还不知道有敏捷方法。
最后一种激励工具是迄今为止我使用起来最有效的。我向团队解释清楚哪些功能是必须要有的，它们必须优先被完成。我告诉他们，必要时任何其他的功能都可能被放弃不做。不幸的是，这些必须要有的功能常常做起来比较乏味，没有意思，甚至不值得一提。因此我告诉我的团队，如果他们想要做那些很酷的功能，必须首先保质保量地完成之前的这些关键功能。在这个前提下，他们才会被鼓励去做那些不那么关键、却要炫得多的东西。这种激励是积极的、有建设性的，并且非常地有效。屡试不爽！
在日期上沉沦
继续前面的讨论：时间表在不同的功能单位之间（不只是开发，还有项目管理、测试、用户体验、市场、外部合作伙伴）同步工作时，绝对是必要的；你还必须要解决这个问题。
——一个没有对齐的脑袋
如果你确实需要具体的“功能交付日期”来同步各个工种和依赖方的工作，那么你的软件永远也没法出货。当然，我们的软件一直在出货——我们甚至准时发布了庞大的Office XP。要知道，它的发布日期是在两年之前计划的。因此，肯定存在其他的一些关键因素。
其实真正起决定作用的，是要在顺序、成本和方法上达成一致，并且提供及时的状态报告。各个工种之间要协商达成协议，定义好状态汇报的流程，并且避免工作的相互牵制。
顺序：对于功能实现的先后顺序的协商已经不是什么新鲜事了，尽管有些部门从来都不能对优先顺序达成一致。
成本：成本的协商通常发生在开发人员和项目经理之间。（比方说一个开发人员说：“如果我们使用标准控件，可以帮你节省2周的时间。”）但有时候就只是开发人员做决定。其实，成本的协商也应该让测试和实施人员参与进来。
方法：对所使用的方法的协商通常在项目管理规范书中做，但很少在开发和测试的规范书中做——这对他们不利。
状态汇报：至于状态的及时汇报，你务必要把邮件和“测试发布文档”（TRD，Test Release Document）登记起来，或者两者任选其一，以便让项目经理、测试和实施人员了解项目的进展情况。测试部门需要对阻碍工作继续进行的Bug使用警报。项目经理采用类似于“规范书变更请求”（Spec Change Request，SCR）的方式来汇报规范书的更改。（了解更多的关于SCR的内容，请阅读第3章的“迟到的规范书：生活现实或先天不足”栏日）
如果各个不同的部门能够对他们的工作顺序进行合理的安排，知道各自的工作需要花费多少时间，对他们使用的方法也很有信心，并且保持着最新的状态报告，那么项目就上轨道了！问题找到了，风险降低了，意外也很少发生。更重要的是，没人有压力去为了几个人为的交付日期而犯错。相反，每个人都朝着同一个目标在努力——为我们的客户交付一个令人愉快的体验。
……
