登入帳戶　 |　訂單查詢　 |　購物車/收銀台( 0 )　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入 新註冊 |　新用戶登記

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / EMS，時效：出貨後2-3日

新書推薦： 《 改变历史的意大利豪门 ： 传奇家族美第奇 》 售價：NT$ 420.0 《 Procreate插画手绘从新手到高手 》 售價：NT$ 493.0 《 山河不足重，重在遇知己 》 售價：NT$ 252.0 《 独自走过悲喜 》 售價：NT$ 381.0 《 永不停步：玛格丽特·阿特伍德传 》 售價：NT$ 442.0 《 假努力：方向不对，一切白费 》 售價：NT$ 335.0 《 北京三万里 》 售價：NT$ 437.0 《 争吵的恋人：我们为什么相爱，又为什么争吵 》 售價：NT$ 330.0

建議一齊購買： + NT$ 407 《 七周七并发模型 》 + NT$ 621 《 人件（原书第3版） 》 + NT$ 456 《 高效能程序员的修炼 》 + NT$ 735 《 设计原本：计算机科学巨匠Frederick P.Brooks的反思（ 精装版）（图灵奖得主、软工之父、《人月神话》作者Brooks经典著作，揭秘软件设计本质！程序员、项目经理和架构师终极修炼必读！全新翻译出版） 》 內容簡介： 本书是《代码大全》的姊妹篇，资深软件开发专家30余年工作经验结晶，被誉为“软件行业的财富”，微软公司软件工程师必读之书。它从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题（大多数问题可能会给公司或软件项目带来毁灭性灾难），并给出了问题的解决方案和最佳实践，值得所有软件工程师和项目管理者研读。 本书将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。 I. M. Wright’s “Hard Code”: A Decade of Hard-Won Lessons from Microsoft, 2E （ISBN：978-0-7356-6170-7） Copyright ? 2011 by Microsoft Corporation Simplified Chinese edition Copyright ? 2013 by China Machine Press. This edition arranged with Microsoft Press through O’Reilly Media, Inc. Authorized translation of the English edition of I. M. Wright''s “Hard Code”:A Decade of Hard-Won Lessons from Microsoft, 2E. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls of all rights to publish and sell the same. All rights reserved. 英文原版由Microsoft Press出版2011。 简体中文版由机械工业出版社出版2013。 简体中文字版由Microsoft Press通过O’Reilly Media, Inc.授权机械工业出版社独家出版。 英文原版的翻译得到O’Reilly Media, Inc.的授权。此简体中文版的出版和销售得到出版权和销售权的所有者——O’Reilly Media, Inc.的许可。 目錄： 本书赞誉 译者序 序 前言 第1版前言 第1章项目管理失当 2001年6月1日：“开发时间表、飞猪和其他幻想” 2001年10月1日：“竭尽所能，再论开发时间表” 2002年5月1日：“我们还开心吗？分诊的乐趣” 2004年12月1日：“向死亡进军” 2005年10月1日：“揭露真相” 2008年9月1日：“我得估算一下” 2009年5月1日：“一切从产品开始” 2009年9月1日：“按计划行事” 2010年5月1日：“敏捷的团队合作” 第2章过程改进，没有灵丹妙药 2002年9月2日：“六西格玛？饶了我吧！” 2004年10月1日：“精益：比五香熏牛肉还好” 2005年4月1日：“客户不满” 2006年3月1日：“敏捷子弹” 2007年10月1日：“你怎么度量你自己？” 2010年10月1日：“有我呢。” 2010年11月1日：“我在缠着你吗？Bug报告。” 2010年12月1日：“生产第一” 2011年2月1日：“周期长度——生产力的老生常谈” 第3章根除低下的效率 2001年7月1日：“迟到的规范书：生活现实或先天不足” 2002年6月1日：“闲置人手” 2004年6月1日：“我们开会的时候” 2006年7月1日：“停止写规范书，跟功能小组呆在一起” 2007年2月1日：“糟糕的规范书：该指责谁？” 2008年2月1日：“路漫漫，其修远——分布式开发” 2008年12月1日：“伪优化” 2009年4月1日：“世界，尽在掌握” 2011年4月1日：“你必须做个决定” 第4章跨越工种 2002年4月1日：“现代临时夫妇？开发与测试” 2004年7月1日：“感觉性急——测试者的角色” 2005年5月1日：“模糊逻辑——君子之道” 2005年11月1日：“废除工种——有什么理由搞专业化？” 2009年1月1日：“持续工程的鬼话” 2011年5月1日：“测试不该不受尊重” 第5章软件质量不是梦 2002年3月1日：“你对你的安全放心吗” 2002年11月1日：“牛肉在哪里？为什么我们要质量” 2004年4月1日：“软件发展之路——从手工艺到工程” 2005年7月1日：“复审一下这个——审查” 2006年10月1日：“对质量的大胆预测” 2008年5月1日：“碰撞测试：恢复” 2008年10月1日：“盯紧标称” 第6章有时间就做软件设计 2001年9月1日：“错误处理的灾难” 2002年2月1日：“太多的厨师弄馊了一锅好汤——唯一权威” 2004年5月1日：“通过设计解决” 2006年2月1日：“质量的另一面——设计师和架构师” 2006年8月1日：“美妙隔离——更好的设计” 2007年11月1日：“软件性能：你在等什么？” 2008年4月1日：“为您效劳” 2008年8月1日：“我的试验成功了！（原型设计）” 2009年2月1日：“绿野中长满蛆了” 第7章职业生涯历险记 2001年12月1日：“当熟练就是目标” 2002年10月1日：“人生是不公平的——考核曲线” 2006年11月1日：“职业阶段上的角色” 2007年5月1日：“与世界相连” 2007年11月1日：“找个好工作——发现新角色” 2007年12月1日：“要么带头做事，要么唯命是从，要么赶紧离开” 2008年7月1日：“猩猩套装中的机遇” 2010年3月1日：“我是很负责的” 2010年4月1日：“新来的伙计” 2010年６月１日：“升级” 2010年９月１日：“辉煌时代” 2011年１月１日：“个体领导者” 第8章自我完善 2002年12月1日：“合作还是分道扬镳——协商” 2005年2月1日：“最好学会平衡生活” 2005年6月1日：“有的是时间” 2005年8月1日：“寓利于乐，控制你的上司” 2006年4月1日：“你在跟我讲吗？沟通的基础” 2007年3月1日：“不是公开与诚实那么简单” 2009年3月1日：“我听着呢” 2009年7月1日：“幻灯片” 2009年12月1日：“不要悲观” 2010年8月1日：“我捅娄子了” 2011年3月1日：“你也不赖” 第9章成为管理者，而不是邪恶的化身 2003年2月1日：“不仅仅是数字——生产力” 2004年9月1日：“面试流程之外” 2004年11月1日：“最难做的工作——绩效不佳者” 2005年9月1日：“随波逐流——人才的保持和流动” 2005年12月1日：“管理我在行” 2006年5月1日：“比较的恶果——病态团队” 2008年3月1日：“必须改变：掌控改变” 2009年6月1日：“奖赏，很难” 2009年10月1日：“招人总是后悔” 2009年11月1日：“管理馊了” 2010年1月1日：“一对一与多对多” 2010年7月1日：“文化冲击” 第10章微软，你会喜欢它的 2001年11月1日：“我是怎样懂得不再焦虑并爱上重组的” 2005年3月1日：“你的产品单元经理是个游民吗？” 2006年9月1日：“有幸成为Windows的主宰者” 2006年12月1日：“Google：严重的威胁还是糟糕的拼写？” 2007年4月1日：“中年危机” 2008年11月1日：“虚无主义及其他的创新毒药” 2010年2月1日：“我们是功能型的吗？” 术语表 內容試閱： 第1章 项目管理失当 本章内容： 2001年6月1日：“开发时间表、飞猪和其他幻想” 2001年10月1日：“竭尽所能，再论开发时间表” 2002年5月1日：“我们还开心吗？分诊的乐趣” 2004年12月1日：“向死亡进军” 2005年10月1日：“揭露真相” 2008年9月1日：“我得估算一下” 2009年5月1日：“一切从产品开始” 2009年9月1日：“按计划行事” 2010年5月1日：“敏捷的团队合作” 我的第一个栏目是在2001年6月微软内部网络杂志《Interface》上发表的。为了进入I?M?Wright的人物角色，我需要找到一个真正让我苦恼的主题。而工作时间表和进度跟踪再好不过了。 项目管理的伟大神话至今都让我疯狂，它的威力远胜过其他任何主题。这些神话是： 1．人们可以按期完成任务（事实上，项目可以按期交付，但项目员工能按期完成各自任务的概率不会高于击中曲棍球的概率）。 2．有经验的人估算日期比较准（事实上，他们能够较好地估算工作，但不是日期）。 3．人们必须准时完成各自的任务从而使整个项目按时交付（事实上，员工们不能按时完成自己的任务，所以你若想你的项目能够按期交付的话，你必须进行风险管理、范围管理并通过沟通来减轻人性的弱点可能给项目带来的负面影响）。 在这一章中，I?M?Wright将讨论如何通过管理风险、范围和沟通，来保障项目能够按时完成。前两个栏目专门讨论开发工作时间表，接着讨论善后事宜的管理（我们称之为“Bug分诊”）、死亡行军、撒谎以掩饰问题、快速而精准的估算、服务管理、风险管理，以及在一个大型项目中整合各种方法以便协同运作。 不得不提的是，通过我在微软这些年工作期间的观察，在不同的规模、不同的抽象层次中，项目管理有不同的表现形式。这些层次包括：一个团队或功能层次（大概10人左右）、项目层次（50～5 000人为一个特定版本工作）以及产品层次（由高级主管领导的多个版本开发）。敏捷开发在团队层次很适用，传统方法在项目层次中很适用，而长期的战略性规划方法在产品层次很适用。然而，人们很少同时在不同层次工作，实际上，每个人总是会分年段地在这些层次间工作。所以人们常常认为某一层次的高效方法应该应用到其他层次上，悲剧就这样产生了。准则就是：小型、紧凑的团队跟大型松散的组织动作方式不同，应相应地选择适合你的方法。 ——Eric 2001年6月1日：“开发时间表、飞猪和其他幻想” 一匹马走进酒吧，说道：“我能在两天内完成那个功能。”开发成本计算和时间表是个笑话。相信它的人，要么是傻瓜，要么是初出茅庐的项目经理。这不是模糊科学，这是瞎编。不错，的确有人相信编码工作可以被精炼成一个可预见进度和质量的可重复的过程，那我儿子至今还相信牙仙子呢！事实上，除非你只需编写10行那么长的代码，或者代码可以直接从以前的工作中复制过来，否则你不可能知道编码会花费多长时间。 作者注：项目经理（Program Manager，PM）有很多职责，其中职责之一是说明最终用户体验和跟踪所有项目的整体进度。这种角色是必要的，但他们常常不讨开发者的喜欢，因而也很少得到开发者的尊重。真遗憾，项目经理是一份很难做好的工作。但是，对于Wright先生来说，项目经理仍然是一个有趣并且容易达到的目标。 译者注：①关于牙仙子（Tooth Fairy）。美国人有个信仰：小孩子换牙时，父母会告诉他把牙齿用信封装好，放在枕头下，早上起来的时候牙仙子会用钱跟他换牙齿。这钱当然是父母给的，用来鼓励小孩子拔牙。牙仙子在美国是人尽皆知的，虽然只是一个“善意的谎言”!②关于飞猪（Flying Pigs）。猪会飞吗？美国人常用此来比喻离奇荒诞之事。 里氏震级估计 译者注：里氏震级（Richter?scale）是地震等级的一种数值标度，分1～10级，每上升一级，强度增加约60倍。 当然，你可以估算，但估算出来的时间是成对数关系的。有些事情需要花费几个月，有些事情需要几周，有些需要几天，有些需要几个小时，有些则只需几分钟。而我跟我的项目组项目经理（Group Program Manager，GPM）一起给一个项目做时间安排时，我们对每个功能使用“困难中等容易”3个等级来评估。“困难”意味着一个全职开发人员需要花费整个里程碑时间；“中等”意味着一个全职开发人员需要花费2～3周时间；“容易”意味着一个全职开发人员需要花费2～3天时间。没有其他等级了，也不做精确的时间表。为什么呢？因为我们俩知道，我们无法预测更精确的时间了。 在我的记忆里，除了一系列里程碑、测试版、正式版发布等“项目日期”外，我没有在开发时间表上为各个功能规定交付日期。一个好的开发时间表应该是这样的——它只是简单地列出在每个里程碑期间需要实现的功能。那些“必须有”的功能放在第一个里程碑期间内并且都是要完成的，如何完成则是根据开发人员的数量和“困难中等容易”等级；“最好有”的功能放在第二个里程碑期间内；“希望有”的功能放在第三个里程碑期间内；除此之外的所有功能统统不做。通常情况下，如果到了第三个里程碑期间的第二周，仍然有较多“最好有”、“希望有”的功能没有实现，这时候大家都很惶恐，你就要把所有“希望有”的功能扔掉，并且“最好有”的功能也只保留一半。 作者注：里程碑的设定因团队而异，也因产品而异。典型情况下，一个里程碑跨越6～12周不等，是“项目日期”，是组织（50～5 000人）用于同步工作和复审项目计划的时间点。在里程碑期间，各个团队（3～10人）可能使用他们自己的方法来跟踪具体的工作，比如简单的工作条目（work?item）清单、产品备忘录及实施进程图。 译者注：产品备忘录（product backlog）是在项目开始的时候，需要准备一个根据商业价值优先级排好序的客户需求列表，是一个最终会交付给客户的产品特性列表，涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。实施进程（burn?down）图是敏捷软件开发方法Scrum中常用的一种图表，用来展示剩余待完成工作与时间之间的关系。时间标识在横坐标轴上，未完成工作标识在纵坐标轴上。 风险管理 这才是我要引出的主题。在开发成本计算和时间安排上不能只盯着日期或时间不放，应该关注风险管理。我们通过软件的功能和特性来取悦客户，不管这是个软件套包还是网络服务。这里的风险指的是，我们未能在合适的时间，将符合质量要求的功能集合交付到客户手中。 一个好的开发时间表通过优先处理关键功能来管理风险。这些关键功能是能让客户满意的最小功能集合。通过“困难中等容易”这种评级方法，可以判断出在这个最小集合中包含哪些功能是切实可行的。其他的功能按照优先顺序和一致性原则依次加入。 然后你开始编写代码，并且看着功能实现从困难转向容易，又从容易转向困难。通过集中所有必要的资源，以降低不能按时交付高质量的“必须有”的功能的风险，其他的都是次要的。你还可以将不紧要、但又不失挑战性的项目交给实习生去做。 作者注：具有讽刺意味的是，几乎所有的工程师和经理都赞同优先处理“必须有”的功能，但事实上很少有人真的这么做，因为“必须有”的功能通常是乏味的，比如安装、软件工程创建、向后兼容性、性能优化和测试套件等。然而没有这些功能，你的产品根本就无法发布。因此，产品发布往往是因为这些问题而一拖再拖。 一定要破除“功能交付日期”的神话，因为开发人员专注于这种日期的时候会破坏风险管理。真正要关心的日期只能是“项目日期”，比如各个里程碑、测试版，等等，而绝不应该是“功能交付日期”。项目日期之间一般都有较长时间的间隔，而且这种日期不会很多。管理这几个日期要容易得多。如果要求开发人员在某个日期之前一定要实现某个功能，当他们不能按时完成时他们往往不会告诉你，而是对你说“我正在加紧做……我会加班……”之类的话。 在软件开发过程中进行风险管理，我们还要特别注意以下几个因素：一个是过度劳累的员工，一个是匆匆忙忙实现的、质量很差的功能，再一个就是你花费几周的时间且动用2～3位甚至更多的高级开发人员去解决一个棘手的问题。如果你的开发人员是在围绕“功能交付日期”付出大量的努力，而不是帮助你在产品的关键功能上降低风险，那么真有可能浪费时间了。 客户赢了 一个产品的成功与否，取决于你对关键功能的风险管理能力。当你给你的开发团队解释清楚这一点之后，情况就完全不一样了。当然，额外的功能可以锦上添花，但最关键的还是要专注于存在风险的地方，充分沟通，并一起努力把它们解决掉。 当所有人都理解了目标，所有人都能比以前工作得更好。每个艰巨任务的完成都能鼓舞士气，即使初级员工也会因为成熟的决议而得到回报。最终，我们的客户是大赢家，因为他们得到了真正想要的功能，并且产品质量也是他们当初所期望的，而不是一些勉强实现的、质量不能保证的垃圾。 顺便提一句，我对开发时间表的所有论述，对于测试时间表同样适用。 2001年10月1日：“竭尽所能，再论开发时间表” 该对我6月份的那个栏目（“开发时间表、飞猪和其他幻想”）的评论做出一些回应了。其实，大部分评论都是恭维之词，这里就不再赘述了，因为没有必要再次证明我有多么正确。我这里要做的是，回应一下那些对那个栏目还在无知中徘徊但又非常热情的读者朋友们。 作者注：这是我仅有的一个“邮包”栏目，收集了我对一些读者来信的回复。我还在持续不断地收到读者对我的栏目的大量“反馈”，但一旦一个栏目很受欢迎，很多新的话题便会涌现出来；讨论那些新话题的价值要远远超过对一个老话题邮件的回复。不管怎么样，当我回顾这个早期的栏目时，我意识到，可能Wright先生应该再次清空他的邮包了。 软件工程绝对是含糊的 我对关于不能也不应该对一个功能的开发做时间安排的论断表示怀疑。文中精确地论述了“编码”活动。遗憾的是，这是初中生干的事情——拼凑一个VB程序来解密信息、相互通信。我们可是软件工程师啊，不是电脑苦工。 ——一个充满怀疑的无知者 我经常听到这种说法，但请就此打住。银行经理并不管理银行，软件工程师也不在软件上做工程。他们开发软件，定制软件，通常事无巨细、从头至尾参与其中，并不需要了解操作范围、公差、故障率、压力条件等度量标准。的确，我们的系统有这些标准，但这些标准不是为软件编码准备的。 我曾到一个工程学校进修过。我的朋友当中也有很多是电力、基建、航空、机械等方面的工程师。这些工程师做的项目，其构造模块和结构流程都经过了很好的定义和提炼，而且都是可预测的。虽然有时候为了达到客户的要求需要一个合适的设计，但只要用一种新颖的方法把各个模块组合在一起就很有创造性了，就算是最标新立异的建筑也会符合一定的公差要求，并且具有严格的可控质量和功能。 但对软件开发来说，情况就不一样了，尽管很多人竭力想让这两者达成一致。软件的各个构造模块太底层了，变数太多。它们之间的交互影响太难预料了。像Windows、Office、Visual Studio及MSN等大型软件系统的复杂度，已经远远超过了工程的正常范围，以致哪怕只在这些系统中做微小的功能改动，也无法粗略估计出这些改动所引起的“平均失效时间”。 因此无论好坏，还是抛开痴心妄想和崇高理想，回到现实中来吧！我们必须承认，我们是开发者，而不是工程师。我们不能奢望轻易得到传统的工程领域积累了成百上千年的经验才做到的“可预测性”。这无异于我们奢望：不用跟电脑说什么，电脑就能按照我们心里的想法去做事。我们还办不到！ 作者注：在我写下这个栏目6年后的今天，微软已经对很多软件进行了“平均失效时间”的评估。除此之外，把编程当做工程看待的各种方法也逐渐出现了。这个我会在第5章的“软件发展之路——从雕虫小技到系统工程”栏目中再次介绍。纵然如此，我仍然认为本栏目很好地见证了软件开发作为一个专业领域，它已经走过了幼年，但跟它早已长大成人的传统工程兄弟相比，他还只是个十几岁的小朋友。 相信一半你看到的，别信你听到的 如果我在某个功能或者一段代码上依赖于另外一个团队或产品组，我肯定不想听到像“你要的东西应该可以在这个里程碑期间内完成”这样的说法。我需要一个很具体的交付日期。我要有具体细节。 ——一个需要日期的人 我想写几个关于依赖关系和组件团队的栏目，也许将来会吧，但眼下我只想讨论依赖方的开发时间表。首先，假设你的依赖方确实有一份开发时间表，你会相信它吗？你也许会说：“当然要信，我有其他选择吗？”建议在你的胃病恶化之前赶紧吃一点PepcidTM（一种胃酸抑制剂）。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。 但我并不是说你不能跟依赖方合作。相反，你应当与他们很好地合作，因为依赖方可能为你的团队、产品和客户带来大量的经验和意外的收获。我只是告诫你要高度警惕当前正在发生的事情。要向他们提出定期多次交付的要求，并对交付的东西进行自动化测试。获取他们对RAID进行读和写的RDQ，观察它们的数量以及存在问题的地方。派你的项目经理去参加他们的分诊会议。加入他们的邮件列表。 作者注：查一下本书最后的“术语表”，以便理解这些用于Bug跟踪的词汇。 基本上，你需要像鹰一样盯着依赖方。他们是你的团队和产品的一个扩充。你跟他们接触、沟通得越多，你在规避其短处以及促进其改变方面的能力就越强。至于他们承诺的功能什么时候能够完成，你必须依赖你在如下3个方面上的影响力：提高优先级，沟通渠道，独立测试（为了知道他们的功能是否真正可用了）。 激励：不能光靠比萨和啤酒 总的来说，你的观点用在项目早期的计划上还行，但对于产品发布前的最后一个里程碑就不那么合适了。时间表怎样提供最后期限和时间约束，让团队遵照执行，使得它能作为一种日常管理工具去激励团队的执行力？你必须要解决诸如此类的问题。 ——一个找不到（汽车）油门的人 首先我要重申：如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。如果你不想你的开发团队这么对你的话，你必须建立起一个更好的激励机制。我用过3种不同的方法，这些方法能使大家互相协调工作并产生良好效果。 第一种，也是最基本的方法，就是应用里氏震级估计。我的开发人员知道，我期望的是每个功能在大致那么多的时间内完成。如果一个原先估计需要2周的任务实际上花了2周半，可能关系不大。但如果花的时间比原先估计的要长得多，那么通常是有实实在在的原因的，那个开发人员必然会让我知道这个原因。如果缺乏充分的理由去延期交付，则足以对开发人员形成一种鞭策。然而，因为没有卡得很死的日期，大家几乎不会去想到隐瞒和欺骗。 第二种激励工具是瞄准里程碑日期。这有招致大家走捷径的危险，但总体的效果是鼓励开发人员从一开始就努力工作，并且让他们对自己是否落后于进度做到心里有数。“功能交付日期”和里程碑日期关键的不同在于，后者是给整个团队设置的日期，需要整个团队一起努力去达到它。因此，个人抄近路的压力就会小很多。然而，这种危险性仍然无法杜绝，逼得我使出最后也是最有效的一招。 作者注：一个自我导向的团队向着一个清晰的共同目标一起努力，这是很多敏捷方法的核心概念，尽管在2001年我还不知道有敏捷方法。 最后一种激励工具是迄今为止我使用起来最有效的。我向团队解释清楚哪些功能是必须要有的，必须优先完成。我告诉他们，必要时任何其他的功能都可能被放弃不做。遗憾的是，这些必须要有的功能常常做起来比较乏味，没有意思，甚至不值得一提。因此我告诉我的团队，如果他们想要做那些很酷的功能，必须首先保质保量地完成之前的这些关键功能。之后，再去做那些不那么关键却要炫得多的东西。这种激励是积极的，有建设性的，并且非常有效。屡试不爽！ 在日期上沉沦 继续前面的讨论：时间表在不同的功能单位之间（不只是开发，还有项目管理、测试、用户体验、市场推广、外部合作）同步工作时，绝对是必要的；你还必须要解决这个问题。 ——一个出格的人 如果你确实需要具体的“功能交付日期”来同步各个方面和依赖方的工作，那么你的软件永远也没法发布。当然，我们的软件一直在发布——我们甚至准时发布了庞大的Office XP。要知道，它的发布日期是在两年之前计划的。因此，肯定存在其他的一些关键因素。 其实真正起决定作用的，是要在顺序、成本和方法上达成一致，并且提供及时的状态报告。各个方面之间要协商达成协议，定义好状态汇报的流程，并且避免工作的相互牵制。 ? 顺序：讨论协商各个功能实现的先后顺序已经不是什么新鲜事了，尽管有些部门从来都不能对优先顺序达成一致。 ? 成本：成本的协商通常发生在开发人员和项目经理之间（例如一个开发人员说：“如果我们使用标准控件，可以帮你节省2周的时间。”）但有时候就只是开发人员做决定。其实，成本的协商也应该让测试和实施人员参与进来。 ? 方法：讨论协商使用哪种方法通常在项目管理规范书中做，但很少在开发和测试的规范书中做——这对他们不利。 ? 状态汇报：至于状态的及时汇报，你务必要把邮件和测试发布文档（Test Release Document，TRD）登记起来，或者两者任选其一，以便让项目经理、测试和实施人员了解项目的进展情况。测试部门需要对阻碍工作继续进行的Bug使用警报。项目经理采用类似于“规范书变更请求”（Spec Change Request，SCR）的方式来汇报规范书的更改。（了解更多关于SCR的内容，可阅读第3章的“迟到的规范书：现实生活还是先天不足”栏目。） 如果各个不同的部门能够对他们的工作顺序进行合理的安排，知道各自的工作需要花费多少时间，对他们使用的方法也很有信心，并且保持着最新的状态报告，那么项目就上轨道了！问题找到了，风险降低了，意外也很少发生。更重要的是，没人顶着因为人为的交付日期而犯错的压力。相反，每个人都朝着同一个目标在努力——为我们的客户交付一个令人愉快的体验。 2002年5月1日：“我们还开心吗？分诊的乐趣” 如果你没有把这个概念搞清楚，请告诉我…… 项目经理希望瞬间得到无穷多个功能，测试人员和服务营运人员希望永远也不要增加新的功能，而开发人员只想在不受外界干扰的环境下编码实现很酷的东西。现在，邀请这几个方面的主管，让他们带着相互冲突的理想去同一间房间，关上门，再给他们点可以用来打架的东西。会发生什么呢？分诊！ 作者注：当产品开发问题涌现（比如未完成的工作条目、Bug或设计变更）出来时，它们都被记录在一个工作条目数据库中。分诊会议就是为了安排这些问题的优先级，并且决定每个问题如何解决而召开的。很多“冲突”（保守的说法）就是源自于这个会议。 译者注：关于分诊（Triage）。这是一种根据紧迫性和救活的可能性，在战场上决定哪些人优先治疗的方法。战地医学的基本原则之一是，如何将伤者划分为3类：①无论是否接受医疗都会死亡；②无论是否接受治疗都没有生命危险；③只有及时地接受医治才能保全性命。抛开它的病理本质，分类本身极其重要，只要你希望最大限度地保存有生力量。如果你不进行分类，结果将会比你做分类时要糟糕得多。 很庆幸，鲜血没有从分诊室的门缝中流出来。当然，这正是调解员要做的事情。大部分分诊会议都搞得像大屠杀一样。但必须要这样吗？我在微软见过的几次最激烈的争吵就发生在分诊会议室里。这样很糟糕吗？抑或就该这样子？ 战争是地狱 参加过残酷的分诊会议的人，他们都会告诉你这样不好。即使你赢得了大部分的争论，你也会被这粗暴的分诊搞得精疲力竭。 基本上，病态的分诊和病态的团队常常同病相怜。它们在团队成员身上制造坏的“血液”，让他们常常产生报复性的、毫无建设性的行为。 为什么要这样呢？我们这里鼓励激情。我们想要人们为他们的信念而战，站在我们客户的立场上做出正确的决定。带一点点健康的竞争有问题吗？然而，当这竞争不是一点点也不健康时，那就不好了。 这不是个人的事情 不应该认为Bug是个人的事情，但事实却是这样的： ? 对于发现Bug的那个测试人员来说，Bug代表着他工作的质量：“什么叫这个Bug不够好，无需修复？” ? 对于定义这个功能的项目经理来说，Bug考验着他当初的设计：“那个Bug完全摧毁了这个功能的特色！” ? 对于服务营运人员来说，Bug意味着实实在在的、可能永无穷尽的工作：“什么，你不关心这个Bug？反正不要你每天早上3点钟进办公室来重启服务器！” 作者注：关于早上3点钟重启的趣事。像大部分提供软件服务的公司一样，微软现在正在改变营运模式，不再提供每周7天、每天24小时的不间断电话服务了。取而代之的是，我们把服务设计成具有自愈能力（重试、重新开始、重启、重新镜像、重置机器）的系统。现在的服务营运人员只需在正常的上班时间，根据自动产生的替换清单对组件进行更换就行了。 ? 对于开发人员来说，Bug代表着一种个人的价值判断：“事情没那么糟糕吧！” 分诊所做的决定应该基于我们客户的利益和微软的利益，而不能光凭个人的感觉。然而，因为各个方面对于Bug有着各自不同的立场，分诊讨论转眼之间就会脱离轨道。 分诊的5条黄金法则 你怎样才能保证分诊正常地进行并且具有建设性呢？采纳我下面的5条黄金法则吧： 1?关上门。分诊是一个协商的过程，而协商最好在私底下进行。当做决定的过程保密时，大家更容易坦诚相见、相互妥协乃至达成一致。这也便于分诊的与会者把他们的决定作为团队的决定向其他人解释。 2?所有的决定都是团队决定。当达成一致意见之后，所做的决定就不再是个人决定，而已经上升到了组织的高度。作为分诊团队中的一员，每个人都要无条件地支持这些决定。分诊的与会者应该具备为每个分诊决定做出辩解的能力，就好像这些决定完全出自于他自己一样。 3?每个专职领域只派一名代表。分诊必须快刀斩乱麻。遗憾的是，参与的人越多，过程就越漫长；个人情绪掺杂得越多，一致的结论也越难达成。一个人做个决定可以很迅速，但你需要整合各个方面的观点来做出一个集思广益的选择。因此，折中的办法是，每个专职方面各派出一名代表参与讨论，从而兼顾效率的同时，使各方观点得以充分体现。 4?指定一个可以做最终决定的人。如果与会者不能达成一致，我们就需要有一个人做出最终决定——理想的话，这种情况不会发生。就我个人而言，我更倾向于让项目经理来做这个最终决定，因为项目经理本来就是做协调工作的，之后也是他的职责要去解释这些决定并让其付诸执行。他应该不会滥用这个特权。然而，真正的威胁还在于，可能会有某个工程方面的代表（绕开项目经理！）把他的决定强加给所有的与会者，这样也能让大家达成一致。 5?所有的决定都应遵从“贵格会”信条。这是最重要的一条法则。通常所说的“一致意见”意味着所有人都同意，但对于像分诊这样艰难、牵涉个人观点的事情，这个要求显然太高了。遵从“贵格会”信条只是意味着没有人反对——所有与会者必须为大家都能接受的解决方案而协同工作，只要不起冲突即可。这样就会产生一种很容易就能实现的、通常也是最理想的结果。（注意：这里说的“贵格会”只是指遵从相同信条的一类人，而不是有宗教信仰的那种。） 遵照上述5个法则，你的分诊就会充满热情、具有建设性并且富有效率。不过，下面我还要讲一些细节问题，以使得本栏目更加充实。 魔鬼藏在细节里面 这里有一些细节上面的处理技巧，可以让你的分诊会议开得更加顺利： ? 如果你们的争论针对的是人，而不是Bug，你就需要把焦点转移到“做什么最有利于客户和长期股票价格”的话题上去。这种方法避开了讨论个人问题，同时把会议的焦点集中到了它本该集中的地方。 作者注：在所有的栏目中，我都在谈论要把注意力放在客户和业务上，而不是个人问题上。你可能想知道，为什么你不能只考虑客户，而不去管长期的股票价格。我对这个观点表示理解，但我也知道，如果我们的业务做得不好的话，我们也就没有客户了。因此，拥有一个商业计划来指引我们的工作，这对于为我们的客户提供可持续性的利益是很必要的。 ? 如果你对某个Bug或某个修复需要得到额外的信息，有时候你需要通过电话或亲自从分诊团队之外邀请一个人进来。请记住，当你完成提问之后，继续争论你们的决定之前，一定要送走这个访客。否则，分诊的机密性就会被破坏，所做的决定也就不再是分诊决定了。 ? 如果你想让你的团队中的某个人了解分诊过程，则可以邀请他加入一个分诊会议，但叮嘱他，务必在你们讨论期间要像趴在墙上的苍蝇那样保持安静，并且向他强调协商过程的机密性。 很难进行下去，不是吗 如果一个或几个分诊团队成员不能就某个问题达成一致，会议无法进行下去，就给他们一些“银弹”吧！游戏规则是，你任何时候都可以用银弹来获取特权，让大家遵从你的意见，但是子弹用掉一颗就少一颗，用完为止。当有人在某个问题上不肯屈服的时候，可以问他：“你想用一颗银弹吗？”如果用，其他人都要支持他的决定。通常这个人会说：“不，不，这事没那么重要。”然后，会议可以继续进行下去。 作者注：几年来，这个关于分诊的栏目引来了大量的争论，特别是上面关于“银弹”的这段。有些人抱怨不应该使用“子弹”这个字眼，而要用“令牌”。更多的抱怨是：一个关键的团队决定可能由某个人通过使用他的“银弹”做出，这个很危险！但实际上，这种事情永远也不会发生。“银弹”是一种稀有资源，它用来帮助它的主人提升问题的重要性。大家不会轻易使用它。因此，如果有人在一个关键问题上滥用一颗“银弹”的话，总会有其他人使用剩下的“银弹”去对抗他。尽管如此，我还从来没听说有这种事情发生呢！ 最后，该到数据库中去解决分诊会议讨论过的Bug了： ? 记得使用“分诊”标签去表示这是一个分诊会议决定。 ? 记得解释清楚分诊团队所做决定背后的考量。 ? 不要去“解决”Bug（尤其是外部Bug），除非你再也不想看到它了。通常情况下，团队把有碍产品发布的Bug标为“外部”或“待办”，意思是说，“我们现在不想处理这个Bug，以后会另行安排。”但如果那个Bug被“解决”了，它就落在了“雷达”能够扫描到的有效区域之外，相应的问题也就被隐藏了起来。 作者注：你可以在第2章“我烦扰你了吗？Bug报告”中看到关于Bug、优先级、分辨率的话题。 谨小慎微 分诊被证明是你需要对团队履行的最重要的职责之一。良性的分诊会议几乎总是跟良性的项目和项目组直接相关。这种关系的真正美妙之处在于，积极、富有成效且愉悦的分诊会议将给你的工作、你的团队带来同样的效果。但跟解决团队和项目的全部问题比起来，解决分诊中遇到的问题要容易得多，牵扯的人也要少得多。 再好不过的是，你们使分诊会议得以改善，并步入正轨，这可能会成为你一整天最快乐的事。当分诊的焦点是Bug而不是人，大家意见统一而不是相互攻讦时，那么会议的紧张气氛就会消散，纷争与挫败就会以诙谐的氛围而代之。健康良性的团队在一起工作，他们开的分诊会议常常充斥着俏皮话、玩笑、矫情讽刺和令人发笑的误述。对你的分诊技巧做一些适当的调整吧——你们的笑声可能会传到走廊上，久久回荡！最好总是关着门。 2004年12月1日：“向死亡进军” 曾经在一个死亡行军的项目组呆过吗？也许你现在所做的项目正是。这类项目有很多种定义，但基本上都可以归结为，“在太少的时间内要做太多事”。因此，你被要求在一段很长的时期内，每天工作很长的时间，以消除两者之间的矛盾。死亡行军因为其漫长、艰辛和伤亡重而得名。（如果我的说法伤害到了在第二次世界大战中真正经历过死亡行军的那些人的亲属，我道歉。不过，遗憾的是，软件中随处可见不当文字的使用。） 很难搞明白，为什么这么多项目组继续进行死亡行军，即使他们几乎肯定会失败，有时候还很悲壮！毕竟，毫无疑问，你在走向死亡。我看不出有任何诱因所在。 译者注：关于死亡行军（Death March），典出第二次世界大战太平洋战场的菲律宾群岛。1942年夏季，日军相继猛攻巴丹半岛和哥黎希律岛，美菲联军大败，美国远东军司令麦克阿瑟携夫人乘潜艇逃出战场。接替指挥战局的温赖特少将遵照白宫旨意，认为坚持抵抗只会造成无谓的伤亡，便命令全部美菲军队无条件投降。然后，日军派人把温赖特将军押送到中国沈阳，关入监狱。同时下令美菲所有被俘人员做长距离徒步行军，从巴丹半岛的马利维尔斯奔向位于圣费南多的俘虏营，行程长达1 000多公里。此时正值炎夏，病疫流行，粮食匮乏，日军对战俘更是恣意虐杀；等到达目的地的时候，死伤人数竟达25 000余人。几个月之后，有3名美国士兵从日军战俘营中侥幸逃出，越海到达澳大利亚的布利斯坦，揭开了这次死亡行军的秘密。 暗箭伤人 愚蠢的管理层继续热衷着死亡行军，他们暗箭伤人，因此我要拿出其中的几支“暗箭”来曝曝光。 作者注：死亡行军不只在微软才有，也不是只有微软才普遍存在这样的问题。这是我当初加入这个公司时发现的一个令我吃惊的事实。早在1995年我加入微软之前，这个公司就已经以工作时间长而闻名了。对此我很担心，因为我有一个两岁的儿子，并且计划再要一个。但我的上司明确地告诉我，死亡行军并不是公司的制度。他的话是对的，但当微软或其他公司的管理层仍然对这种愚蠢而又不可思议的做法抱有幻想时，那就是另外一回事了。 ? 管理层神经太大条。管理者做事情不考虑后果。他们采用傻瓜才用的方法：太多的工作要做吗？那就加油干吧！最起码，管理者可以辩解说，他们正在做着事情，哪怕做的可能都是错事。 ? 管理层天真得难以置信。管理者不知道死亡行军是注定要失败的。不知何故，好像他们在过去的25年里都在睡觉，或者从来就没有读过一本书、一篇文章，或没有访问过任何网络站点。他们认为，每天至少多工作4个小时，并且每周多增加2个工作日，将会使生产力翻倍。数学可以这么算，但遗憾的是，人是非线性的，不能这么简单地加减。 ? 管理层不切实际。管理者认为，他们的团队能够克服难以逾越的难题。规则和纪录将被打破。他们有世界上最好的团队，他们的团队能够应对任何挑战。显然，他们不明白速度超过一头牛（很难）与快过子弹（不可能）之间的区别。 ? 管理层没头脑、不负责任。管理者知道死亡行军必将失败，这个过程会摧毁他们的团队，但他们还是会蛮干，逞英雄。他们通过请客吃饭、评选明星和高分考核来奖励英雄行为。因为管理者知道，我们的客户和合作伙伴在下一次复审结束之前，是不会被我们交付的“垃圾”吓跑的。我觉得这些管理者是最该被拖去让史蒂夫痛斥一顿的。 作者注：史蒂夫是指史蒂夫?鲍尔默（Steve Ballmer），我们敬爱的CEO。他大力提倡工作与生活的平衡，并且以身作则。我曾多次看到他在他儿子的篮球比赛中加油呐喊，或者和他妻子一起在外面看电影。 ? 管理层都是些毫无责任感的懦夫。管理者知道死亡行军很难避免，但他们缺少勇气说“不”。因为，如果他们随大流，他们就不用承担什么责任，这些懦夫也不会因为项目失败负多大责任。当然，项目一旦失败，他们的员工会恨他们，并且离开团队，但至少他们还可以和跟他们一样懦弱、可怜的朋友分享“战争”的故事。 很多人都撰稿论述过在软件项目中死亡行军的无效性，但不知何故还是有人“慷慨赴死”。我无法说服那些不切实际、不负责任的人，但我可以开导那些神经大条、天真的人，并且教懦弱的人一些方法。 对失败的祈祷 给无知者的一些启迪——死亡行军之所以会失败，是因为： ? 一开始就注定要失败。很明显，你有太多太多的事情要做，但你的时间远远不够。你必败无疑！ ? 怂恿大家走捷径。当你处在压力之下时，没什么比找一些省事的方法逃离工作更自然的了。遗憾的是，捷径降低质量，并且增加风险。这对于小功能或短期之内的项目或许关系不大。但随着项目不断深入，那些风险和糟糕的质量会贻害无穷。 ? 没有太多的时间去思考。项目需要松弛的时间来产生效率。大家需要时间去思考、阅读和讨论。没有这种时间，你就只能凭着仓促的判断去做事情。而仓促的判断往往是错误的，导致糟糕的设计、计划和质量，引来以后大量的返工或成堆的缺陷。 ? 没有太多的时间沟通。你说得对，沟通不畅和误解是所有麻烦之源。很多其他方面运作良好的项目，就是因为沟通上的问题才失败。当人们每天都要工作很长的时间，他们就无暇顾及沟通，效率也很低。沟通不畅成了一个难以逾越的障碍。 ? 制造紧张、压力和机能障碍。当有压力存在时，适意首先消失了。大家都自顾不暇。意外事件不断被扩大和曲解，抱怨声越来越多，甚至出现更坏的情况，大家不再说话。 ? 士气受挫、动力受损。辛酸、压力及长时间与家庭和朋友疏远，都使人的精神和人际关系折损。最终当项目难逃失败，错过了交付日期，也没有达到质量目标，人们常常会抓狂。如果幸运的话，你只是在项目结束之后转到另一个项目组继续工作。如果不那么幸运，你可能要离职、离婚、生病甚至有轻生的念头。 顺便说一下，管理者常常分不清一些员工在工作上长时间的自愿付出和死亡行军之间的差别。死亡行军是完全不同的概念。它们之间的区别在于，死亡行军强制你付出很多的时间。而当人们自愿时，常常是因为他们真的喜欢。这段时间里他们很放松，没有任何压力或理由去走捷径。 作者注：这是常被人们忽略的最关键的一点。自愿的长时间工作跟死亡行军绝对是不同的。 ? 信心在进程中消失。稍微有点智商的人就能意识到，死亡行军是对出现的问题的一种补救。这样做对于我们的员工、客户及合作伙伴来说不是奉献，是个人能力出了问题。只是埋头工作，回避真正的问题，只会更有损于他人对我们合作能力的评价。 ? 不妥善解决问题。工作更长时间不能解决那个真正导致“在太少的时间内要做太多事”的问题。除非这个问题根除了，否则别指望项目除了变得更坏之外能有其他进展。 ? 降低你的标准。当你已经走了捷径，引入了糟糕的设计和计划，产生了大量的返工和缺陷，打乱了你的信息沟通，怂恿大家相互挑刺，挫伤了员工的士气，摧毁了我们对交付能力的信心，结果还是无法达到质量目标和按期交付（以前遗留下来的任何问题都没有得到解决）时，你就别无选择了。通常这会导致降低质量门槛，将计划延后，然后继续死亡行军。“干得好啊！” 转折点 那么，如果你发现自己正面临着“在太少的时间内要做太多事”的情况，你应该怎么办呢？从务实的角度出发，答案非常简单，就是要搞清楚，为什么你会要做这么多的事情，而你却只剩下这么少的时间了。 答案不是“因为那是管理层设定的日期和需求”。为什么管理层设定那些日期和需求呢？如果你完不成某个需求，或者不能在某个日期按时交付，管理层会做什么？他们会将计划延后吗？延后多少？他们会减少功能需求吗？哪些功能会被减掉？你是否还能在过程或方法上做更多的根本性改变，以求力挽狂澜？告诉管理层，你的目标是达到所有的需求并按期交付，但你必须为最坏的情况做好打算。 然后为最坏的情况做打算。按可接受的最迟交付日期及最少功能制定一个计划。如果在有效时间内还是因为任务太多不能完成，就全面拉响警报！你的项目已胎死腹中。如果你为最坏情况所做的计划是完全可行的，那就要全力以赴。告诫你的员工，勤勉者可以在考核时得到3?5以上的分数，但偷懒者的分数必定在3?0以下。 作者注：这些数字源自于微软老一代的评分系统，分数取值范围为2?5~4?5（分数越高，奖励越丰厚）。分数3?0是可接受的，不过大部分人都想追求得到3?5或者更高的分数。 不寻常之路 你所做的努力使得项目避免了死亡行军，并且赢得了宽松的时间来改善。你的团队很可能比最低要求走得更远，但他们做到这些并没有走捷径，也没有做糟糕的决定或自相残杀。你将按时交付当初承诺的东西，并且使你的合作伙伴和客户建立起信心。 这听起来倒是合情合理，但其实在情感上很难接受。为最坏的情况做打算感觉像要放弃一样。你像是在示弱，好像你无力应对挑战似的。多么具有讽刺意味啊！事实上，情况恰恰相反。 不面对危机是懦弱的表现。假装最坏的情况不会发生，也只是自欺欺人和不负责任。拿出你的勇气来，面对现实！做事机灵一点，别在最后还要把痛苦留给你的合作伙伴、客户和员工。相反，这样体现了你的价值，你的团队、你的生活、你的自尊毫发无损。 作者注：在最近长达9个月的项目中，我的团队在关键的依赖性服务上拖延了3个月时间才完成整个项目，同时我的团队将原本要4个月时间才能完成的主体功能模块缩减为1个月来完成。我们不能延迟时间表也不能削减软件功能模块（我们已将这两者向客户做出承诺）。我们并没有经历死亡行军，相反，我们直接投入到一个与依赖性服务相关的开发环境中同步进行工作，就像这些服务已经完工一样。这种策略不仅补回了之前过多消耗的时间，而且减少了返工次数，因为我们可以在工程创建的早期就将回馈反应给依赖性服务开发团队。在客户相当满意的情况下我们及时发布了软件。事情很艰难而我的伙伴们工作很努力，但是他们同样有宽余的时间并感到快乐，他们只是出于对发布高质量产品的渴望及为他们的同事提供帮助的心愿。在产品发布后，我们没有一个人离开团队。 2005年10月1日：“揭露真相” 我不可能说谎——多诱人的话啊，但也只能骗骗小孩。每个人都会时不时地说谎。有时是要故意掩盖一些细节，有时你没有说出你的真实感受，有时就是彻头彻尾的编造。不管是什么原因或者处在什么环境，说谎就是欺骗，含糊不了。 有些人可能想为这种行为辩解，称这是“善意的谎言”，但它仍然没有改变其本质：不诚实。如果有人发现我说谎，不管这个谎言有多么微不足道，我会立即充满懊悔并老老实实地坦白。不过在我小时候，采取的回应却是抵赖。但后来我了解到，抵赖比当初说谎引起的冒犯更具破坏性。大部分人，包括我在内，说谎的目的不是冒犯别人。我们的动机纯粹是为了私利。 不得不指出的是：欺骗其实是逃避问题的一种最容易而下流的方法。那么它跟软件开发又有什么关系呢？因为通过关注你或者你的团队“在什么时候”说谎，以及“为什么”说谎，你能查明从产品质量到人才保持的所有问题，最终提高生产力。 遭受错觉之苦 说谎是少数几个有价值的可以提醒你有麻烦的“过程噪声”之一。为什么这么说呢？因为说谎、时间周期、进展中的工作和不能替代的员工都会掩盖问题。漫长的时间周期和大量进展中的工作掩盖了工作流程中的问题。不能替代的员工掩盖了工具、培训和可重复性的问题。而说谎能够掩盖任何问题。仔细观察这些过程噪声能够发现问题，并且为过程改进创造机会。 作者注：上述每一种过程噪音我都会在后面的栏目中再次介绍，比如第2章的“精益：比五香熏牛肉还好”和第9章的“随波逐流”。至于下文的“5个为什么”，像“精益”一样，这些概念都来自于丰田汽车公司。 关键是要找出说谎的根本原因。有很多好方法，不过我这里要推荐的是应用“5个为什么”，即连问下面的5个问题： ? 为什么你要说谎？你在隐瞒什么苦衷？ ? 为什么要隐瞒那个苦衷？有什么危险？ ? 为什么危险会发生？有没有办法避免？ ? 为什么你没能从一开始就避免危险？你需要采取什么样的措施？ ? 为什么你还坐在那里？赶快行动！ 接下来，我们拿工作中经常碰到的、人们会说谎的几个例子来练习上述方法。我们将应用“5个为什么”，揭露说谎的根本原因，并讨论其解决方法。以下是谎言家族的邪恶四人组： ? 滥用“做完了”这个词 ? 含糊地表达尴尬的考核评语 ? 粉饰给客户和上司的进度报告 ? 否认机构重组的传言 好好找一下自身问题 假设你的开发团队应该在星期一完成所有的功能开发。到了星期一，你在团队里巡视了一遍，每个人都说，“我做完了。”后来，你发现半数以上的功能都Bug成堆，四分之一的代码没有处理错误情况，没有辅助功能，也没有经过压力测试。你可能会问：“为什么我的团队水平越来越差了？”但更好的问题是：“为什么我的团队要说谎？”让我们来问5个为什么： ? 为什么我的团队谎称已经做完了？他们想隐瞒什么？他们要赶一个最后期限，如果不能达标，就会降低他们在团队中的地位。所以要达标只要说：“我们做完了。”很简单。 ? 为什么只说做完了，但没有具体解释？有什么危险？没有人想让自己难堪。遗憾的是，说“我做完了”对个人来说没有任何危险。因此他们为什么不说谎呢？危险留给了整个团队。这才是真正的问题。 ? 为什么会发生这种事情？你能避免吗？问题在于，你没有给团队定义一个可验证的“做完了”的标准。这给欺骗留了一扇后门。为了避免它，你需要对“做完了”做一个清晰的定义，并且得到团队的认可，使用客观的手段去验证是否真的做完了。 ? 为什么你不对“做完了”做一个清晰的定义？你需要再做些什么？当你和你的团队对“做完了”的定义和验证手段达成一致时，你就要把工具准备到位。假设这个定义是：单元测试的覆盖率达到60%，并且95%的测试用例能够通过，另外还做了一个三方的代码审查，并找出其中80%的Bug。现在你还需要做的是，提高代码覆盖率，并在创建好的系统中为单元测试配置自动化测试套件，同时在一个合适的时间为审查员安排一次审查过程，然后就是做代码审检。 ? 为什么你还坐在那里？你需要的大部分东西都可以在工具箱中找到——除了首先你必须要有揭开“我做完了”的勇气。关键是要找准欺骗的原因，从源头上解决问题。 作者注：工具箱是微软内部共享工具和代码的仓库。这些工具可以用来评测代码覆盖率，进行单元测试，甚至为代码审查计算Bug抓取率。它们中的很多都已经集成到了Visual Studio、Office在线模板等产品中。 译者注：Bug抓取率=已经找到的Bug数÷估计的Bug总数。关于“代码审查”，可参阅本书第5章的“复审一下这个——审查”栏目。 给我个坦率的回答 你的一位员工工作一向很出色，考核分数你准备给她打4?0，你也这样告诉了她。但你的部门开了一次协调会议，那位原本能得4?0的员工只能得3?5了，因为相对于同部门的其他同事来说，她的绩效还不够好。你可以很轻易地对你的那位员工说：“我觉得你应该得4?0，但是你也知道，考核系统是相对的，我不能总是给你该得的分数。” 你在说谎，不是因为你说的话不对，而是因为你没有在这个过程中扮演好你的角色。让我们再来问5个为什么： ? 为什么不尽到你的责任？你在隐瞒什么？你喜欢这位员工，不想责备她。 ? 为什么不责备她？有什么危险？你的员工可能就不喜欢你了，甚至离开你的团队。 ? 为什么会发生这种事情？你能避免吗？你是传话者，你的员工感到无助，你也帮不上忙。为了减轻负面影响，你需要告诉她如何去争取她想要的考核分数。 ? 为什么你不早告诉她？你需要再做些什么？你需要知道为什么她得了3?5，而那个人却能得4?0。 作者注：基于绩效的差异化薪水支付，这种做法在高科技行业中饱受争议。就拿这个数字考评系统来说吧，微软已经把它的过程改了很多次，即使这样，它仍然是基于把你的工作跟其他做相同工作的、具有相同职责水平的人去比较的原理。管理者要做的事，就是要理解这些规则，并且清楚地解释给你的员工听，告诉他们如何通过善意的比较去提高自己。 ? 为什么你还坐在那里？找出分别得4?0和3?5的员工之间的差异，然后告诉你的员工。她会对如何提高自己有个清晰的方向，并且控制那个提高过程。当然，她仍然可能不开心，但至少你帮助了她，她也知道了自己该做些什么。 给猪抹口红 对照时间表，你的团队的进度已经落后了。你有一大堆的Bug要去修复，根本来不及。你的客户和上司要求知道项目的状态。但你没有如实反映情况，而是给他们描绘了一张美丽的蓝图，好像你的团队有足够的时间去赶上进度一样。你变成了一个懦弱而无耻的人，你除了对此感觉不佳外，你还应该做些什么呢？下面是5个为什么： ? 为什么要孤注一掷？你在隐瞒什么？你不想难堪或者让别人来干涉。 ? 为什么害怕被责备？有什么危险？你担心你的项目会因为你的无能而被搁置，或者转交给其他人去负责。 ? 为什么会有这种事情发生？你能避免吗？如果你的客户和上司在全无征兆的情况下发现你们要延期了，他们将不再信任你能继续胜任现在的职责。为了避免这个问题，你应该让你的项目状态透明从而避免给他们带来一个冷不丁的错愕，并且给出一个可靠的计划，使项目回到正常的轨道上来，这样才能赢回你的客户和上司对你的信心。 ? 为什么你不一开始就让项目状态透明？你需要再做些什么？经常收集你的团队的状态，然后公布或者通过E?mail发送出去，这给你的工作增加了大量的额外负担。替代方案是，你可以毫无掩饰地在你的SharePoint站点上公布你的项目时间表和Bug数据，并要求你的团队直接在上面更新，以便所有人都能看到。使用图表来清楚地表示进展情况（或者没有进展）。当数据更新之后，通知一下你的团队。所有人对项目状态都有了统一的认识，你就能按照计划把项目带回到正常轨道。 ? 为什么你还坐在那里？没什么难的。项目状态透明使工作有条不紊，同时你也赢得信任，而信任是事关你能否成功的关键要素。 看看所有这些传言 机构重组的传言漫天飞舞。你的产品单元经理曾经交待过你不要声张，但期间你的团队开始胡乱猜测。不可避免，这个话题在你的团队会议上被提了出来，但你对是否知情矢口否认；你告诫大家流言的祸害性，并提醒大家需要把精力集中在他们当前的工作上面。然而，你心存内疚，终日担心有一天整个团队都知道你当着他们的面说了谎。 作者注：产品单元经理（Product Unit Manager，PUM）是微软内部的第一级多领域管理层。产品单元经理通常负责一个大的产品线（比如Office）上的某个产品（比如Excel）。他们也可能负责一个大产品中的一个重要组件，比如Windows的DirectX。机构重组（Reorganization）通常从最高级的管理层开始，然后在随后的9~18个月内慢慢地向下扩展开来。关于机构重组，我在第10章的“我是怎么学会停止焦虑并爱上重组的”栏目做了更多的论述。当微软公司向一个高效的组织结构演化的时候，产品单元经理是一个很稀有的角色，我同样将在第10章的“我们是否是功能型？”中论述。 ? 为什么否认这些传言？你在隐瞒什么？主要是因为你的上司交待过了要你保密。你不想你的团队比你的上司更能胡乱猜测。 ? 为什么担心对传言的胡乱猜测？有什么危险？你担心你的团队被流言卷入太深，从而影响到正常的工作。另外，有些团队成员甚至可能因为害怕不称心的改变而选择离开你的部门。 ? 为什么会有这种事情发生？你能避免吗？大部分团队成员，尤其是那些高级成员，知道有时候重组会变得很糟糕。然而，没有人（包括你）知道重组是否真的会发生，也不知道最后会重组成什么样子。因此，你团队的顾虑根本就没有事实依据。 ? 为什么你的团队仍然在为传言焦虑？你需要再做些什么？出现这种情况的话，问题恰恰就在你身上。你对传言太焦虑了，刻意不把你所知道的告诉你的团队。你应该知道，迄今为止，在曾经计划的重组中，真正发生的其实大概只有三分之一。 ? 为什么你还坐在那里？这里的解决方法很简单，也很明显：说真话。“对，我也听到了很多传言。我们在员工会议上讨论过了。不过，在重组真正发生的那一刻之前，最起码，没有任何人知道是否真的会有一次重组。大部分计划中的重组不会发生，而因为我们的胡乱猜测延误了正常的工作，那我们就太愚蠢了。” 我想知道真相 我对人们是否应该永远说真话并没有定论。否则，别人会觉得我很虚伪，就像在我的丈母娘问我对她的装饰的看法时，会给我惹来一身麻烦。 然而，我们为同一家公司工作。你不应该在业务问题上对你的同事说谎。谎言掩盖问题，但问题其实应该暴露出来。如果你觉得你必须说谎，问问自己为什么。然后再次问为什么，直到你找出真正的问题所在。人们一直想知道如何去实现“可信计算”的第四根柱子——“商业诚信”。现在你应该知道了吧！ 2008年9月1日：“我得估算一下” 尽管“你的任务估算是怎么产生的？”这样的疑问总是列在诸如“不要对你的项目经理或同事抱怨”的话题之首。但当我与刚出道的工程师们讨论问题时，首先的话题不是估算，而是职业发展和一些大众话题。这就是为什么问题总是在高谈阔论中变得无法控制。估算就是在预测未来，有太多的问题是未知而不可预见的，因而想为一个精神错乱的暴君提供一个精确的估算简直不可能。是不是？肯定是这样的，对吧？ 错了。估算来自于软件工程师在规范的基础上对最小细节的把握。要身体力行。其实很简单，有非常多看似不同的方法会为你的完工时间提供精确的预测。所有这些方法皆源自于一个简单的概念——上一次用了多长时间，那么这次也是这么长时间。没有比这更容易的了。 通过对比之前的工作你已经明白现在的事是怎么回事了。但这还不够，真正的问题不是任务估算，真正的问题是接受这份估算。估算很简单，让人接受可不容易。 作者注：很多咨询顾问、研究小组及试验项目把精力花在估算上。我敢肯定他们会跟你说，估算很精确，他们都专注于用技术来避免缺陷。一切搞定之后，最麻烦的是让人相信这个估算是对的。这是最难办的事，但这对于精确度却是最重要的。 没有人会接受这样一个计划 让我们假设一下，在执行很多项任务时，你确实记录了一下这些任务要花去你多少天时间（你是这样干了——你邮箱里邮件的日期就说明了这一点）。让我们再进一步设想，你以之前所用的时间作为今天执行类似事情的估算（你已经变得精熟多了）。你的项目经理将会有什么反应呢？我想，那将是：“哦，算了吧。你在耍我呢？” 这只是玩笑话。让我们更深一步探讨。设想，你对你的项目经理说你的估算是来自于对之前项目艰难度的总结。他们不相信这种委屈的理由又是什么呢？以下有三条： 上次跟这一次不一样。 你第二次本该要比第一次快。 上次发生了少见的令人痛苦的事情。 让我们逐一驳斥这些强词夺理的说法。 完全两码事 对于来自于上一个项目经验一成不变的计划表数据，你的项目经理拒绝它的第一个借口就是：上次不一样。什么都变了，或许开发环境及工具都变了；或者设计变了，意味着工程程序也得变；或者需求变了，管理变了；或许月亮跟土星的相对位置也变了呢。 撇开这些借口不讲，只有两个因素对你的估算有那么点影响——工具和工程程序的变化，其他因素对这次开发来说都影响甚少，或者说都微不足道。 就算工具及工程程序的变化可能将极其明显地提升你对估算的准确性——工具的变化要必须使实现端对端功能缩减15的时间，工程程序的变化要必须使一周的工作量减少数天。不然，其对于估算的影响不过算是一种干扰。 看看吧，万变不离其宗。搞定它。 作者注：我们假设一下，一项任务需要花去你两个星期时间，这个时间有一两天的偏差。因此，工具及程序变化如果只节省一天，这对于两个星期来说已经不重要了。 我越来越棒了 第二个拒绝你的计划表数据的理由是：你这次本该会比上一次干得好。但有意思的是，这仅仅是因为你这是第二次。问题在于你不是干同样的项目（尽管希望是）。仅有的相同点是你所用的工具、工程程序、项目规模以及软件工程的一般性任务。 你对软件工程的一般性任务本应该很稔熟，所以你更了解上一次的项目细节对于估算下一次的项目是没什么作用的。当然，如果你是学校刚毕业的新生，那么用在第二个项目上的时间当然比第一次要少。 如果你改变了工具及工程程序，你的进展将会变得很慢，因为你是第一次使用它们。或许它们变化很小，或许带来效益不错，这当然很好。但不要欺骗自己，它们同样带来了难题。 你确实很想以一个相同的模式对当前项目与前一个项目进行比较。比较越到位，这次估算就越精确。但两次估算方法的最大不同在于，它们从哪方面进行比较。 哦，不。不会再发生了 你的项目经理拒绝你的计划表数据的最后一个理由是：令人痛苦的事只在上一次恰巧发生了。比如意想不到的安全补丁，或者功能模块比起预期的复杂得多，组织结构及关联工程的重置，更不用提类似暴风雪、地震这样的事了。对的，地震，你根本没办法预测地震。 就算你有测算恐怖地震这样的本领。还是有出人意料的补丁、功能模块、组织重构及灾难性事故在项目的每一个环节中等着你。通常，随机事件会时而发生，但是它们的影响并非你所想象的不可预测。感谢李雅普诺夫的中心极限定理，随机事件的总体影响服从于统一均值分布。不管上次花了多少时间，这次花的时间也差不多一样。就是说，只要你不自以为这一次不一样（译者注：概率上讲随机事件分布是服从一定规律性的）。 旧瓶装新酒 好了，我们已经论证了你的项目经理会拒绝你提出的估算方案。因此，他们一方面强迫你去设计个你认为根本不可信的可笑方案，一方面责备你动作慢没有早些拿出这样的估算方案。 我们已经知道，精确的估算非常注重细节。重要的问题是，“你怎么将你认为细致入微的精确估算变成让你的项目经理愿意信服的那样？” 假设你的工作时间是可以把控的——这些时间是排除了像地震、查看E?mail、浴室漏水等事件干扰之外的正常工作时间，那么你将按小时而不是按天数设计你的估算方案。没有了这些琐事的分心，你的估算方案看起来将更精致、更可信，就算它跟原来的还是没什么两样。 按小时估算看似有点难，因为你手头没有这么多详尽的数据。但是，你确实可以通过一些简单的方法，如计划扑克法（或者团队DELPHI法，它更精确、更具灵活性），从而快捷、简易又精确地按小时安排你的工作时间。 计划扑克法是由三个以上的工程师围着一张桌子各自私下对同一项任务做出自己的估算。他们同时出示各自的估算从而不会彼此施加不当的干扰。如果大家的估算是相符合的，事情就算完了。如果不一样，最高及最低估算者解释一下他们的原因，在团队中讨论他们的想法，并不断重复直至达成共识。这个过程将各种潜在问题的可能性摆上桌面。 当你们出台了一个可信的按小时计量的估算方案后，还是不能得出结论说完成某项任务要用多少时间，而只是说你在一星期内需要花多少小时用在一项任务上。即便除去假期、培训及大型会议时间，大多数团队只将不到一半的工作时间花在项目任务上，其他的时间他们都在开会、回复邮件、午休等。如果你的项目经理不相信，很简单，只要花两个星期的时间让这个团队记录他们的工作时间，数字是不会骗人的。 作者注：即使除去假期、培训时间、线下会议以及其他安排好的非任务时间，大多数工程师团队只用了大概42%的时间在他们的任务上。你可以通过多种方式，如不收发邮件，不开会，或者让功能团队合署办公及自我管理，或者可以使用诸如Scrum迅步法加强团队专注度，从而为你的任务增加几天或几个下午的时间。 我目前的团队使用“事务监控点”代替按小时计量任务。这个概念很简单，你可选用一种监控点计量法代表任务平均长度，比如8个这样的点。通过这种任务平均长度来估算其他相关任务。大多数团队使用块状长度来估算，而我使用斐波那契数（1,2,3,5,8,13,21,34,…）。几星期后，你计算一下你的团队一个星期可以完成多少个监控点。这就是你团队的速率。你可以在实际操作中更新这种速率并利用它来精确地将事务监控点转换成天数。 你的成果可能各种各样 就像我之前提到的，有一种稳定的随机性或“变异性”贯穿于整个项目的各个环节。虽然它们有平均值，但每个估算都会因为有标准误差而出现状况。标准误差是基于百分比的，它的大小决定于估算范围的大小。因此，为期两天的估算可能左右误差就一两小时，为期两星期的估算误差就在一两天时间了（同样可能多一两天或少一两天），而为期三个月的估算误差就将是一两星期。 只要你不要过于乐观，随机性并不会产生波澜。在项目完成时，整个项目的标准误差跟各个个体任务的标准误差差不多是一样的。如果你太过乐观（说“下次肯定花不了这么多时间”），你的标准误差就会不断增加，而不是平均值了。 我的观点是，估算两天的任务有多少分钟的误差或者是三个月的任务有多少天的误差并不重要。重要的是你需要一个数量级的时间估算，就像在几年前我的第一篇文章中说的：“开发时间表、飞猪和其他幻想。” 我要相信 你应该怎么估算？与同事们专注于你手头上的任务或是通过计划扑克法或团队DELPHI法等手段将这些任务按优先等级排序（计划扑克法对理解一般任务有帮助，DELPHI法则对其他有用）。这只是相对容易的部分。 真正的问题在于最后让人相信并接受你的估算，然后按计划进行。如我之前所述，过多的承诺是愚蠢的，它的要命处在于会导致“向死亡进军”（参看前述内容）。死亡行军是一个重要的风向标，它表示管理是脆弱的、无力的、充满谎言的和不负责任的。 计划安排出现的问题如恶魔一般，但是可以避免的。如果你适当地安排工作的先后次序，先搞清楚什么是最首要的，你就会在计划执行中减少压力。当你基于你的估算做出可行性的承诺时，就会让你的客户及合作伙伴感到可信，从而建立信任，提升你的团队及公司的名誉。要有个好的估算是相对容易的，但相信他们并相信自己是个挑战。 2009年5月1日：“一切从产品开始” 说我“老顽固”，但我相信产品决定一切。有个好点子还不够，光努力也不够，几近完成也不够，你必须得最终让产品面市。 微软的面试常常这样开始：“你都做过什么项目？”如果你最近没有什么成功案例，他们就会问：“为什么？”为什么？因为你不能提供产品你就不能向客户提供价值，你不把这次的任务完成，下一次你就不能接着干并不断提升水平，你没有客户你就没有客户回馈。 人们常常抱怨他们的升职机会及回报与他们的付出不符。我说：“是的，就应该是这样。”这样会影响产品质量吗？不，你已经为产品设了最低的质量标准并成功推出了产品；那么这样会影响创新吗？不，创新者通常最初冒着低收入的风险来获得与他们成果等价的高回报。 作者注：一些人报怨在微软对于创新思想并不给予丰厚回报。那是这些人并没有成功地使这些创新思想得以实现，能这样做的人已经成为我们机构及技术领军人物。 一切从产品开始。这点特别适用于服务（译者注：指软件抽象层，如SOA），我也将在接下来的内容里重点讨论此类话题。评论家们声称在这一个以服务为主导的新世界中，微软已经忘了怎么去开发这些产品了。可能吧，但是确切地说比起其他公司所认知到的，微软不是忘了怎么开发，而是根本没想到要开发这些产品。我们需要一些提醒及培训，特别当IT业转而面向服务的时候。 作者注：重在产品会导致死亡行军吗？不。相反死亡行军会拖延产品面市。就像我在“向死亡进军”中所说的：“死亡行军源于缺乏计划及勇气。”这对于理解服务的概念非常重要，在服务领域，产品要不断地推陈出新，这样才能保持长期成功。 作者注：顺便提一下，对于这句话：“比起其他公司所认知到的，微软不是忘了怎么开发，而是根本没想到要开发这些产品。”我受到了很多批评。这句话听起来有些傲慢，往往让人感觉微软并不愿听取一些关于开发新产品的意见。确实，I?M?Wright很自大而且为此很自豪，就像他声称的，在我们最终赶上对手之前，微软并不想听取这些意见，我们之前很多的竞争者也不认为微软有快速并反复听取这些意见的相关记录。有些人可能会说，“那是因为我们公司的规模（足够大）。”但是我们并不是总这么强大。有些人会说，“这是我们的策略。”但是策略并不是无懈可击的，你必须以正确的方法在正确的时间开发正确的产品。这需要耐心并不断学习。 我为你提供了服务 根据评论家的说法，就提供服务这点，微软忽视或失去了多少呢？也许还不至于让你如此确信评论家的说法，但足够引起你的疑虑。让我们带着些许欣喜来消除这种疑虑与哀叹。 疑虑是： ? 服务让你觉得什么都会变得不一样。 ? 服务注重数据，而套件产品注重功效。 ? 服务比起套件产品更关心安全性。 ? 服务在依赖性上存在严重问题。 ? 服务比起套件产品需要更高的质量以及更快的更新周期。 哀叹与欣喜是： ? 服务不是只在单个客户端上运行的，它是存在于几百台机器上的。 ? 服务必须有自我扩展功能。 ? 服务容易变换，而不像套件产品那么难。 ? 服务能即时升级以迎合人们的需求。 ? 服务是实时的，多变的。 让我们拨开迷雾，从褐红鲱鱼开始。 那是什么味儿 服务面临的第一条褐红鲱鱼个头很大：“服务改变了一切。”就像我在“你的服务”（见第6章）所讲的：“完全不是那么回事。”就像其他所有产品一样，服务始终致力于帮助客户实现他们的目标，你得始终关注客户体验及他们所期望完成的目标，不然你就失败了。就是这样。 接下来的三条褐红鲱鱼是——注重数据、安全问题以及依赖性问题。虽然之前已经花了我们不少心思去理解这些问题，但这与实现套件产品是一样的。无论在软件客户端还是服务器端，为了使数据格式的变化不被客户发现，你必须避免这种情况发生；在现今，不能说你的计算机产品或服务足够强大而不会受到攻击——你必须保证它们的安全；最后，如果你认为客户端的外部依赖性不存在问题，你就不会需要过多的驱动程序。我不是说这些不是什么真正的问题——而是说，对于服务来说这些问题不新鲜也不特别。 最后一条褐红鲱鱼是再寻常不过的，服务实现与套件产品生产的不同之处在于其高可用性与互联网响应时间。看吧，套件产品经常会出故障或者当要正式使用它们的时候总要重启计算机，这样太糟糕了，出现像这样糟糕的事情已经有些时间了。服务同样要注重这样的质量要求，虽然很多服务产品也时常失败。 关于互联网响应时间，在10多年前引入Windows Update后，这个问题就出现了。如果你认为这些补丁不过是修补一下安全问题，就不会引起太多关注。不管是服务还是套件产品，不断增加的客户体验问题在客户向我们提供报告之后如果能快速地得以解决，这样对于客户来说他们感觉会非常棒。 然而，不是说逐日逐月地、渐近地提升客户体验就行了。不管服务还是套件产品都需要典型的、打包完整的升级包来为客户提供突破性的价值。Facebook不想像Vista一样逐步地升级为Windows 7，从而也使自己逐步升级为Twitter。因此，你必须关注客户真正要实现的是什么，而有些时候这些改变不是那么迅速的。 作者注：了解发布产品的最好途径就是早发布，常发布。要让每个程序的“构建”都是可发布的“构建”，每天构建，且每星期至少对整个系统重新构建一次。定期发布技术预览版及测试版。定期发布将使产品逐步更新修复。早发布，常发布，生命在于运动。 译者注：褐红鲱鱼，在18~19世纪的不列颠海域，鲱鱼被用做一种鱼饵，在那个年代没有冷藏技术，一般用盐腌制或烟熏后保存，烟熏后的鲱鱼就呈褐红色并有一种刺鼻的味道从而迷惑猎物。 这里有太多问题了 然而，并不是所有与产品实现相关的问题都适用于服务实现，还有心态、过程管理及团队协调需要你特别处理。 首要的是，服务在分散于全球的多个数据中心上的成千上万台计算机上运行。有时候它们的功能与数据会有重复，有时候又不一样。通常，它的规模程度与可靠性亦步亦趋，这样会暴露出设计与同步性问题，很多书籍已经对此做过相关介绍（再读一次这些书也不会有什么新发现）；其次比较严重的问题是调试与部署问题。 为什么调试一项服务这么困难？计时问题可谓是在多台机器、多个处理器的多个线程上的杀手。哎呀！然而，这还不是最要命的。 在你调试一个问题的时候要做的第一件事是什么？分析栈，对吗？对于服务来说，栈分散在服务器与响应方之间，这使它几乎不可能跟踪一个特定的用户行为。好消息是，有一个工具可以有助于将分布于各个计算机间的行为进行关联；而坏消息是，这同样还不是最棘手的问题，最棘手的问题是你总是在一个实时的环境中调试，你得不到符号、断点或者逐步跟踪代码中每一步的能力。 至此，让我们回顾一下。调试服务意味着在没有栈的、没符号的或在动态代码中没有断点的多台机器上调试繁琐的计时问题。只有一种解决方案——使用测试设备，有很多这样的设备，这样的设备是从一开始就针对某种服务设计好的，它预先考虑到了你以后将在一个无法进行栈跟踪、没有符号、没有断点的动态机器上调试。 他们增长得太快了 解决调试问题给我们带来了另一个重大困难——部署问题。部署应该是完全地自动化及轻便的。就拿安装程序时文件复制来说，要快速地复制文件，就意味着不用注册，不用用户干预，甚至不用指导用户干什么。 为什么部署需要这么快速又简单？有两个原因： 你正在将软件安装在运行着的、遍布全世界的成千上万的机器上。安装必须在无须人为干预的过程中进行，稍有复杂就会引致失败。记住，在1 000台机器上花五分钟就是三天半的时间。最好不要出什么问题。 服务器的数量需要根据负载量动态增加或减少。不然，你就是为了满足高要求而在浪费硬件、浪费电源、浪费制冷以及带宽。因为你的规模决定于负载，它会随时变动。当负载变动的时候，你就需要自动且迅速地扩充系统。 令人庆幸的是，有Azure可以为你在部署时分担重担（所以用这个就可以了，不用另外再开发类似工具），不过，你还是需要设计好你的服务以便于安装时快速复制文件。 人生太无常 有很多问题你可以预测，但不能预测的呢？服务在时刻不断地变化着。有些服务固定不变，它们保持着你的数据（像Facebook及eBay），而有些服务却不会（像搜索引擎及新闻）。稍稍几分钟的宕机就会让你失去数千的客户，数据损坏或丢失可能让你失去上百万的客户。他们马上会换地方，我们的竞争对手会很高兴地接受他们。这是把双刃剑，你必须努力去招揽新客户并留住他们。 当你升级你的服务时，客户就会马上体验到最新版本的功能，而不是要过好几年。如果有一个bug在一个客户的上千次体验中发生一次，那么意味着这个bug也会在几千个客户身上发生（大数定律）。这样你就必须及时解决此类问题或者进行事务回滚。不管怎样，到星期五再更新服务绝对是个坏主意，而是应随时有个应急回滚按钮以应对不测。 最后，应该认识到服务是实时的、变化着的事物。你可能会想，因为服务器是我的，是在我的构想中设立并配置的，那是一个可控的环境——那只是在你把机器开关打开之前。一旦服务器开始运行，这些都变了。内存使用在变动，数据及其布局在磁盘上也会变化，网络流量发生变化，系统负载也发生变化。服务像条河流而不是块石头，你不能刻舟求剑。必须随时关注它们，为使你生活得更轻松，要始终谨记五“重”自动化——重试、重新开始、重启、重新镜像、重置机器（虽然重新替换有时需要人为干预）。 面对这些让人心烦的事，客户们很期望得到一些宽慰。一个理想的方法是建一个“点子检测”平台，因为你可以看到客户的不同看法并看看他们日常关注的是什么；同时应具备这样的能力：马上加以改进并在以后找出会间歇性诡异发生的bug（谨记五“重”方针）。 返璞归真 现在你明白了。围绕客户及其目标的传统的稳健代码编写方式是发人深省的。 然而，如果缺少成果面市，这些什么也不是。要成功就要先有成果。是的，我们的质量标准已经有所提升，我们不是要王婆卖瓜，所以我们需要定期改进客户体验质量，不管是长周期还是短周期的；我们必须通过互联网、PC、电话去实践体验。我们必须服务好客户，让他们开心从而使他们更靠近我们。这是个长期的过程，但千里之行始于足下。 2009年9月1日：“按计划行事” 我的大儿子会开车了。但也为我的生活平添两份担忧：一是我已渐感年老，二是颇为我的儿子担心。为了减轻这第二种担忧，我和我的妻子设了一个强制性的禁令：我的儿子如果回家晚了，他必须先给家里打个电话。有一天，他回家晚了20分钟又没事先通知，我们生气了，我的妻子愤怒是因为他晚了20分钟，而我愤怒是因为他没事先打电话通知。 为什么我的儿子没有打电话说要晚点回家？因为，跟我妻子一样，他只把注意力放在计划上。在回家之前，（不打电话）他可以避免纷争。他说：“我已经尽我所能早点赶回家了”——为此都好几次违反交通规则。但我的儿子没有明白要点，规矩的目的是想减少风险，而他对此做出的反应是增加了风险。 软件工程师也经常这么干。从一个开发计划开始，非人所愿的问题就随之发生，然后他们就延期交工。为了避免纷争，他们往往并不向项目经理提及延迟的事，而是匆忙赶工，牺牲质量，草率应付计划，所有这些都使工程陷于不可控也不透明。其结果跟项目经理所料恰恰相反，而那些项目经理是严格按部就班执行计划的。为什么？因为多数项目经理及工程师不能区别这两种计划——兑现承诺及风险控制。 作者注：我很喜欢这个专栏，它囊括了关键性及基础性的问题，虽然这些问题通常被误解。我希望我的家庭、我的朋友、我的同事及我的团队都读一读。 谁懂事物具有两面性，谁又不懂？ 的确，有两种类型的时间表及项目管理技术。 兑现承诺。你向客户或者合作伙伴做了承诺，你必须遵守承诺按时保质完成任务。要按时。 风险管理。工作有关键性及期望性之分。人们或许会做出错误的选择从而产生问题，你必须善于进行风险管理以保证关键性工作的完成。 这两种项目时间表及项目管理技术往往会被搞混，为什么？ 它们通常同时发生。承诺贯穿于整个工程项目。但它是由许多个小任务组成并需要风险管理。 两者都有时间表。不同的是向客户承诺的计划时间表不可精确确定，但所有人及事情又为其所驱使。而风险管理的时间表可以有很多监测点以保证其踪迹可寻。 它们都可称为计划。很多人不知道二者的区别。 人们所被告诫的往往只是承诺。当适龄儿童入学后，他们就因为有时间表及规矩显得中规中矩。当他们日后学习了项目管理，就只知道甘特表及里程碑，而把风险管理抛在脑后。 风险管理往往是自我学习的过程，是非正式的。只有一小部分人真正学习过风险管理，大多数人只是在大学里为应付大工作量的任务才向同僚们效仿了一下。我们不是将所有事情及时完成，而是成立工作组，只关注关键性工作，以及极力减少有损我们评分的可能。 不能很好理解这些道理的惨痛结果是导致可怕的决策、可悲的工程实施以及计划失败。你必须知道二者的区别以及将正确的计划应用到相应的问题上。让我们从兑现承诺开始。 这是你唯一承诺的事 “兑现承诺”是跟他人合作的基本准则，也是多数商业行为的准则。在需要内部相互依赖、外部相互信任的情况下，如果产品没有按工程日期安排及时到位，你们的工作就无法协调进行。因为承诺是前后关联的，你必须及时完成承诺之事，不然你就会面临惨重失败。 假如你女儿的生日快到了，你承诺说将给她买一款她喜欢的新游戏，如果别人承诺了游戏出品时间而又没完成，你会是什么感觉呢？在开发者、厂商、销售商以及你之间是手手相传的链条，所有这些都及时到位才能确保在你女儿生日的时候让她开心。 当然，这对基于Web的产品来说是相对容易的，但是在团队及部门间相互关联的过程中还是会产生同样的问题。承诺并交付产品才使信任得以建立，及伙伴关系得以维系，失信则相反。虽然很多软件项目只需要很少或根本就没有团队协作，而运作大型成熟的项目通常就需要守信以及其他项目管理技术。 作者注：为了有助于做出承诺，一个公司通常使用库存、保留余地以及其他风险管理的形式为实现承诺的每一步骤提供保障。这就是风险管理的精髓。你使用正统的项目管理方法确保整体目标的承诺得以履行，而使用风险管理确保履行承诺过程中的每一个步骤无恙。 你不认为那是一种风险吗 风险管理是关于如何确保关键性工作得以完成的论题，即便是在一个极易变动的环境里。Scrum及Feature Crews就是两个在软件开发中比较突出的例子，它们关注于风险管理，确切地讲，风险意味着你不能高效地将有价值含量、高质量的产品提供给客户。 就像我在第1篇专栏“开发时间表、飞猪和其他幻想”中提到的那样，开发计划及测试计划都在风险管理之列。所有的标志性日期都是降低风险的检测点，但只是仅有的几个跨团队的同步检测点（标志性里程碑）才是向客户承诺的要点。 什么才是风险管理的重点、先后次序以及其表现状态，这还没有确切的说法。只要注意什么是重要的，先把重要的做好并在条件改变的时候跟踪其状态就可以了。注意，紧盯着细节工作日程安排并不重要，你在规定的时间以规定的质量完成最关键的任务才是重要的，其他的可以不用太在意。 这就是为什么你要告诉你的工程师，就像我告诉我的儿子一样：“是否按时回家并不重要，告诉我们你不能按时回家了才是重要的。”如果你知道风险的存在，你只要管好这些风险就可以了，工作时间表只不过用来提醒你计划需要更改了。 当然，你不能过了向客户承诺的时间（一个标志性里程碑）而将关键性任务一直向后拖延，就像我的儿子不能在外超过凌晨1点钟，不然我们将没收他的驾照。禁令应事先设置，它防止了可能发生的这种灾难，这就是禁令应具有的功效。 作者注：有很多众所周知的风险管理技术。这里顺便列出几个在软件开发中用得到的（好几个在前面的专栏提到过）： 开几次常务会议，15分钟左右，谈谈进展情况、未来的期望及目前遇到的一些难题（称为Scrum迷的Scrum会议）。 为所分配的任务做个备案（在缺乏经验的人与富有经验的人合作的情况下）。 留点余地——安排些额外的时间以备不测（就我个人而言，我向来不喜欢这种方法；我宁愿为任务列一个优先次序表也不愿有面面俱到的想法）。 轻在承诺而重在成果——也可以说是量力而行。 留有退路——始终谨记为有风险的任务设个预案，比如削减功能模块或重新使用老版本。 平衡风险——当事务发生变化时，通过增加或移除风险始终使你的项目保持在一种常态：有点担心但并不恐怖。比如，如果一个团队成员的父母过世了，你的风险就增加了，所以你必须削减具有风险性的功能模块或重新将那项艰巨的任务分配给一个高级工程师。 选择一个正确的工具 所以，当你开始对一个计划付诸实施之前，先等一下，思考一下计划都有什么。其中是否有一连串的约定时间及产品需要交付？或者有哪些不同优先级的重要任务你需要跟踪监视并防止其错过的？ 就比方说我儿子回家的禁令，不夸张地说，那就是我不容许他破坏的任务。因此，我们需要风险管理以及需要及时关注其状态的重点，而不是说关注什么时候回家这样的事。这样的模式很适用于大多数软件开发项目。你只是想你的工程师及时告知你情况，这样如果他们延时了，你可以进行调整。太精细是不必要的，而且会适得其反。 然而，如果你跟多个团队及合作伙伴实施一个大型项目，那么在一定级别的层次上，你们相互间的承诺及同步是很重要的。在这个层次的时间表上都是一个个里程碑以及经典的项目管理工具。 不要将高层次的工作计划与低层次的任务相混淆，如果你对待低层的相互间约定像对待高层的一样，你的工程师就会抄近路并快速赶工，你可能就会导致他们破坏整个关键性任务，从而破坏了你高层的客户合约，风险管理也就无从谈起。你在合适的层次使用合适的方法，你一晚上都会睡得很好的。 作者注：更多关于传统项目管理技术与敏捷项目管理技术组合的话题，参见下一专栏“敏捷的团队合作”。 2010年5月1日：“敏捷的团队合作” 我用Scrum已经7年了，而后面6年我一直写关于它的文章。Scrum的概念太吸引人了——规则多变、自我管理的团队在短而固定的周期内周而复始地进行一系列小环节（或功能）工作，并不断提升水平。很多微软团队的成功都来自于此。让人犯昏的是高层的项目经理与团队层的Scrum工程师仍存在严重隔阂。 很多高层及中层的项目经理认为Scrum是混乱的、随意的、危险的并毫无意义的，会使大家对计划失去信心；而很多Scrum迷认为项目计划是种浪费，会引起混乱，毫无价值，只是让不切实际的高层管理者设计个看似完美的计划表以自我满足。结果怎样？他们都错了，而认为他人无知就是愚昧者自作聪明，那么就是，双方都无知。 Scrum是按计划加载的，比起我在微软所见到的其他项目管理方法，它更高效并精确地跟踪数据（除了TSP，在少数团队中使用）。同样，高层项目计划对于项目规模的成功把控、协同合作及萌生宏观上的创造力是很重要的。如果你着眼于小处，Scrum就足够。如果你只想比你的竞争对手提供更低质量且不用太顾及客户价值的产品，或者只想在你局部的范围内微观管理所有工程状态，那么只要项目计划足够就可以。如果你着眼全局并想高效地提供高质量且丰富的客户价值，那你就需要在高级项目计划与Scrum间找到平衡。 作者注：功能小组一个有趣的Scrum变体。这种组织方式最先源自于Microsoft Office的项目开发。就像Scrum团队，功能小组是规则多变并能自我管理的团队，在一个很短的周期内他们周而复始地进行一系列小环节（功能模块）工作。虽然他们可能也会开些常务性会议，但他们并不仅仅是照搬Scrum模式——固定周期迅步法及频繁的重复规划。不过，功能小组已经成为了很多微软团队工作的一种主要方式，它们能高效地执行一项简洁的软件工程过程。 我尊重你否定我的权力 为什么在高层的项目经理及Scrum迷之间会存在如此隔阂呢？几年前，在该章对于管理失当的介绍中我已有所提及。 项目管理在不同的规模、不同的抽象概念中有不同的表现形式。有下面几种：团队或功能层次（大概10人左右）、项目层次（50~5 000人为一个特定版本工作）以及产品层次（由执行官领导的多个版本开发）。敏捷开发在

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式	香港用户　 |　台灣用户　|　海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.