微软项目管理简介课件

微软项目管理 内容 l微软历史，微软项目组织框架，微软项目管理战略 l原则一：将大项目分成若干里程碑式的重要阶段，各 阶段之间有缓冲时间，但不进行单独的产品维护。 l原则二：运用想象性描述和对特性的概要说明指导项 目 l原则三：根据用户行为和有关用户的资料确定产品特 牲及其优先顺序 l原则四：建立模块化的和水平式的设计结构，并使项 目结构反映产品结构的特点 l原则五：靠个人负责和固定项目资源实施控制 l小结：同步稳定开发法 l微软团队，微软测试，微软文化，微软人才，微软启 示 微软历史 l1975年 多少员工与营业额？ l3个员工与$16K营业额 l1989年 多少员工与营业额？ l4000个员工与$800millions营业额 l2000年 多少员工与营业额？ l35000个员工与$ 24000millions 营业额 l利润？ l$ 15000 millions l平均年龄？ l34岁 微软的人员分工与职责 微软产品组织结构 微软产品项目组人员结构 lWindows 2000 多大？ l50millions line of code lPM项目经理?人 l约250人 lDeveloper开发人员? l约1700人 lTester测试有关人员? l约3200人 人员分配比例 微软的软件开发过程简介 微软的哲理 l微软与CMM或ISO所推崇的结构化软件工程方 法不同。微软追求高度灵活，把松散组织成的 小组风格提升成为正规的产品开发 微软的目标 l自由性和严格性的统一。小的，平行的小组（ 38人）能够分工合作，形成大的组织，并能 以相对快的速度开发大型产品。 l各小组可平行工作，但坚持同步，且经常性进 行纠错。 微软的软件工程原理 The first principle of software engineering ? KISS Keep It Simple and Stupid 软件项目管理与好莱坞电影 大家应该非常熟悉好莱坞电影的制作流程。？ 首先是找编剧写剧本，然后聘请导演、挑选演员，影片拍摄 完成之后，由市场推广人员负责宣传造势这是一支整合 作团队，但成员之间的合作很少有固定的时候，往往是电影 拍竣，成员也各奔东西。之后呢，又一部新影片进入规划阶 段，于是，又一支新团队诞生了 在这样的形势下，软件企业亟需轻装上阵，这就要求企业在 危机来临前重视自己的核心技术，尽可能地把非盈利核心的 业务外包出去，让这些业务成为其它企业的盈利焦点。 微软开发流程图 微软软件项目管理管理思想 闪耀着智慧的光芒1 l精明人士和小型团组。聘请一批素质高、水平高的人物组成小 型团组。他的依据是：优秀开发员总是喜欢与优秀的开发员在 一起工作，利用这种优-优组合，大大提高了工作效率和工作 质量。 l使团组之间相互依赖性减少的产品结构。在微软，其良好的组 织结构能使相互依赖性降到最低限度，即使在开发组内部也是 如此，从而有效降低了各团组及团组内部之间进度协调这一瓶 颈所带来的工作和控制难度。 l单一的主要开发语言。盖茨认为，“员工们可以争论什么是最 优的开发语言。但是一经确定，即是唯一”。这样做消除了工 作人员就技术或项目管理进行交流的客观障碍。 l公司内部使用自己设计的软件工具。这样，开发人员就能毫不 费力地掌握它们，同时降低公司的生产成本。“总的来说，微 软从使用自己的软件工具中获得了莫大的好处。” 微软软件项目管理管理思想 闪耀着智慧的光芒2 l多人了解有关产品细节。在微软，很少出现这样的情 况：仅仅一个人熟悉一个庞杂的代码，而其他人嚷嚷 “噢，上帝！咱们的头是唯一能修改这个代码的人。 ”这对软件的开发与维护来说是至关重要的。它不会 因为哪怕是一个关键人物的出走而使整个软件项目停 顿下来。而在软件界，技术人员流失是经常发生的。 l经理人员既创建产品又进行技术决策。微软称其没有 不懂技术的管理人员，因此，去寻求技术和管理之间 的平衡毫不费力。 l范围广泛的消费者信息反馈圈。对软件产品来说，这 一点是很重要的，它不仅有助于完善产品，也是树立 良好产品形象的有力手段。 规范的软件项目开发管理1 l项目进度报表制度 微软的每一种软件产品都有相应 的项目进度报表，盖茨及其他高级行政管理人员（包 括相关项目组的领导）每月都会接到从不同的项目组 递交的此类报告，从而全面掌握各项目组的项目实施 状况。 微软的进度报表要求言简意赅，并且有一套标准格式。 高层管理人员能迅速地浏览报表并发现可能存在的问题 。 微软项目开发管理还有单一的主要开发语言、统一的技术标准等 技术特点，它们共同作用，使微软的软件开发工作高效、实用 ，这里不再赘述。 规范的软件项目开发管理2 2.程序复查 大约每过三个月，微软就召开各项目的程序复查会 议。这些会议一般延续两个小时，盖茨与其他高级管理人员通 常都会参加。 项目组一般从各职能领域派遣一至二个关键人员为代表列席会议 ，这些职能领域包括程序管理组（专门负责编制产品说明书） ，软件开发组（编写计算机代码），软件测试组（测试代码） ，产品管理组（产品策划及营销），用户培训组（准备产品文 档），涵盖了软件开发中的各个方面。 这样的程序复查是一种严格、全面的项目检阅。通过程序复查， 高级经理们将会对各项目的进展和前景有一个进一步明确的认 识，从而可以确定哪些项目应加快步伐，哪些应取消。不过， 各项目组（产品组）自己的问题要由自己解决。 盖茨的杰出才能在这里又一次得到充分体现：他能迅速发现各小 组正费尽心机设法解决的技术细节问题，而不论此项目课题是 属于他所擅长的领域还是超出他个人经验之外。 同步稳定的方法 l创意通过特性的演进以及固定资源来发挥 把大项目划分为多个子项目，每个称为里程碑， 安排缓冲期 利用“预想陈述”和“特性规格概述”来指导项目 用户需求的获取，大规模的用户调查 模块化，每个模块与组织结构一致 设计按照体系结构进行。 l目标：适应变化的需求，发挥开发人员的灵 活性。 l原则：频繁的同步，周期性的稳定。 微软开发战略 l在微软的产品定义与开发过程中，微软 软件开发遵循着一种可称之为 什么？ l“靠改进特性（Feature）与固定资源（ Resource）来激发创造力”的战略。 l该战略可分为五个原则： l原则一：将大项目分成若干里程碑式的 重要阶段，各阶段之间有缓冲时间，但 不进行单独的产品维护。 原则一 l项目进度安排与里程碑 微软通常采用“同步稳定产品开发法” 。典型项目的生命周期包括三个阶段： l计划阶段：完成功能的说明和进度表的 最后制定 l开发阶段：写出完整的的源代码 l稳定化阶段：完成产品，使之能够批量 生产（Roll Out） 里程碑的作用 程序员极容易沉迷于技术，要 么乐不思蜀，要么焦头烂额。 里程碑就象心灵的灯塔，使忙碌 的人群不混乱，不迷失方向。 原则一的特点1 l这三个大阶段以及阶段间内在的循环方 法与传统的“瀑布”（Water Fall）式开发 方式很不相同，后者是由需求、详尽设 计、模块化的代码设计与测试、集成测 试以及系统测试组成的。而微软的三个 阶段更像是？ l风险驱动的、渐进的“螺旋”式的生命周 期模型。 原则一的特点2 l计划阶段的产品是想象性描述与说明文件，用来解释 项目将做什么和怎么做。 l在管理人员拟定进度表、开发员写出代码之前，这些 东西都促进了人们对设计问题的思考与讨论。开发阶 段围绕三次主要的内部产品发布来进行；稳定化阶段 集中于广泛的内部与外部测试。在整个产品生产周期 中，微软都使用了缓冲时间的概念。作用？ l缓冲时间使开发组能够对付意外的困难和影响到时间 进度的变故，它也提供了一种手段，可以缓和及时发 货与试图精确估计发货时间之间的矛盾。 原则一的特点3 l在开发和稳定化阶段的所有时间中，一个项目通常会 将多少时间用于开发，多少时间用于稳定化？ l2/3的时间用于开发，1/3的时间用于稳定化。 lOffice部门副总裁曾这样概述通常的进度：“一般说来 ，在总的进度表中，用一半的时间写出产品，留下另 一半的时间调试或应付意外事故。这样，如果我有一 个两年的项目，我会用一年来完成事先想好的东西 如果事情有点麻烦，我便去掉我认为不太重要的 特性。” l这种里程碑式的工作过程使微软的项目经理们可以清 楚地了解产品开发过程进行到了哪一步，也使他们在 开发阶段的后期有能力灵活地删去一些产品特性以满 足发货时期的要求。 1.1计划阶段1 l计划阶段是在一个项目的生命周期中， 所有于开发前进行的计划所占用的时间 。 l计划阶段产生出想象性描述、市场营销 计划、设计目标、一份最初的产品说明 、为集成其他组开发的构件而规定的接 口标准、最初的测试计划、一个文档策 划（印刷品和联机帮助形式的）以及一 份可用性问题清单（Usability List）。 1.1计划阶段2 l计划阶段从想象性描述（Vision Statement） 开始。？ l想象性描述来自产品经理以及各产品单位的 程序经理；它是对规划产品的市场营销设想 ，包括了对竞争对手产品的分析以及对未来 版本的规划。 l想象性描述也可能讨论在前一次版本中发现 面临必须解决的问题以及应添加的主要功能 。所有这些都基于对顾客和市场的分析以及 从产品支持服务组处得到的资料。 1.1计划阶段3 l说明文件从一个大纲开始，然后定义出新的 或增加的产品特性，并对其赋以不同的优先 级。 l说明文件只是产品特性的一个预备性概览； 从开始开发到项目完成它要增加或变化？ ？ l20% - 30%。 l虽然在生命周期的后期说明变化一般较小， 但越到后期，开发员就越是必须？ l出具充分的理由来作改变。 1.1计划阶段4 l通常程序经理使用VB创建项目原型。 l他们也开展设计可行性研究以了解设计 中的取舍情况，尽快做出涉及产品说明 的决定。 l对于重要产品的说明需由公司高层领导 进行复审。对于不太重要的产品，则由 部分经理去完成。 计划阶段5 l计划阶段中最重要的事情是让整个产品 组的成员对共同的目标形成共同的认同 。 l一座伟大建筑的诞生往往只缘于一位伟 大建筑师的不朽贡献，但一个伟大软件 的设计却需要？ l成百上千人的智力创造。 1.2开发阶段1 l开发阶段，也叫主要里程碑阶段。 l开发阶段的计划对三四个主要的里程碑版本都逐个分 配一组特性，规定出特性的细节和技术上的相关性， 记录下单个开发员的任务以及对进度的估计。 l在开发阶段中，开发员在功能性说明的指导下写源代 码，测试员？? l写出测试项目组以检查产品的特性与工作范围是否正 常，用户教育人员（User Education）? l编写出文档草案。 l在每一个子项目（里程碑）内，进度表应当具体到每 一个开发人员，而且进度表中应当加入缓冲时间。 1.2开发阶段2 l当测试员发现错误时，开发员怎么办？ l并不是留待以后处理，而是马上改正，并在 整个开发阶段内使测试不断地、自动地进行 。 l这就改善了产品的稳定性并且使版本发布日 期更易估计。当达到项目中的一定阶段点后 （40%时），开发员就试图“锁定”产品的主 要功能要求或特性，从此只允许小范围的改 动。如果在此点之后开发员想作大的改动， l他们必须与程序经理以及开发经理进行讨论 协商，也许还要征求产品部门经理的意见。 1.3开发阶段3 l一个项目是围绕着3或4个主要的内部版本，或“里程碑 子项目”来组织开发阶段的。一般用2至4个月来开发每 一个主要的里程碑版本。每个版本都包括其自身的编 码、优化、测试以及调试活动。项目为意外事故保留 总开发的？时间 l1/3，即“缓冲时间”（Padding Time）。苹果公司？ l苹果公司的小组是割裂的、独立的，各自开发各自的 东西。在还有3个月就要发货时，才会将所有的东西 集成起来； lBorland公司以一种渐近的方式进行开发，即把工作分 成许多小的部分，并且总是让开发的东西能够运转。 看起来似乎这种渐进的方法费时，但实际上几乎没有 用过很长时间，因为这使你总是能掌握住事情真实的 情况。 缓冲时间 l项目进度表中的缓冲时间（Padding Time） 微软使用缓冲计划，以在最高的效率与较好 地对未来作预计之间求得平衡。 l这种应付突发事件的时间在开发和稳定化过 程中是每一个主要里程碑的一部分。 l缓冲时间主要用于弥补由于对特性（Feature ）的不完全理解，或者是技术困难或是由于 疏忽而忘记把任务写入进度，或者是未料到 的难题而形成的漏洞。 l缓冲时间有助于？ l一个项目适应意料之外的事件。 1.2开发阶段4 l当对最后一个主要的 里程碑版本做了测试 与稳定化之后，产品 就要进行“外观固定”（ UI Freeze），？ l即确定产品的主要用 户界面，如菜单、对 话框以及文件窗口等 。此后有关用户界面 将不再进行大的改动 ，以免引进同步修改 相应文档的困难。 开发阶段5 l开发阶段有一个微软所有的产品组都会用到 的重要里程碑：？ l代码完成（CC：Code Complete）。 l达到这个里程碑，意味着所有特性的编码任 务全部完成，特性的集成测试通过后，除解 决Bug以外，不再有新的代码进来。 l代码完成是明显的界线，标志着产品可以交 付测试。 l至此开发周期进入第三个阶段。 1.3稳定化阶段1 l稳定化阶段，也叫测试阶段，或叫QA 阶段 l稳定化阶段着重于对产品的测试与调试 。项目在此阶段尽量不再增加新的功能 ，除非是竞争产品或者市场发生了变化 。 l稳定化阶段也包括了缓冲时间，以应付 不可预见的问题或者延迟。 1.3稳定化阶段3 l微软的测试进行了比较详细的描述，我个人 认为微软的测试是Microsoft软件产品开发中 一个十分重要也是十分有特色的分工。 l这是通过在微软将近一年的观察和与国内同 类企业的分析，我才得出这样的结论。 l大家都很明白，国内的软件开发商在这方面 做得很不够，尤其不重视软件的内部测试， 在他们的思想中，可能有一个误区：认为测 试应该完全去由去谁负责？ l用户（白鼠） 1.3稳定化阶段4 l其实不然，在软件的开发流程中，软件的测试与开 发是一种“矛与盾”的关系，互为补充，缺一不可。 l如果你是一个程序经理，这个时候去看记录Bug的数 据库，会发现一大堆Bug急剧涌现，随着一个个Bug 被解，Bug量逐渐递减。 l在微软，可能这种关系发挥到了极至：有时开发部 门与测试部门互相较着劲， l开发经理和测试经理的地位是相同的，有时甚至测 试经理的地位甚至凌驾于开发经理之上，但他们之 间没有根本的利益冲突，只有一个共同的目标： l将产品的质量提高。 1.3稳定化阶段5 l微软内部，专门有一个小组负责为微软的工程师们提 供日常工作和管理的工具软件，他们是非盈利机构， 其主要任务是开发微软内部所需要的工具软件：例如 ：SLM(Source Library Tree),源代码管理工具， l负责管理软件开发过程中各个程序员的源码，各个程 序员负责写自己的模块，每天将完成的代码Check-in 到一个中央服务器的SLM树中， l这个SLM树由预先定义好的脚本在固定的时间开始编 译，通常这个过程需要好几个小时，所以微软内部根 据各个项目组的情况有各自的规定：？ l比如开发员必须在下班前（比如下午6：00）之前将 当天修改的代码Check-in进去，这样SLM才开始编译 。 1.3稳定化阶段6 l第二天，QAQA是微软大的产品部门下设的一个比较专业的测 试部门（Quality Assurance Dept）组的各个测试员从服务器上 下载前一天的一个Build开始测试，将测试的情况及时的反映到 另外一个工具软件中：RAID lRaid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance. l这个工具负责管理产品的BUG情况，每个BUG包含很多属性： l比如状态（活动的、解决的、关闭的）、严重级、优先级、哪 个区域、哪个版本出现的、发现者、要将这个BUG赋给哪一个 开发员等等一系列属性。 l还可以根据这个工具查询哪个开发员当天的BUG活动的、解决 的数量，哪个测试员的BUG质量数目等等一些基本的产品质量 情况，这样项目经理可以很容易的？ l掌握该项目的具体进展情况。 1.3稳定化阶段7 l如果在项目的开发中期，发现的BUG数目比解决的BUG数目持 续的多（意味着该产品的活着的BUG越来越多），可能意味着 l这个项目出现了问题，决策者可以迅速的作出相应的决策，及 时的纠正产品开发中出现的失误 l微软曾经有很多产品因为这样的因素被Cancel了。 l还有项目经理可以根据这个工具，及时的掌握、了解每个测试 员和开发员的工作状态，这一点很重要。 l很多人曾经说过：Microsoft凭借着SLM和RAID打败了无数的 竞争对手。 l这两个工具确实是非常杰出的工具，微软将它们使用到了十分 艺术的程度上，对微软的成功起着非常重要的作用。 1.3稳定化阶段8 l更难能可贵的是，目前这些工具在功能上？ l还在不断的进行改进、升级，使得微软的工程师们工 作起来更加如虎添翼、虎虎生风，这样的企业哪有不 成功的道理? 在测试过程中，也不是随便的对软件产品毫无目的的 瞎使用、乱使用， l微软也有一套十分先进的方法和工具支撑着测试的每 个方面：比如ATCM( Access Test Case Management) ，一种基于Test Case（测试用例）的测试管理工具就 承担着这方面的工作。 可用性测试的重要1 l所有用过微软产品的人会有一种感觉，微软产 品非常易用。如何使产品做到易用？ l微软的办法是通过重视可用性测试（Usability Testing）来实现。 l可用性测试的使命是通过在产品开发周期的各 个阶段加入客户资料和信息来使产品更有用、 适用和易用。 可用性测试的重要2 l在产品开发周期的第一个阶段可用性测试就要 展开工作， l比如，微软中国研发中心的产品组会把产品的 新特性做一个模拟的模型，找用户来试用，产 品组的可用性测试人员便会在试用过程中准备 录音机、摄像头，把用户的行为摄下来，说的 话录下来，按的键记录下来，研究他们对产品 的反应，以便把产品设计调整到足够好。 可用性测试的重要3 l微软中国研发中心中文处理组有一个产品 “微软拼音 输入法”，其最早的帮助功能是用鼠标右键击活菜单， 这是Windows常用的菜单风格，但是通过前期的可用 性测试，他们发现 l中国用户习惯了用鼠标左键，很少用右键，这样用户 很难找到微软拼音的帮助功能。 l后来微软中国研发中心把“帮助”放在显示特别明显的 地方输入法状态条上，这样，按左键就能使用帮 助功能。 l“用户的需求可能跟你想的不一样，这就要真正倾听用 户的呼声，让用户来试用，看用户的反应，来决定修 改你的产品”， l微软中国研发中心这样的例子很多。 可用性测试的重要3 l在第二个开发阶段，当开发人员达到M1，能看到产品 的最重要的特性时，可用性测试人员要随时反馈设计 好不好，如果要有个别的改动，则在M2中将M1的某 些功能改动加进来。 l可用性测试人员要理解用户的工作领域、行为和心理 ，微软公司总部有很多做可用性测试的人员是心理学 方面的专家。 l用户的感受只有通过可用性测试人员分析、理解成对 功能的描述，或者对功能的反馈，才能使产品开发人 员能够理解并改进。 软件帝国大厦的根基 微软正是靠着什么 构建起软件帝国的 大厦、谱写着软件 事业的辉煌。 程序员的聪明和测 试员的勤奋！ 特殊角色程序经理1 l程序经理（或叫程序管理：Program Management） ，他负责整个产品开发过程的协调，是微软各产品 组中非常重要的一个角色。 l在微软的产品组中，程序经理的角色很特殊，他是 惟一在产品开发周期的三个阶段都显得非常重要的 角色。 l程序经理在规划阶段要贯彻和推进目标描述，书写 功能/特性规格说明，创建主要的进度表。 l规格说明是基于产品规划所产生的目标描述来具体 定义特性的实现步骤，目标描述文档是基于大量用 户的调查报告和各种研究方法得出的用户的需求， 定位产品的目标。 特殊角色程序经理2 l但这只是给出了一个大方向，程序经理必 须把这个大方向细化成若干个具体的特性 ，这些特性不仅要满足目标功能的要求， 而且又必须是程序开发人员能够理解的语 言。 l比如 Word某一版要支持HTML，产品规划 只定目标，但程序经理就要把这个目标细 化成几个具体的特性。 特殊角色程序经理3 l在第二个阶段，程序经理要管理整个开发工作的进度 ，检查开发人员的实现是否与规格说明相吻合，而且 要使团队目标集中、齐心协力。 l如果在开发过程中有什么特性的变化，或者某些功能 在设计时很好但在实际开发中出现问题，程序经理便 要负责其更新规格说明，还要与产品规划、测试人员 沟通项目的进展状态，协调开发过程中出现的问题。 l代码完成里程碑达到之后即开始大规模的测试，程序 经理那时的作用就更大了，他要制定和控制每个Bug 的优先级，做取舍决定，发送Beta版并收集用户反馈 ，确保产品按时达到发送候选（RC）。 特殊角色程序经理4 l一句话，程序经理的中心任务是保证软件高质 量并按时出品。 l由于总是要在品质与进度上找到平衡点，程序 经理必须精于“引导、驱策、鼓励、要求”团队 做出最好的软件和表现出最好的工作效能。 特殊角色程序经理5 l在微软不同的团队里，程序经理所做的事情也有一定 的差别。 l有偏技术性的设计功能的程序经理，他们是团队中的 关键人物； l有一种程序经理被叫做Release Program Manager，他 的主要任务是控制开发流程; l还有的程序经理会做一些客户需求调查的工作，定位 产品方向。 l无论如何，程序经理的基本素质首先是？ l要有很好的沟通技巧，具有设身处地为他人着想的本 领； l其次考虑问题周全，能处理复杂的情况； 特殊角色程序经理6 l此外，程序经理要对开发产品所使用的技术很熟悉， 对用户需求的理解力也要非常好。 l比如在具体的开发过程中，测试人员发现Bug越多越 好，但开发人员却希望Bug越少越好，程序经理要善 于协调二者的矛盾； l在产品的开发过程中通常会出现人员突然流动的现象 ，或者硬件环境出了问题，或者外边竞争对手出现变 化，程序经理对这些要反应非常机敏，有能力做出对 公司、产品和客户影响最小的果断的取舍和决定。 特殊角色程序经理7 l微软的开发人员无疑是每一个产品组中非常重要的角 色。一个头衔是软件设计工程师（SDESoftware Design Engineer）的开发人员的级别有可能比某一个 经理要高很多。 l在微软，开发人员根据他本身知识和能力的不同分为不同的级 别，顶级的开发人员负责整个软件的结构设计，中间有负责某 一功能类的结构设计师，最底层的开发人员只完成规定的模块 实现。 l好的结构设计对产品的稳定性、可扩充性非常重要， 特别是对一个由多人参与的项目而言更是如此。在产 品组中，最厉害的开发人员是整个产品结构的设计师 。 l应该说，微软每一个产品中都有几个核心开发人员来 控制整个产品的结构，其他开发人员则在他的领导之 下共同完成开发工作。 原则二 运用想象性描述和对特性的 概要说明指导项目 为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过 程中出现的变化并保持足够的灵活性，微软采用想象性描述和概要 的说明来指导项目开发，而不是？ 在一开始就努力写出一份完整和详细的 说明。 2.1想象性描述 l所谓想象性描述是由程序经理和来自市场营 销组的产品计划人员共同编写的一份非常短 的文件，在其中主要是定义产品开发的？ ？ l目标（不涉及产品的具体细节！） l通常对一个全新的产品，想象性描述一般会 相对较详细，在其中还含有一份粗略的说明 文件。总的来说，微软对于想象性描述的要 求是： l越短越好！ 想象性描述要求 尽量说明“产品不做什么“ 而不是“产品要做什么“ ！ 想象性描述的过程 l运用想象性描述，程序经理开始编写功能说明文件， 该文件解释产品的特性是什么以及这些特性如何与其 他特性及产品发生关系。 l最初它只是一个概要性的说明文件，随着项目的进展 ，程序经理会随时向其中添加更多的细节，最终的说 明文件将变得象用户手册一样。 l完整的说明不只起着对产品最新功能的描述作用，而 且它还是在产品投产与发货之前进行测试与评估的主 要依据。想象性描述有助于决定删除哪些特性。 l微软内的各个开发组采用想象性描述帮助细化产品版 本的规定主题，然后以此主题来决定是否需要增加产 品各个可能的特性。通常不要轻易改变所确定的主题 ，否则可能造成产品开发上的混乱。 编写说明文件 l说明文件在产品小组的所有成员之间，产品小组之间以及产品 小组与管理部门之间起着传递产品的设想与要求的作用。 l在说明文件中必须清楚地描述产品特性（描述每个特性如何工 作，外观如何以及从用户的角度出发如何与用户交互。如果特 性有一个界面，还应包括一张示意图，以显示出界面的效果） ，并赋于其相应的优先级。 l程序经理据此建立起项目的开发进度表。此外在其中还应包括 以下各项内容：用一句话表示的项目开发目的，关于产品是什 么与不是什么的清单，对顾客的定义，对竞争产品的定义，产 品对系统的要求（包括操作系统版本、最小内存要求、硬盘空 间、处理器速度以及显示器分辩率），对第三方（如打印机驱 动程序、组件）的任何依赖性。 l程序经理负责协调并“写下“说明 程序经理应考虑以下问题： l这项特性的要点是什么？ l用户如何使用该特性？ l这项特性有意义吗？ l该产品中或微软的其他产品中有类似的特性吗？ l有哪些问题被遗漏了？ l组内的交流令人满意吗？ l最终程序经理通过与组内开发人员的共同讨论决定有 关特性的内容，并将其写下来。 2.2构造原型1 构造原型是程序经理具体说明一件新产品 或一个新版本的最好方法， 这从许多方面来说都使开发前测试成为可能，尤其在可 用性方面，并且有助于对与用户交互情况作出好的理解 ，它也能使产品说明更紧凑。 2.2构造原型2 l微软的开发人员通常采用VB构造用户界面原 型，但是对于构造计算机屏幕模型之类的工 作，画笔（Paint brush）也是一个很好用的工 具。 l死板的说明变成有生命的文件，说明不应过 于详细以至限制了发明创造。 l在项目开发过程中，说明文件的早期版本会 有相当大的增加与改变。 l由于说明的变动可能会导致相应开发工作的 极大变动，所以微软通常是将精力首先集中 于什么？ 2.2构造原型3 l首先集中于那些没有什么用户界面的特性上 ？ l因为在完成开发前不必去了解用户对它们有 何反应，也就是说这些特性不大可能改变。 l然后再面对其它特性。但是当产品开发到一 定程序后，例如40%之后，程序经理必须严 格控制对特性的修改（主要是指增加新的特 性），否则不光会造成开发延迟，而且会？ ？ l压缩可用的测试时间。 原则3：根据用户行为和有关用 户的资料确定产品特牲及其优先 顺序 l对于一个开发项目而言，如何确定最终产品中应包含 什么特性通常是比较困难的一件事。为此微软采用了 一个称之为“基于行为制定计划”的方式来进行特性选 择与优先级安排。 l基于行为制定计划法从对用户行为，诸如写信或做预 算，做系统研究开始。然后，根据某一特性在支持重 要的或者是经常的用户行为上的程序对其进行评价。 这样做的优点是？ l对特性取舍更具理性：讨论对顾客想要做什么加以更 好的安排，对某个给定特性是否方便了特定任务的更 集中的辩论，可读性更强的说明，以及在市场营销、 用户教育和产品开发中更好地同步。 3.1 特性选择和优先级安排中的 基于行为制定计划1 l基于行为制定计划法中的关键点在于? l按用户行为、产品特性以及行为和特性之间的 内部联系来分析产品。 l程序经理和产品计划者把产品试图支持的用户任务或 方案分成大约20个“行为”，然后他们努力把行为（以 及任何子行为）映射入微软的现行特性和竞争对手产 品的特性中去。 l他们也把行为映射到不同的顾客形象或不同的市场部 分中去。 3.1 特性选择和优先级安排中的 基于行为制定计划2 l当说明产品的新版本时，基于行为制定计划法帮助程 序经理和开发员集中他们的精力与创造力。 l象Excel之类的项目，争取在每个新版本中加入的主要 行为不超过四个。绝大多数特性直接映射入这些行为 之中。炒鱿鱼宏( L AYOFF macro) l该做法使项目可以按特性对用户的价值来进行分级。 通过分级，促使程序经理和开发人员都行动起来，使 他们的特性支持尽可能多的行为。 l这种良性竞争对于用户有益，同时也利于提高生产率 。 3.2为顾客行为而非产品特性准备资 料 l基于行为制定计划进度，项目在计划阶段首先集中于 行为，其次才是特性。 l程序经理和市场营销人员并不去思考和排除他们喜爱 的特性，再围绕它们搞出想象性描述的草案。他们真 正做的是? l列出一份顾客都做些什么的清单，然后? l把想象性描述集中于支持那些 行为的特性上。 3.4做市场营销研究以支持 基于行为制定计划法 l为支持基于行为制定计划法，从市场 营销组来的产品经理与程序经理、开 发人员一起开展一些联合的研究，如 指导对用户的研究工作。 l然而，一般来说是产品经理做大多数 的研究，并可使其更明确地影响微软 产品的演进。 原则4：建立模块化的和水平式的设 计结构，并使项目结构反映产品结 构的特点 l微软产品设计中的一个关键概念是? l产品的基础结构（Infrastructure ） l尤其是生命周期短的应用软件，应随项目的进展变得 更加单一（而不是错综复杂）。 l当开发组构造产品的第一版时，他们更多地使用分级式结构， 好为产品设计规定出一个最初的架构。随着时间推移，他们向 单一的结构迈进，以使项目能集中于特性开发。 l微软越来越强调不同产品间的特性共享。共享有助于使不同产 品? l“性能与感觉”（Look and Feel）都统一协调起来； l它也方便了需要不只一个应用软件的用户，减少了代码的重复 书写，缩小了单独一个应用软件的规模。 原则4：建立模块化的和水平式的设 计结构，并使项目结构反映产品结 构的特点 l微软用特性小组组织产品开发，这种方法使得 每个人都容易明白小组是如何与整个产品相关 联的。项目从规定概要说明开始。 l概要说明的形式是一份已确定了优先级安排的 内容清单，涉及产品下一版本将要开发的相对 独立的特性，以便由分开的特性小组加以开发 。 l程序经理和开发员把项目分成特性子集，再将 之分配给每个特性小组，让他们在3到4个主要 的内部项目里程碑中进行生产。 l这种产品组织与开发方法使微软能靠简单地增加开发 员和创建一个大的小组来渐进地增加产品的功能。 4.1把特性(与函数)作为开发单 位 l微软软件产品的特性是用户最终可见的相对独立的功 能单位，就如建筑材料一般，对应用软件产品更是如 此。 l系统软件产品，如NT或者95的特性，对最终用户通常 不直接可见。微软和其他公司有时简单地称这些不直 接可见的特性为? l“函数”。 l程序经理承担开发一组特性或函数，实现从说明经测 试、文档化直到最后完成的过程。他们必须与开发员 合作，后者负责估计进度表与完善每个特性。开发员 还要在一台联网开发计算机上存储一到几个文件，用 以保存特性的程序源代码。大多数特性的开发与改进 只要？开发员 l一名开发员，而有的大型特性则要一个小的小组。 4.2产品结构是决定其长期结 构完整性的基石 l产品结构是产品内部的基干，它规定了重要的结构构 件以及这些构件如何组装到一起。 l产品结构及用于组装结构的构件，提供了实现产品特 性（即做详细设计与编码）的支柱。 l产品的结构对最终用户而言，通常并非直接可见。只 有结构要实现的特性是可见的。 l产品结构也是决定产品长期结构完整性的基石。 l产品功能的任何改变都不应造成潜在的产品结构散架 。 4.3产品的层次结构 l对于产品，也可以采用层次结构的方法加以分析。通 常定义良好的层次结构有助于对产品特性进行灵活的 增加、删除与改进。 l此外良好的层次结构有助于产品在不同平台上的移植 。 l例如Excel总共定义了？层？ l五层，其中只有最底层的操作系统层是与平台相关的 ，其它各层均是通过调用其下层所提供的API接口加 以实现的，所以其移植极其方便。 l而在Windows 95中通过“虚拟机”的概念实现了对16位 、32位以及DOS程序的支持。 4.4小的结构文档：源代码是唯一文 件 l除了API文档，微软不对其产品结构生成相应的文档 ，虽然有时高级开发员可能会写下高层结构。 l对复杂的特性，许多开发员在某些点记录并复查特定于他们所 负责的结构细节，但此工作是可选的，并不强制执行。 l除了源代码文件与特性说明，为数不多的组为新程序 员准备了描绘某层结构的文档（主要的数据结构，如 何工作等等）。但是这些文件并不时常更新，经理们 也不要求项目组生成此类内部文档。在有关的说明文 件中，并不涉及实现问题。开发员应该知道如何去实 现，或者能够去学会。记录的关于结构的文档如此之 少是因为？ l“一个开发员的工作是编写我们要卖的代码，而不是花 时间写高水平的设计文件”，“设计文件不应与源代码 分离”。分割代码与“保持事情的简单”。 4.5特性小组和作为“内容专家“的小组领 导 l特性小组一般由一个领导和3至8名开发人员组成，工 作于相关的特性领域。 l小组的规模常常视小组领导的经验和能力而定。特性 小组领导向项目开发领导汇报并负责项目的全部开发 工作； l而项目开发领导则拥有对产品的更为全局性的观点， 从而最有可能发现不互相关联的问题。 l在特性小组中的每个人均是此领域的“专家”，他们了 解如何使用产品、了解竞争对手的产品、了解未来将 向何处去。 l通常为便于交流，提高软件的组织结构（软件倾向于 映射出构造它的组织的结构），应保持特性小组的？ ？ l小规模！ 原则5：靠个人负责和固定项目资源实施控制 1 l对于软件项目而言，精确估计产品的开发与交付进度 是很困难的。 l对此微软采取的方法是将进度安排和工作管理的责任 推到最底层，即单个的开发人员和测试人员那儿去。 l这保证了每个人除了作为小组的一部分外，还负有个 人的责任。 l单独的开发人员设立他们自已的进度表，程序经理把 单独的进度表汇总起来，再加上缓冲时间，以制定出 一个全面的项目进度表。 l顶层的总经理也固定人员与时间等基本资源，以确保 项目集中并限制其努力与创造程序。 原则5：靠个人负责和固定项目资源实施控制 2 l关键的目标，尤其对应用软件，是指明产品的 目标出品日并争取尽可能长久地坚持它。 l程序经理和开发员从出品日回溯，规定中间的 项目里程碑的日期。 l这个“固定的出品日法“的中心在开发员身上。 l以避免因为项目没有固定的结束点，导致在最 终无用的设计、再设计和测试的循环中消耗一 年或更多的时间。 5.1开发人员做出他们自已的进度估 计 l“日期设定方法”。但是开发人员一般会做出较乐观的 估计， l因此开发经理还需对他们所提供的日期进行调整并加 上缓冲时间以避免因因信息不完全而出现的问题。 l微软这种制定进度的方法的优点在于： l它从人们那儿得到更多的合作，因为日期是自已定的 ，不是经理定的； l进度总是富有进取性，因为开发人员不可避免地会低 估他们真正需要的时间。 5.2对细致的任务的进度估计 l微软的第二个进度安排方法是：? l对要完成的任务做非常详尽的考虑，在此基础上请开 发人员给出他们对“实现”的估计，以此力图“促使”更 加现实主义并避免过度低估。 l通常微软把任务细化到4小时（半天）到3天之间。对 于准确进度的安排，微软的经理是这样认识的： l“任何任务只要超过一星期，那人们就一定没有充分地 全盘考虑它。任何任务某人估计只用少于半天就可完 成，则他对它考虑得太多了。他应该用更多的时间去 编程，更少的时间来考虑”。 l对于类似类于