微软是如何开发软件的.ppt

微软是如何开发软件的.ppt

《微软是如何开发软件的.ppt》由会员分享，可在线阅读，更多相关《微软是如何开发软件的.ppt（60页珍藏版）》请在冰豆网上搜索。

个案研究:

微软是如何开发软件的,曹严明软件设计工程师微软,内容,SharePointTeamServices简介SharePoint团队SharePoint产品开发过程产品开发总结人员管理问题与回答,SharePointTeamServices简介,SharePointTeamServices是什么?

SharePointTeamServices是一个团队Web站点解决方案,您可以根据需要创建工作区,以管理团队活动并创作共享的发布作品.,SharePointTeamServices,创建每个人都能使用的团队Web站点基于浏览器的编辑与MicrosoftOffice集成团队成员间有效地协作信息共享文档共享自定义以适应团队的需要基于浏览器的自定义及站点管理MicrosoftFrontPage集成,SharePoint架构,技术基于FrontPage2002Serverextensions系统要求Windows2000ServerorAdvancedServer使用SQLServer在专用环境下可安装MSDE,演示SharePointTeamServices,SharePoint团队,SharePoint团队,产品部门经理:

1项目经理:

10开发人员:

29测试人员:

27可用性工程师:

1（合用）用户培训:

2（合用）产品经理:

1（合用）本地化:

4（合用）行政助理:

1,微软的惯例和原则,1984年,Multiplan项目第一次设立了项目经理一职来管理整个项目.此后项目经理一职在公司正式化.1988年以前,微软只有一个测试组和一个用户培训组.如果一个项目要延期,就从别的项目调一些人员.1988年,Publisher1.0是第一个项目在计划表里使用里程碑.这个程序后来在微软各个项目中广泛使用.1989年,建立了产品部门.一个产品部门包含所有的为某一个产品负责的人员.一个产品部门本身象一个公司那样运作,负责按时推出产品.,纵向汇报结构,项目经理,使命:

按时出品合适的高质量的产品确保产品符合市场需求以及微软本身的业务需求提供领导能力,而不是独断专行对产品的功能,时间表和资源负责交流与沟通,处理本团队与公司其他团队的关系,开发人员,使命:

写出高质量的软件技术专家给产品规格说明书提供反馈设计算法和数据结构设计,实现,调试程序,测试人员,使命:

验证高质量的软件系统地监测与评估项目的各个方面以确认达到质量标准独立地验证产品的特征和性能-确保与假设相符测试产品与设计标准一致汇报产品质量状况作为客户的支持者为质量而奋斗,可用性工程师,使命:

使产品更有用,更好使用与产品团队密切合作理解用户的任务范畴进行可用性测试进行产品竞争性测试产品领域调研,本地化工程师,使命:

在国际市场上推出符合地缘政治及地区文化标准的产品为特定的国际市场翻译,改编产品更改界面大小重新设计图表改写内容,产品经理/产品策划人员,使命:

定义满足客户需求的产品进行调研并提供分析来鉴定用户需求,市场走向,竞争对手,以及产品方向调查用户访问营销人员及产品支持人员的反馈形成共享的产品远景哪些人是用户?

他们需要些什么?

产品团队需要做什么来满足客户的需求?

定义产品长期的目标（3-5年）,产品支持工程师,使命:

让客户高兴客户满意是最关键的目的快速地解答问题准确的解决方案鉴别最常见的问题以及关键的产品支持趋势把客户不满的关键原因传递给产品团队去解决,Web维护工程师,使命:

为Web服务提供高可访问性,高回应性,安全的托管服务经营业务监测站点及服务器汇报可访问性及回应时间扩大规模来匹配产品需求负责安装产品的小型版本为产品策划人员,开发人员,测试人员以及项目经理提供反馈来经济有效地提高产品质量,SharePoint产品开发过程,由里程碑驱动的进程,里程碑是一些回顾和同步点,里程碑不是凝固点里程碑允许团队评估进展情况,作一些中期调整完成一个主要里程碑表示团队与客户同意继续下去可用的正式版本是团队完成一个里程碑的客观证据,SharePoint:

从策划到发行,MM05/28/99,8周MM1-7/19/99,12周稳定-10/11/99,7周MM2-11/29/99,12周稳定-3/6/00,6周代码完成-4/14/00Beta1-4/17/00-14周Beta2-7/31/00,12周Final-10/16/00,17周发行-3/2/01,MM0:

5/28/997/16/99,8周,产品规划阶段哪些人是用户?

用户需要些什么?

远景声明增添/裁减功能详细的产品规格说明书产品规格说明书复审确定时间表,应尽早考虑的事情,绩效安全规模可伸缩性可获得性可用性国际化本地化,权衡得失利弊,资源,功能,时间表,MM1:

7/19/9910/8/99,12周,开发人员书写第一里程碑里的功能测试人员书写第一里程碑里功能的测试计划项目经理驱动各个方面的信息交流,使团队精力集中在远景和时间表上,实践,开发人员:

书写坚固的源程序源程序标准书写简便的源程序书写源程序时考虑到绩效,安全,国际化及本地化源程序再使用源程序复审技术设计说明书,实践,源程序管理源程序库标准的源程序Checkin过程标准的Build环境每日BuildBuildLab每周正式的Build交付给测试人员,实践,测试人员:

跟踪bug的RAID数据库每周bug趋势报告重点测试日自动化所有的测试操作系统映象与项目经理及开发人员复审测试计划与书写该功能的开发人员密切合作洁净的测试机器,测试人员,每周bug趋势报告,项目经理:

清晰明了的原型非常好的用户界面与其他团队良好的合作支持dogfood收集反馈信息严格遵守时间表,实践,项目经理,Office10总站点产品规格说明书站点产品规格说明书产品原型,MM1稳定:

10/11/9911/26/99,7周,产品稳定阶段所有开发人员完成第一里程碑里的功能与其他团队同步开发人员注意力于bug第一里程碑结束标准第一里程碑功能说明书准备好功能集调整时间表调整,MM2:

11/29/993/6/00,12周,开发人员书写第二里程碑里的功能测试人员书写第二里程碑里功能的测试计划项目经理驱动各个方面的信息交流,使团队精力集中在远景和时间表上,MM2稳定:

3/6/004/14/00,6周,产品稳定阶段所有开发人员完成第二里程碑里的功能与其他团队同步开发人员注意力于bug第一里程碑结束标准代码完成!

Beta1:

4/17/007/31/00,14周,Bug评估（http:

/obtriage）Bug条目报表公司内部dogfoodBeta1结束标准Beta1发行反馈,Beta2:

7/31/0010/16/00,12周,Bug评估公司内部dogfoodBeta2结束标准Beta2发行反馈,后期调试:

10/16/003/2/01,17周,Show-stopperbugsBug评估源程序冻结用户界面冻结对新功能说不,出品:

3/2/1,Partytime!

产品开发总结,产品开发总结,宗旨:

从每个参与产品开发的人员那里获取反馈信息,为将来能开发更好的产品产品开发总结讨论会问卷调查主要回答两个问题:

什么做得不错?

什么可以做得更好?

什么做得不错?

很早就开始考虑到绩效问题并在产品开发中一贯注重这个问题控制住bug的数量非常好的工具,比如Officeprofiler所有的说明书以及其他产品信息都在一个中心位置（http:

/office10）公司内部dogfood专用的测试服务器,什么可以做得更好?

程序稍微有些混乱:

人事变动,产品定义,等等代码生成太繁复,太慢直到很晚才考虑到升级的情況（Beta1toBeta2）每个人从第一天起就应该考虑程序安全性问题需要更多更好的工具:

自动化,本地化,等等所有权不明:

功能所有权重叠Unix支持应该更早一些裁掉在实时运行着的服务器上调试十分困难,如何改进,组成行动小组分析并推荐改进方案,人员管理,人才是成功的关键,雇用聪明的人才给予个人努力的动机奖励超常的成绩栽培个人技能让人才留下来建立团队精神,绩效评估,每年两次员工年度绩效评估报告经理反馈调查报告,绩效评估等级,SMART绩效目标,Specific具体的标明具体的行为和技能.Measurable可测的数量上和质量上的尺度.成就是什么样子?

Achievable能行的目标应有挑战性但也不是不现实的.Results-oriented注重结果的用结果来衡量成绩,而不是过程.Time-specific特定阶段的设立里程碑,核查点,以及完成日期,人员管理,每周一对一回顾每周功能小组会每月产品团体大会一些注意事项团队成员间的冲突工作与个人生活之间的平衡不要把人弄得疲倦不堪,总结,团队合作,每个团队成员都有具体的角色和具体的责任每个团队成员都有共同的产品远景对产品责任的观点无疵漏的观点着眼于用户的观点乐意学习的观点,由里程碑驱动的进程,四个阶段:

计划与功能说明书（MM0）主要里程碑（MM1MMn）质量确保出品（RTM/W）清晰的产品远景清晰的时间表注意力集中于远景和时间表良好的风险管理,优秀的人才创造优秀的产品,创立一个优秀的团队提供有力的领导使人们乐意他们的工作,问题与回答,