微软团队成功秘诀

 像这种天才型的特殊程序设计师，为了清静而把自己关在房间里很长的时间，而没有人知道他的工作进展，也 许是有发挥创造力的必要，但这对于如期推出产品而言是 冒着极大的风险，无论他多么优秀，领导者都不该把重要 的工作交托给他，除非让他与其他的开发人员一起接受定 期检查工作进度，而且对时限绝不宽贷。可惜有些天赋才 智恣意奔驰的人无法忍受这样的限制。在软件业中，这种 人确实存在，他可以做一些无法想象的创举（在实验室 里?），掀起一波技术的飞跃，但他绝对不会出现在矢志如 期推出产品的开发团队中。
  不论是健康的或病态的闭关修炼者，允许一位开发人 员关在房间里没有人知道他的工作进度，结果通常会是开 发团队的致命伤。所以，一定得竭尽所能地避免这种情况， 绝对不要允许”没有检查点的组员“，否则你难逃失败。
  下载法则软件要经常建构，就 能顺利推出软件通常是由许多许多程序组成的；程序写好后，经过编译器产生执行码，这个动作叫 compile， 通常如果是小而独立的程序，可选直接选择编译成可 执行档，但是以软件包或 C++之类的大型软件而言， 程序数目都在数百个以上，通常每个程序都是编译成 对象文件，即object code，然后众多不同的程序依一 定的结构关系组合成一个软件，这个组合的动作叫作 建构，build，产生的结果是真正可执行的完整软件。 每一套软件的建构方式多多少少都有些不同，原则上， 被呼叫的程序或函数库要先build，主程序最后build。
  ―译者注）将程序建构成软件才能推出，这个自然，总不能卖给 顾客一个不可执行的原始程序代码吧！但我的意思是要能 够经常且定期地建构软件，并不是到了期限前一天才建构 那么一次。你必须随时都让整个软件的现状都能被大家看 见才行。
  在很早以前曾经有过一个案例，各个程序都按计划中的时间表进行撰写，个别程序的测试也完全正 确，但是到了最后却怎样也无法组合，各个程序就是 无法搭配。因为各个程序之间都有相互传递资料或先后连结的关系，或是其中有一个程序内有个无伤大雅的小瑕疵未被注意，但却在别的程序上造成大问题。 在写程序的过程中随时要注意我的程序能否跟其他所 有的程序相互配合，最好的办法就是常常 build，这 样才能做完整的测试。完整测试是 build最基本的目 的，所以作者就不刻意强调，但定期建构软件还有更 重要的益处。―译者注）你能想象几百位工匠蒙着眼睛盖一栋大楼吗？不知道 自己在盖大楼的那一部分，不知道这栋大楼现在盖到第几 层，只顾盖自己的部分，这种大楼怎会不垮呢？因此，经 常建构软件是非常必要的，这个法则的重点不仅是要在整 个开发过程中经常地、定期地建构软件，而且要尽可能建 构出现阶段最完整又最正确的软件，更重要的是建构出来 的结果要放在公开的地方，让每个人都能看到。
  软件也许不必每天都做建构，但是一定要经常且定期 做，而且不只是程序要做建构，安装程序和线上求助的部 分也要包括在内，然后将建构出来的结果放在公开的地方， 让品保人员可以评估每天的软件状况，也可以观察出它发 展的情形，或是陷于停滞。规律建构软件是一项最可靠的 指标，表示团队的运作是否正常，软件是否能够完成。
  丑媳妇也要经常见公婆软件的建构需要时间，程序也很复杂，值得你为它仔 细研拟最适当的策略。在微软内部有很多开发团队采取每 日建构的策略，并有专门的小组（build master）负责这项 工作。建构程序是很重要的，必须确定软件能够建构得起来，没有失败或中断。在每一只程序置入（ check-in）开发环境时，会产生这一只程序需要的建构程序（通常是配 合适当选项的 compile），然后整合在整体的建构程序中。 于是其中任何一段建构程序发生问题的话，很容易找到由 谁来负责，所以组员的责任心和荣誉感会促使自己一定要 做出至少能够合格的程序，而每天的软件建构就会非常顺 利。当然你可以做得更严格，以我的经验，一天建构一次 是最有效率的方式（请参考下一个法则）。
  有些软件公司每次的建构都是把所有的程序都一遍，然后build起来，有些则是将修改过的 程序compile，再build上已有的软件。由于全部 build 一次所需的时间可能太长，所以大部分的公司都采取 第二种方式。说得更口语一些，就是把其中的一块挖 下来改一改再嵌回去。当这段程序被认为 OK了，就 做置入的动作，check-in；每隔一定的时间，就有专 人把这些被改过的程序compile和build。―译者注）另一方面，项目经理应该是拟定最佳化的建构策略， 而不是绝对性的每隔几天做一次建构。不一定要每天做， 应该是采取对软件最适合又最小的间隔，重点是在能够建 构出软件的前题下，用最短的时间间隔建构出软件。
  老实说，我并不知道软件”应该“采取多长的建构周期最好，但我非常相信大部分的软件公司在这方面都做得 不够。对某些开发团队而言，每天建构一次也许稍多，但 我很确定，对任何开发团队而言，每周建构一次绝对是最 起码的。
  项目经理一定要时常看见软件的整体状况，才能明 了现在正在做什么。即使你的工作分配和检查点设置得 非常好，各个组员之间的信任与承诺关系也非常理想， 但若是无法建构软件，则你对进度的掌握将仅限于想象 和猜测，而不是根据事实，所以你还是不能掌握软件开发的真正状况。
  每一次你建构软件，你就能算出错虫数目有多少，你就能掌握软件开发 的进度，你就能看见功能日益成形。
  再者，为了让软件能够建构出来，程序必须维持在 一定的品质水准，太夸张的错误要立刻被发现，而且不 可能将软件倒回去重来。因此，每隔固定时间建构软件，才能够维持软件有一定的秩序和品质，这一点要让大家都知道。 更重要的是，定期建构软件就像是团队的心跳一样，每天五点（比方说），大家都看到今天整个团队的工作成 果，每天都看得到今天的进步，这对团队士气有很大的 鼓舞。如果有一天软件建构失败，或是为了某种原因而 不做建构，马上就会引起大家的注意和紧张，一定要找 出原因来改正。如果建构经常失败，这就是整个项目失 败的前兆。
  但请不要搞混了，我所谓的软件建构，不是程序设计 师在自己的 PC上做的小规模的建构，而是指正式的、公 开的建构，将大大小小的程序结合成软件，而且是每个人 都能看见、能执行的软件。品保人员可以对它做初步的测 试（sniff test），看看它的基本功能大致上有没有错误。如 果你每天都做软件建构，你就很有把握它至少不会当得惨 兮兮，而且大家可以看见它朝着目标一天天地迈进，功能 特色一天天地成形；而且每个人都测试着相同的软件，对 于软件的现状也就会有相同的认知。
  经常建构软件还有其他的好处：
  经常而公开地建构软件可以看出组员彼此之间真正的信赖程度。只要有任何一个环节没有密合，软件就建构不起来，检视建构的过程就像是检视组员之 间或是团队对外的关系，在任何地方发生问题都很 容易找到。
  建构出来的软件可以显露出在设计时没有考虑到的 问题，例如执行效能、对象大小等等，这种问题万 一发现得太晚就来不及修改了。
  软件的建构会很自然地让组员的脚步一致。一般 而言，建构软件最常见的问题是版本协调，最严重 的是各人有各人的版本，谁都不知道别人在做什么 版本，有了公开建构的软件，大家的版本就可以同 步了。
  建构软件可以促使组员面对他想忽略的问题。团队 恒等于软件，所以目前的软件状态就是目前的团队 状态。当我遇到产品有问题时，我追问组员：”我 们软件建构的情况如何？“答案很多种，意思只有 一个：”我们花很多时间才能成功建构一次，有时 候长达两个星期，我们希望时间能够缩短，但是因 为某些某些原因，我们没有办法照计划来建构。“是的，要频繁而规律地建构软件当然会有很多困难，但是解决这些困难却能够带来健康的团队和顺利的开发。
  开发人员必须得自律，自己仔细检查所有的功能都完善了 才把程序置入，程序不仅要在逻辑上执行正确，还得注意 体裁（程序段落清楚）和资源运用（内存用完了要释回）， 以及执行效能，如果个别的程序组件都很健全，就比较容 易建构软件，并且能够大大减少回溯检查的时间消耗。
  在开发过程中，很容易对软件的状况产生错觉，但 是如果你每天都建构一次软件，你看到的将会是具体的 事实。
  下载法则掌握实际情况这又是一个很简单又很有用的道理，引伸的意义是”每天都要有可以推出的产品“。 你必须对软件的实际状况知道得非常清楚，特别是要推出的时候，你必须知道它是什么模样，架构、特色、效 能特性等等。