人月神话：微软开发模式和原则
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
微软通常采用“同步－稳定产品开发法”。典型项目的生命周期包括三个阶段：
计划阶段：完成功能的说明和进度表的最后制定
开发阶段：写出完整的的源代码
稳定化阶段：完成产品，使之能够批量生产（Roll Out）
这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”（Water Fall）式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。
在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。这种里程碑式的工作过程使微软经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足进度要求。
计划阶段
这里我总结了一下，主要是做以下事情
把你准备做什么样一个产品搞清楚，这个产品有什么特性
这个产品有没有市场，用户为何需要这个产品，已经该产品的走势
这个产品大概是个什么样子，是否有个大概的原型展示方便高层决策
设计的功能，目标，优先级，大概的进度。
所以微软指的这个计划阶段保护了很多可行性研究和产品规划的内容在里面，更多的是一个产品规划的内容。
开发阶段
开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户教育人员（User Education）则编写出文档草案。(参考微软的MSF模型)
当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后（40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此只允许小范围的改动。如果在此点之后开发员想作大的改动，他们必须与程序经理以及开发经理进行讨论协商，也许还要征求产品部门经理的意见。(这里有两点，一个是提倡及早的发现缺陷和持续的集成，一个是后期严格的对需求变更进行控制）
一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即“缓冲时间”（Padding Time）。
(应该所1/3时间是足够多的，一般研发项目很难预备这么足够的Buffer)
当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”（UI Freeze），即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动，以免引进同步修改相应文档的困难。
稳定化阶段
稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟。在软件的开发流程中，软件的测试与开发是一种“矛与盾”的关系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。
在微软内部有专门的SLM源代码管理工具，负责管理源代码和自动构建。开发人员每天在下班前将自己的代码Check In,SLM由预先定义好的脚本进行自动编译。第二天测试人员再下载前一天的Build进行测试。将测试的情况及时的反映到另外一个工具软件中,可以根据这个工具查询哪个开发员当天的BUG活动的、解决的数量，哪个测试员的BUG质量数目等等一些基本的产品质量情况，这样项目经理可以很容易的掌握该项目的具体进展情况。还有项目经理可以根据这个工具，及时的掌握、了解每个测试员和开发员的工作状态，这一点也很重要。(微软的源代码管理和每日构造和持续集成机制是很值得推广的地方)
微软也许正是靠着“程序员的聪明和测试员的勤奋”构建起软件帝国的大厦、谱写着软件事业的辉煌。
[解决办法]
sf
[解决办法]
jf
[解决办法]
说句题外话;
微软的成功很多都是来自与其他公司高手的加入.
例子很多:
SQL SERVER, .NET....
都是挖人来做的
[解决办法]
写的很好啊，很有启发，想自己做软件的时候发现，这种递增式的开发是很有必要的。不过要看你是做哪一行业的软件了，不同行业的软件开发过程可能存在很大的差别。
[解决办法]
不错.很内行.
