Microsoft的软件开发模型简介-集合

作者: hyenachenyao（BlueHyena）-北京大学出版社出版的《微软的秘密》一书的摘录

北京大学出版社96年底出版的《微软的秘密》一书是我所介绍的有关微软软件产品开发过程的最，最深入的书. 通过本书，我们可以了解Microsoft如何有效地科学地管理软件产品的开发. 我认为这些经验对中国的大多数软件开发人员特别是关心中国软件行业发展的朋友大有裨益. 的. 因此，我特别摘录了本书中与软件产品开发相关的一些内容（第4章“产品定义和开发过程”）并与您共享. 作为摘录，本文自然而然地闲逛了，因此，如果有时间，我建议您查找原始书籍.

在产品定义和开发过程中，Microsoft遵循一种称为“通过改进功能和固定资源来激发创造力”的策略. 该策略可以分为五个原则:

首先，将大型项目划分为几个里程碑式的重要阶段，每个阶段之间都有缓冲时间，但是没有单独的产品维护.

第二，使用富有想象力的描述和功能的简短描述来指导项目.

三，根据用户行为和与用户有关的信息确定产品特性和优先级.

第四，建立模块化的横向设计结构，使项目结构体现产品结构的特征.

五，依靠个人责任和对固定项目资源的控制.

原则1: 将大型项目划分成几个里程碑式的重要阶段，每个阶段之间都有缓冲时间，但是没有单独的产品维护.

项目进度和里程碑

Microsoft通常采用“同步稳定的产品开发方法”. 典型项目的生命周期包括三个阶段: 在计划阶段完成功能描述和时间表的最终制定，在开发阶段编写完整的源代码，并在稳定阶段完成产品的开发. 实现批量生产. 这三个主要阶段以及这些阶段之间的固有循环方法与传统的“瀑布”开发方法有很大不同，传统的“瀑布”开发方法由需求，详细设计，模块化代码设计和测试，集成测试以及系统测试组成. 微软的三个阶段更像是风险驱动的，渐进的“螺旋式”生命周期模型.

计划阶段的产品是富有想象力的描述和文档，用以解释项目将要做什么和要做什么. 在管理人员草拟时间表并由开发人员编写代码之前，所有这些都促使人们思考设计问题. 讨论和开发阶段围绕三个主要内部产品版本进行；稳定阶段着重于广泛的内部和外部测试. 在整个产品生产周期中，Microsoft使用了缓冲时间的概念. 缓冲时间使开发团队能够处理意外的困难和影响时间表的变更. 它还提供了缓解及时发货与试图准确估计交货时间之间矛盾的方法.

在开发和稳定阶段的所有时间中，项目通常将其时间的2/3花费在开发上，将1/3的时间花费在稳定上. （办公室部门副总裁曾经以这种方式概述了通常的进展情况: “一般来说，在总体进度表中，一半时间编写产品，另一半时间用于调试或应对事故. 因此，如果我对于一个为期两年的项目，我将用一年的时间来完成我事先想到的事情……如果事情有些麻烦，我将删除我认为不重要的功能. ”）这种里程碑式的工作流程使Microsoft经理能够了解产品开发过程的步骤，他们还能够在开发的后期灵活地删除某些产品功能，以满付期的要求.

计划阶段

计划阶段是指在项目生命周期中进行所有计划之前所执行的时间. 计划阶段产生富有想象力的描述，营销计划，设计目标，初始产品描述，为集成其他小组开发的组件而指定的接口标准，初始测试计划和文档计划（印刷和帮助））以及可用性问题列表. 规划阶段以富有想象力的描述开始. 富有想象力的描述来自每个产品单元的产品经理和程序经理；这是产品运营的营销理念，包括分析竞争对手的产品和计划显示的版本. 富有想象力的描述可能还会讨论以前版本中必须解决的问题以及应添加的重要功能. 所有这些都是基于客户和市场分析以及从产品支持服务小组获得的信息.

描述文件以轮廓开头，然后定义新的或添加的产品功能，并为其分配不同的优先级. 本文档仅是产品功能的初步概述. 从开发开始到项目完成，都需要增加或更改20％-30％. 尽管在生命周期的后期阶段更改通常很小，但是后期开发人员必须有充分的理由进行更改.

通常，程序经理使用VB创建项目原型. 他们还进行设计可行性研究，以了解设计中的权衡因素，并尽快做出涉及产品描述的决策.

重要产品的描述需要由公司的高级领导审查. 对于要求不高的产品，一些经理会这样做.

发展阶段

开发阶段计划为三个或四个主要里程碑版本的每一个分配一组功能，指定功能和技术相关性的详细信息，并记录各个开发人员的任务和进度估计. 在开发阶段，开发人员在功能描述的指导下编写源代码，测试人员编写测试项目团队以检查产品功能和工作范围是否正常，而用户教育者编写文档草稿.

当测试人员发现错误时，开发人员不会将其留给以后处理，而是会立即进行纠正，并使测试在整个开发阶段连续且自动运行. 这样可以提高产品的稳定性，并使版本的发布日期更容易估算. 在进入项目的某个阶段（占40％）之后，开发人员试图“锁定”产品的主要功能要求或功能，并且只允许进行很小的更改. 如果开发人员希望在此之后进行重大更改，则必须与程序经理和开发经理一起工作，并可能会向产品部门经理寻求建议.

一个项目围绕3或4个主要内部版本或“里程碑子项目”进行组织. 开发每个主要里程碑版本通常需要2到4个月. 每个版本都包含自己的编码，优化，测试和调试活动. 该项目为事故保留了总开发时间的1/3，即“缓冲时间”. （Apple的团队是独立的，独立的，并且自己开发自己的东西. 只有3个月的出货时间，所有东西才会整合； Boland以渐近的方式发展，也就是说，将工作分成许多小部分，并且始终让开发的东西起作用. 这种渐进方法似乎需要很长时间，但实际上Jihu并没有使用很长时间，因为它使您始终可以掌握事物的真实情况. ）

在测试并稳定了最后一个主要里程碑版本之后，该产品将“固定外观”，即确定该产品的主要用户界面，例如菜单，对话框和文件窗口. 从那时起，将不再对相关的用户界面进行重大更改，从而避免了同步引入相应文档修改的麻烦.

稳定阶段

稳定阶段集中在产品测试和调试上. 在此阶段，除非竞争产品或市场发生变化，否则该项目将尝试不添加新功能. 稳定阶段还包括处理不可预见的问题或延迟的缓冲时间.

项目进度中的缓冲时间

Microsoft使用缓冲计划在最高效率和对未来的更好预测之间取得平衡. 这次处理紧急情况是发展和稳定过程中每个重要里程碑的一部分. 缓冲时间主要用于弥补由于对功能的不完全理解或技术困难，或者由于疏忽或无法预见的问题而忘记编写任务以完成进度而导致的漏洞. 缓冲时间有助于项目适应意外事件.

原则2: 使用富有想象力的描述和特性的简短描述来指导项目

为了提供足够的开发框架以允许工作继续进行，并适应开发过程中的变化并保持足够的灵活性，Microsoft使用富有想象力的描述和摘要说明来指导项目开发，而不是从一开始就试图写一个完整而详细的描述. 所谓的虚构描述是由市场经理的项目经理和产品计划人员准备的简短文档，主要定义了产品开发的目标（不涉及产品的具体细节！）. 通常对于崭新的产品，富有想象力的描述通常是相对详细的，并且还包含一个粗糙的描述文件. 总体而言，Microsoft对富有想象力的描述的要求是: 越短越好，请尝试解释“产品没有做什么”（而不是“产品做什么！”）.

使用富有想象力的描述，程序管理器开始编写功能说明文件，该文件解释什么是产品功能以及这些功能与其他功能和产品的关系. 最初，它只是一个简短的描述文档. 随着项目的进行，程序经理将随时向其添加更多详细信息，最终的描述文档将变得像用户手册一样. 完整的描述不仅用于描述产品的最新功能，而且还是在产品投入生产和运输之前进行测试和评估的主要依据.

富有想象力的描述有助于确定要删除的功能

Microsoft中的各个开发团队使用富有想象力的描述来帮助完善产品版本的规定主题，然后使用此主题来决定是否增加产品的每个可能功能. 通常不要轻易更改已确定的主题，否则可能会导致产品开发混乱.

写一个描述文件

文档在产品团队的所有成员之间，产品团队之间以及产品团队与管理部门之间传达产品想法和要求方面发挥着作用. 必须在描述文件中清楚地描述产品功能（从用户的角度描述每个功能的工作方式，外观以及与用户的交互. 如果该功能具有接口，则还应包括以显示效果）的接口），并为其赋予相应的优先级. 在此基础上，程序经理确定项目的开发进度. 另外，还应包括以下内容: 用一句话表达的项目开发目的，产品是什么，不是什么的列表，客户的定义，竞争产品的定义以及产品的系统要求. 产品（包括操作系统版本，最低内存要求，硬盘空间，处理器速度和显示分辨率），是否依赖第三方（例如打印机驱动程序，组件）.

程序经理负责协调和“写下”说明

计划经理应考虑以下问题:

＊此功能的重点是什么

＊用户如何使用此功能

＊此功能有意义吗？

＊此产品或其他Microsoft产品是否具有相似的特征？

＊遗漏了哪些问题

＊小组内部的沟通是否令人满意？

最后，程序经理通过与小组中的开发人员讨论来决定功能的内容，并将其写下来.

构造原型

原型制作是程序管理员指定新产品或新版本的最佳方法. 这样就可以通过多种方式进行开发前测试，尤其是在可用性方面，并有助于与用户互动. 对情况的充分了解也可以使产品说明更加紧凑.

Microsoft开发人员通常使用VB来构建用户界面原型，但是Paintbrush还是用于诸如构建计算机屏幕模型之类的任务的良好工具.

僵化的描述成为生动的文件

描述不应过于详细以限制本发明. 在项目的开发过程中，文档的早期版本将有所增加和更改. 由于描述中的更改可能会导致相应的开发工作发生重大变化，因此Microsoft通常将精力集中在那些没有用户界面的功能上，因为在完成开发之前不必了解用户如何对它们做出反应，也就是说，这些特征不太可能会改变. 然后面对其他特征.

但是，在产品达到某个程序（例如40％）之后，程序经理必须严格控制功能的修改（主要是指添加新功能），否则不仅会导致开发延迟，但也会压缩可用的测试时间.

原则3: 根据用户行为和与用户相关的数据确定产品及其优先顺序

对于开发项目，通常很难确定最终产品应包含哪些功能. 为此，Microsoft采用了一种称为“基于行为的计划”的方法来选择功能并确定优先级.

基于行为的计划始于对用户行为的系统研究，例如写信或制定预算. 然后，它基于支持重要或频繁用户行为的程序评估功能. 这样的好处是，可以更合理地讨论特征的选择，更好地安排客户想要做的事情，就给定特征是否有助于完成特定任务进行更集中的辩论，并获得更易读的解释，以及更好的营销同步性，用户培训和产品开发.

在特征选择和优先级安排中基于行为的计划

基于行为的计划方法的关键是根据用户行为，产品特征以及行为与特征之间的内部联系来分析产品. 程序经理和产品计划人员将产品要支持的用户任务或解决方案分成大约20个“行为”，然后他们尝试将行为（以及任何子行为）映射到Microsoft的当前特征和竞争对手的特征中产品. 他们还将行为映射到不同的客户图像或不同的细分市场.

在描述产品的新版本时，基于行为的计划方法可帮助程序经理和开发人员集中精力和创造力. 每个新版本中最多只能有四个针对Excel等项目的主要操作. 绝大多数控制直接映射到这些行为. 这种方法可以使项目根据特征对用户的价值进行排名.

通过评分，鼓励程序经理和开发人员采取行动，以便其功能支持尽可能多的行动. 这种良性竞争对用户有利，但也有利于提高生产率.

针对客户行为而不是产品特征的恐惧数据

根据合肥市规划的进度，该项目首先在规划阶段着重于合肥市，其次是特色. 计划经理和营销人员不会考虑并排除自己喜欢的功能，而是围绕它们提出富有想象力的描述草案. 他们真正要做的是列出客户的所作所为，然后将其富有想象力的描述集中在支持这些行为的特征上.

以行为为中心的产品综合考虑

因为基于行为的计划是基于整个产品的角度进行的，所以它可以帮助从事不同职能的项目成员了解该产品的功能以及其他产品的相应特性如何支持那些需要或不需要其他功能的应用程序. 软件产品的行为.

进行营销研究以支持基于行为的计划方法

为了支持基于行为的计划，营销团队的产品经理与程序经理和开发人员进行了联合研究，例如指导用户研究. 但是，总的来说，产品经理会进行大部分研究，并且可以使其更清楚地影响Microsoft产品的发展.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-172843-1.html