为什么word2007保存的文档还是以2003的形式打开的，而不是用2007的形式打开的？怎么回事？_百度知道
为什么word2007保存的文档还是以2003的形式打开的，而不是用2007的形式打开的？怎么回事？
请问怎样才可以让word的格式打开我是下了2003的兼容版，下了2007的绿色版，word的格式打开
可是我的总是07的以03的格式打开、怎么弄啊。07以07的格式打开，但是我想让03以03的格式打开我是安装了03对07的兼容
提问者采纳
找个doc后缀的文件，右键-属性，里面选office word 2003找个docx后缀的文件，点打开方式后面的更改这个很简单，右键-属性，点打开方式后面的更改。excel，里面选office word 2007这样就行了
提问者评价
我试了 我的还是那样
我就那样吧
其他类似问题
为您推荐：
word2007的相关知识
其他2条回答
word2003就可以选择word 97-2003，word2007可以选择word 2007 document点击“另存为”，会出现“保存类型”
2007的保存方式有word文档、启用宏的word文档、word97-2003文档、word模板，启用宏的word模板，word97-2003模板、PDF、XPS文档、单个文件网页、网页、筛选过的网页、RTF格式、纯文本、wordXML文档、 word2003XML文档、word97-/95-RTF
总共就有这么多保存格式。您看是哪个？
word文档(.docx)是07的默认方式，如果你安装了03对07的兼容包，03就能打开07了。
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁& [软件]Office 2007把藏功能曝露出来
[软件]Office 2007把藏功能曝露出来
office 2007中的亮点功能
易用、协同与商务智能
在微软（中国）工程师的现场演示中，2007 Office系统Beta 2版本在易用、协同和商业智能等方面的进展也令人耳目一新。
Word 2007的字体可实时预览并在浮动工具栏里实现格式设计的功能，由于Word 2007文档是完全支持XML格式，生成文档的扩展名是DOCX，文件可直接发送至博客或Wiki（百科全书）中，新的Word XML格式还在很大程度上缩减文件尺寸。Word
2007还提供了多种与他人共享文档的方法，用户可以在没有第三方工具的情况下将Word文档转换成PDF或XPS格式的文件。通过SharePoint
Server内置的工作流服务，用户可以在Word 2007中发起并跟踪文档审批流程，这将缩短企业范围的审批周期。
Excel 2007使用了全新的图表引擎，用户可以将丰富的可视化增效特性应用于图表，例如3D效果、柔和阴影以及透明度。此外Excel 2007图表引擎与Word 2007以及PowerPoint
2007相互兼容，因此用户能够在所有应用程序中以同样的方式创建图表并与之交互。另外Excel最大支持的行列数将由65536行、256列增强到1048576行、16384列。
Powerpoint
2007在创建具有动态效果的图表上将更加轻松，其中包括动态工作流图表、关系图表或层级图表，并可以将已发布列表转换成图表，或者修改并更新现有图表。
Outlook 2007提供的瞬时搜索功能已被完全集成到界面中，用户可以快速搜索关键字或其他条件，在电子邮件、日历、联系人或任务中定位项目。新的日历功能为让用户与企业内部或外部人员之间共享日历，用户可以创建Internet日历并将其发布到Office
Online上并将日历快照以电子邮件方式发送给他人或者向客户发送一个自定义的电子商务卡片。Outlook 2007在与Exchange Server
2007结合时，进一步增强了协同、安全性和易用性。
7种桌面版本应对不同需求
Office系统的组件比以往更多，其中包括十多种桌面组件（Word、Excel、PowerPoint、Outlook、Access、InfoPath、
OneNote、Project、Publisher、SharePoint
Designer、Visio、Communicator、Groove）和几种服务器组件（
Project、Portfolio、SharePoint和InfoPath 2007 Forms Services）。
微软在正式发布2007
Office系统的桌面版时将推出7个版本以满足不同用户群的需要。这7个版本包括：基础版、家用及学生版、小型商务版、标准版、专业版、专业增强版和企业版。其中标准版包括Word、Excel、PowerPoint、Outlook这四大最常用的组件；基础版则只包含Word、Excel、Outlook三个组件；家用及学生版在基础版上增加了OneNote；小型商务版在标准版上增加了Publisher，并在Outlook中增加了Business
Manager组件；专业版在小型商务版上加了Access；专业增强版在专业版上又加了Communicator和InfoPath；企业版则包括10种组件，其中包括首次推出的Groove，该软件可为团队提供一个协同工作环境，可用于开展从简单的文档协作到与业务流程集成的自定义解决方案等多种项目。
提示：试试键盘 “← →” 可以实现快速翻页
搜索关键词Submitted by
on Fri, 08/09/2006 - 00:15.
I have a game I play with programmers. I call it five bugs in five minutes. It’s been I while since I’ve done it (you have to be sitting close to the people doing the programming), but I still get to play it every now and then.
The game works like this:
A programmer finishes coding some testable unit of work
The programmer comes over and throws down the testing gauntlet
You go over to the programmers desk and they launch the software you will be testing, navigating to the code that is supposedly “done”, and establishes the limits to the software they are presenting you with
You accept or you decline the challenge (noting that declining lowers your project “street credit”)
If you accept, you test for five minutes with the programmer looking over your shoulder
Every time you find a bug, you laugh sadistically and tell the programmer the bug you found
The programmer (and this is important) confirms or denies that what you found counts as a bug
After five minutes you stop
If you found five bugs (that the programmer confirms are bugs), the programmer pays you five dollars (or buys you lunch)
If you fail to find five bugs (that the programmer confirms are bugs), you pay the programmer five dollars (or buy them lunch)
I find that this game has the following side effects:
Over time, I get more free lunches then I give
Over time, I developer better communication
they become more willing to help me, and they become more interested in fixing my bugs
Over time, the programmers get better at preventing the types of bugs I find - forcing me to change my test techniques and raise the bar of my testing
Over longer periods of time with the same developers, I start to give more free lunches then I get
It allows both of us to grow in a fun little competitive way.
11:59 Link URL:
并非所有的回答都是完美的，不过足够我们参考----cocobase（红色字体的问题表示我们现在做的不够或较重要的）1. 你们的项目组使用源代码管理工具了么？应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么？应该用。ClearQuest太复杂，我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么？不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站？要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么？应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么？需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么？需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么？应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么？要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么？需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况？ 应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么？应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么？不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间，从95%做到100%好值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
16. 登记新缺陷时，是否写清了重现步骤？要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么？要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么？必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么？必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登记的人最后关闭的么？Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 你们的程序员厌恶修改老的代码么？厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
22. 你们项目组有Team Morale Activity么？每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要省这些钱。
23. 你们项目组有自己的Logo么？要有自己的Logo。至少应该有自己的Codename。
24. 你们的员工有印有公司Logo的T-Shirt么？要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议要的。要让team member觉得高层关注这个项目。
26. 你们是给每个Dev开一个分支么？反对。Branch的管理以及Merge的工作量太大，而且容易出错。
27. 有人长期不Check-In代码么？不可以。对大部分项目来说，最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么？要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。
29. 有没有设定每天Check-In的最后期限？要的，要明确Check-In Deadline。否则会Build Break。
30. 你们能把所有源码一下子编译成安装文件吗？ 要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么？当然要做。有三样东西是软件项目/产品开发必备的：1. 2. 3. daily build。
32. 你们公司有没有积累一个项目风险列表？要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
33. 设计越简单越好越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。
35. 你们会隔一段时间就停下来夯实代码么？要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。
36. 你们的项目组每个人都写Daily Report么？要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。
37. 你们的项目经理会发出Weekly Report么？要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
38. 你们项目组是否至少每周全体开会一次？要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
39. 你们项目组的会议、讨论都有记录么？会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。
40. 其他部门知道你们项目组在干什么么？要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。
41. 通过Email进行所有正式沟通Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。
42. 为项目组建立多个Mailing Group如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么？应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
44. 你做决定、做变化时，告诉大家原因了么？要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。
45. Stay agile and expect change要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
46. 你们有没有专职的软件测试人员？要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
48. 你是先写Test Case然后再测试的么？应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例？不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合但要想清楚，你是否有时间去运行那么多test case。
50. 你们的程序员能看到测试用例么？要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。
51. 你们是否随便抓一些人来做易用性测试？ 要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳臭的看久了也就不臭了，不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么？别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。
53. 你们的性能测试是等所有功能都开发完才做的么？不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。
54. 你注意到测试中的杀虫剂效应了么？虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
55. 你们项目组中有人能说出产品的当前整体质量情况么？要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
56. 你们有单元测试么？单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。
57. 你们的程序员是写完代码就扔过墙的么？大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
58. 你们的程序中所有的函数都有输入检查么？不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么？要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
60. 你们有统一的代码书写规范么？要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么？要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62. 产品各部分的界面和操作习惯一致么？要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63. 有可以作为宣传亮点的Cool Feature么？要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
64. 尽可能缩短产品的启动时间要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
66. 你们根据详细产品功能说明书做开发么？要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
67. 开始开发和测试之前每个人都仔细审阅功能设计么？要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么？要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么？不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。
70. 你们的程序员写程序设计说明文档么？要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。
71. 你在招人面试时让他写一段程序么？要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。
72. 你们有没有技术交流讲座？要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。
73. 你们的程序员都能专注于一件事情么？要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
74. 你们的程序员会夸大完成某项工作所需要的时间么？会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
75. 尽量不要用Virtual Heads最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。
15:06 Link URL:
软件开发成功12法则
--------------------------------------------------------------------------------
来自：Blog 作者：Joel Spolsky 翻译：Frank Li []
有没有听说过SEMA？这可是衡量一个软件开发组好坏的很深奥的系统。别动，等一下！别按那个链接！给你六年你也搞不清这玩意儿。所以我自己随便攒了一套衡量系统，信不信由你，这系统，三分钟就可掌握。你可以把省下的时间去读医学院了（译注：美国的医学院可是要读死人的！）。
Joel 衡量法则
1. 你们用不用源文件管理系统？
2. 你们可以把整个系统从源码到CD映像文件一步建成吗？
3. 你们每天白天都把从系统源码到CD映像做一遍吗？
4. 你们有软件虫管理系统吗？
5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？
6. 你们的产品开发日程安排是否反映最新的开发进展情况？
7. 你们有没有软件开发的详细说明书？
8. 你们的程序员是否工作在安静的环境里？
9. 你们是否使用现有市场上能买到的最好的工具？
10. 你们有没有专职的软件测试人员？
11. 你们招人面试时是否让写一段程序？
12. 你们是否随便抓一些人来试用你们的软件？
“Joel 衡量法则”好就好在你只需照着逐条回答以上问题，然后把所答为”是”的问题算成一分，再加起来就可以了，而不需要去算什么每天写的程序行数或程序虫的平均数等等。但咱丑话说在前面，可别用”Joel 衡量法则”去推算你的核电站管理程序是否可靠。
如果你们得了12分，那是最好，得了11分还过得去，但如果只得了10分或低于10分，你们可能就有很严重的问题了。严酷的现实是：大多数的软件开发公司只能得到2到3分。这些公司如果得不到急救可就玄了，因为像微软这样的公司从来就没有低过12分。
当然，一个公司成功与否不仅仅只取决于以上标准。比如，让一个管理绝佳的软件公司去开发一个没有人要的软件，那开发出来的软件也只能是没有人要。或反过来，一帮软件痞子以上标准一条也达不到，没准照样也能搞出一个改变世界的伟大软件。但我告诉你，如果不考虑别的因素，你只要能达到以上12条准则，你的团队就是一个可以准时交活的纪律严明的好团队。
1. 你们用不用源文件管理系统？
我用过商业化的源文件管理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但如果你根本就没有用源文件管理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。
使用源文件管理系统还有一大好处是，由于每一位程序员都把源文件从源文件管理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。
2. 你们可以把整个系统从源码到CD映像文件一步建成吗？
这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。
如果这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。如果这时候你需要做20步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。
正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行)
3. 你们每天白天都把从系统源码到CD映像做一遍吗？
你们有没有遇到过这样的事情：一个程序员不小心把有毛病的源码放进源文件管理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源文件管理系统，然后他高高兴兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。
这种造成最终文件没法制成的情况很糟糕，但却很常见。如果每天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好每天下午（比如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件管理系统里，午餐后，大家回来，如果最终文件已经制成了，好！这时大家再从源文件管理系统里取出最新的源文件接着干活。如果最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。
在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。
如果想更多了解这个话题，可以读我的另一篇文章 Daily Builds are Your Friend.
4. 你们有软件虫管理系统吗？
不论你有任何借口，只要你写程序，哪怕只是一个人的小组，如果你没有一个系统化的管理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记得自己的软件虫。没门！我从来记不住超过２到３个软件虫。而且第二天早上起床后忙着去买这买那，好不容易记住的软件虫早忘掉了。你绝对需要一个系统来管住你的那些虫。
软件虫管理系统功能有多有少。但最少要管理以下几种信息：
如何重复软件虫的详细步骤
正常情况（无虫）应是怎样
现在情况（有虫）又是怎样
谁来负责杀虫
问题有没有解决
如果你觉得用软件虫管理系统太麻烦，可以简化一下，建立一个有以上5列的表来用就行了。
如果想更多了解这个话题，可以读我的另一篇文章Painless Bug Tracking.
5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？
微软Windows Word的第一版的开发项目曾被认为是”死亡之旅”项目。好象永远也做不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度假，让大家坐下来好好想想。
大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出的程序毛病百出。由于项目经理的开发计划并没有考虑杀虫的时间，大家只能把杀虫的任务往后推，结果虫越积越多。有一个程序员负责写计算字体高度的程序，为了图快，居然写一行”return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序功能迟早都会成为软件虫。在项目总结会上，我们称这种工作方法为”绝对劣质之路”。
为了避免再犯这个错误，微软制定了”零缺陷策略”。许多程序员嘲笑这个策略，觉得经理们似乎在指望靠行政命令来提高产品质量。而事实上”零缺陷策略”的真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。
为什么要这样做呢？
一般说来，你越不及时地杀虫，杀虫的代价（时间和金钱）就会越高。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能解决它，因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题，可这个程序是几天以前写的，你可能就需要折腾一会儿，还好，你还大致记得，所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题，就比较难解决了，因为你已经忘了许多细节。这时候，你还没准儿正忙着杀别人程序里的虫呐，因为这家伙到加勒比海阿鲁巴岛度假去了。这时候，解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地，非常系统化地从事，而且你很难知道多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用户手里了，才发现问题，那你就等着套腰包吧。
总结起来，就一条：越早解决问题，越容易解决。
另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举个例子，如果我问你写一段程序去把一个列表排序需要花多长时间，你可以给我一个比较确切的估计。如果你的程序，在Internet Explorer 5.5安装以后，工作不正常。我问你要多长时间把这个问题解决，你恐怕都估计不出来，因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决，也有可能只花两分钟。
这个例子告诉我们，如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。
把已知的虫全部解决，这样做还有一个好处：你可以对竞争对手快速反击。有些人把这叫着”让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。
6. 你们的产品开发日程安排是否反映最新的开发进展情况？
为什么我们需要开发日程安排？如果你的程序对公司的业务很重要，那公司就必须知道你的程序何时能写完。满世界的程序员都有一个通病，那就是他们都搞不清自己何时才能写完要写的程序。他们都只会对管理人员嚷嚷：”等我做好了就做好了！”
不幸的是，程序写完了，事远远没完。作为一个公司，在发行产品之前，还有许许多多的事情要做：何时做产品演示？何时参加展览会？何时发广告？等等。所有的这一且都依赖于产品的开发日程安排。
定下产品开发日程安排，还有一个很关键的好处：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否则这些可要可不要的东西有可能把你缠住。请看featuritis 。
定下产品开发日程安排，按照它开发，这并不难做，请看我的另一篇文章 Painless Software Schedules ，这篇文章告诉你一种制订产品开发日程的好方法。
7. 你们有没有软件开发的详细说明书？
写软件开发的详细说明书就像是绣花：人人皆知是好东西，可没谁愿意去做。
我不知道这是为什么，也许是因为多数程序员天生就不喜欢写文章。其结果是，一个开发组里的程序员们，宁可用程序来沟通，也不愿写文章来表达自己。他们喜欢上来就写程序，而不是写什么详细说明书。
在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了，不仅仅是时间上的代价，而且也有感情上的代价，因为没人愿意将自己做成的东西扔掉。所以这时候解决问题总有一些阻力。
没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。我觉得这就是Netscape遇到的问题。前四个版本的程序越写越乱，以至管理人员作出一个愚蠢的决定：把以前的程序统统扔掉，重新写。后来他们在开发Mozilla时又犯了同样的错误。产品越做越乱，完全失控，花了几年的时间才进入内部测试阶段。
我最得意的理论是：如果让程序员们接受一些写文章的训练如an intensive course in writing，他们就可能会改变一下不写说明书的坏习惯，而以上所说的糟糕的例子就有可能少发生。
另一个解决问题的办法是：雇一些能干的项目主任，专职写产品开发详细说明书。
不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。
如果想更多了解这个话题，可以读我的四篇文章。
8. 你们的程序员是否工作在安静的环境里？
当你让你的智囊们工作在安静，宽敞，不受人打扰的环境里，他们往往能更快地出活，这已是不争的事实。有一本经典的讲软件开发管理的书Peopleware 把这个问题阐述得很清楚。
问题在于，我们都知道最好不要打断这些智囊们的思路，让他们一直处于他们的最佳状态中，这样他们就能全神贯注，废寝忘食地工作，充分发挥他们的作用。作家，程序员，科学家，甚至篮球运动员都有他们的最佳状态。
问题还在于，进入这个最佳状态不容易。我觉得平均起来，需要15分钟才能进入最佳状态，达到最高工作效率。有时侯，当你疲劳了或已经高效率地干了许多工作了，你就很难再进入这个状态，只好干点杂事打发时间，或上网，玩游戏等。
问题更在于，你很容易就被各种各样的事打扰，被拽出你的最佳状态：噪音啦，电话啦，吃午饭啦，喝杯咖啡啦，被同事打扰啦，等等。如果一个同事问你一个问题，只花你一分钟，可你却被拽出你的最佳工作状态，重新回到这个状态需要花半小时。你的工作效率因此而受到很大影响。如果让你在一个嘈杂的大房间里工作（那帮搞网站的家伙还就喜欢这样），边上的推销员在电话里大叫大嚷，你就很难出活，因为你进入不了你的最佳工作状态。
作为程序员，进入最佳工作状态更难。你先要把方方面面的细节装在脑子里， 任何一种干扰都可能让你忘掉其中某些东西。你重新回来工作时，发现好些东西记不起来了（如你刚用的局部变量名，或你刚才的搜索程序写到哪里了等）你只好看看刚写的程序，回忆一下，慢慢地回到你刚才的最佳工作状态。
我们来做一个简单的算数。假设一个程序员被打扰一下，哪怕只有一分钟，他却需要花15分钟才能回到最佳工作状态（统计资料显示如此）。我们有两个程序员：杰夫和愚夫， 坐在一个大办公区里工作。愚夫想不起来用什么函数去进行Unicode 字符串复制。他可以花30秒查一下，或者花15秒问杰夫。由于他坐在杰夫的旁边，他就选择去问杰夫。杰夫被打扰了一下，耽误了他15分钟，节省了愚夫15秒钟。
现在，我们把他们俩用墙和门隔开，让他们俩分坐在不同的办公室里，愚夫又想不起来什么涵数名，自己查一下要花30秒；问杰夫，要花45秒，因为他要站起来走过去问（对这帮程序员来说，这可不是件简单的事，看看他们的体质就知道为什么了）。所以他选择自己去查。愚夫损失了30秒钟，可是杰夫少损失了15分钟。哈哈！
9. 你们是否使用现有市场上能买到的最好的工具？
用可编译语言写程序恐怕是这世界上为数不多的还不能随便抓一个破计算机就可以做的事。如果你用于编译的时间超过几秒钟，你就应该换一台最新最快的计算机了。因为如果编译时间超过15秒，程序员们就会不耐烦，转而去上网看一些无关的东西比如The Onion，弄不好一看就是好几个小时。
调试图形界面软件时，用只有一个显示器的计算机不仅不方便，有时甚至是不可能。用有两个显示器的计算机，要方便许多。
程序员们经常不可避免地要去画一些图标或工具栏图。多数程序员没有一个好的图形编辑器可用。用微软的”画笔”软件去画图标简直是笑话，可事实上大家还就在这样做。
在我的前一个工作，系统管理员成天给我发来自动警告，说我在服务器上使用了超过220兆的空间。我告诉他，按现在硬盘的价钱，超出这点空间的价钱远低于我用的厕纸的价钱。让我花10分钟去清理我的文件绝对是我工作效率的莫大浪费。
一流的开发组绝不折腾它的程序员。工具落后会让人用起来觉得难受，一点点积累起来，会让程序员们成天叫苦，而一个成天叫苦的程序员绝对不会是一个高消率的程序员。
再添一句，要想使你的程序员高兴，最好的办法就是给他们买一些最新最棒的工具软件。用这种方法可以让他们乖乖地为你工作，这可比用高薪吸引他们来得便宜得多。
10. 你们有没有专职的软件测试人员？
如果你的开发组里没有专职的测试人员，或没有足够的测试人员（两到三个程序员就应该配一个测试员），那你的产品就一定是毛病百出，或者你在花100美元一小时的代价去雇你的程序员去做30美元一小时就可以雇到的测试员的工作。想在测试员身上省钱，绝对是打错了算盘。我真不明白为什么这么多人算不过来这笔帐。
我有另一篇文章专门讲这个，请看Top Five (Wrong) Reasons You Don't Have Testers。
11. 你们招人面试时是否让写一段程序？
我问你，让你去招一个魔术师，你是否连看都不看一眼他的魔术玩得怎样就要他？当然不会！
你举办婚宴，要请一个厨师，你是不是连也不他做的菜好吃不好吃就要他？我想也不会。
奇怪的是，几乎每天都有这样的事发生：在面试一个程序员时，简历写得漂亮，谈得热火朝天，问几个简单的问题（如CreateDialog()和DialogBox()有什么区别？这种问题，查一下帮助文件就知道了），人就招进来了。你真正应该关心的不是这人记不记得这些写程序的边边角角的东西，而是他能否出产品！更糟糕的是，许多问题是知道就知道，不知道，想死也不知道的问题。
不能这样下去了！在面试时，请一定要让写一段程序。在我的这篇文章里Guerrilla Guide to Interviewing，我有许多好建议。
12. 你们是否随便抓一些人来试用你们的软件？
这句话的意思是，让你从走道里走过的人中，随便抓几个人来，让他们试用你的软件。如果你抓五个人来用你的软件，那你就可能把你的程序中95%的不方便使用的地方找出来。
要想让用户去买你的软件，你必须要设计好你的用户界面。这其实并不难。你可以读我的free online book on UI design打打基础。
用户界面设计的关键是，如果你让几个人去用你的软件（五六人可能就够了），你可能很快就找出最大的问题。想知道为什么吗，请读Jakob Nielsen's article。只要你坚持随便抓一些人来试用你的软件，你就能将你的用户界面设计得越来越好。
The Joel Test 软件开发成功12法则的四个实用领域
1. 用该法则来衡量你的软件开发组，告诉我你得的分数，让我来品头论足。
2. 如果你是开发组的经理，用该法则来使你的组提高效率。如果你们一上来就能得12分，你就 别再打扰你的程序员了，专心致志别让公司的管理人员来烦你的程序员吧。
3. 如果你在找一份程序员工作，问问你未来的老板他能得几分，如果分数很低，你一定要确信你进去后有足够的权力来改变这一切，否则，最好躲远点，不然，你在那儿会很难受的。
4. 如果你是投资者，正在决定是否向一个软件公司投资，或者你的软件公司正在决定是否兼并另一个软件公司，该法则可以帮你做决定。
作者：Joel Spolsky 是纽约市一家小软件公司，Fog Creek Software, 的创始人。他毕业于耶鲁大学，曾在美国微软公司、Viacom、Juno 任软件设计师及经理。
15:07 Link URL:
57224/2924}