项目管理介绍及相关注意事项.doc_第1页
项目管理介绍及相关注意事项.doc_第2页
项目管理介绍及相关注意事项.doc_第3页
项目管理介绍及相关注意事项.doc_第4页
项目管理介绍及相关注意事项.doc_第5页
已阅读5页,还剩16页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1.1 成成超级浅谈项目管理之一(原创)想首先问大家一个问题:你觉得中国人聪明还是美国人聪明?我见过最好的回答是美籍华人。我们说美国人很愚蠢,为什么呢?你们都考过T或G吧,他们经常会出这么一道题1/3+1/2=?50%的人回答是2/5,这可是美国研究生入学考试的试题呀!通常在这个问题之前还有一个1/2+1/2=?为什么?他们怕太难了,先给个容易的热身一下。我在美国的时候见过很多的PHD,对于美国人来说if.else.是逻辑,而if.if.else.就成了哲学,也是美国这么多哲学博士的原因:)我们说美国人很愚蠢,那我们为什么还要学习他们呢?这个问题稍候我们会回答。再问一个问题:如果你刚买了一个豪华的房子,可你三岁的儿子把整个墙壁上都写上“我爱长城永不到,我爱北京天安门”,你该怎么做?有的女孩子说暴打,呵呵,这个答案从女生的嘴里说出来还是比较少见。美国人怎么办?他们会对孩子说:“你老人家真有绘画的天赋,简直就是毕加索的毕加索,你这一幅画至少能卖100万美金”你们知道美国人喜欢钱,用金钱来量化一定是效果明显。但显而易见,您老人家把画画在墙壁上是不能永久保存的,所以我明天给你买一个画布,你就尽情的画吧。否则我们要损失多少个毕加索呀!于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。中国人很聪明,从大家就可以看出来,但中国人聪明做工作就有了聪明的做法,他们往往是每个项目都是按照自己的见解来做。而美国人如何来操作呢,他们就像洗澡,会在面前挂一张纸,上面写着先洗头,再洗耳朵,再洗脸,这样做事情就有了一定的流程,渐渐的就形成了一套体系。所以这也是我们今天来探讨项目管理的目的所在。 项目管理分九个知识领域,分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。其中时间,质量和成本管理构成了三角形大家在纸上画一个三角形在各个边上标上时间、质量、成本(等边三角形)任何一方的移动必定带动其它的变形,如果时间缩短,怎么样?就是我们常说的“献礼工程”,同时必定会影响质量和成本。问大家一个问题,这个三角形中间是什么东东?对,是范围管理,也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形” 下面介绍一下项目管理的“项目管理三角形”项目三角形中的成本,主要来自于所需资源的成本,自然也包括人力资源的成本。这个相信很好理解。为了缩短项目时间,就需要增加项目成本(资源)或减少项目范围;为了节约项目成本(资源),可以减少项目范围或延长项目时间;如果需求变化导致增加项目范围,就需要增加项目成本(资源)或延长项目时间。通过“项目管理三角形”我们了解了项目成本、时间,质量和范围的简单定义。我们说一个项目经理有多少时间是用来做沟通的工作的?应该不少于75%的时间是用来沟通的,所以项目管理将项目沟通管理单独列了出来。所有这些领域都有一个主线就是项目的整体管理来统一的。由于时间的限制我们不详细讨论其它的知识领域,因为今天是入门的,哈哈 另外项目管理除了九个知识领域,还应该了解5个过程组5个过程组就是:启动,计划,执行,控制,收尾。这5个过程组贯穿于每个知识领域的始终,你们了解吗?举个例子字来说某人(比喻)好不容易找了个女朋友,为了增进进一步的距离,他想来个欧亚8日游,于是他把自己多年的积蓄3万元,一次性投入。但在旅游过程中,他的MM看上了另外一个帅哥,于是人财两空,说明什么问题?说明他的项目启动的时候就出现了问题,没有很好的做市场调研,结果过程就没有办法控制。根据PMI的解释,接单之后项目自然转入启动阶段,于是他刻苦的工作,终于又攒了3万,这次他不和美女旅游了,考虑到自己的费用,他请这个姑娘看了场电影。于是他带这个姑娘看了第一滴血。看的那叫爽,姑娘看的也很爽,看看完后她觉得这个家伙有暴力倾向,于是又分手。说明什么问题?对,没有进行有效的需求调查,也就是在计划的时候没有明确的需求定义。于是他下次的时候知道了姑娘爱看歌舞剧,于是他就请一个靓女看了天鹅湖,可是以外有发生了进去后发现座位不在一起,等他们把位子换到一起的时候歌舞剧结束了,这说明什么?对,说明没有很好的执行,起码在执行过程中没有进行有效的监督。其它的过程不一一解释,我在这里强调的是收尾的重要性。我们往往非常注重合同性收尾,却总是忽略管理性收尾。什么是管理性收尾呢?某人同志吸取了所有的经验教训,终于领了结婚证,还应该干些什么呢?对了,还应该把所有的经验教训总结一下,以书面的形式汇报给老妈,并张贴于门后。然后在中堂挂一幅对联:欲谈恋爱者需先阅读门后之恋爱指南,以后凡是自己的兄弟姐妹要谈恋爱的,必须先参阅门后的恋爱指南。这样能起到什么效果呢,对,以后他们的恋爱项目操作至少能停留在这个水平。这个过程怎样来保证呢,对,还需要我们的QA人员,也就是他的妈妈负责质量控制。家规一条,不参阅者或不照此操作者不许谈恋爱!大公司一般有质量管理部门(QA),QA的成员基本上都是由非常有经验的PM转型过来的老狐狸,是老总接班人的有力争夺者:)这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。 哪个门后的恋爱指南我们称之为文档,文档重要吗?我们说在电信科技处的同志们说重要,为什么因为他们管这个,但对于我们呢?大家拿起你身边的一只笔,告诉我他多长?有的说10厘米,有的说10.0987厘米。我们说他的估算很精确,但不准确!这是我如果拿一只笔告诉你正好10厘米,然后和你的笔比对你是不是就比较容易得出测算?这说明文档是非常重要的,有的人认为文档是最无聊的,项目结束后做个总结不就是了吗。错,文档的整理应该贯穿于项目管理的始终。文档的管理是对项目进行良好的跟踪和监控的一个手段,简单的讲就是根据你的项目计划进行你的文档管理。一般档案分类主线是:立项、计划、执行、结束4大类;然后在每大类中,再根据任务或者团组分类管理,根据哪个需要根据你项目复杂程度和管理习惯,总之原则是方便你对整个项目进度的追踪。 1.2 成成超级浅谈项目管理之二(原创)以上我们讲了项目管理的九个知识领域,五大过程组,还有“项目管理三角形“,下面我们讲PMBOK。 PMBOK是项目管理圣经,也就是Projectmanagementbodyofknowledge,项目管理知识体系指南,它是美国项目管理协会(PMI)的核心指导出版物但它象一本字典,往往你看到第三页会睡着:在此简单介绍美国项目管理协会(PMI)和国际项目管理协会(IPMA)美国项目管理协会只有PMP一个证书,而IPMA有四级,你可以一毕业就可以考试,这个我们后面详细的讲。 下面讲几个名词,如果你掌握了,一和人讲项目管理你就抛出来,一定没有人敢小看你。他们是WBS、甘特图、基准(BASELINE)、项目干系人和关键路径; WBS是WORKBREAKDOWNSTRUCTRE,工作分解结构WBS的定义还是很麻烦的,PM要召开团队进行讨论,向成员提供与项目相关的所有详细数据,并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式(BRAININGSTORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准。比如我们要结婚了,怎么来分解呢无非是办酒席,拍结婚照,等等,这个在论坛上曾有人做了详细的分解,大家都可以找到。我们说为什么WBS重要,而且大部分项目管理的咨询都是针对WBS的咨询因为WBS做好了,以后工作就有了参考物,你就知道在不同的阶段你应该干什么,完成到什么进度。其实WBS的划分是没有规则的,主要的考虑角度是方便你做各类的统计工作,为管理服务。同样的一个项目其管理的侧重点不同,WBS结构的划分也可能是完全不同的。衡量划分好坏的标准应该是看其是否满足你管理的需要。 甘特图也叫横道图等,很多名称,我们说它是甘特在第一次世界大战时开始使用,它就是在WBS的基础上将WBS形象化老控制进度 对于基准,我举个例子。我们在没有结婚之前,你脚踩几只船?我们说法律允许但道德不允许,但你可以脚踩N只船。但当有一天你和你的朋友进了一个小黑屋子,然后带了两个盖章的本本的时候,你还可以脚踩N只船吗?我们说此时就不允许了,因为你过了一个基准线(BASELINE)如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。那我们的项目要越轨怎么办,也就是项目变更?我们说对这样的项目变更会影响各要素比如时间,成本,质量等。我们应该统一由项目管理办公室来进行控制,如果你要变更基准,必须要进行严格的限制。在客户提出变更请求时,要建立变更申请登记表和变更申请表,并让客户签字。有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要卖面子,但是也别卖的太干脆,不要让他们得到的太容易。PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。 如果一个项目进行过程中,比如现在的点心的3G项目,你发现如果再多花一点时间就可以编写出对以后非常有用处的程序,但这个程序不在本项目范围之内,你要不要做?对,我们说不能做,你可以重新起一个项目来做,但不能在这个项目里做,这样会是我们的项目成本超出,风险增加,而且和其它的项目缺少比对性和参照的价值。 这也是我们说现在有大约80%以上的项目失败的原因,我们说项目失败并不是项目进行不下去了,彻底破产,在PMI有明确的定义,凡是项目的成本超出预算,质量没有得到保证,时间超过预计等等都在失败的范围之内。 这个在华为做的很好,华为有个有名的增量开发的名声。只用20%的功能先满足你80%的需求,其它的功能我可以开发升级的版本,于是就在小数点后平明的增加数字,于是就是了V1,V1.1,V1.11.等版本它从来不一下子满足你所有的需求,我们大家想想,谁没有事情拿出自己的手机把所有的PING码都试用一下,我们说没有,我们大部分的需求是在打电话,发消息,打打游戏,对不对?这点在项目管理中非常重要,请大家结合数据好好研究。 项目干系人是什么东东,谁给我举一个例子?对,包括项目人员的老婆孩子,正确我们说有的项目需要的时间很紧张,如果你的项目成功了,但项目的程序员们都成了光棍,那专案还是非常失败,至少不是丧心病狂的PM这么想。合理解决项目干系人的冲突是个很累的问题,其中还包括你的只能经理们,你的董事长,你的客户,等等,等等,有的说没用?好,如果你的项目进展不下去,你该怎么办?对,开会,把你的高层找一个坐到会议室,不用他说话,只让他暧昧的看着大家,大家一定会想,这个家伙一定和领导有关系,我们还是好好的做这个项目,下一个专案再给他使拌子吧:)所以为了不累死好好分析一下你的项目干系人吧 成成超级浅谈项目管理之三(原创)写到这个我暂时停止,感觉思路有些混乱,我想我重新来过,系统化的讲解项目管理的知识,大家等我一段时间哦 我们上次讲了一些基础的知识,包括什么是项目管理,项目管理包括什么? 你说项目管理有几个知识领域?你说项目管理有几个过程组?让我们想起了泡MM的例子是不是?还有老母亲做QA的比喻几天我们着重强调的是 专案是什么?人们常用“时间”,“资源(或缺乏资源)”,“某种工作努力”,“交付物或者产品”,“综合工程”,“缺乏凌驾其它班组的职权”,以及“预算”来给它下定义。实际上,项目是一种独特的工作努力,即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。首先给大家一个项目的定义,到底什么是项目?根据PMPBOK的定义,项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。这个过程受到时间、人力、资源、成本、质量上的限制项目有几个特征:1.临时性2.独特性3.一次性下面大家告诉我下面哪个是项目:A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂C改建道路D工程材料采购E开发软件包F结婚典礼G寻找拉登有人说是寻找拉登,大家说寻找拉登有明确的结束时间吗?当然我们可以假设寻找拉登50年如果找不到,项目就结束是不是?所以说我们今天不讨论哪个到底是项目,所有的问题都要放到具体的环境下,否则没有意义。 下面大家可以开始提问了。 什么是WBS呢?WBS是工作分解结构,就像一张道路交通图,它能够指引你如何从当前位置到达想去的地方。没有它,你可能就要迷路了。怎样来做一个好的WBS呢?有时候在接受新项目时前无例子可借鉴感觉分解时真困难,因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类,因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解,但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE,muturallyexclusive,collectivelyexhaustive,即相互独立,完全穷尽的原则,也就是现在较流行的说法横向到底,纵向到边,如果分解时坚持了这个原则,我想一定会有Perfect的WBS,其实WBS并非是PMI的真传,只是被PMI起名为WBS,有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度,但WBS确实是做事的核心步骤。做一个WBS需要注意一些什么问题呢?第一级通常与项目生命周期相同(如需求分析,设计,采购,施工)第一级应在项目进一步分解前完成WBS的每一级都是其上一级的片断(Segment)一个工作单元只与一个上层单元相关上层单元的工作内容应该等于其所有直接下层工作单元的总和一个工作单元由一个人负责在整个WBS中使用同一种定义,在整个组织中亦然通过将人员包括进WBS来激励他去完成计划什么是甘特图呢?1.以图形或表格的形式显示活动。2.现在是一种通用的显示进度的方法。3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内 什么是风险呢? 首先问一个问题你们说在一个项目中,初始阶段和结束阶段哪个时候项目的风险大?对,是开始的时候,因为在开始的时候我无数的不可控制的因素。那什么阶段的损失大呢?对,在结束的时候,所以说两者是相反的/所以说在项目的启动阶段成功的可能性最小,风险发生的概率也就最高,但是这时候一旦预计的风险发生了,损失是最小的。想想广州和深圳很多烂尾楼?损失会有多少? 另外我们要明确几个定义:1确定性:具有明显的可能性,比如中国和韩国对抗赛,胜负是很明显的:)2风险: 韩国队能赢中国队几个球是一种风险的预测。3未知性:中国和美国比赛门球那就是未知的。 谁动了我的拇指?我们发现了一种管理理论,它能使被炒了鱿鱼的人感觉良好纽约时报最近刊登的一篇文章尽管看上去很短,对我们这些经商的人来说却很有意义。文章说的是一位名叫丹尼尔普罗文扎诺(Daniel Provenzano)的人,38 岁,住在纽约州的上萨德尔河镇。此人最近被控犯有 44 条罪状,但他只承认欺诈和没有向州里申报所得税这两项罪名。然而,这些偶发事件并不能使该文成为一篇有关管理的重要报道说实话,这种令人吃惊、非同寻常的报道多少年才能见到一次。以下是文章中的相关部分:普罗文扎诺先生说,他当初在利堡拥有一家名叫 Advice Inc. 的印刷公司时,发现他聘请的一名销售代理贪污了 9,000 美元。普罗文扎诺先生说,他告诉那人“如果他想保住工作,我就得折断他的拇指。”他说,公司的另一名雇员开车把那位销售代表拉到蒂内克的圣名医院(Holy Name),在医院外面用锤子敲折了那人的拇指,等医生给他接上断指后,又叫车把他送回家。普罗文扎诺先生解释说,他“不想开一个先例,”偷钱的雇员必须受到惩罚。他说,那名雇员最后退还了 4,500 美元,并且保住了工作。我知道诸位心里在想什麽:这是犯法行为。我也感到震惊,因为普罗文扎诺被提起公诉的罪状是他那种狡猾的管理方法。说实在的,我倒觉得他那个“小小的建议”对于企业经理们来说大有教益,因为他们无不为在我们这个以人为本的经营环境里出现的问题而挠头,比如如何对付 10% 表现最差的雇员。使这项制度闻名于世的是通用电气公司(GE),而且许多公司都在实行:每年解雇评估结果最差的工人。尽管不少经理人反对这样做,认为这太不人道,可是,不处理 10% 表现最差的雇员会引起经营业绩上的大问题。普罗文扎诺发现了一个更加仁慈、温和的办法。要是换了别的公司,那名雇员的下场只有被炒鱿鱼。可是在 Advice 公司,他却保住了工作。你认为后来会怎样?我敢肯定他现在是个工作非常、非常出色的雇员。对于大多数经理来说,普罗文扎诺的创举会成为他们管理手段中一个很受青睐的新内容。顺便说一句,在 Advice 公司,“管理手段”显然不只是一句空话。 如何成为杰出的雇主。由于顶尖人才处处难觅,大多数公司如今都想成为所在行业或地区最为人称道的雇主。Advice 公司早就明白这一点。那个有过失的雇员并没有在上司的办公室里受到处罚并且被打发回家了事。只有平庸的雇主才会这样做。在 Advice 公司,另一名雇员也许是人事经理?从百忙中抽出时间开车送那人直奔急诊室。然后 该文原原本本地都说了公司叫车把那人送回了家。这等于向正在求职的人才传递了一个明白无误的信息:Advice 是一家悲天悯人的公司。 如何给别人树立榜样。经理们永远会面临的一个问题是,如何使全体雇员明白,表现特别好或特别坏的人会有什么后果。有几家公司确实把每个人的工资和奖金都公布在内联网上了。可是,报酬只能反映出一个方面。在 Advice 公司,一个在大多数公司里几乎不会被人提起的问题贪污几个星期来无疑成了大家挂在嘴边的话题,至少一直持续到那名雇员拇指上的石膏被取掉之后。而且,雇员的偷盗行为很可能会越来越少。 了不起的罗伯托戈伊苏埃塔(Roberto Goizueta)在担任可口可乐公司首席执行官期间经常谈起如何树立榜样的问题。有一回他说:“有时你不得不在广场上搞一次杀一儆百的活动!”当然,他只是在打比方。他假如能说到做到,也许会是成为更加出色的首席执行官。 如何区别对待雇员。这是杰克韦尔奇(Jack Welch)最喜欢的理念之一,那就是经理应当根据雇员的不同表现给予完全不同的待遇。韦尔奇喜欢用工资、奖金和优先购股权来体现这些差异,但必须知道的是,由于现在是后普罗文扎诺管理时代,可以看出,这位通用电气公司管理思想大师的想象力还不够丰富。纽约时报的这篇文章既引人入胜,又令人气馁。它用寥寥数语便开辟了一个全新的管理视野,但是没说的话肯定更多。我们必须敦促普罗文扎诺动手写一本书,完整地解释他的管理思想。写书可不是一件轻而易举的事,不过他会有很多时间的,而且几乎不会受到任何打扰多亏了这次诉讼,他要坐上十年左右的牢。项目管理注意事项一、引言软件行业从20世纪60年代开始操作系统的研发,到20世纪90年代中期行业快速发展。从原有的作坊式开发到目前团队协作完成,从早期的技术力量竞争到现有的项目成本控制竞争,从面向结构到面向对象再到面向服务架构,项目管理被提到一定的高度,如何有效的经营项目来降低风险、控制成本,确保项目进度流畅,在有效的时间内保质、保量的完成验收。成为不少项目管理人士的追求目标。结合个人项目管理实践,本人有几点管理注意事项与大家一起分享。二、项目管理注意事项开发模型确定一个项目的好坏,开发模型优良是项目成功重要保障,有了好的开发模型我们可以很好的控制项目进度、降低风险。所以我们在项目开始前首先需要确定项目的开发模型。这里我们建议采用迭代式的开发模型。我们知道原有早期传统的开发模型是一个文档驱动的流程,它将整个软件开发过程划分为顺序相接的几个阶段,每个阶段都必需完成全部规定的任务后才能够进入下一个阶段。项目开始首先完成系统需求规格说明书,之后才能够进入概要设计阶段,编码则在系统设计完成之后进行。这就意味着只有当所有的系统模块全部开发完成之后,我们才进行系统集成,对于一个由很多个模块组的复杂系统来说,这是一个非常艰巨而漫长的工作,且存在着潜在的风险。如:需求或者设计中的错误无法在项目早期发现,只有在系统交付客户之后才能发现原先对于需求的理解是错误的,系统设计的错误也只有在测试阶段才能被发现。对于项目风险的控制能力较弱,往往项目风险只能随着项目结束才能逐步降低,同时也只有经过系统测试之后,才能确定设计是否能够真正满足系统需求。软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱,需要进行返工或其他一些额外的开发周期,造成项目延期或费用超支。项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的,当他回答系统已完成了80%的开发任务时,剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。 在传统的瀑布模型中,早期是无法发现,需求和设计中的问题,只有当系统第一次集成后,这些设计缺陷才会在测试中暴露出来,需求缺陷则需要等到系统与用户见面后,方可暴露。从而导致一系列的返工:重新设计、编码、测试,进而导致项目的延期和开发成本的上升。为了解决传统软件开发流程中的问题,我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中,我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中,我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标,这些小目标都有一个明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动,在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划,整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布和产品交付等各种类型的开发活动,迭代完成之后需要对迭代完成的结果进行评估,并以此为依据来制定下一次迭代的目标。开发计划制定确定好项目的开发模型,一整套配套可行的项目开发计划是开发过程中进度控制的标准,同样是用户、公司管理层了解项目进展的依据。通常项目管理人员、需求人员和用户根据用户原始需求(可以是项目方案书或者是建议书),一起定义整个项目过程中的项目迭代过程个数以及每个迭代过程的开发目标和范围。如何进行迭代过程的划分和范围有效定义呢?是我们迭代开发计划制定的首要任务,我们这里推荐两种划分原则,一、用户需求至上原则,也就是根据用户需求的优先级,进行逐个模块击破,每一个迭代是用户需求一个的模块,当然模块小时或者人员充足时,也是在一个迭代中完成两个或者三个模块。二、当用户需求没有鲜明优先级时,我们可以采用功能逐步求精开发法,类似于我们早期采用快速原型开发,划分多个迭代,确定每个迭代需要达到的功能的完善层次,例如,首先第一个迭代仅完成系统的原型开发,第二迭代则紧接着完成各业务基本功能,然后逐步完善直至满足用户需求。无论怎样划分我们的迭代过程,总之需要把握一个原则,框架尽早规划,版本快速集成。项目只要进入软件实现过程早期,建议实现周版本的概念,确保一周一个版本,一来方便项目管理人员了解项目进度、质量,从而根据前期项目完成情况和近期的用户需求变动及时调整计划。二来可以尽早将系统与用户见面,及时发现对于用户需求理解不正确之处,同时还可以激发用户潜在需求,细化需求。在软件实现过程后期,则可以根据需要调整集成版本频率。所以,虽然每个迭代开发过程中的开发活动是可以选择性的裁减,但通常软件实现、版本集成和软件测试是每个迭代不可缺少的活动,否则迭代过程将失去它的含义。迭代过程个数和范围确定后,则需要与每个迭代过程中的开发活动相关者协商讨论进度安排,先明确各开发活动的起始、截至时间,然后在根据开发活动的具体需求进行任务细化。如果希望能将项目进度控制在计划之中,任务越细越好,每个任务跨度不要太大,一天一个任务最好。当然这种情况是很能实现的。确实,我这里说的是一种比较理想的情况,但并不是不可能。在这里我们就可以了解到迭代开发计划给我们带来的好处。项目开始了需求通常都是很泛,不太明确。与用户交流,可能他认为自己已经表达了所有需要。实际也许他确实已经充分描述了他所知道的需求(业务需求),但完善我们的系统,除了基本业务需求外还有很多非功能性需求,比如:系统性能需求、界面显示需求、系统操作流程需求等等,尤其是目前B/S架构的开发模式,界面需求已经越显示出它的重要性。而这些需求在项目早期,在没有任何可见事务的情况下,用户很难意识到它的重要性。我们只有逐个迭代的细化,每一个迭代过程完成既是需求进一步细化的依据又是一个新系统的开始,每个迭代开始前都要根据上个迭代的成果和所要达到的阶段性目标细化定制。组内成员配置项目启动之前除项目管理者着手计划制定外,同时也需要对其项目组那成员配置进行规划,界定其职责。通常我们需

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论