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

原则4: 建立模块化和水平的设计结构，使项目结构反映产品结构的特征

Microsoft产品设计中的一个关键概念是产品的基础结构，特别是生命周期较短的应用程序软件，随着项目的进行，它应该变得更加统一（而不是复杂）. 当开发团队构建产品的第一个版本时，他们更经常使用层次结构来指定产品设计的初始体系结构. 随着时间的流逝，他们转向了一个单一的结构，以便该项目可以专注于功能开发. 该项目需要逐步鞭打和删除我，花一些时间来更改和发展我，并提高产品性能和操作的一致性. Microsoft越来越强调不同产品之间的功能共享. 共享有助于协调不同产品的“性能和感觉”；它还为需要多个应用程序软件的用户提供了便利，减少了代码重写，并减小了单个应用程序软件的大小.

Microsoft使用功能组来组织产品开发. 这种方法使每个人都易于理解该组与整个产品的关系. 该项目以法规的摘要描述开始. 摘要描述的形式是与相对独立的功能相关的内容的优先列表，这些功能将在下一版产品中开发，以供独立的功能团队开发.

程序经理和开发人员将项目划分为功能子集，并将其分配给每个功能团队，从而使他们能够生成3-4个主要的内部项目里程碑. 通过这种产品组织和开发方法，Microsoft只需添加开发人员并创建一个庞大的小组，即可逐步增加产品的功能.

使用特征（和功能）作为开发单元

微型软件产品的特征是相对独立的功能单元微软公司开发的软件，就像建筑材料一样，对于用户而言最终是可见的，尤其是对于相应的软件产品而言. 系统软件产品（例如NT或95）的特性通常对最终用户不直接可见. 微软和其他公司有时只是将这些不可见的功能称为“功能”.

程序经理负责开发一组功能或功能，以实现从描述，测试和文档到最终完成的过程. 他们必须与开发人员合作，开发人员负责估计进度并改进每个功能. 开发人员还需要在联网的开发计算机上存储一个或多个文件，以保存程序的源代码.

大多数功能仅由一个开发人员开发和改进，而一些大型功能则需要一小部分.

产品结构是决定其长期结构完整性的基石

产品结构是产品的支柱. 它指定了重要的结构组件以及这些组件如何组装在一起. 产品结构和用于组装结构的组件为实现产品特性（即详细的设计和编码）提供了基础. 产品的结构通常对最终用户不直接可见. 仅要实现的结构的特征可见. 产品结构也是决定产品长期结构完整性的基石. 产品功能上的任何更改都不应导致潜在的产品结构崩溃.

产品层次结构

对于产品，您还可以使用层次结构进行分析. 定义明确的层次结构通常有助于灵活地添加，删除和改进产品功能. 此外，良好的层次结构有助于将产品移植到不同的平台上. （例如，Excel总共定义了五层，其中只有操作系统层的底层与平台相关，其他层是通过调用较低层提供的API接口实现的，因此其移植是在Windows 95上通过“虚拟机”的概念支持16位，32位和DOS程序. ）

小型文档: 源代码是唯一文件

除API文档外，Microsoft不会为其产品结构生成相应的文档，尽管有时高级开发人员可能会编写高级结构. 对于复杂的功能，许多开发人员会在某些时候记录并查看特定于其职责的结构细节，但是这项工作是可选的，而不是强制性的. 除了源代码文件和功能描述之外，少数小组还为新程序员准备了文档来描述结构层（主数据结构，其工作方式等）. 但是，这些文件不会不时更新，管理人员不需要项目团队生成此类内部文档. 相关文档未解决实施问题. 开发人员应该知道如何实现它，或者能够学习它. 关于该结构的书面文件很少，因为“开发人员的工作是编写我们要出售的代码，而不是花时间编写高级设计文件”，“设计文件不应与源代码分开”.

拆分代码并“保持简单”

具有特色的团队和团队负责人为“内容专家”

功能组通常由负责人和3至8个开发人员组成，负责相关功能区域. 小组的人数通常取决于小组负责人的经验和能力. 特性团队负责人向项目开发负责人报告，并负责拟议目的的所有开发工作；项目开发负责人对产品有更全面的了解，因此很可能会发现与部门有关的问题. 功能组中的每个人都是该领域的“专家”，他们了解如何使用产品，了解竞争对手的产品以及未来的发展方向. 通常，为了促进沟通和改善软件的组织结构（软件往往会勾勒出构成软件的组织的结构），应保持特征组的较小规模.

原则五: 依靠个人责任和对固定项目资源的实际项目控制

对于软件项目，很难准确估计产品开发和交付进度. 在这方面，Microsoft采取的方法是将调度和工作管理的职责推到最低的级别，即各个开发人员和测试人员. 这样可以确保每个人除了成为小组成员之外，还负有个人责任. 各个开发人员设置自己的进度表，而程序管理器汇总各个进度表并增加缓冲时间以创建全面的项目进度表. 高层总经理还会固定人事和时间等基本资源，以确保项目集中化，并限制其工作量和创造程序.

主要目标（特别是对于应用软件而言）是指示产品的目标生产日期并力求尽可能长时间地维护它. 计划经理和开发人员从生产日期回溯，并指定中间项目里程碑的日期. 这种“固定生产日”方法的重点是开发人员. 这是为了避免在最终的无用设计，重新设计和测试周期中浪费一年或一年以上的时间，因为该项目没有固定的终点.

开发人员自行估算进度

比尔谴责康Kang每次砣烤护理∽砸训练并调查第八个姓氏intersection棕榈相交ǖNa棕榈凇C挑衅速色这不是一个好主意怪N Yi盗贼？ 0年前，我放弃了自制的日期设置方法. “但是开发人员通常会做出更乐观的估计，因此开发经理仍然需要调整他们提供的日期并增加缓冲时间，以避免由于信息不完整而引起的问题. Microsoft取得这种进展的方法的优势在于，它可以得到人们的更多合作因为日期是自定的，所以这不是由经理决定的；进度总是激进的，因为开发商不可避免地低估了他们需要的房地产.

估计详细任务的进度

Microsoft的第二种调度方法是非常详细地考虑要完成的任务. 在此基础上，要求开发人员给出他们对“实现”的估计，以便“促进”更多的真实感. 并避免高估.

通常，Microsoft将任务精简到4小时（一天半）到3天之间. 关于准确计划的安排，微软的经理知道: “任何任务只要长达一周以上，人们就不能充分考虑它. 任何有人估计它可以在不到半天的时间内完成的任务. 被认为太多了. 他应该花更多的时间进行编程，而花更少的时间去思考. “对于Windows NT这样的操作系统，调度更加困难. 或估计工作单元的进度半周.

安排开发人员和团队进度时的心理

当项目规模扩大时，Microsoft将员工分成小组. 然后经理将时间表的职责和所有权尽可能地分配给团队和个人. 这给双方都带来了作品的主人翁感. 这也会给团队（尤其是团队负责人）带来很大的压力，以跟上其他同事的预期进度，因为经理可能会重新平衡进度并从落后的团队或个人那里接管工作. 这样微软公司开发的软件，同事之间的压力使管理人员可以毫不费力地对个人或个人团体的进度进行严格控制.

“固定”发行日期

为了将创造力限制在期限内，Microsoft现在争取在新产品或新版本产品开始之前的固定生产日期，至少以生产日期的内部目标为前提. 这给人们施加压力，要求他们削减功能并专注于一项，迫使他们认真考虑将新功能添加到产品中. 尽管最终产品交付目标可以由高级管理人员确定，但是开发人员和团队仍然可以制定自己的时间表.

附录: 同步稳定的开发方法

计划阶段

定义产品的想象力描述，描述和进度

*富有想象力的描述产品和过程管理部门使用广泛的客户意见来确定和优化产品特性.

*文档基于富有想象力的描述，程序管理部门和开发团队定义了功能的功能失调，结构问题以及零件之间的相关性.

＊制定进度表和结构特征组. 在文档中，程序管理部门协调计划并安排特征组. 每个小组包括大约1个程序经理，3-8个开发人员和3-8个测试. 人员（与开发人员以1: 1的比例并行工作. ）

发展阶段

使用3-4个顺序子项目，每个子项目都会生成一个里程碑产品来完成功能开发.

程序经理协调开发过程.

开发人员设计，编码，调试. 测试人员和开发人员会结成对，并不断进行测试.

*子项目I前1/3的功能: 最重要的功能和共享的组件.

*中间的子项目II 1/3特征.

*子项目III后1/3个特征: 最不重要的特征.

稳定阶段

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