CMMI3精髓培训(中级1)


CMMI 精髓培训-中级1 彭国明 http://www.mansuo.com 上海漫索计算机科技有限公司 Page 2 目录 1. 项目立项管理 2. 项目策划 3. 项目监控 4. 风险管理 5. 结项管理 6. 小结 Page 3 1.1引言 ‹ 项目管理应当有始有终,立项和结项分别是项目管理的头和尾,其重要性不言而喻。然而这么重 要的管理工作却被传统软件工程教科书和CMMI忽视了,导致大多数软件开发人员不仅不懂得立项 管理和结项管理,甚至有“事不关己”的错觉。 ‹ 国内有许多项目要么没头没尾要么虎头蛇尾,令人叹息。人们已经司空见惯了,扭转这种陋习的 确不容易。 ‹ 人们都知道“良好的开端是成功的一半”,那么错误的开端将有什么样的结局呢?至少我目前看到 的是100%的失败。在企业里不能鼓吹“失败是成功之母”这种理念,因为项目失败可能导致企业倒 闭,“失败”再也没有机会当“成功”的妈妈了。 ‹ 为了避免项目失败,首要任务是做好立项管理;为了复用项目成功的经验,吸取挫折的教训,应 当做好结项管理工作。 1. 项目立项管理 Page 4 1.2.什么是立项管理?为什么需要立项管理? 1.2.1 什么是立项管理 ‹ 立项管理是决策行为,决策是指“做正确的事情”(do right things)。而立项之后的研发活动和管 理活动的目标是“正确地做事情”(do things right)。这里所谓的“正确”就是指符合企业利益最大 化这个根本目标。 ‹ 立项管理的主要目的是:通 过 规范化的流程,判断并采纳符合企业根本目标的立项建议,提供合 适 的 资 金 和 资 源 , 使 立 项 建议成为正式的项目。反之,拒绝不能给企业带来利益的立项建议,避 免浪费人力资源、资金和时间。 1.2.2 非规范立项(独断式决策 )的问题 ‹ 领导者个人的智慧毕竟有限,一个人做决策难免带入较多的主管臆断,决策风险比较高。而且领 导者个人承担的责任太大,这种把群众撇在一边的做法显然不合理。 ‹ 即使领导者做出了英明的决策,但是群众却难以学习并继承这种英明的决策过程,浪费了宝贵的 知识财富。 – 诸葛亮是中国历史上最英明、最勤劳的首相,但是当一个好人的力量超过了群众的力量的 时候,就埋下了衰败的伏笔。诸葛亮在世时过于忧国忧民,他连处罚士兵二十大板这样的“ 小事”都要亲自处理,实在是位好心的独裁者。诸葛亮累死之后,后继无人,蜀国的败家子 们很快就把国家搞灭亡了。 – 诸葛亮树立了“鞠躬尽瘁”的典范,我们后辈在敬仰他的同时也要引以为戒:企业的繁荣昌 盛和持久发展不能依赖于个别领导者的鞠躬尽瘁。 Page 5 1.2.3 规范化的立项管理 ‹ 宗旨:创建一种群体决策的立项管理规范,不仅让群众贡献智慧,而且让群众分担责任,使成功 的经验被企业不断复用,并升华成为企业的制度。 ‹ 立项管理的流程如图1所示,分三个阶段:“立项建议阶段”、“立项评审阶段”和“项目筹备阶段”。 图1 立项管理流程 1.2.什么是立项管理?为什么需要立项管理? Page 6 1.3. 立项建议 1.3.1 规程(procedure) ‹ 目的:立项建议小组进行产品构思、立项调查和可行性分析,撰写相应文档并申请立项。 ‹ 角色与职责:立项建议小组实施本规程的所有活动 ‹ 启动准则:立项建议小组已经成立 ‹ 输入:与目标产品有关的任何信息 ‹ 主要步骤:(迭代进行) – 第一步:产品构思 – 第二步:立项调查 – 第三步:可行性分析 – 第四步:撰写文档 – 第五步:申请立项 ‹ 输出:《可行性分析报告》、《立项建议书》以及调查报告等文档 ‹ 结束准则:立项建议小组按照指定的模板撰写了《可行性分析报告》和《立项建议书》,并做了 内部审查(消除拼写、排版等错误)。 ‹ 度量:立项建议小组统计工作量和上述文档的规模,将来汇报给项目经理。 Page 7 1.3. 立项建议 1.3.2 产品构思 ‹ 在撰写正式的《立项建议书》之前,立项建议小组首先要在宏观层面上搞清楚“开发什么”、“怎样 开发”、“怎样赚钱”等重大问题,即产品构思。 ‹ 产品构思的主要内容有: – 待开发产品的主要功能; – 待开发产品的技术方案; – Make-or-Buy分析(确定哪些产品部件应当采购、外包开发或者自主研发) – 开发计划; – 市场营销计划(如果是合同项目,可能不必考虑市场营销问题) ‹ 上述构思经过提炼之后,最终将写在《立项建议书》中。 Page 8 1.3. 立项建议 1.3.3 立项调查 ‹ 立项调查的目的是为产品构思和可行性分析提供充分的、有价值的信息。如果不做调查的话,那 么产品构思和可行性分析建立在空想之上,主观臆断的成分就很多。 ‹ 立项调查的主要内容有:市场调查;政策调查;同类产品调查;竞争对手调查;用户调查; ‹ 常见立项调查方式有:从Internet上搜查相关资料;从出版物中提取信息;与用户交谈;向用户群 体发调查问卷;与同行、专家交谈,听取他们的意见。 ‹ 立项调查应当遵循以下原则:调查者应当客观地对待被调查的事物,不可有意往“好处”或者“坏 处”靠。所获取的数据、图表要真实并且有据可查,不可凭空捏造。 ‹ 人们有时候搜集了太多的信息,却杂乱无章地堆放在计算机里,以至于阅读起来非常麻烦,导致 信息的利用率极低。有些信息可能是一些独立的文件,有一些则可能是文字片断,为了更好地保 存并利用这些信息,调查人员最好起草一份《调查报告》,将原始信息分门别类地归整起来,建 立索引,让别人读起来更加方便。对于信息,我们并不贪图大而全,我们只需要有价值的信息, 恰好够用并且容易阅读就可以了。 1.3.4 撰写《立项建议书》或《技术解决方案》 Page 9 1.4. 可行性分析 1.4.1 为什么要进行可行性分析 ‹ 《立项建议书》主要论述“开发什么样的产品、如何开发、如何赚钱”等问题,但是并不保证上述 设想一定就能成功,所以称为“建议”而非“决议”。 ‹ 不同的企业对待同一份《立项建议书》的态度可能有很大的差异。国内著名的IT企业联想集团领 导人柳传志曾说:“没 钱 赚 的 事 我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有 可靠的人选,这样的事也不干。”可是对于某些公司而言,只要能赚钱并且不犯法,什么事情都愿 意干。 ‹ 可行性分析的目的就是通过各个方面的分析,判断《立项建议书》中的那些建议能否真的实现? 成功或者失败的可能性有多大?值不值得立项?一般地,可行性分析的要素有: – 市场可行性分析 – 政策可行性分析 – 技术可行性分析 – 成本效益分析 – SWOT分析 ‹ 《可行性分析报告》写得好不好,不能拿“厚度”来评判。《可行性分析报告》的宗旨是为决策提 供有价值的证据和结论,既不能讲大话和空话,也不能连鸡毛蒜皮的小事都要分析。 ‹ 立项建议人和评审者双方都要做可行性分析。无论你多么追求客观公正,人总是会在可行性分析 过程中带入很多主观论断,这是正常现象。如果双方都做了可行性分析,那么很容易分清异同之 处,在立项评审过程中可以把精力集中在意见分歧比较大的关键问题上。 Page 10 1.4. 可行性分析 1.4.2 市场可行性分析 ‹ 首先要分析市场发展历史与发展趋势,判断本产品处于市场的什么发展阶段。可以简单地把市场 划分为三个发展阶段:未成熟的市场、成熟的市场和将要消亡的市场。 ‹ 对于将要消亡的市场,风华正茂的企业不能进入,而那些“饱一顿饥一顿”、“打一枪换一炮”的小 公司可以进入。富有企业瞧不起的市场,说不准就是贫穷企业的金矿,富人和穷人各有各的活法 ,关键是不能走错道。 ‹ 对于成熟的市场,客户的需求是明摆着的,商家都看得见,于是纷纷挤入。虽然需求风险比较低 ,但是竞争者多了,就会大打价格战,利润自然会下降。目前国内家电市场就是真实的写照。如 果想在成熟的市场谋求一席之地,企业必须具备以下特色: – (1)有成本优势。如果你的成本比对手的低,那么别人拼不过你; – (2)细分市场的定位非常准确。细分市场对应顾客的个性化需求,谁能够充分挖掘顾客的 个性化需求,谁就能在这个细分市场吃个饱。 ‹ 涉足未成熟的市场要冒很大的风险,因为很难准确地估计潜在的市场有多大?自己能占多少份额 ?如果错误地高估了市场,那么即使你成为老大也会因需求不足而饿死。风险和利润总是结伴而 行的,想发财就要冒险。 – 一些拥有创新技术的中小型企业喜欢冒险探索新的市场,而许多大企业通常静观其变、规 避风险。等开拓者头破血流地把市场基础打好后,大企业突然全线出击,迅速占领市场, 把开拓者一举消灭。真是“螳螂捕蝉、黄雀在后”啊。 ‹ 不论想进入那种类型的市场,都要尽可能准确地分析市场的总额、竞争对手所占的份额,以及本 产品可能占有的份额。同时要深入分析消费者的群体特征和消费方式,以便发掘细分市场。 Page 11 1.4. 可行性分析 1.4.3 政策可行性分析 ‹ 何为政策?政策就是政府干预市场的堂而皇之的借口。众所周知,国内大部分成功的企业都有坚 实的政府背景。甚至连外商都知道,在中国做生意必需和政府打交道。这是中国的国情,估计保 持数十年不变。 ‹ 我们在做立项可行性分析的时候,千万不要忘记分析政策将对产品造成的影响。重点分析: – (1)有无政策“支持”或者“限制”; – (2)有无地方政府(或其它机构)的“扶持”或者“干扰”。 ‹ 如果发现有政策支持,那么要及时善加利用。例如各地方政府都制定了扶持软件企业的政策,如 果你能享用,就无形地提高了竞争力。 ‹ 如果发现有政策限制,那么想想“有无空子可钻、是否可以打擦边球”。别人因政策限制而不能做 的事情,你巧妙地做了,那就是本事。例如黄山香烟广告 “一品黄山,天高云淡” ,电信业内走政 策边沿而成功的最有名的例子就是“小灵通” ‹ 如果你开发的产品既无政策支持,也无限制,而你又希望得到政策的支持。那么你就协同业内人 士积极地和地方政府沟通,引导政府制定对行业有益的政策。 ‹ “世上本无路,走的人多了,就成了路”,政策亦是如此。如果你善于利用政策,你就比竞争对手 多几分优势。 Page 12 1.4. 可行性分析 1.4.4 技术可行性分析 ‹ 技术可行性分析可以简单地表述为:做得了吗?做得好吗?做得快吗? – (1)能否在给定的时间内实现软件的全部功能?如果在项目开发过程中遇到难以克服的技 术障碍,麻烦就大了。轻则拖延进度,重则断送项目。 – (2)软件的质量如何?例如有些应用对实时性要求很高,如果软件运行慢如蜗牛,即便功 能具备也毫无实用价值。有些高风险的应用对软件的可靠性要求极高,例如航空航天系统 ,如果软件出了差错而造成客户利益损失,那么软件开发方可要赔惨了。 – (3)软件的开发效率如何?如果开发效率比较低,不仅导致成本增加,而且延长了产品上 市的时间,可能会丧失市场机会。 – 软件维护是非常拖后腿的事,它能把前期拿到的利润慢慢地消耗光。如果软件的质量不好 ,将会导致维护的代价很高,所以企图通过偷工减料而提高生产率是得不偿失的。 Page 13 1.4. 可行性分析 1.4.4 成本收益分析 ‹ 成本——收益分析最容易理解。收益减去成本就是利润,如果成本高于收益则表明亏损了,如果 成本大大高于收益那就亏大了。企业什么事情都有可能干,惟独亏本生意不能干。 ‹ 企业在产品开发、营销、维护方面所付出的都可以折算成金钱,汇总起来就是总成本。如果做的 是小本生意,真的要对成本进行细算,否则入不敷出。 ‹ 收益包括“可以用金钱量化的收入”和“难以用金钱估算的好处”,通常大家更加关心前者。如果是 承包某个客户的项目,那么收益就写在合同中。如果是开发自己的软件产品,那么收益就是销售 额。 ‹ 人们喜欢吃着碗里的、看着锅里的,还想着别人家里的。短期利益和长远利益兼得是人们梦寐以 求的事。在现实中,这等好事可不会轻易降临。 – 每当我们沉迷于短期利益而不思进取的时候,应该好好回忆童年时代那些伟大的抱负,给 自己一些激励。 – 能为了长远利益不惜短期亏损的人,要么是雄心勃勃的将帅之才,要么是“纸上谈兵”、“眼 高手底”的那一类庸人。那些为长远利益奋斗的人们,你们可得把长征的路途走完,千万别 让事业在中途夭折啊。 Page 14 1.4. 可行性分析 1.4.5 常见决策分析方法-SWOT分析 ‹ SWOT代表强项(Strengths),弱项(Weaknesses),机会(Opportunities)和威胁(Threats)。 SWOT是产品立项过程中最常用、非常有效的可行性分析方法,核心问题是: – 我们的强项是什么?我们如何利用这些强项? – 我们的弱项是什么?我们如何减少这些弱项的影响? – 市场为我们提供什么样的机会?我们如何把握这些机会? – 什么威胁着我们的成功?我们如何有效地对付这些威胁? ‹ 一般地,市场和政策属于环境因素,环境因素并不由企业控制,基本上与企业的内部特征没有多 大关系。而对于许多采用成熟技术的产品而言,同行企业的技术可行性分析结果大同小异。而 SWOT分析则是与企业内部特征紧密相关的,实质上是核心竞争力的分析。 ‹ 在很多时候,“市场、政策、技术”方面的可行性分析不足以使决策者下定决心立项或者否决立项 建议,此时SWOT分析举足轻重。 ‹ 遗憾的是,软件工程书籍和CMM/CMMI中都没有论述SWOT分析方法,有些项目管理书籍也只是简单 地介绍一下,所以大部分软件人员不懂得SWOT分析。我要提醒大家的是,并不是任何团队(或企 业)都能够使一个很好的产品构思转变为可赢利的产品。我亲身体会了SWOT分析的效力,所以极 力建议同行们学会SWOT分析。 Page 15 1.5. 立项评审 1.5.1 角色职责 ‹ 立项建议小组把《立项建议书》、《可行性分析报告》递交给有决策权的公司领导。 ‹ 公司领导根据项目的特征组织立项评审委员会,并确定一位主席。一般地,立项评审委员会由公 司领导、各级经理、市场人员、技术专家、财务人员等组成。委员会按少数服从多数原则投票决 定是否同意立项(此时公司领导只是一名委员,不具有一票否决权)。 ‹ 主席应当具备比较丰富的评审经验,能够控制评审会议的进程。主席除了主持评审会议之外,还 要负责撰写《立项评审报告》。 1.5.2 步骤 ‹ 第一步 评审准备。主席确定评审会议的时间、地点、设备和参加会议的人员名单,分发材料。 ‹ 第二步 举行评审会议。主席宣讲本次评审会议的议程、重点、原则、时间限制等。立项建议小 组陈述《立项建议书》的主要内容。评审委员会提出疑问,立项建议小组解答。双方应当对有争 议的内容达成一致的处理意见。记录员记录答辩过程的重要内容(问题、结论、建议等)。 ‹ 第三步 评估。每个评审委员会根据“立项评审检查表”(见5.3) 认真地评估该项目。 ‹ 第四步 评审会议决议。评审委员会给出评审结论和意见。如果半数以上的评委反对立项,则评 审结论为“不同意立项”。如果半数以上的评委赞同立项,则评审结论为“同意立项”。 ‹ 第五步 公司领导终审。如果公司领导的终审结论与评审委员会的结论“一致”,则公司领导和评 审委员会共同分担立项评审工作的责任。如果公司领导的终审结论与评审委员会的结论“相反”, 公司领导可以行使“一票否决权”,则公司领导应当对立项评审工作负全部责任。 Page 16 1.5. 立项评审 1.5.3 立项评审检查表(checklist) ‹ 产品需求、目标清晰吗?产品符合本公司短期、长期的发展战略吗? ‹ 客户需求强烈吗?消费群体的购买力强吗? ‹ 当前市场总额大吗?市场发展前景好吗?预期能占有的市场份额令人满意吗? ‹ 己方的核心竞争力强吗?SWOT分析令人满意吗? ‹ 产品的技术方案合理吗?技术实现途径(如自主开发、外包开发等)合理吗? ‹ 产品的开发计划合理吗?实际用于开发本产品的经费、人员、物资、时间能满足要求吗? ‹ 产品的营销计划合理吗?成本-效益分析令人满意吗? ‹ 产品的质量令人满意吗?产品在使用过程中会给用户带来意外的损失吗? ‹ 有政策风险吗? ‹ 有知识产权风险吗? ‹ 有财务风险吗? ‹ 有不可预测的市场风险吗? 1.5.4 编制立项评审报告 Page 17 1.6. 项目启动 ‹ 当立项建议被批准之后,公司领导首先任命合适的项目经理,让项目经理去筹备项目。 ‹ 项目经理组建项目组,确定CM、CCB、QA等人员 。 ‹ 项目经理及参加立项建议或投标的相关人员给项目组介绍项目背景和基本情况。 ‹ CM(配置管理人员)选择相应的机器,搭建配置环境,安装配置系统,建立配置库。 ‹ 项目经理组织、安排有关项目前期工作,包括必要的培训、进行项目计划活动等。 ‹ 项目经理填写《项目启动基本情况表》 报公司领导审批。 Page 18 1.7. 项目定义过程 1.7.1 建立项目定义过程 目的:从本组织的标准过程集合剪裁形成“项目定义过程”,用“项目定义过程”来管理项目 角色:项目经理、EPG 输入:项目启动基本情况表 主要步骤: 1.选择合适的生命周期模型; 2. 选择最适合该项目需求的标准过程 ; 2.按照剪裁指南剪裁组织标准过程集合和其他过程财富,以产生项目已定义过程; 3.项目已定义过程形成文件; 4. EPG、项目经理对《项目定义过程》进行同行评审,必要时修改项目已定义过程。 输出:项目定义过程 Page 19 1.7.2集成项目管理过程域(IPM)结构图 1.7.项目定义过程 • Process and Product Measures • Documentation • Lessons Learned OPD Project’s Defined Process Integrated Plans Use Org. Proc. Assets for Planning Project Activities 用组织过程财富 策划项目活动 Manage the Project Using the Integrated Plans 利用综合计划 管理项目 Manage Stakeholder Involvement 管理共利益者 介入 Stakeholder Coordination Issues Contribute to the Organizational Process Assets 充实组织 过程财富 Manage Dependencies 管理依存 关系 Documented Critical Dependencies Collaborative Activities and Issues Coordinate and Collaborate with Relevant Stakeholders与相 关共利益者合作 Use the Project’s Defined Process运用项目已定义过程 Establish the Project’s Defined Process 建立项目已 定义过程 Integrate Plans 综合计划 Project Plan Resolve Coordination Issues 解决协调 问题 IPM: Integrated Project Management Page 20 2. 项目策划 2.1.1 什么是项目策划 ‹ 项目策划(Project Planning)的目的是为项目的开发和管理工作制定合理的行动纲领(即项目计 划),使所有人员按照该计划有条不紊地开展工作。为了避免词义混淆,这里把动词Planning译为 策划,把名词Plan译为计划。 2.1.2 为什么要进行项目策划 ‹ 软件项目策划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排 ,制定出一些计划(包括高层的和细节的),使大家按照计划行事,最终顺利地达到预定的目标 。如果不对项目进行规划的话,一群人天马行空、各干各的,项目进展不到一半就混乱不堪了。 2.1. 项目策划的概念 Page 21 2.1. 项目策划的概念 2.1.3 谁在什么时候进行项目策划 ‹ 在立项管理过程,公司领导首先任命一位项目经理,项目经理筹备项目经费、人力资源、软件硬 件资源等。《项目定义过程》已评审通过,那么项目经理和核心成员即可组成一个项目策划小组 ,开始进行项目策划。 ‹ 疑问:在《立项建议书》或《技术解决方案》中不是已经有了项目的开发计划了吗?为什么还要 进行项目策划呢? – 《立项建议书》中的开发计划仅仅是一种设想而已,因为当时人们并不知道公司是否会采 纳这个建议、也不知道领导支持的力度有多大。 – 假设《立项建议书》中的计划需要10名开发人员和一百万元经费,但是当立项之后公司只 能给予5名开发人员和50万元经费,那么原计划必须做出重大调整。 2.1.4 项目策划产生的成果是什么 ‹ 一是全局的计划书(Overall Plan),这里称为《项目计划》; ‹ 二是一些下属计划书(Subordinate Plan),例如配置管理计划、质量管理计划、阶段开发计划和 测试计划等。 ‹ 下属计划书是对《项目计划》的补充,其内容不可与《项目计划》冲突。通常《项目计划》由项 目经理负责制定,由公司领导审批。而下属计划书一般由项目成员制定,由项目经理或各相关小 组负责人审批即可。 Page 22 2.1. 项目策划的概念 2.1.5 项目策划过程域(PP)结构图 Planning Data Establish Estimates 建立估算 Obtain Commitment to the Plan 获得对计划的承诺 Develop a Project Plan 制定项目计划 Project Plans PMC PP: Project Planning Page 23 Determine Estimates of Effort and Cost 估算项目 人力和成本 Planning Data Establish Estimates建立估算 Estimate the Scope of the Project 估计项目范围 Establish Estimates of Work Product and Task Attributes 对工作产品 和任务估算 Define Project Life Cycle 定义项目 生命周期 2.1. 项目策划的概念 2.1.5.1 建立估估算 Page 24 Establish the Budget and Schedule 建立项目 预算/进度 Planning Data Develop a Project Plan制定项目计划 Plan for Data Management 计划数据管理 Plan Stakeholder Involvement 共同利益者 参与计划 Plan for Project Resources 项目资源计划 Project Plans Establish the Project Plan 制定项目计划 Identify Project Risks 识别项目风险 Plan for Needed Knowledge and Skills 计划所需 知识和技能 2.1. 项目策划的概念 2.1.5.2 制定项目计划 Page 25 Obtain Commitment to the Plan 获得对计划的承诺 Reconcile Work and Resource Levels 配备工作与资源 Project Plans Review Plans that Affect the Project 评审项目计划 Obtain Plan Commitment 获得对计划 的承诺 2.1. 项目策划的概念 2.1.5.3 获得对计划的承诺 Page 26 2.1. 项目策划的概念 2.1.6 项目策划的流程 Page 27 2.2. 如何进行项目估计 2.2.1 观念 ‹ 在制定项目计划之前,理应采用恰当的方法对重要的数据进行估计,否则计划就乱写了。一般地 ,项目估计的要素是软件规模、工作量和人力成本,如果这些要素估计得比较准确得话,那么后 续制定的项目计划就比较合理。对于一些外包项目而言,项目估计得到的数据是双方讨价还价的 依据。 ‹ 项目估计几乎不可能成为一门精确的科学,因为在项目刚开始时,人们对产品需求和技术的了解 还比较肤浅,而项目实际能够拥有经费和资源很大程度上是靠项目经理争取来的,不确定因素比 较多。在这种情况下人们很难作出准确的估计。但是大家都认同:依据某种方法(规则)进行估 计显然比瞎猜好得多。 ‹ 常用的项目估计方法大体分为两类,第一类是数学模型,第二类是简单直观的“分解-累计”方法 2.2.2 用于项目估计的数学模型 ‹ 采用数学模型这种方法是学术界热衷的,因为有数学公式的东西更显得有学术味道。这类方法适 合于非常成熟的软件公司,该公司积累了丰富的历史数据,以至于能够归纳出数学模型来指导新 项目的规划。 ‹ 典型的数学模型如 E = A + B×(ev) C – 其中A,B,和C是由经验导出的常数,E是以“人月”为单位的工作量,ev是估算变量如代码行 (LOC)或者功能点(FP)。 Page 28 2.2. 如何进行项目估计 2.2.3 简单直观的估计方法 ‹ 产品规模估计方法 – (1)项目策划小组先分解产品的功能,制定“产品功能分解与规模估计表” 。软件规模的 度量单位主要有:代码行、对象个数、页面数等等。 – (2)规划小组各成员独立填写表格。 – (3)汇总每个成员的表格,进行对比分析。如果各人估计的差额小于20%,则取平均值。 如果差额大于20%,则转向第(2)步,让各成员重新估计产品的规模,直到各人估计的差 额小于20%为止。 Page 29 2.2. 如何进行项目估计 2.2.3 简单直观的估计方法 ‹ 工作量估计方法(步骤与规模估计相似) – 先估算开发工作量。一般地可以把开发过程划分为需求开发、系统设计、实现、测试四个 阶段,分别估计每个阶段的工作量,然后累计得出总的工作量 – 再估算管理工作量。一般地,项目的80%以上的工作量用于开发,20%以下的工作量用于 管理。 Page 30 2.2. 如何进行项目估计 2.2.3 简单直观的估计方法 ‹ 人力成本估计方法 – 如果已经估算出项目的工作量,那么估算人力资源成本就比较容易。每人每年的成本显然 高于年薪,因为每个人除了拿工资外,日常还要消耗公司资源,公司要额外支付各种保险 金等。 – 一般地,对于软件企业,每人每年的成本大约是其年薪的1.5至2.0倍(姑且称之为成本系 数)。如果成本系数太高的话,表示该公司要么福利极好要么铺张浪费;反之如果系数太 低的话(最低为1.0),表示该公司福利极低。 – 简单的案例:如果乙方想承包甲方的项目,假设乙方估计该项目的工作量为10人年,乙方 人员的平均年薪为8万元,成本系数为2.0。请问乙方的人力资源报价如何?(设备成本、 差旅费等等另外计算) – 乙方的人力资源报价应该是 10×8×2.0=160万元吗?不对,如果这样报价的话,乙方的 老板只好喝西北风了。报价必须考虑利润,假设双方可以接受的利润率为20%,那么乙方 报价应该是160×1.2=192万元。 – 乙方应该把报价的详细清单(不是最终结果)给甲方看,表明这个报价是合理的,而不是 狮子开大口。甲方要检查这个报价清单,尽可能把里头的“水分”挤出来。双方必然有个讨 价还价的过程,如果想说服对方,一定要拿出经得起推敲的数据来,以理服人。否则双方 尽是胡侃,最后在酒桌上解决,这是比较低俗的商业谈判(也算得上是国粹了),不值得 大家效仿。 Page 31 2.2. 如何进行项目估计 2.2.4 无效的项目估计 ‹ 在某种情况下,任何的项目估计方法都没有实际价值,例如: – (1)项目的人员已经被上级领导限定死了,再多的活也是那几个人干; – (2)除了办公计算机和工资外,这个项目没有其它经费,项目经理只有干活的权利没有用 钱的权利; – (3)项目的结束日期早就被领导和客户指定了,不管合理不合理,反正时间一到就要交付 软件。 – 如果人员、资金、时间都已经被毫无道理地指定了,你进行科学地估计还有啥用?这样的 项目在国内并不少见,如果你碰上了,那么就自认倒霉吧。 Page 32 2.3.制定项目计划 2.3.4.1编制项目估算书 规模估算:通常的估算方法DELPHI、历史经验数据分析法、PERT方法和FP功能点分析方法。单位 :功能点(FP)、代码行(SLOC)或千行代码(KSLOC)对象数量、UC点数等;文档规 模可以选择文档页数。 工作量估算:估算方法有历史经验数据分析法、COCOMO估算模型、IBM估算模型 进度估算:进度估计方法估计项目总体进度。 – 在交付日期已确定的情况下(如,已签定开发合同),总体进度=交付日期-项 目启动日期。 – 在交付日期不确定,且团队人数未知的情况下,采用COCOMO估算模型、IBM估 算模型估计总体进度。 – 在交付日期不确定,且团队人数已知的情况下,总体进度T=总工作量E×(1-Q )/ 团队人数N。 计算公式:工作量=规模/平均生产率 Page 33 2.3.制定项目计划 2.3.4.2编制项目估算书 成本估算: 从过程财富库中提取公司与软件相关的各角色标准成本单价。 计算分项人力成本=分项工作量*成本单价。 估计项目发生费用。 计算项目总成本=各分项成本之和+项目发生费用。 关键计算机资源估算: 罗列项目本身存在的计算机资源限制,根据软件需求确定本项目的关键计算机资源。 估计开发环境、测试环境和运行环境对关键计算机资源的要求。 Page 34 2.3.制定项目计划 2.3.5编制项目进度计划 项目进度计划:主要包括进度规划(里程碑计划)、阶段计划和个人安排。 进度规划:在项目启动时项目经理制定项目进度规划(一般按软件项目生命周期的阶段划分,明确 项目里程碑) 阶段计划:在各阶段中项目经理及相关角色制定阶段计划(如调研计划、需求分析计划、系统设计 计划、编码计划、测试计划、质量保证计划、安装调试计划、培训计划、验收计划等等) 个人安排:相当于目前正在实施的周计划,由项目经理在阶段计划基础上制定项目小组成员下周每 天的工作计划,并在每周一对上周的计划进行跟踪。 进度计划制定的原则:充分考虑每个工作人员的实际能力、计划的合理性和实用性、考滤计划任务 的关联性、充分利用Project工具。 Page 35 2.3.制定项目计划 2.3.6编制评审计划 同行评审:目的是尽早地发现工作成果中的缺陷,并帮助开发人员及时消除缺陷,从而有效地提高产品的质 量。评审类型:个别讨论、集中会议、电子邮件、会签、日常交流等形式。同行评审报告。 管理评审:主要是对计划类的工作产品进行评审。 2.3.7编制组间协调计划 目的:协调管理的目的是为了建立一种工作方式,使软件项目组与其它部门、客户等相关的组能积极协作, 从而使项目能更好、更有效地满足客户需求 工作步骤: z 识别关键依赖:项目经理在项目策划过程中或项目跟踪实施中需要分析所有的项目工作内容,并从中 识别出项目组哪些工作依赖于其他部门或客户,并确定哪些对项目目标有重大影响,需要重点协调的 ,这些依赖称之为“关键依赖”。 z 记录关键依赖:识别出来的“关键依赖”记录下来,以便协调有关事项、问题。 z 协商关键依赖:项目经理应就识别出的“关键依赖”与相关的部门或客户协商,并达成共识。“提供什么” 、“由谁提供”、“何时提供”、“验收标准”;确定对于“关键依赖”,双方或多方怎样进行协调和跟踪工作 ;协调跟踪的主要方式等。 z 制定组间协调计划:协调计划中应说明“项目组的工作”、“依赖的外部工作”、“依赖的相关部门 ”、“完成时间”等内容。 Page 36 2.3.制定项目计划 2.3.8编制项目度量计划 目的:采集项目数据,分析项目进展状况,为项目经理及公司领导提供决策依据。保证项目达到预期目标, 为组织提供原始数据。 度量计划的内容:度量目标、采集方法、采集责任人、采集时间、采集存储、分析方法、分析责任人、分析 时间、数据存储。 2.3.9编制风险管理计划 目的:识别潜在的问题,以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动,缓解不 利的影响,实现目标。风险管理是在项目过程最容易被忽视的环节。 2.3.10编制项目培训计划 目的:项目经理应将项目所要求的能力、技术作出评估及确认,并针对项目组成员的能力及水平状况,列明 项目组所需要的培训。从而为项目的顺利实施打下基础。 Page 37 2.4.制定项目从属计划 2.4.1编制测试计划 测试人员编写《测试计划》初稿 2.4.2编制质量保证计划 质量保证人员编写《质量保证计划》 2.4.3编制配置管理计划 配置管理人员编写《配置管理计划》 2.4.4编制项目采购计划 如果涉及到采购,由项目经理提出申请,采购人员编写《项目采购计划》 Page 38 2.5. 审批项目计划和从属计划 2.5.1 评审流程 ‹ 项目经理把《项目计划》及从属计划发给项目成员。 ‹ 项目成员对《项目计划》及从属计划进行评审。 2.5.2 审批流程 ‹ 第一步,项目经理把经评审通过的《项目计划》递交给公司的领导。 ‹ 第二步,公司领导根据“项目计划检查表” 认真审阅该《项目计划》,如果没有异议,那么就签字 批准;如果有不同意之处,就和项目经理沟通,并请项目经理及时修改。 ‹ 第三步,公司领导签字批准之后,该《项目计划》就成为“正式文件”,所有的项目成员都必须按 照该计划执行。如果以后要修改《项目计划》的话,必须准照变更控制流程来修改。 ‹ 如果是合同项目,那么要请客户和公司领导共同审批文件。 2.5.3 注意事项 ‹ 如果公司领导不认真审阅《项目计划》而例行公事地签字批准的话,那么项目计划的审批流程一 点意义都没有。我见过不少雷同的场景,秘书把一叠文件摆在领导的桌面上,领导上班时,一边 无聊地翻阅文件一边签字,体会着当领导的快乐与烦恼。 ‹ 软件公司的领导通常都是稿软件出身的,按理说他比普通项目经理更加清楚如何进行项目策划, 所以如果领导不用他的智慧审批《项目计划》的话,那么领导就是个摆设,对规范化管理没有促 进作用。 Page 39 2.6. 项目计划变更控制 2.6.1 为什么要变更项目计划 ‹ 在人们刚开始制定《项目计划》的时候,由于对项目本身缺乏深入的理解,第一个版本的《项目 计划》有可能比较粗略甚至不切实际。在项目执行过程中如果发现《项目计划》与实际情况有比 较大的偏差,应当及时更新《项目计划》。所以《项目计划》不是一成不变的,它将随着项目的 进展而逐步完善。《项目计划》一般不纳入基线进行管理。 ‹ 项目计划变更控制的目的是: – (1)修改原《项目计划》中不合理的内容,产生新的《项目计划》; – (2)按照指定的流程修改《项目计划》,防止发生混乱。 ‹ 一般地,若下列情况发生,应当变更《项目计划》: – 进度偏差超过了容许的误差,如20%; – 费用偏差超过了容许的误差,如20%; – 项目采用的生命周期模型发生了显著的变化; – 用户需求发生了重大的变化; – 发生了不可抗拒的变化,例如公司裁员、公司调整、产品发展战略调整等。 Page 40 2.6. 项目计划变更控制 2.6.2 项目计划变更控制流程 ‹ 第一步,项目经理向公司领导提交《变更申请书》,该申请书应当说明:变更原因;变更的内容 ;此变更对项目造成的影响。 ‹ 第二步,公司领导审批该申请书。如果领导不同意变更,那么项目按照原计划执行;如果同意变 更,那么转向第三步。 ‹ 第三步,项目经理制定新的《项目计划》,并提交给公司领导。 ‹ 第四步,公司领导审批新的《项目计划》。 ‹ 为了提高效率,第一步和第三步可以合并一起,由项目经理执行。同理第二步和第四步也可以合 并一起,由公司领导执行。如果是合同项目,那么要请客户和公司领导共同审批文件。 Page 41 3. 项目监控 3.1 为什么需要项目监控 ‹ 因为执行计划的是人而不是机器,每个人做事都可能与计划有偏差,何况一群人呢。再者,环境 也会发生变化。 ‹ 项目监控至少有以下几个好处: – (1)避免原本合理的计划在实施过程时落空; – (2)避免“执迷不悟”地按照不合理的计划行事; – (3)将监控过程产生的数据保存起来,为公司持续的过程改进提供有价值的数据。 ‹ 项目监控(Project Monitoring and Control)的目的是通过周期性地跟踪项目计划的各种参数 如进度、工作量、费用、资源、工作成果、风险等等,不断地了解项目的进展情况,以便当项目 实际进展状况显著偏离计划时能够及时采取纠正措施。 ‹ 项目监控的基本原理是:将项目实际情况与项目计划进行对比,如果发现某些因素的偏差非常大 (超过了容许的误差),那么及时分析原因,给出纠正措施。 ‹ 项目经理不要企图对所有的项目事务进行监管,否则要管的事情实在太多了,最终什么都没有管 好。一般地,项目监控的重点是:任务进度;项目费用;人员业绩;软硬件资源;项目风险; Page 42 3. 项目监控 3.2 项目监控(PMC)结构图 Project Plan Monitor Data Management 监督数据管理 Monitor Commitments 监督承诺 Monitor Project Planning Parameters 监督项目策 划参数 Conduct Milestone Reviews 执行里程碑 审查 Monitor Project Risks 监督项目风险 Analyze Issues 分析问题 Take Corrective Action 采取纠正措施 Monitor Project Against Plan 对照项目计划监督项目 Conduct Progress Reviews 执行进展 审查 Monitor Stakeholder Involvement 监督共利益 者介入 Manage Corrective Action 管理纠正措施PP Manage Corrective Action to Closure 管理纠正措施直到结束 PMC: Project Monitoring and Control Page 43 3. 项目监控 3.3 项目监控方法 ‹ 日报、项目周报、项目月报、里程碑状态报告、阶段报告 ‹ 会议、日常交流 3.4 任务进度监控 ‹ 任务进度监控的要点是: – (1)记录某任务的实际开始时间和实际结束时间; – (2)在检查的那一天,判断该任务的状态是“提前、延迟还是正常”; – (3)记录实际产生的工作成果; ‹ 项目经理使用合适的软件工具,很容易地绘制出“Gantt对比图” 。对于那些进度被延迟的任务, 项目经理应当和责任人交流,分析原因。如果是原计划太乐观了,那么适当修改原计划;如果是 人员工作不得力,那么要求责任人加班追赶进度。 Page 44 3. 项目监控 3.5 项目费用监控 ‹ 费用监控的目的是将项目的实际花费控制在预算之内。项目经理首先要记录所有的开支项。如果 公司已经使用比较好的财务软件,那么这些财务数据已经保存在数据库内。 ‹ 对于大部分软件项目而言,项目经理只需要懂得一点点财务知识就行了。对财务数据进行简单的 处理,就能获得比较有用的监控信息: – (1)绘制饼形图,看看各个费用类别之间的比例是否合理; – (2)绘制柱状对比图,看看每种费用类别是否超支。 Page 45 3. 项目监控 3.6 人员业绩记录 ‹ 许多公司都在年终进行业绩考评,领导往往只记住下属的最后一个月表现,淡忘了他们在以前的 功和过。所以传统的年终考核有很大的弊端。 ‹ 项目经理要在平时记录项目成员的业绩,否则在项目结束后就没有公正考核成员业绩的证据。可 以用Word或者Excel制作表格。注意业绩表是个比较敏感的东西,项目经理要注意措词,避免挫伤 那些业绩不佳的人员的自尊心和积极性。 Page 46 3. 项目监控 3.7 软硬件资源监控 ‹ 十几年前,计算机是非常昂贵的设备,人们把它当宝贝似的看管起来,现在很少有人再这样做了 。这里所谓的资源监控是指对“关键资源”的监控,监控的目的就是确保关键资源安全有效,并且 提高其利用率。 ‹ 例如用作服务器的计算机是关键硬件资源,项目经理要清楚这台服务器能否有效地支持应用。如 果服务器的速度和内存太低了,项目经理就要设法提高服务器的配置。反之如果应用是轻量级的 ,那么没有必要购买高档的服务器。 ‹ 例如用于配置管理的ClearCase是关键软件资源,ClearCase的每个License很贵。如果项目拥有的 License不够用,那么需要扩充;如果License足够多,利用率不高,那么应该把License分给其它 项目用。 3.8 风险监控 详见“风险管理”内容 Page 47 3. 项目监控 3.9 项目进展报告 ‹ 项目经理应当定期(例如每2周一次)撰写项目进展报告,通报给上级领导和所有项目成员。进展 报告的格式可以自由制定,关键是要总结出实质性的内容,让人们清楚地知道项目的真实状况, 而不是记流水帐。 ‹ 在各里程碑阶段,项目经理需要重新估算,项目经理编制《里程碑状态报告》。 ‹ 许多人把项目进展报告写在email里,虽然起草和发送比较方便,但是容易丢失历史信息(如果 email删除了报告也就丢失了)。最好是把项目进展报告保存在数据库里,人们可以使用浏览器来 访问,那么任何人在任何时间都可以了解项目进展状况和历史信息。 Page 48 4.风险管理 HighHigh LowLow HighHigh 风风 险险 的的 影影 响响 LowLow Acceptable Risk Unacceptable Risk 风险发生的可能风险发生的可能 Risk assessment drives to acceptable risk 风险(风险(RiskRisk):损失或损害的可能性,尚未实际发生;):损失或损害的可能性,尚未实际发生; 问题(问题(IssueIssue):已经发生的影响项目顺利进行的状况;):已经发生的影响项目顺利进行的状况; 4.1 什么是风险 Page 49 z “风险管理”目的是识别潜在的问题,以便策划处理风险的活动和在 必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目 标。 z “风险管理” 是一个连续的前瞻性的过程,它是业务和技术管理过程 的重要组成部分。 z “风险管理”主要目标是预防风险。 4.2 风险管理的目的 4.风险管理 Page 50 4.3 风险管理(RSKM)结构图 Determine Risk Sources and Categories 确定风险 来源与类别 Define Risk Parameters 定义风险 参数 Identify Risks 识别风险 Evaluate, Categorize, and Prioritize Risks 对风险进行 评价、分类 排序 Develop Risk Mitigation Plans 制定风险 缓解计划 Implement Risk Mitigation Plans 实施风险 缓解计划 Risk Repository Prepare for Risk Management准备风险管理 Identify and Analyze Risks 识别和分析风险 Mitigate Risks 缓解风险 Establish a Risk Management Strategy 制定风险管理 策略 PP RSKM:Risk Management 4.风险管理 Page 51 风险识别 风险分析 风险应对 计划 跟踪和控制风险管理 计划 进一步 行动 1.定义项目的 风险管理过程, 使用的工具、 方法 2.定义风险、识 别和风险分析、 风险应对计划、 跟踪和控制等各 项工作的职责和 方法 3.定义如何评估 风险管理水平 1.1.理解项目中有理解项目中有 哪些可能令人哪些可能令人 不满意的结果不满意的结果 2.2.根据项目的根据项目的 各种知识领域各种知识领域 ,,产品特性产品特性,,项项 目特性等识别目特性等识别 风险风险 1.根据不同因素 对风险进行分 类,判断该风险 之前是否发生过 2.分析风险发 生的可能性、 潜在影响,及 风险的严重程度 1.讨论确定如 何应对风险, 列出将潜在的 规避风险方法 2.评估不同方 法中较为适用 的,作为主要 规避策略 3.应对策略: 规避风险, 转嫁风险, 缓解风险, 接受风险 1.判断风险是 否仍然存在, 执行风险应对 计划、跟踪风 险当前状态 2.定期进行风 险状态回顾, 采取必要措施 1.根据实际情 况重新调整风 险可能性、影 响、严重程度 以及应对策略 2.根据实际情 况识别新的风 险,进一步跟 踪控制 4.风险管理 4.4 风险管理过程 Page 52 Classification Description Impact Probability Mitigation Status ++ == 要评估哪方面的 风险 什么样的风险, 提出人,提出时 间等 如果发生会有什 么影响 风险发生的可能 性有多大 如何降低风险 跟踪风险目前的 状态 风险管理列表 4.风险管理 4.5 风险管理要素表 Page 53 风险分析 高 中 低 高 低 中 风 险 的 影 响 发生可能性 最严重的风险 首先考虑 严中的风险 其次考虑 重要风险 再其次 4.风险管理 4.6 风险分析矩阵表 Page 54 不能直接 控制的部分 可直接 控制的部分 项目干系人积极 参与并做出承诺 客户能够感知 项目带来的好处 通过风险管理 降低了风险 项目交付团队 利益得到保障 工作计划和进度 都在计划范围内 范围清晰、可控 团队士气高昂 红色: 存在重大问题,需要立即采取行动 黄色: 警告,存在一定问题,需要采取行动进行纠正 绿色: 进展顺利,没有什么问题; 4.7 7个关键风险的评估方法 4.风险管理 Page 55 5. 结项管理 5.1 基本概念 ‹ 项目结束有两种状况:一是正常结束,二是异常结束。前者是指项目按预定计划结束。后者原因 有多种,归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中 途淘汰,有些项目在执行过程中大大偏离了计划(如进度延误、费用超支)而被取消。 ‹ 不论项目属于正常结束还是异常结束,都要按照结项管理规范处理。国内很多项目普遍存在“虎头 蛇尾”的现象,结项管理畸变成了“走过场,吃顿饭”,这是非常有害的。 ‹ 有价值的结项管理至少包括三项内容: – 对项目的有形资产和无形资产进行清算,既要防止资产流失,又要及时地重复利用这些资 产。在结项的时候,我经常看到行政人员认真地记录设备资产,财务人员分厘不差地结算 经费,却几乎不见有人考察并提炼无形资产。对于软件企业而言,可以复用的软件成果( 包括代码、文档)才是企业最有价值的财富,硬件设备会越用越差,但是可复用的软件成 果却越用越好。 – 对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价 值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。 – 总结经验教训,使整个机构受益。一些经费充足的项目在结项的时候,人们通常不会忘记 进行最后一次“吃喝玩乐”,可是忘了乘着团队尚未解散的时候总结经验教训。做完一个项 目,不论结果好坏,每个人都有自己的真切感受,如果把这些感受汇总起来,就能够提炼 出对企业非常有益的知识财富。 Page 56 5.2集成项目管理过程域(IPM)结构图 • Process and Product Measures • Documentation • Lessons Learned OPD Project’s Defined Process Integrated Plans Use Org. Proc. Assets for Planning Project Activities 用组织过程财富 策划项目活动 Manage the Project Using the Integrated Plans 利用综合计划 管理项目 Manage Stakeholder Involvement 管理共利益者 介入 Stakeholder Coordination Issues Contribute to the Organizational Process Assets 充实组织 过程财富 Manage Dependencies 管理依存 关系 Documented Critical Dependencies Collaborative Activities and Issues Coordinate and Collaborate with Relevant Stakeholders与相 关共利益者合作 Use the Project’s Defined Process运用项目已定义过程 Establish the Project’s Defined Process 建立项目已 定义过程 Integrate Plans 综合计划 Project Plan Resolve Coordination Issues 解决协调 问题 IPM: Integrated Project Management 5. 结项管理 Page 57 5.3 结项管理流程 ‹ 第一步 公司领导指示。对于异常结束的项目,公司领导应当明确指示该项目经理,确定何时结 束项目。公司领导应当向员工们解释为什么要异常终止项目,否则员工们人心惶惶,不利于企业 的稳定发展。对于那些按照计划执行的项目,当项目开发工作接近尾声时,公司领导和项目经理 应当根据机构的现状,协商确定何时结束该项目。 ‹ 第二步 结项申请。项目经理撰写《结项申请书》并递交给公司领导。 ‹ 第三步 结项评审。公司领导根据项目的特征成立结项评审小组。一般地,该小组由市场人员、 技术专家、财务人员、行政管理员等组成。财务人员主要清算项目的财务,行政管理员主要检查 项目的设备(有形资产)。剩余的经费应当被公司回收,设备应当被重新利用。如果发现存在非 法的资产流失问题,应当及时上报给公司领导,由领导处理。技术专家与项目成员交流,发掘可 以重复利用的成果。结项评审小组对该项目进行综合评估,并与项目成员们共同总结经验教训, 撰写《结项评审报告》。 5. 结项管理 Page 58 6. 小结 PP What To Build What To Do SAM PMC What To Monitor Replan Plans Status, issues, results of progress and milestone reviews Product component requirements Technical issues Completed product components Acceptance reviews and tests Engineering and Support process areas Status, issues, results of process and product evaluations; measures and analyses Commitments Measurement needs Corrective action Supplier Supplier agreement Corrective action 初级项目管理类过程域 Page 59 6. 小结 RSKM Risk status Risk mitigation plans Corrective action Risk taxonomies & parameters Risk exposure due to unstable processes Identified risks IT 集成组 Integrated work environment and people practices Process Performance objectives, baselines, models QPM 定量项目 管理Organization’s standard processes and supporting assets IPM for IPPD Project’s defined process Statistical Mgmt Data Process Management process areas Quantitative objectives Subprocesses to statistically manage Engineering and Support process areas Coordination, commitments, issues to resolve Monitoring data as part of supplier agreement Configuration management, verification, and integration data ISM 集成供应商 管理 Project performance data Integrated team management for performing engineering processes Shared vision and integrated team structure for the project Coordination and collaboration among project stakeholders Lessons Learned, Planning and Performance Data Project’s defined process Product architecture for structuring teams Basic Project Management process areas 高级
还剩58页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

open-wyp

贡献于2011-09-24

下载需要 15 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf