| 看微软的软件开发——站在巨人的肩膀上 |
"站在巨人的肩膀上"，也许可以帮我们看得更高更远。微软帝国的大厦是如此高大、辉煌而眩目，究竟有什么秘密？它正是靠着"程序员的聪明和测试员的勤奋"构建起软件帝国的大厦、谱写着软件事业的辉煌。
这些天才的建筑师是如何成功的？他们有什么秘密武器？籍此文来"窥一斑"，而见"全豹"。
请注意微软是基于产品的开发模式，而目前我们的开发模式基于项目，正在向产品化的方向转型。剔出不同点，发现共通点，就是我们可以借鉴和参考的"武器"。当然，我仅仅是基于SQA的角度，并且根据自己工作中所见所感而写的，难免片面，仅供大家参考。
一、关于过程
1. 产品的开发基于过程--若干里程碑式的重要阶段；
我们与之的共同点在于：基于项目的开发，同样基于若干里程碑式的重要阶段，每一个里程碑处，都会形成若干重要的工作产品，如需求规格说明书、体系结构设计和数据库设计说明书…不同之处在于"是形似还是神似的问题"。"里程碑式"的工作产品，水分有多少？质量如何呢？是否真正可称之为"里程碑"还是仅仅为了赶工期呢？需求规格书能否全面、详尽、无二义性地表达用户需求呢？体系结构设计能否真正达到目的？如果一步一个脚印，踏踏实实地到达每一个里程碑，后面的路会越走越顺畅。
2. 使用缓冲时间，帮助项目适应意料之外的事件，归避风险；
在微软的开发模式中，每一阶段约有1/3的时间留作缓冲时间，以在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间是每一个主要里程碑的一部分。缓冲时间主要用于弥补由于对特性（Feature）的不完全理解，或者是技术困难或是由于疏忽而忘记把任务写入进度，或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之外的事件。我们在项目的开发过程中，也常常会遇到难以预料的事件和风险：如用户配合差、技术的难题、用户需求的变更、人员的流动等等，常常会影响计划的进度，以至于延误工期，或者是开发出的产品不尽如人意。而现实往往是：一压再压的工期，越来越多的需求…使我们陷于被动、难于应付。我们有些项目往往是战线拉得很长，远远超过了预期的工期。与其这样，倒不如在策划时，能够为自己留点余地，加一些缓冲时间，是否可以使我们更加主动，产品更加完美呢？
在我们向产品转型的现在，做精品软件的思想，是否也能使我们更加理性、冷静地行为呢？
3. 充分而有效的计划阶段，产生出开发计划、最初的产品说明、最初的测试计划、用户文档策划、问题清单等；
这一阶段类似于我们的"项目策划阶段&需求分析阶段"。注意：必须是充分而有效的阶段，否则，地基不牢固，如何建筑坚固的楼宇？
4.科学、艺术地制订进度计划；
我们也订进度计划、周计划，可是又有多少能够按时完成？其中之一的原因是：计划制订不科学、不合理，所以建议大家在订周计划之前，不要贪多求全，而要量力而行。至于如何科学、艺术地订计划？这是个值得探讨和深入的话题，限于能力和篇幅，不再赘述。
二、关于测试
5.对测试的重视。测试与开发几乎同步进行，及早测试，及时更正错误，并在整个开发阶段内使测试不断地、自动地进行；
微软操作系统的bug，似乎已经成了众人嘲讽的话柄，但这也在某种程度上证实了测试的难度和重要性。尽管存在着bug，但是我们仍然不得不承认windows无可比拟的诸多优点。这其中一个不可不说的现实是：测试功不可没！微软对测试的重视贯穿于整个过程：从计划阶段-开发阶段-稳定阶段，测试工作贯穿始终。测试员与开发员并行、配对工作，人员的比例是1：1（这在我们看来似乎是有些不可思议，我们的测试、开发员之比约为1：4）。在产品稳定化阶段，还要进行详尽全面的内部测试，之后对"β"版本，由用户进行全面的外部测试。文中，有这样一段话，在软件的开发流程中，软件的测试与开发是一种"矛与盾"的关系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。我相信，在微软，这种对测试的认识是"深入人心"、上下共通的，否则，没有上层的重视，没有开发员与测试员的配合，没有顺畅而高效的流程和沟通，测试工作如何能达到这样的高度呢？
什么时候，我们对测试的认识能够普及到每一个人，能够象对待开发一样对待测试？我们的开发员和测试员不会再各自为政？测试员不会再抱怨"版本又变了，我一点儿也不知道"，"开发文档总是不尽人意"？开发员不再埋怨"我很忙，没有时间，文档里很清楚"？
希望这个时间不要离我们太远。
6.高技术、高素质的测试人员；
微软的测试员不但善于发现错误，还要分析错在那里，并且能与开发员一起清除错误。测试员与
开发员的水平不相上下，甚至更高。这也是测试经理能够与开发经理并驾齐驱，甚至临驾其上的原因之一。
7.高效的源代码管理工具、先进易用的测试工具和测试管理工具；
"工欲善其事、必先利其器"。微软的秘密武器之中，有这样一些重要组成：SLM(Source Library Tree),源代码管理工具，负责管理软件开发过程中各个程序员的源码。
RAID（Raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance）.这个工具负责管理产品的BUG情况，进而可以了解产品进展情况（如果BUG数持续增加，那就意味着产品可能出了问题），项目经理还可以根据这个工具，及时的掌握、了解每个测试员和开发员的工作状态。另外，微软还有一套先进的方法和工具管理着测试的方方面，使得测试员能够在有序、条理的条件下使用和测试软件产品。
有很多人曾经说过：Microsoft凭借着SLM和RAID打败了无数的竞争对手，我看这话一点也不假。这两个工具确实是非常杰出的工具，微软将它们使用到了十分艺术的程度上，对微软的成功起着非常重要的作用。更难能可贵的是，目前这些工具在功能上还在不断的进行改进、升级，使得微软的工程师们工作起来更加如虎添翼、虎虎生风，这样的企业哪有不成功的道理?
我们的配置管理工具VSS，在整个软件生命周期中，对维护和规范我们的工作产品发挥着越来越大的作用。可是，由于种种原因，我们总是听到开发员和测试员的抱怨"CHECKOUT怎么这么慢？5分钟甚至更长"，"糟糕，又出错了！"…应当尽快改善工具存在的问题，让它地帮助我们提高效率，规范流程，让大家习惯和喜欢用工具。
我们的测试工作大部分还停留在"刀耕火种"的手工时代，测试效率低，周期长，不能在软件开发的各个周期进行完整的测试。希望自动化测试工具尽早发挥它应有的作用。
现在我欣喜地看到，我们的测试队伍不断壮大，有越来越多年轻、积极的力量加入进来。测试管理工具也正在改进中，自动化测试也已经启动…
最后，建议大家有时间看看这篇文章，你一定会有不同的收获。 |
| yippit 发表于 2006/10/19 16:44:00 阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志 |
发表评论：
|
|
| 公 告 |
|
| 登 陆 |
|
| 日志日历 |
|
| 搜 索 |
|
| 日 志 |
|
| 评 论 |
|
| 链 接 |
|
| 统 计 |
| |