IE成功开发经验

IE成功开发经验Howtoorganizeprojectteam

如何组建项目小组Howtomanageprojectprocesslifecycle

如何管理开发项目案例分析：微软如何管理软件开发项目--IE--NetscapeInternetusers浏览器的市场占有率1009080706050403020100199619971998199920002001浏览器之战微软的因特网之日-1998年12月7日1996年初组建网络平台和工具部门（IPTD）“我们领先了微软两年——他们不可能赶得上我们”-1995年Netscape向公众这样宣称。“我们领先微软一年——他们不可能赶得上”-Netscape1996年这样宣称。由于IE3.0具有卓越的技术性能，1996年末AOL决定将其作为默认的浏览软件。1997年，在IE4.0与Netscape浏览器评比中，IE4.0赢得了所有业刊的好评。1999年，在IE5.0又快又可靠，而Netscape已经无人问津了2001年，IE6.0仅与IE5.0竞争——浏览器之战宣告结束！微软是如何赢得浏览器之战的市场策略：因特网的飞速发展给了微软机遇和挑战，微软一定要抓住机遇迎接挑战的心态产品发布日产品关键性能竞争对手是谁客户定位如何获胜每天工作12小时以上，一星期7个工作日如何组建项目小组IE的项目小组规模1994年冬，Windows95中IE1.0，最初一组有7名成员1995年11月IE2.0，30人1996年8月IE3.0，70人1997年1月IE4.0，300人1999年8月IE5.0，500人2000年7月IE5.5，300人2001年8月IE6.0，100人如何组建项目小组IE4产品部（300人）产品组总经理（1人）产品规划（5人）产品经理（20人）程序经理（50人）软件开发工程师（100人）软件测试员（100人）用户培训（10人）产品组组织结构ProductUnitManager产品组总经理GroupProgramManager(s)程序经理ProgramManagerLead(s)程序经理组长DevelopmentManager(s)开发组经理ProgramManagers程序经理DeveloperLead(s)开发小组组长Developers开发员TestManager(s)测试组经理TestLead(s)测试小组组长Testers测试员ProductPlanner产品计划人员IE产品性能组的组建IE产品单元组大约分为10个性能组。每个组负责一系列划分很明确的性能，每组约由10-50人组成。根据其负责的性能规模，性能组有时会被进一步划分成子性能组。每个最终的子性能组人员和职责都很明显，一般有大约10人组成：一个程序经理，几个开发人员和测试人员。一个程序经理可以负责一个或多个性能组。开发人员和测试人员也可以同时安排在多个性能测定组中。IE性能测定组的成员性能组的领导人员（GPMorGM）程序经理开发人员测试人员用户培训设计人员网络开发人员可用性工程师子性能组中的工作关系ProgramManager程序经理DeveloperLead开发员组长Developer开发人员Developer开发人员Developer开发人员Developer开发人员ProductManager产品经理TesterLead测试员组长Tester测试人员Tester测试人员Tester测试人员Tester测试人员UserEducation用户培训UsabilityEngineer可用性工程师Designer设计师项目组成员的职责程序经理：对产品前景明确，并写出产品的规格书列出工作项目表，以规格书为基准来查和工作项目组织会议，筛选错误控制开发过程引导开发过程协调不同组的组员（开发组，测试组，产品经理，地方性用户培训组等等）对产品的按时发布负责。是领导人，服务，协调者；但不是老板项目组成员的职责开发员分派项目资源设计性能对性能进行编码对性能进行单元测试为产品的发布作准备开发组长为该组提供技术指导负责产品的技术操作项目组成员的职责测试人员编写测试计划和测试案例实现测试的自动化朋友测试运行测试案例测试完并signoff成追踪的builds负责产品的质量测试项目组成员的职责产品经理：监控产品的商务过程发现并追踪市场机遇在产品开发过程中完全扮演客户代言人的角度在产品的功能和发布日期之间做出权衡负责营销、销售策划是程序经理的商业顾问项目组成员的职责另外的组员用户界面设计者自始至终对产品的外观设计负责Ownplanforlook/feelacrossteams负责组与组之间的互动计划用户培训组：负责卫星能住的文档设计作计划，包括印刷品和在线的电子版负责内容生成，包括内容较验可用性组可用性的测试也是设计的一个重要部分通常会提供2-3个设计方案，然后提交可用性测定组Accessibilityteam：支持残障用户项目组的主要原则人员有才智，组的规模要小产品的结构体系要减少各组之间的依赖性经理们能够同时创建产品和做出技术性的决定快速确定产品技术与商业经营之间的权衡开发过程要使得大的组能够象小的组一样工作控制项目（产品）开发周期项目（产品）周期：规划设计阶段开发、生产阶段测试、稳定阶段发布阶段事后分析开始下一版本（另一周期）规划设计阶段一般的工作阶段里程碑的时序安排产品前景描述和目标设定产品高层次性能设计详细的性能设计项目（产品）规划计划阶段一般的工作流程识别商业机会，制定基本的经营计划草拟一个项目计划（前景描述，基本的性能，建议进度表，里程碑，资源评估）组员进行集体讨论，将产品性能最后确定。写一页产品规格（按优先次序排列的产品性能，资源评估，进度表评估，风险评定）确定产品性能，设定开发周期里程碑的时间项目（产品）规划计划阶段里程碑的时序安排-为重要的成就估计一个大致的时间框架以IE的里程碑为例

日期

交付出6/25/99产品前景规划和目标设定7/1单页产品规格书准备完毕7/15详细产品规格书准备完毕9/1完成平台的编码10/8所有的组完成用户界面的编码11/7RC011/19Beta-1RTM4/5/00Beta-2RTM7/12/00RTM

项目（产品）规划计划阶段产品前景描述：详细说明产品的发展方向与目标IE浏览器的前景向企业及终端用户提供主流互联网客户软件、并以及最低的TCD成本获得快速、及时、专业的服务，同时对微软办公软件进行最佳补足。通过提供以上服务来使IE浏览器的市场占有率在1998年内达到65%。投资领域：TCD-易配置，易安装同行中最快捷最可靠的客户端软件对Office9有强大的补足功能移动网络用户的最佳浏览器项目（产品）规划计划阶段性能和用户界面规格：对已定及待定性能作详细描述以IE的说明为例Owners所有者Summary摘要Guidingprinciples操作原则Scenario假定情况Design设计Security安全性Setupanddeployment安装与发放Globalization/localization全球化/地方化Openissues已知问题Changehistory改变历史开发阶段开发计划阶段设置开发环境源代码登记过程（Checkinprocess）每日机器码建造过程（Dailybuildprocess）错误资料库的管理项目开发阶段开发计划开发员阅读所有的说明书，列出工作项目并估计工作天数召开小组会议，讨论所有的工作项目并制定出主进度表开发组长为每个开发人员安排工作项目并平衡各组员的工作量测试主张制定专门的合作测试员（Buddytesters）合作测试员准备详细的测试案例项目开发阶段设置开发环境开发人员设置源代码树的结构、自己性能租在服务器上的目录制定源代码登记作业表、登记流程测试人员/机器码造建人员机器码造建人员准备造建机器和服务器设定造建日程表（日起/时间）建立错误（bugRaid）资料库测试人员/机器码造建人员建立各组的网页及设各组电邮名设定小组会议的日程安排项目开发阶段源代码登记过程Syncanddoprivatebuild确保新的编码能与最新源代码树公共文件相适同事为你做代码复阅尽早发现错误的和不完整的编码每段编码都要经过一个以上开发员的认同和理解符合源代码登记标准化通过BAT,BVT及其它测试确保每日构建的机器码符合最低要求观测登记时间段中的情况变化当机器码造建过程出错中断时，确保能够容易地识别错误所在将编码改动通知整个产品组（送电子邮件）电子邮件应包括编码改动的目的，谁作的编码复阅，有可能影响到的文件和测试标准项目开发阶段每日机器码造建过程整个编译过程大部分是自动的每天在同一时刻把最新改动过来的源代码复制到机器码造建服务器上来进行所有的组成部分的机器码生成运行BAT和BVT将机器码造建状态用电子邮件发送到项目组在公共服务器上发布造建结果和源代码改动纪录项目开发阶段错误数据库的管理（Raid,webRaidetc）每个产品都有一个中央错误资料库（Raid’webRaid等等）测试员会发现大多数错误，这些错误可能是编码错误或性能需求程序经理查看这些错误并把他们分派给各个开发员开发员纠正错误后把他们分还给测试员测试员用第二日的新机器码来校验和关掉这个错误稳定阶段性能冻结完成编码用户界面的冻结测试版发布项目稳定阶段性能冻结性能的任何变动都要经过一个特殊的过程(FDR).每个变动都要经整个战斗团队的复查和认同性能变动认同的标准通常很清楚，而且往往设置得很严一些可考虑的情况：新的终用户的反馈意见竞争者的新产品可赢得一个大客户微软各团队间的支持法律问题项目稳定阶段编码的完成开发人员完成了所有的事先分配的开发项目，产品所有的性能都被囊括到了造建完的机器码版本中了。测试员开始综合测试，着眼点为各个性能部分的测试案例程序经理开始日常的错误筛选和错误分派开发员开始大量的纠错误工作项目稳定阶段用户界面冻结用户界面的外观和上面的字符串不再改变UA开始写程序说明和产品指南手册Intl组开始地方化过程任何变动都要经过战斗队和UA/Intl程序经理的认同每个变动都要用bug记录下来项目稳定阶段Beta测试版发布部分完工的产品向外部合伙人发布Beta测试版中包含一些有许多错误的性能对特定的性能收集客户的反馈扩展测试范围稳定并改进产品的质量提供组与组之间的综合交付使用加强与外部合伙公司的合作、协调发布阶段零错误之日（ZBD）RC0,RCX源代码资源树的开支RTM/RTWSignoff结束项目发布阶段零错误之日开发员必须纠正资料库中所有现存错误测试员开始用高优先级测试案例进行第二轮的通体测试战斗团队每天都要查看新找到的错新错要根据新高标准进行重新优先级排序优先级第一或第二的新错误要求于24小时内纠正项目发布阶段候选发布产品RCO-所有现存优先级为1/2的错误已被纠正的产品如果有新的错误出现，它必须是show-stop才可被纠改，否则延迟到下次发布再纠改开发员必须在24小时内纠正新的错误直到现有的新错误（show-stop）都被纠正之后，新的RC候选版才能被公布测试员要对新的RC候选版进行全面的regression测试（通常几天时间）项目发布阶段代码资源树的分支在目前的产品版本发布之前就已经着手准备下一轮的开发准备了分派一些程序经理为下一个产品版本设计性能为当前的源代码资源树做备份让部分开发人员转到下个版本的开发设计工作错误纠错变动被写入发布产品的源代码树，所有其它的错误和新的性能被写入资源树的分支树项目发布阶段RTW/RTM向制造业/网络发布产品只有当最终的RC造建版本中不再出现新的show-stop错误时，测试组才能为RTM/RTW版做最后的发布签字在测试结束后如果出现非常严重的新错误，则产品将被“召回”。此过程须经GM/VP的同意测试小组为RTM版本做最后的测试验收，PM验收金主蝶并开