可以探讨探讨

不过就软件工程应用的总体目标而言，微软的成功无出其右，windows的成功我觉得历史几乎只有system360可以超过他，历史上，360一出，诸mainframe纷纷退避，windows参差相似。而windows, system360, linux的开发历史正代表了三种不同软件工程的思想，这三种也正是三种现在主要的软件工程方向。

其实我觉得不妨设想一下，假如是先有linux和open office,那么windows还会这么成功吗？

 为什么就不会呢？
　

---

当然，事实上，如果让Linux和Open Office占先，那么Bill Gates就不是Bill Gates了

我手头有这么几本书

1.微软的秘密
Microsoft Secrets - How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
by Michael A. Cusumano

2. The 12 Simple Secrets of Microsoft Management - How to Think and Act Like a Microsoft Manager and Take Your Company to the Top
by David Thielen

3. 微软团队:成功秘诀
Dynamic of Software Development
by Jim McCarthy, Denis Gilbert

4. 微软研发:致胜策略(开发过程调试技术)
Debugging Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
by Steve Maguire


5. 微软项目:求生法则
Software Project Survival Guide - How to Be Sure Your First Important Project Isn't Your Last
by Steve C McConnell

6. 软件开发的科学与技术
微软亚洲研究院著

我觉得微软的开发模式和管理模式与XP很类似，但是我想学微软的公司会不会死掉，因为微软的人才策略与众不同

微软的开发模式比较特别，呵呵。

我觉得微软的所有制度都建立在人才是第一流的人才上，极端地反对文牍主义，极端地自由化，甚至有一些无政府的味道，不重视formal的东西，只看中代码，开发人员通常从feature specification开始完成代码，等等等等。

这些在国内的环境里， 尤其在企业员工素质不是很高的情况下，很难照搬。

 回复: 具体一点好么
　

---

这一点我同意，但是看msf并不是去照搬他们的模式，但是他们这些模式的精髓还是可以学习的。比如他的六个角色，之所以要这么设置，充分说明了一个项目所涉及的方方面面，做一个项目必须从这些角度去看问题。
目前比较流行的敏捷开发，不是也不提倡formal的东西吗？微软也不反对formal的文档啊。我们与微软的mcs合作开发过项目，我们的formal的文档还是很多，而且很formal的。

我看到94年的一本讲微软的书，提到程序经理更像一个协调者，而不是管理者，开发小组是按照特性划分的，小组长负责指导小组成员的开发，更像是一个知道者/教练， 产品部门经理更像是一个推动者，产品经理是相当于营销经理。

在这里，看不到什么正式的权威，好像很扁平，但是感觉上很难实施。

能不能讲一下微软的文档有哪些？ 微软的方法与XP之间又有什么区别？ 象微软这样规模的软件企业，如果采用类似XP的方法，它的优点和缺点在什么地方？

微软的XP之道

摘自XPChina

最近读了关于微软得软件开发模式得资料，又读了关于“极端编程”得资料。了解了现代企业得现代管理模式。“极端编程”是指软件开发的极端状态，也就是理想状态。微软的方法更具体，“极端编程”在开发过程中各方面人员的相互交流方面更成熟。总体上两种方法在大的方面都是雷同的。

关于微软得开发模式得资料可以参考《微软的秘密》，关于极端编程的资料可以参考 http://c2.com。

综合两者，简述一下软件开发的方法。

保证开发计划按时完成和产品质量的方法：

开发要完成的内容是根据用户的需要确定的。在微软是由销售人员确定用户需求。这里主要说明“极端编程”的方法。在极端编程中，用户确定要开发的功能，用户可以把对自己更重要的功能放到前面先完成。开发人员对这些功能提出每个功能实现的时间，用户如果认为时间太长可以取消一些功能。这样，通过这种协商和反馈，保证了开发的最大价值。同时，因为是开发人员确定功能实现的时间，因此，计划必要容易按时完成。特性不要要求太具体，要简单勾勒。

实际上，用户开始不知道自己需要什么，这需要开发人员研究用户行为，提出可以实现的效果，用户对效果进行评价和修改，来确定开发的目标。当开发完成时也要提供给用户进行试用，获得反馈意见，对产品进行改良。这也是和用户不断交流的过程。这种交流保证了产品确实是用户需要的。

对于每项功能，由开发的组织者和开发员讨论制定详细的完成步骤，确定每一部分要达到的具体效果，写详细的文档，描述每个界面完成的外观和函数的功能。这叫任务引擎。任务引擎不是一次写成的，可以随时间不断详细化。

根据任务引擎再编制详细的时间计划，将任务引擎划分为若干个任务，每个任务由一个人负责，这个时间计划要由每个具体的开发人员提出或协商每个任务和每个任务的具体部分的完成时间，这个时间计划要细分到半天至三天，至少一个星期。在每项任务的完成时间后面要留有缓冲时间以应付意外情况和时间估计的不准确。只有计划的时间单位的细化才能保证任务的完成在完全的掌握中。

在时间计划中有界面冻结时间、文档冻结时间、代码冻结时间，这样保证了计划的相互关联的部分不会影响计划的完成。

开发部门和测试部门是相互独立的部门，几乎每个开发人员对应一个测试人员，两者的人数是1：1。要求开发人员每天把完成的代码放到服务器上，每天测试人员进行昨天完成的代码的测试以及以前代码的测试，并将发现的问题发到服务器上，反馈给开发人员。有时因为发现的问题太多，管理人员会发现开发的难度，因此会取消部分任务和开发。测试人员和开发人员要完成的工作都有详细的规范，规定具体要完成的内容。通过专业的测试，保证了软件的质量。

在开发中，管理人员要追踪计划的完成情况，及时发现问题，指导问题的解决，保证计划完成，根据问题调整计划。

微软把每个软件版本的开发过程分为几个里程碑，大概每两三个月一个里程碑，每个里程碑实现部分的特性（软件功能。在微软，软件功能被成为特性。）。最重要最基础的特性放到前面的里程碑中，不重要的特性放到后面的里程碑中，这样，如果要保证软件的按时发布，最后可以删掉一些不重要的特性保证软件的按时发布。每个里程碑都要在公司内部和外部进行软件的发布和各种公共测试，保证了用户的反馈和这部分功能的最后稳定。这样，避免了到软件发布的最后时期才进行各种公共测试的被动。也加大了和用户交互的机会。

在每个里程碑中，一般都留下三分之一的缓冲时间，来应付各种开发的意外情况，使开发工作可以从容完成，如果到了缓冲时期，为了保证计划的完成有可能取消一些不必要的功能。缓冲时间在“极端编程”中称为“时间因子”。

这些方法实现比较复杂，但这是已经有大量工程和公司的实践。不是理想的空中楼阁。针对具体公司，根据自己的管理条件，可以分批逐步实现。或者没有能力实现，也可以参考先进的项目管理方法，认识到自己管理上的各种问题产生的原因，有一个管理的目标。

你说得对，我的理解是，msf的组队模型提倡一种平等的交流，每个角色在项目组内都是平等的，只是从事的工作不同而已。在现实的执行过程中，还是需要有人来对整个项目负责的，每个项目仍然是有项目经理，就像MSN有MSN的项目经理，Windows2000有Windows2000的项目经理，等等。

微软的文档也很多，比如有《Vision/Scope》、项目结构文档、设计规格说明书等等。

我觉得象XP这样的敏捷开发适于小型的团队，需求不明确或者变化很大的项目，可能适于国内很多做小项目的公司。而MSF则是一种重型的过程模型，对开发大型项目来说，他的作用能够体现的更加充分。

 回复: 能不能讲一讲？
　

---

其实，去微软的大多都是牛人，所以很多别人觉得比较奇怪的方法在那里都是有可能的。

 你会越活越好！
　

---

很多优秀的方法都有他们的相通之处，我们要学他们的精髓，而不是表面的内容。

微软招人的一个要求就是野心勃勃，微软的文化是比较赞同冲突的，这就建立了一个平等的基础。 如果其它公司没有这样的背景， 是很难学得微软的秘诀。