2007年2月1日：“糟糕的规范书：该指责谁？”
规范书基本上都是可怕的。不仅仅指项目管理规范书，而且也包括开发规范书和测试规范书。我说的“可怕”，主要是指难以撰写，难以使用，而且难以维护。你要知道，这很可怕！规范书往往还是不完善的，组织得很差，并且没有得到充分的复审。规范书永远都是这个样子，也看不到有任何变好的迹象。
为此，我想要指责项目经理，部分原因是因为我喜欢这么做，但更主要的还是因为他们是糟糕规范书的始作俑者。然而，事实不允许我指责项目经理。人人都在写糟糕的规范书，而不只是项目经理。即使项目经理偶尔写出了上好的规范书，但其他大部分的还是很糟糕的。不管谁来写，上好的规范书总是难以撰写和维护的。
如果项目经理不该为那些以次充好的规范书承担罪责，那么该指责谁呢？管理层将是最直接的目标（另一群我喜欢指责的人）。事实上也是，有些组织，比如Office部门，一贯以来写的规范书都比其他部门的要好。因此，管理层显然在其中发挥着作用。然而，Office部门这么多年来调换过很多次管理层，因此，这里的原因必定比主管的人更加深层次。
树立靶子
现在清楚了，我应该去指责写规范书的过程——我们是怎么写规范书的，以及我们使用什么工具。这个过程是烦琐、艰难并且乏味的。规范书模板冗长、吓人，复杂到无法驾驭。所有这一切使得要写成一份上好的规范书，比披着皮大衣、穿着拖鞋想要去赢得一场马拉松比赛还要无望。
一些落后于时代的杞人忧天者可能会说：“写规范书的过程如此荒谬紊乱是有原因的。所有的模板元素和过程步骤都是用来避免以前发生过的灾难的。”看到了吧，你不必去担心从公司高层传达下来太多的官僚主义，其实，在下面的基层已经自己累积了很多。
病态的过程总是源自于最好的意图。麻烦出在，这一路走来，最初的目标和意图都不知不觉地迷失了。唤醒这个目标和意图，使用新的、更好的方法去实现将会使它们重归正途。
作者注：我在波音公司工作了5年。在那里，不是所有但绝大部分官僚主义看起来都来自于公司高层。我已经在微软工作了12年。在这里，不是所有但绝大部分官僚主义看起来都来自于基层。我们在最底下的层次，工作独立，很自由。有时，这意味着我们这是在作茧自缚。
沟通分解
所有项目管理、开发和测试规范书的目标，都是为了跟不同时间、不同地点的人进行设计和设计决定的沟通。我们想要使这种沟通变得容易而稳健，并且进行大量的反馈和质量检查。
假设你还没注意到，这里有4个独立的要求：
容易
稳健
反馈
质量检查
每个要求都可以通过一个不同的解决方案来满足。“我们只需在规范书中多加几节来满足所有的要求”，这种方法跟“我们只需给这个类多加几个函数来实现所有的功能要求”一样的愚蠢。我们还是对这些要求逐个来分析吧。
保持简单容易
规范书必须要容易写，容易懂，并且容易维护。它应该使用标准的符号（比如UML）来绘制图表，使用通用的术语用于文字表达。它不应该承载太多的内容或者说得过于深入。
格式越简单越好。在“工程卓越手册”（Engineering Excellence Handbook）中的通用规范书模板有30节之多，并且还有3个附录。而上好的Office规范书模板也有20节。它们都太复杂了！
一份规范书只需要3节，再加上一些元数据：
需求：为什么会有这个功能？（跟应用范例和客户角色联系起来。）
设计：它怎么工作？（图片、动画和图表特别有用。）
问题：做了什么决定？风险和权衡都有哪些？（比如依赖关系。）
元数据：标题、简短描述、作者、功能团队、优先级、成本和状态等。
就这些了！“状态”元数据可以是个工作流，也可以是个检查清单，但不能太复杂。
“但威胁模型放在哪里？还有隐私声明呢？源代码插桩或者性能度量呢？”我可以肯定你会提出这些要求。请你冷静一下！这些条目属于质量检查，我在后面很快就会谈到。规范书结构本身是简单的，比实际需要的多一点或少一点都不行。这样才能容易写，也容易被人读懂。
在线资料：规范书模板（Spec templatedoc）。
变得稳健
规范书必须是稳健的。它必须是可被验证的，并且所有定义的功能需求和质量需求都能被满足。你可能会问，“怎么做到？”但“怎么做到？”究竟是什么意思？怎样在第一时间验证需求？那就要编写测试，对吗？对！这就是你怎么写出一份稳健的规范书的方法。在规范书的第一节中，当你列出功能和质量上的需求时，应该包含如下内容：
唯一标识优先级功能或质量简短描述相关应用范例用于验证需求的测试
如果你不能指明一个测试来验证一个需求，那么这个需求就不能被满足，因此要把需求丢弃。不能丢弃？那好吧，重写需求，直到它能被测试为止。
作者注：我相信，一个可靠的设计把“测试”和“需求”放在基本同等重要的地位。每个需求都应该有一个测试。每个测试都应该基于一个需求。这将导致，清晰而可被验证的需求；更加全面的测试；一致的完成标准（即所有测试通过等于所有需求得到了满足）；以及更好的设计，因为测试驱动的设计自然要更加简单，更加内聚，具有更松的耦合。
获取反馈
在规范书付诸实现之前，越多的眼睛看到它，它就会变得越好，并且将来要求的返工也会越少。如果你想很容易就能获得反馈，你也想别人很容易就能提出反馈，至少你要将规范书草稿放到SharePoint上，并进行变更跟踪和版本控制。做得更好一点，你可以把规范书放到一个维基站点上去，或者贴在功能团队主要活动区域的一块白板上。
撰写规范书的这个过程、反馈和变更管理需要有多正式呢？像我在前一个栏目讨论的那样（即本章的“停止写规范书”那个栏目），正式的程度取决于沟通是否直接，以及沟通的“带宽”有多大。在同一个共享区域、同一个时间、工作在同一个功能的人们，可以使用很不正式的规范书和过程；而在不同时区、不同时间、工作在不同功能的人们，则必须要有高度正式的规范书和过程。
不管怎么样，你想让规范书随时都可以修改，直到团队认为它不需要再改为止。那你怎么知道规范书不需要再改了呢？答案是，要等到测试团队验证规范书通过了所有的质量检查。
集成质量检查
这是我们目前正在使用的规范书最离谱的地方：各个部门不是把安全、隐私和许多其他问题当做质量检查，而是把它们一节一节单独地写在了规范书中。这是个灾难，原因是：
规范书变得更大并且复杂得多。
作者必须在各节中复制信息。
读者对后面的节次重视不够，导致严重的质量缺口。
设计变得难以理解，因为它们的描述分散在多节之中。
错误和缺口很容易被忽略，因为没有一个节次对设计作了完整的描述。
更新几乎是不可能的，因为一个最新的改动会影响多个节次，牵一发而动全身。
取而代之的是，采用适合于每一份规范书的质量检查，它以一个清单的形式出现，并且每个人都能触手可得。一开始的几个检查对于每个团队都是一样的：
需求清楚、完整、可验证并与有效的应用范例关联了吗？
设计满足了所有的需求吗？
所有关键的设计决议都被解决并存档了吗？
接下去的一套质量检查也相当基本：
所有的术语都被定义了吗？有没有兼容性问题？
安全问题解决了吗？故障和错误处理解决了吗？
隐私问题解决了吗？涉及安装和升级问题了吗？
用户界面是否有亲和力？维护问题解决了吗？
为全球化和本地化准备好了吗？备份和恢复问题解决了吗？
对于响应和性能的期望是否清楚并可测量？是否有足够的文档用于支持故障检修？
源代码插桩和可编程能力定义清楚了吗？有没有潜在的问题会影响打补丁？
各个团队还可以为他们自己或者他们的产品线增加更多的质量检查，解决他们常常面临的特殊的质量问题。
在线资料：规范书检查清单（Spec checklistdoc）。
这里的关键是，设计节次对功能进行了完整的描述，而质量检查保证了没有东西被遗漏。是的，这意味着设计节次可能会变得非常庞大，以覆盖所有需要涉及的领域。但这些领域不再把每项功能的质量要求再展开赘述（比如对话框的安全、对话框的隐私、对话框的亲和度等）。
取而代之的是，文档中的相关区块都可看成是功能的逻辑性组件（比如应用程序编程接口、对话框、菜单等）。重复消除了。每个功能组件完整地被描述出来，并且所有的质量要求都融合在了设计情境中。
作者注：一个奇怪而有趣的巧合。在本栏目发表之后的第二天，Office部门把他们的规范书模板做了简化，只使用单独的一个节次来描述设计，并且采纳了我发布的质量检查清单。尽管我不能对这个改变邀功，但我的成就感着实得到了满足。
差别在哪里
如果增加了所有的这些检查和测试，你可能会怀疑我根本就没有对规范书作出简化。其实，这里的最大改动是：
节次的数量减少到了只剩下3个（需求、设计和问题）。
设计在一个节次中得到了完整的描述。
所有功能和质量上的需求都可以被验证。
我也已经谈到了，我们还有机会把规范书写得不那么正式一点，并且更容易被理解。
那么谁该为糟糕的规范书负责呢？其实我们都有责任。不过，糟糕的规范书主要还是由不良的习惯和糟糕的工具造成的。只要做一些小小的改变，并且使用大大简化的模板，我们就能改进我们的规范书，改善部门之间的沟通，并且促进工种之间的关系。总而言之，这样做可以让我们在微软工作得更加开心而富有效力。
2008年2月1日：“路漫漫，其修远——分布式开发”
如果你是软件极客，就像我，很自然就会成为朋友与家人的技术产品顾问。当你看到你的家人备受软件折磨时，特别是这个软件是你参与编写的，至少你可以告诉他们：“让开一下，我是计算机科学家。”接着解决了所有的问题。是的，当你撤销他们所做的失败“操作”时，你可能会战战兢兢，但是你还是会及时摆平所有问题。但前提是，你就在他们身边不远。
如果你老妈住在千里之外，你们的通话很可能像下面这样：
老妈：亲爱的，他们更改了我的密码，现在我的Email进不了了。
我：好的。登录你的计算机，打开Outlook。
老妈：密码是什么？
我：输一个你通常用过的。
老妈：我不是在申请一个新邮箱，是我的老的邮箱。
我：知道。打开Outlook。
老妈：我从哪里输入密码？
我：在你输入用户名的主页面上，输入密码。
老妈：什么是主页面？
我：等会。你现在能打开Outlook吗？
老妈：是的。我已经打开它了。但是你说叫我登录计算机。
[另外又要花一小时在菜单、对话框及按钮操作上]
如果你有个像远程协助（Remote Assistance）这样的工具，那以上情况就不会这么糟了。但使用这种工具在防火墙及路由器后面操纵同样会非常有趣。本来5分钟可以处理的事变成了耗时1个小时的噩梦，那会怎么样呢？在你工作中的任一个时间点与地点，这种时间消耗与麻烦会成数量级倍增，这样就将我们引入一个话题：分布式开发。
大家不用呆在一个地方了吗
在全球多个地点共同对一个项目进行开发已成为稀松平常的事。但，这样虽然增加了团队开发的多样性，吸收了各界精英，这应该会是个巨大的优势，结果往往是挫折、延期及质量与机能的错位。为什么？因为有三个大麻烦：带宽、地域分隔及大家齐聚一堂。
畅通的沟通及快速访问中心服务所需的带宽还远远不够。分布在不同地点的项目分工界线不明，导致额外的沟通、冲突、灾难及梳理工作。因为不同的团队互相分隔，大家呆在一起一对一面谈，接洽来客，走廊交谈及其他日常交流这样的情况就不会再有了。
有了这些麻烦，你可能会想：为什么我们还要劳烦分布式开发？不，你想得太简单了，这跟钱无关。采用分布式开发的根本原因是源于人才与市场。计算机科学人才在巴西、俄罗斯、印度、中国等地每年增长近20%，其总和相当于2010年美国软件工程师总量的15倍。他们不会全部跑到雷德蒙去，我们也不想他们这样，因为他们的本土市场对我们至关重要。
所以，如果你现在在带领一个团队，你最好弄明白怎么处理这三个大麻烦。以下让我们对它们逐一进行讲解。
我必须不停地解释，不胜其烦
第一个大麻烦是带宽——人与人及计算机与计算机之间的带宽。人与人之间、团队与团队之间通畅的沟通对于成功至关重要，我之前多次谈到这一点。在同一个房间里两个人之间沟通的信息量要远远大于人们通过电视电话会议（VTC）沟通的信息量，而后者大于通过Live Meeting沟通的信息量，Live Meeting又大于电话（就像上面我跟我妈的电话沟通），电话大于即时通信（IM），IM大于Email。换句话说，Email是个信息量最少的沟通工具，所以它的应用自然最为广泛。
作者注：使用微软的Live Meeting（现在叫做Lync）进行圆桌会议，现在来说是挺好的，虽然其比不上VTC。如果你还没试过圆桌会议，你就错失了体验很酷的技术的机会。它会使人们自动地把注意力放在言语自然通顺的人身上。
事实上，人们都使用Email，因为它的方便性、异步性并可以跨时区。遗憾的是，Email的带宽很小，通信质量差并且需要几经周折才明白对方的意思。因为时区的不同，一次邮件往返就是一天，因此，通过Email交流进展踯躅。计算机间的带宽也是相当慢的，这意味着在雷蒙德快速的源代码控制、文件或数据库操作要历经几个小时才到达大洋彼岸。
你怎样才能消除带宽这个大麻烦？这里有两种方法——增加带宽或削减不必要的通信。
你可以通过使用高带宽的通信工具，如VTC及Live Meeting来提高带宽。这些工具甚至可以在低带宽线路上工作。然而，这些工具是实时同步的，所以你必须同分布在全球各地的团队人员预约交流时间。这意味着如果你在雷蒙德而你团队的另一个成员在中国，你必须约定每天太平洋时间下午4~5点与你的中国同事进行即时会议。
作者注：Live Meeting已与Office Communicator在微软的新产品Lync上集成。用这个可以进行即时通信（IM），非常酷。视频及音频讯息、IP电话、会议呼叫及Live Meeting等都集成在了一个Office应用套件中。呵，我看起来像个推销者，但这个确实很诱人。
你可以通过书写更细致的Email来削减必要的通信。可以预先在Email中提供额外的信息并回答一般性问题来减少问题，消除混乱。这样写Email会多花些时间，但谈不上几天时间，而这在即时通信上都是要花上几天的。
你可以用SharePoint发布项目信息来减少类目繁多的Email及打电话的次数。将主题“怎么做”、讨论目标、检查列表、文档及项目相关邮件、时间表及进度状态放到上面。无论何时何地，新的团队成员到来时，把完善后的上述相关材料及缺少的文档更新到网站。
你同样可以对在不同地方进行的工作建立清晰的项目界线。把本地通信分离出来，包括将源代码控制及数据库存储下来。这样你就只需要在人们或信息跨界的时候再使用跨团队通信。这又将我们带入到下一个大麻烦。
你确实不知道你在浪费时间吗
第二个大麻烦是界限——不同工作地点间的界限。
如果你从未在分布式的项目或团队中工作过，你可能会傻傻地认为分布式的团队都是过得很开心的。就是因为这样单纯的想法让项目经理允许团队中的成员进行远程工作。记住，无知、单纯、愚蠢是成为傻瓜的三部曲。
一个分布在三个不同地点的项目团队不是个开心的团队；在一个很可能成功的项目上工作的三个团队才可能是开心的，这样的团队工作目标一致，认识统一。
因为如前所说带宽的问题，你做不到使团队认识统一、步调一致，除非你将你的队员们集中到一个房间里。这就是为什么有一个共同的协作空间是最好的。也是团队只分布在不同楼层一起应对相同的困难而不是分布在不同的大陆的原因。
要使一个分布式项目能够成功，你必须在分布式的团队间设立清晰的界限，从而有足够的空间独立性使他们独立工作而只需要很少的协作交流。界限越分明，成果越显著。我在第6章的“美妙隔离——更好的设计”对此有更详尽的讲解。
作者注：在分布式的团队间建立清晰的界限并不是禁止界限之间的沟通。你仍然可以进行跨团队的设计、代码复审与计划安排以及头脑风暴。各团队可以相互帮助解决问题，并使之相互联系更紧密。清晰的界限的作用是使团队间不至于天天相互阻挠与干涉。相反，高带宽的交流是必需的，可能一星期就一次，跨团队的协作只是锦上添花之事。
通常，界限是个相对于空间与地域的概念。但是同样也可理解成版本或责任的界限。你同样可以让分布式团队关注本地市场，这不会增加不必要的费用，这里的沟通费用可忽略不计。相反，它减少了不必要的冲突、灾难及梳理工作。
但是如果你的团队是绝对独立的，你怎能保持团队统一协作并相互共享，向着相同的目标前进呢？这就是下一个大麻烦中要说的。
能让我看到你的脸，肯定非常不错
第三个大麻烦是——互相会面建立起人与人之间的紧密联系使合作与沟通更真实。
最大限度地利用带宽并分清界限将解决分布式开发的大部分难题。然而，你们始终还是在同一个项目上为同一个目标工作的团队。你必须维系团队间、同事间的重要关系，并绘制出这种人员关系结构图，图中的相关人员需用人脸照片标示。互相会面是相当重要的。
VTC及其他实时交谈工具对此是很有帮助的。你可以经常在一对一交流场合及会议中使用这些工具。并不必每次都用，但至少一月一次。记住，不同的工作地点之间要实现这些功能需预先约定好时间。
当然，什么也无法替代人与人之间的实际接触，所以面对面的实际会谈每年至少要安排两次。在10月安排一次公司会议及执行力审查，在2月或3月安排一次年度财政及预算计划。每次会面不只两三天时间，一次得1~2个星期。会面内容包括激励斗志、一对一会谈及培训，跟计划及审查会议一样。你们要抽出尽量多的时间进行接触。
有些团队会进行轮换工作或人员交换。在这种情况下，来自某个地方的团队人员要用3个或甚至6个月的时间与另一个地方的团队人员共处。这可以是一次人员调换或指派。这种人员轮换可以提供充分的相互学习的机会，从而建立团队间的互谅，使之相濡以沫保持联系。
最后，有时候制造一种幻象对于维护人际关系，加强沟通非常有效。一些公司已经尝试在普通场合持续播放视频片段。一个在微软行之有效、既省钱又有趣的办法是在人员密集场所放一个很大的乃至真实人物大小的画报。当人们结束会议或在大厅里踱步想些有关项目的事情时，他们看到这些画报就会得到一种暗示，在假想中将这个人或团队囊括在会话中。
太阳下山，你在何方
稍花精力，你就可以在你的项目中应用分布式开发，机会稍纵即逝。分布式开发对于你及微软来说将收获颇丰。
这么多种的体验、文化及想法最初可能使我们的团队及你很不适应。但是随着时间的流逝，你会渐渐感觉自身能力的提升，团队水平的提升，以及产品及服务水平的提升。你工作的成绩将在更多的市场、更多的受众中更受欢迎，在此过程中你将有所学，并逐渐成长。花些时间好好琢磨这三个大麻烦，那么你自己、你的团队、你的工作将会给世界来个惊喜。
2008年12月1日：“伪优化”
为什么？为什么！为什么项目经理会做这么愚蠢的决定，到处改动代码，结果却毫无起色？不仅仅是项目经理，虽然他们在提升性能方面还算是个能手——构架师、团队负责人以及其他一干人等在肆意挥霍大家的生命，做些无用功，做毫无头绪的工作，却不能让我们提供真正有价值的东西。是什么原因造成这样的闹剧？很简单。我们在不断优化——优化我们本身一塌糊涂的东西
。
是哪些白痴在优化他们本身就种下的祸根？就是你们这些人。你，你的朋友，你的老板。这些人都是出于善意却铺就了通向灾难的道路。我们在优化原本错误的做法却成就了最终错误的结果。这样做是错误的，也是可以避免的。但是，同志们，为什么你害怕一点点的努力会造成蓄意的恶行？
你想知道答案
我还是少找你的麻烦，省去些长篇累牍，先给你个答案——向着期望的结果进行优化。这听起来超简单也很显然，但人们总是自以为是地误入歧途，我还是一字一句地逐个讲来。
优化定量测定一下你们现在做得有多好，分析一下你们怎样能做得更好，改变一下方式，然后再测度一下。微软对于优化很有一手，但是我们只度量易于掌控的事而不是探究问题真正出在哪里。所以，优化后却得到一个错误的结果。可以在第2章的“你怎么度量你自己”中了解到更多内容。
意图意图要明确。为优化而优化是纯粹自我满足的表现——不要这样丢人现眼哦。相反，三思，再三思。弄明白你要做什么。专业一些，清醒一些。
期望把心思放在你想要什么，而不是你不想要什么。这里有个误区。人们总是围着问题谈优化而不是解决方法。官僚主义及慢速的软件都是由此而来。他们把精力放在如何驾驭人或代码以防止有错误行为。他们应该把精力放在如何使正确的行为更快更容易上，然后发现其中的异常现象。
结果绝对不要对某个步骤或算法单独分割进行优化。相反，对你期望的最终结果进行优化。我们都体验过局部优化而非总体优化的影响。它扼杀了我们的效率及创新能力，它将摧毁我们的星球。但三两下之后，人们往往就不能摆脱眼前的问题而去顾及他们真正想要的结果。
你能明白什么时候你会伪优化吗？让我们看些例子，再核实一下。
作者注：我意识到，在一个专栏内同时谈论优化代码及优化人的问题会有点混乱。我无法抗拒这么做，因为这二者间千丝万缕的关系正与日俱增。如果对你来说分清二者关系并不难，那就只要关注一下你所在意的问题。
我想，我可以处理
你怎么处理代码的运行时错误？在没有错误出现的情况下你的代码运行有多快？在一次并无错误出现的操作过程中软件运行是顺畅还是经常卡？以最简易最快速的方式完成代码运行有80%的可能，而不是20%。但是，这并不意味着你在错误处理上蒙混过关，你只是没有对它进行优化。要相信，你的代码将以零错误运行，要让它的运行速度更快。对零错误加以验证，确保结果正确。要相信但也要验证。
同样，你是怎么处理人为的与工作过程中的错误？你对其过程中的每一步都进行检查了吗？是否让别人按你的方式，按部就班，并拿出大量的表单来证明他们并没有在骗人？或者，你相信别人能做正确的事——能清除道路上的重重障碍，并随后能验证他们做得没错？相信他们但是要验证。
我无私的读者，包括项目经理，可能会声称他们很信任他们的同事。真的吗？上一次出错时你是什么反应？你是很快修复病根并继续开展工作，还是马上展开一次为期几天或几星期的调查而打乱了团队的工作进展？你是事无巨细亲力亲为还是放手委托给别人？你是每个步骤都要干涉还是只对结果进行评定？信任没那么容易。幸运的是，好人有好报。
似曾相识
你的代码是松散的还是内聚的？是否所有的类、方法及功能都乱成一团麻，还是它们可以分开进行独立测试，每个代码段可以执行各自的目的及任务吗？
有良好架构及分层的代码是易于测试、维护及改进的。但，它不如紧耦合代码的效率高。要有权衡。如果你纯粹为速度而优化，最终你得到的是一团难以维护的面条代码。如果你只为清晰的架构而优化，你就在执行效率上缺乏竞争力。你怎么把握个中尺度？
大部分团队并没有把握好架构与效率之间的尺度——他们在玩过山车：
1团队采用了一个非常好的架构。运行良好，每个人感觉都很好。
2他们对它进行了性能优化。现在效率更高了——原来的团队确实不够专业。
3代码变得难以管理，难以改进，性能遇到了瓶颈，所以这个团队只好痛苦地重构代码。然后代码又变得易于管理了，每个人都笑逐颜开——之前的团队确实还太嫩。
4性能还不够强，所以这个团队又进行性能优化。现在性能又加强了——之前的团队确实没找对路子。
5现在，代码又难以维护了，又要跑回到第3个步骤。
还有一种情况——代码混乱不堪，甚至不能再重构。他们的产品周期变得越来越长，代码运行变得越来越慢，需要更多的内存及更快的CPU。这样的事常发生。
正确的做法是优化以得到期望的结果——易于维护及改进的高性能代码。不是度量运行的速度（这很简单），而是同时度量运行速度及代码复杂度。这样你就找到了二者之间最适当的均衡度。如果你确实够精到的话，你还会度量团队健康及用户满意度指标，在这四者间找到均衡。呵呵，这就像在做买卖（讨价还价）。
击鼓传花
让我们举个更贴切的例子——产品团队的结构。在传统的产品开发与新兴的敏捷拥趸者之间形成了一个战场。谁是对的呢？管它呢！但绝对不要单独地在某一步骤上进行优化——向着期望的结果进行优化。
期望的结果可以在最短的时期内带来大量的客户价值。记住，客户价值是不可用功能多少来度量的，是通过提供令人满意的高质量的点对点体验来度量的。
那么你如何快速地提供高质的价值呢？凭借约束理论（Theory of Constraints，TOC）。约束理论认为一项工程以最快的速度达到目的的方法取决于其中最慢的那一个步骤，比如用户体验、内容发布及团队间共享的可以满足你的需求的操作方法。你的项目经理可能会在规范书中指定一个月内平均完成4项软件功能，开发团队能在一个月内完成2项功能，而测试团队一个月能检测3项功能。要达到项目经理要求的速度，条件还远远不够，对吗？
但是，产品经理们督促项目经理继续写些开发团队无法处理的规范书——优化局部而不是总体。为开发团队添置人力也无济于事（按：《人月神话》与《经济组织》）——同样，眼界太窄了。
正确的做法是，项目经理与测试团队要与开发团队齐头并进。在各个项目功能间留有足够的余地以保持其机动性，但绝不要让项目经理及测试团队的进度快于开发团队。这种约束理论的策略称为：鼓—缓冲—绳子（DrumBufferRope）。因为很难准确预测开发团队的进度，所以你要限制项目功能间的空间，在情况改变的时候，避免开发团队的队列中有太多的工作。
这就是为什么功能小组能行之有效。向着期望的结果进行优化——工作实例，在功能小组中——Office项目采取的方式——项目经理、开发人员以及测试人员在某一个实例中精诚合作，直到完成测试及集成。他们谁也不能跑到别人前头去。Scrum团队与敏捷编程团队要有相同的工作原则。不是简单的团队组合就完美了（虽然他们间的沟通很容易），是要一起步调一致，不断优化产品，为产品带来完善的、高质量的客户价值。
作者注：有读者指出软件开发中的关键制约因素是通信带宽。增加通信带宽的最好办法是使团队同处一地，使他们基于功能点对点一起工作。这种方法同样对提升工作进度有效，就如我之前所说。一些Scrum团队也会采用看板模式，这是一种以更简单更直观的方式应用鼓—缓冲—绳子策略的方法。
不要怨天尤人
对眼前出现的问题往往很容易就会“一见倾心”并马上进行优化，而不是对你实际应该关心的其他问题进行优化。人们向来如此——我怀疑我们与生俱来就是这样的。这确实是优化错误的做法得出错误的结果这种做法的最好理由，但是这个借口太牵强。
你应该明白这个道理，如果你没有，你就没有权力兑现一张支票。想想你期望得到的结果，考虑周全，权衡各因素之间的轻重，在总体上进行优化。这并没那么难。我们每天都这么做，就像我们为我们的人生寻找一种均衡。关键是要深思熟虑而不是耍滑头，要早做计划而不是怨天尤人。你做得到，只要单单地将你的目光盯住终点线。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
