微软团队成功秘诀

在你将它当成产品推出时，你必须知道所有能够得知的情况。
  如果你询问开发人员软件的状况，他可能答对，但那是碰巧。
  现在，假设有人要求你对刚推出的产品加进某一个特 色，你能够立刻掌握这个特色对软件的一切意义，那你就 会胸有成竹，因为你知道该怎么做才能加入这个特色，会 不会对现有架构产生重大的影响或冲突等等。你可以召集 一些开发人员和品保人员、文件人员，讨论一下就可以确 定大家对这项特色的了解，大家对自己的角色和任务范围 都非常清楚，然后你就可以说：”来吧，开始行动！“也许几天以后，也许一星期左右，那几位组员手上拿 着磁盘片来找你，告诉你新的特色做好了，只要安装这个就可以把新的特色加入软件。并不困难，是不是？
  这是因为你能够充分掌握情况的缘故。你要知道，推 出一个新版本就好像无数次不停地加上新的特色，然后推 出。这是最能让你理解组织软件开发活动的方式：将一群 各种角色的人组织成一组，负责一项功能特色；关键就在 让软件保持在你能充分掌握，又能够推出的状态。千万不 要让软件变成一堆凌乱的单元，千万不要让软件成为你不 清楚的状况，千万要抓紧对它的掌握，不要放松。
  想要掌握软件的状况，一定要有品保人员帮助你，你 需要有人专职负责检查软件的状况。如果你去询问开发人 员，他的答案也许是对的，但那只不过是碰巧猜对。开发 人员虽然是直接创造软件的人，但他们却无法知道软件全 面性的真实面貌，这还是得靠品保人员来评估衡量，让专 门的第三者来向你报告软件的状况。
  而且你每天都得亲自做点小的测试，一部分是自动的， 一部分是手动的；每周或每两周要把产品整个测过一遍， 确保你的软件随时都在可以推出的状态。
  什么叫做”掌握软件的状况“呢？就是在某一特定的 时间点，对于每一个产品组件的一切状态都有精确的信息。 因为有品保人员将各个组件都测试过，所以你能确知信息是正确的。在你手上必须有一张清单，上面清楚列出各个测试通过和没通过的功能、错虫数目、错虫发现率和清除 率，和一些其他重要的数据。
  我们要注重数据管理，像变动率（ churn）就是很好 的数据，你可以看出有多少的程序代码增减，当然还有许 多其他的数据可以参考，都挺有用的。但重点是，你决定要看那几项数据，就得每天去测量它们。
  预定的目标能够确实完成，就可以推出。
  然而，并不是由品保人员去评估决定软件是否可以推 出。由于开发是团队全体的责任，软件是否可以推出在每 个人的心里都有数，这应该是不会有争议的─原本设定 的目标能够确实完成，就可以推出。当你终于在每一项预 定功能上面打勾表示完成时，你会拥有那种真正的成就感（还有你的报酬），难怪你愿意为这个勾勾去努力。 但先决条件是你能掌握软件的状况，而且维持有关软件的最新信息。你必须善用你的品保人员来做到这一点。
  时时刻刻对软件的状况清楚掌握其实是相当困难的，你必须有一群非常优秀的品保人员。很多软件公司只有很 少或没有真正的品保人员，所以永远无法掌握软件的状况， 事实上，一个现代化的软件开发团队是不能没有品保的。
  记录里程碑这一段主要是对法则33的补充说明。我在此特别要针 对这些软件开发的观念作详尽的说明，这些都是我多年来 不断摸索、思考、创见、旁征博引以及求来的，是我与多 位极聪明的同事，犯过不少大错所换取到的。
  你想在软件产业中占有一席之地吗？你想有点不凡的 进步，不是吗？所以你必须做个”里程碑“（milestone ） 的记号，表示你现在到达了某个目标，但你还要前进到下 一个里程碑。
  里程碑一定要有一种衡量的标准，否则很难达到，所 以不要设定一个无法精确定义的目标。你的每一个目标， 不论大小，都应该有个专属的档案来做记录，你的资源投 入一定不能模糊随便。
  下载法则零缺点里程碑在发展中的软件本质上是无形的、捉摸不定的。一部分存在于开发人员的脑袋，一部分是在媒体里边看不见的 字节，一部分以纸张的形式散见于各个计划中的文字，更 有一部分是完全不知道的潜意识，随时都在变化，要到适 当的时机才会被激发出来。而团体的潜意识，不论是创造 性或是病态性，在无形中都表现在组员的日常活动和每天 所做的决定中。正如前文所述，软件恒等于团队，所以团 队的一切状况都表现在软件之中，软件就是团队活生生的 投影。
  零缺点不代表软件中没有错虫，也不表示没有遗漏的功能。
  如果想把软件的开发活动管理得当，就得让软件定 期”整装待发“，这时候大家对软件所付出一切有形无形 的努力就可见分晓，同时也可以分析那看不见的潜意识 究竟是创造性或病态性。当以各种形式分散在各处的软 件组件建构成一整体之后，你可以得到完整的软件状况 信息，看看下回应该改进什么。然而，即便是经常建构微软团队成功秘诀软件的好处那么多，这件事背后所需的一切─包括产品 的设计、发展程序和团队内心潜藏的各种动力，实在是 件复杂无比的工作。
  软件推出就是最后一个里程碑。
  暂且不管多么复杂，为了让开发工作能够顺利进行， 你至少要让组员把手上的工作划出一个成形的句点，并且 要有勇气面对一切麻烦的问题，同时也让组员加强对软件 现状的了解，让组员更有信心、更有能力预测自己付出什 么程度的努力会有什么样的结果。一开始大家都会很痛苦， 但慢慢能够培养出这些能力，对这些场面应付自如，开发 工作也会顺利起来（请参看法则3）。
  很多微软的开发团队使用”零缺点里程碑 “（ Z e r o Defects milestone ）的方式来了解软件现状，简称” ZD“ 里程碑。所谓零缺点，并不代表软件中没有错虫，也不表 示没有遗漏的功能，而是指团队的成品达到了事先规划的 品质水准，也经过测试验证，就是零缺点里程碑。在 Visual C++的团队中，我们每一次推出产品通常会预先规划三到四个里程碑，一个产品周期正常是一年左右。
  当然，最后一个、也是最高的里程碑就是软件推出， 但是其他的里程碑绝对是同等重要。
  我们在法则33中倡导，软件应该随时保持可以推出的 状态，而且每天如此、永远如此，这是个理想，但事实上 即使没有进度落后的现象，有时候也会做不到这一点，因 为你 偶 尔 会 需 要 倒 回 头 一 些 ， 去 处 理 前 面 的 问 题（regressive things），像是将前面为了换新功能而暂时替代 的东西要移除掉（好像在道路修筑过程中要另辟一条暂时 的便道才能维持畅通，确定修好了之后便道就得拆除）。 而零缺点里程碑，就像是经过较长的时间后的某一点，要 确保软件的状态必须达到预期的品质水准，好似定期大扫 除或大检修一样，不要把小缺点久留。
  一个里程碑大约是六星期到两个月，当这个日期到了， 除非里程目标已经达成，所有的开发活动都不能跨越这个 里程碑往下走。因此，里程目标常常被称为”中间产品“（deliverables），而且是大家都能看得到的。达成里程目标 之后，新的里程随即开始。
  这个原则说来容易做来难，如果你有充分授权的开发 团队，团队中的各个成员可以共同确定里程目标达成，管理者没什么事要操心。每一次的里程目标都由品保人员事先设计好验证的准则，事先沟通每一个通过验证的品质水 准细节，而且大家都同意、有共识。也就是说，这个中间 产品的品质水准是由组员协商出来的，而不是管理者命令 出来的。每一个中间产品都有事先定义好的验证准则，注 明每一项准则应该在什么时候通过，这许许多多的验证准 则会由项目经理集合起来，就是里程碑。
  采用”零缺点里程碑“最大的好处是，每当有进度延 误时，能够立即发现并在最短的时间内补上，也可以确保 问题能够防微杜渐，及时处理。如果你每一两个月就有一 次里程碑，你就得把进度延误控制在这个里程碑之内。你 在一个里程碑内所发生的进度延误总比整个项目少，也比 较容易赶上，这比到了最后推出时才发现要好得多了。每 一次里程碑都确实达到，也就给你一个确定的信息；若是 预定的里程碑日期到了，软件却又再过了 n周才达到应有 的品质水准，你至少有个立场来催促团队加把劲儿：”我 不知道我们最后的推出日期会延误多久，但这次的里程碑 已经确定我们落后了n周。“法则所有组员一起到达零 缺点里程碑如果有一个工作小组遇到的困难比较多，以致前进的速度比较慢，而其他的小组已经完成份内的工作时，最好 让其他人支持比较慢的这一组；团队工作应该平均分配， 其中有一组做得特别快或慢都不是很好的现象，毕竟，团 队工作是全部都做完才能算完成，只要有一部分尚未完成 就等于失败。