??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
被问的时候,可能目才定下来Q仅仅知道大概的功能模块Q非功能性需求还模糊不清Q甚臛_队成员都没到位。但是上U、销售、客h切地要知道Q这个项目什么时候才能完成?
被问的时候,也可能项目已临近l束Q或者说临近当初计划的交付日期。然而待完成的功能还有一堆,试出来的bug有一大堆Q客户又提出了新的需求,团队正有职 …。但是上U、销售、客户非常急切地要知道Q这个项目到底什么时候才能完成?
q还不算p糕。更头疼的问题是Q?#8220;再有三周Q项目应该完成了吧?”
因ؓ后者根本不是问题,而是命o。项目经理必要能够合理解释Z么三周不能够完成目Q或者说明在三周内,能够完成什么?/p>
我们都用qMS ProjectQ?但是那上面的漂亮表格对这L困境毫无帮助。相反,正是Project 中的甘特囑֒日程表,埋下了陷阱。因为,在Project 中无法预估需要多工作日才能完成模糊不清的需求,也无法体现实际情况发生变化后对进度的影响?/p>
当我们讨度的时候,其实包含了两个未知的变量。第一是完成需求所要的工作量,包括需求定义、开发内容边界;W二是团队的工作能力Q包括成员的行业知识专业技能,成员之间、成员和外部的沟通能力,{等?/p>
关键在于,q两w是变量。如果Q务是搬一千块砖头Q每分钟每h能搬10块,那么l果是显而易见的?/p>
在敏捷开发中Q采用相对估和q代求精的方法来处理目q度的问题?/span>
首先是工作量。用估算代码行数或者界面元素的方式Q就像论斤卖书一P只适用于粗制滥造的软g生q程。用户需要的q不是代码或者按钮,而是可靠易用的功能?/p>
在敏捷开发方式中Q先q户和设计人员_略估计各个功能模块的相对规模和隑ֺQ给Z定的分倹{分g代表具体人月Qv相对比较的作用。例如有查询、显C、修改三个模块,如果实现昄模块的工作量?0分,那么查询模块可能?5分,而修改ؓ20分?/p>
下一步,选择一个工作量估分最低的模块Q例如这里是昄模块Q然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询,昄内容{等。假设这轮估得出此模块需?0人天Q从而得出单位分值对应的人天?Q那么,整个目需?5人天?/p>
q个估算建立在对目的初步了解上Q主要依赖项目经理的l验。有偏差Q没关系。接下来通过q代来求_。先来实现显C模块,如果事实上花费了12人天Q那么根据比例关p,剩余内容的估大U就?2人天?/p>
当然Q比例关pM不是一成不变的。随着模块的逐个完成Q项目经理对目的认识也在加深,他可以再调整剩余模块的相对分倹{?/p>
在实际操作中Q项目经理首先按照优先排列功能模块。然后把高优先的模块尽可能地细分,再选择分值最的模块开始开发。统计d作量Ӟ按比例篏加其他模块的工作量,q加一定的调整pLQ因为模块的复杂度不是线性增长的。每ơP代开发完成后Q逐步降低调整pL。通常4~5ơP代后Q可以将调整pL归零?/p>
在上面的例子中,W一ơ估的初步l果?5人天Q因为完全是凭经验,因此要给较大的调整系敎ͼ比如?.4Q因此给出的估算工作量区间ؓ[45*0.6,45*1.4],?7?3人天之间。ؓ保险赯Q项目经理上报的工作量ؓ70人天?/p>
W二ơ估,剩余内容的初步估ؓ42Q调整系C降ؓ0.3Q因此给Z区间ؓ30?0人天之间。依此类推,通过不断q代Q对剩余工作量的估算越来越_?/p>
q样估算的好处在哪里Q?/strong>
首先Q工作量变量的很大一部分因素Q存在于非功能需求,例如界面的美观程度。而同一目的不同模块之_非功能需求往往是一致的Q相对估法qo了这一层复杂度。团队能力这一变量因素也是如此。当Ӟ随着目的进展,成员的开发能力应该有一定的上升Q但随着加班出差{因素,投入E度也可能下降,因而会怺抉|。M在周?个月以内的项目中Q很出现团队工作能力戏剧性变化的情Ş。因此相对估也qo了这个复杂度?/p>
其次QP代求_方式让项目经理对估算旉更有把握。最初出现偏差是必然的,但只要团队稳定,没有大的需求变动,估算范围迅速收~。这比一ơ性报数更准确?/p>
它的额外好处是,敏捷开发是遵@优先U的Q即使对剩余旉Q即低优先模块的开发时_的估不十分准确Q媄响也不是非常大?
Ҏ一下甘特图方式Q在开发初期就要把各个模块的开发时间估出来以l计总量Q这是瀑布开发的模式?
q度问题的另一斚wQ是目l理如何了解团队以及每个开发h员的开发速度。当d分配之后Q项目经理如何做到心中有敎ͼ估算d实际完成旉?/p>
敏捷开发过E中Q由开发h员自己来估算完成该Q务所需要的旉。当Ӟ每个人的能力不同Q每个h的心态也不同Q有的h保守Q有的h乐观。没关系Q还是靠q代来逐步求精?/p>
在每天的例会上,开发h员被要求对当前Q务的剩余开发时间做重估。不同于Project l计每h每天在Q务中p了多时_敏捷方式只关心这Q务还需要多时间去完成Q直到归Ӟ然后再来l计实际的工作时间?/p>
Z么?因ؓl计开发过E中的花Ҏ间是毫无意义的。这和搬砖头不同Q也许昨天用?个小时没有一点进展,今天一旦想通了׃半功倍。我们真正关心的Q就是到底还需要多时间来完成dQ而不是已l花Ҏ不可恢复的时间成本?/p>
在每天例会中Q项目经理需要注意时间曲U保持水q的成员Q他是不是遇到瓶颈了Q是否需求帮助?也要留意旉曲线下降q度q大的成员,他发C什么好的办法,有没有低估需求?q样Q项目经理会更面向结果,只要按计划保证质量完成Q务就行,成员到底׃多少旉是个人的事。传l做法记录每个h每天的工作内容,W一是因J琐而失真。其ơ,一旦上U发现某人工作时间不够(即便他完成了dQ,忍不住会z新dQ从而造成干z越多,反过来打ȝ序员的积极性?/p>
敏捷估算的关键之处,是把成员能力q个变量的估,交给最合适的人去做,即程序员本h。然后通过比较历次q代时的预估和实际时_l出校正pLQ以避免E序员过于保守或q于乐观。这肯定不是l对准确的,但效果往往比项目经理自己拍脑袋估算Q然后强行指定deadline 要好得多?/p>
在敏捷开发中Q做计划比计划本w更重要。项目经理需要时d前考虑Q考虑各种动态因素,而不是死报着计划本n。在q度估算的时候,目l理应该在不同阶D,Ҏ实际情况Q给出合乎情理的回答?/p>
转蝲自:http://yale.javaeye.com/blog/966689
Java目开发过E中Q由于开发h员的l验、Java代码~写习惯Q以及缺乏统一的标准和理程Q往往D整个目的代码质量较差,难于l?护,需要较大的试投入和周期等问题。这些问题在一个项目组初徏、需求和设计均具有不完全可预期性和完备性的全新目中将ؓH出?/p>
如图1所C,敏捷开发过E经历需求调研,用例分析和用例分解,q入开发P代阶Dc在每个q代q程中,可以采用以下步骤来保证和提高整个目的代 码质量:l一~码规范、代码样?静态代码分?staticcodereview);单元试;持箋集成;代码评审和重?(Review&Refactor)。下文将针对每个步骤和其所使用的工兗方法进行详l描q?/p>
?.敏捷开发中的Java代码质量保证步骤
步骤一Q统一~码规范、代码样?/strong>
规范l一的编码会增加目代码的可L和可维护性,但实际情况往往是项目组内的Java代码开发h员的~码风格常常各不相同Q这可能是由于不?的经验习惯或者缺乏编码规范方面的学习造成的。这样一来,其他目成员或者维护h员在阅读目代码时就需要花Ҏ多的旉来理解代码作者的意图Q所以制?q取统一的编码规范就昑־很重要。编码规范主要应包含以下几个斚wQ?/p>
◆一般规则和格式规范。例如代码羃q、程序块规范、每行最大代码长度等?/p>
◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范
◆文档规范。例如类文g头声明、类注释、成员变量和Ҏ注释{规范?/p>
◆编E规范。例如异常、ƈ发、多U程{方面的处理方式?/p>
◆其他规范。例如日志格式、属性文件格式,q回值和消息格式?/p>
目的编码规范可以参考已有的一些Java~程规范书籍和其他相兌料ƈl合目的本w来制定Q可供参考的书籍有《Java~程风格?英文?名ؓQTheElementsofJavaStyle)。编码规范要形成文档Q而且要简z明了,q组l项目成员一起学习,保所有成员正理解所有条目?/p>
一旦编码规范确定,可以利用Eclipse自n提供的功能来控制代码样式和格式。具体做法是Q点击Eclipse?Windows->Preference菜单,在打开的Preferences对话框的左侧栏中扑ֈJava节点下的子项CodeStyle(如图2)Q该?和它的子允许您对Java代码的样式进行控制?/p>
?.Eclipse代码样式讄H口
例如Qؓ了用自动格式化工具Q可以在Eclipse提供的默认代码格式配|的基础上徏立自定义的格式。在Formatter面板中,点击 NewQ输入新的名字ƈ选择一个默认的配置作ؓ初始化格式,如图3所C?/p>
?.创徏新的代码格式配置
单击OK后就可以在新打开的窗口中q行修改定制自己需要的格式。如?所C?/p>
?.创徏新的代码格式配置
修改完成后点击Apply保存所作修攏V同时可以点击Export当前的格式定义导出成一个XML文gQ这样项目组的其他成员就可以很方侉K?q点d3中的Import按钮来导入该XML文g来用同一个代码格式定义?/p>
q样每次在提交代码到版本控制服务?/span>前就可以通过Eclipse界面里的Source->Format菜单来对代码q行格式化,从?使整个项目的代码h相同的格式。同样可以通过对CodeStyle下的其他目q行讄来帮助对Java代码的样式进行控制。将所有这些样式文件导出成 XML文g后,同编码规范一起归档,供所有项目成员用?/p>
步骤二:静态代码分?/strong> 在完成源代码的开发以后,下面要进行的工作是审视和测试代码。除了通过q行试代码来检查功能之外,q能利用一些静态分析工h快速、直接地 提高代码质量。静态代码分析工具ƈ不需要运行代码,可以直接对Java文g和Class文gq行分析Q通过一些检查条件的讄Q快速找C码中的错误和?在缺陗现在的静态分析工具很多,有FindBugs、PMD、IBMRationalToolQ等{。在q里Q选择FindBugs作ؓ静态代码分析工 兗FindBugs可以和日常开发工具Eclipseq行集成Q在开发过E中Q就可以方便的开始静态代码的查。通过查Class文g或者JAR?Ӟ字节码和一l缺h式进行对比,来发现可能存在的代码问题。在Eclipse的开发环境中Q用插g安装的方式安装了Findbugs后,?Eclipse的配|选项中就会多出来FindBugs的配|选项。可以对自己的项目进行配|,选择需要的Detector查代码?/p>
?.FindBugs的配|选项 讄好自q规则后,在需要检查的代码文g夹上点击右键Q就可以启动FindBugs查。代码可以是一个项目,也可以只是几个文件?/p>
?.q行FindBugs 查完毕后Q会出现FindBugs视图Q把所有检查的l果Ҏ错误分组展示。点ȝ果里面的每一个错误,会自动打开对应的代码。当Ҏ规则?正了所有的错误Q或者说潜在错误Q这些代码也通过了静态代码检查。FindBugs的检查结果可以是XML文gQ也可以是文本文Ӟ便于目的集成管?和检查保存?/p>
?.FindBugs查结?/p>
步骤三:单元试 单元试用例设计和评?/strong> 单元试是Y件开发过E中重要的质量保证环节,在此环节中,设计和评审对于保证整个单元测试过E的完整性和有效性来说十分重要。设计阶D需要具 体考虑要对哪些代码单元q行试Q被单元之间的关系Q测试策略,以及单元试用例设计{,q最l输出《单元测试用例设计》文档,用来指导具体的单元测?执行。在用例设计中,通过对代码单元输入和期待输出的定义来保证该单元的功能正确性,边界值的试和异常测试非帔R要。同时也配合试用例和功能块的匹?Ҏ来衡量用例设计的完整性?/p>
在用例设计完成之后,下一步的工作是q行试用例的评审。个人的理解和经验始l是有限的,用例评审可以借集体之力,对用例设计进入查漏补~, q一步保证测试用例的有效性。由于单元测试属于白盒测试范_它主要通过对代码的逻辑l构q行分析来设计测试用例,因此Q评审员的选择最好以理解代码逻辑 l构为前提,如果评审员来自相?a class="fllink" target="_blank">模块Q还能够有效的发现模块相x和依赖性所带来的问题?/p>
模拟对象技?/strong> 在实际项目中Q开发h员自q代码往往需要和其他的代码模块或pȝq行交互Q但在测试的q程中,q些需要被调用的真实对象常常很难被实例化,?者这些对象在某些情况下无法被用来试Q例如,真实对象的行为无法预,真实对象的行为难以触发,或者真实对象的q行速度很慢。这时候,需要用模拟对 象技?Mock)Q利用一个模拟对象来模拟我们的代码所依赖的真实对象,来帮助完成测试,提高试覆盖率,从而提高代码质量。模拟对象技术利用了在面?接口的编E中Q由于代码直接对接口q行调用Q所以代码ƈ不知道引用的是真实对象还是模拟对象,q样可以顺利的完成对代码的试Q模拟技术有很多U,?jMockQEasyMockQMockitoQPowerMock{等。其中Mockito消除了对期望行ؓ的需求,避免了这些代码的大量初始化?/p>
?.MockitoCZ 在模拟对象过E中Q先模拟一个需要调用的List对象LinkedListQ再讑֮q个对象的行为,当调用get(0)的时候,q??#8221;first”。这P试代码可以利用这个对象来试我们的功能代码,需要调用和q回值的时候,可以利的得到模拟对象的q回倹{也需要对模拟对象 q行错误情况的模拟,保证代码寚w误的处理的正性?/p>
试覆盖率分?/strong> Z衡量单元试的质量和覆盖的范_需要对单元试的代码进行测试覆盖分析。常用的衡量试覆盖率的指标主要有语句覆盖率、分支覆盖率、\?覆盖率、条件覆盖率和方法覆盖率{。具体采用哪些指标可以根据项目的实际情况来定Q以避免因过高的指标增加了代码开发h员的工作量而媄响了目整体的进 度?/p>
EMMA是一ƾ比较流行的开源Java试覆盖率分析工P支持cR方法、代码行、基本代码块{多U类型的试覆盖率分析,支持覆盖率分析l?果导Zؓ多种格式的报告,q用多U颜色来高亮昄不同的覆盖率状态。EclEmma是一Ƒ֟于EMMA的Eclipse插gQ方便在 EclipseIDE中进行测试覆盖率分析。如?Q在试用例写好后,可以在右键点L试类Q选择CoverageAs->JUnitTest?/p>
?.q行试覆盖分析 单元试跑完后,Coverage视图中会昄所选择的测试的覆盖率。双L开某一具体的类后,可以看到高亮昄的覆盖分析结果,如图10所 C。红色代表测试没有覆盖到该行Q黄色表C部分覆盖,l色的行表示该行在本ơ测试中被覆盖到?/p>
?0.查看试覆盖分析l果 在Coverage视图中可以通过点击鼠标右键测试覆盖分析的l果导出成需要的格式Q例如HTML?/p>
?1.导出试覆盖分析l果 ?2昄了导出的report?/p>
?2.试覆盖分析报告 Z保证单元试的有效性和质量Q可以规定一个测试覆盖率的下限,例如所有的包和cȝ覆盖率必达?0%以上。不q值得注意的是Q不要单U追 求高覆盖率,要同时注意测试用例的质量Q如果测试用例本w就写的有错误,那么即ɋ试覆盖率很高也没有意义?/p>
步骤四:持箋集成 持箋集成(ContinuousIntegration)是利用一pd的工PҎ和规则,做到快速的构徏开发代码,自动的测试化Q来提高开?代码的效率和质量。利用自动构建工P随时都能把提交的代码构徏出来Q提供一个可以测试用的版本Q让用户和开发h员同时看到相同的功能Q尽早的发现问题 和错误,也可以尽快的得到试人员和用L反馈?/p>
要做到持l集成,p利用一pd工具Q把开发过E中的重复工?a class="fllink" target="_blank">自动?/a>。搭动的构徏服务?/a>Q?自动的进行单元测试和发布新版本,一个集成的服务器可以提供构E的l果报告Q自动通知开发h员构建结果,q且保存历史数据?IBMRationalTeamConcert(RTC)可以提供工作d的管理,目计划的安排,代码版本理控制Q自动构建可用版本,生成构徏l果?告。这些过E构成了目的持l集成过E,其中Q版本的自动构徏和代码的自动单元试是持l集成的关键q程QRTC在这些过E上提供了有力的支持?/p>
自动构徏 RTC提供了buildengine来负责构建buildQ首选,启动buildengineQƈ和RTC服务器徏立了q接。再创徏目?build定义。在q个定义中,需要设定编译哪?a class="fllink" target="_blank">模块 可以看到Q通过在build定义上,点击h构徏Q就可以触发一ơ构E。选择需要的构徏参数Q这个过E就会在后台q行。每一个开发h员,?了稍许的代码改变和提交,都可以触发新的构E,来保证我们代码的有效性。申请一个新的构建的q程如图13、图14所C?/p>
?3.甌一个新的构?/p>
?4.构徏甌界面 当构建结束后。RTC服务器会提供构徏l果报告。开发h员可以查询到q次构徏的详l信息?/p>
?5.构徏l果 整个开发过E中Q构建版本的q程应该是无数次的,通过每次构徏Q都可以得到当时代码的编译情况,q且可以得到一个可q行的Y件版本。在构徏定义 上,RTC支持讄构徏计划。定时自动的触发一ơ构建?/p>
?6.构徏定义 自动单元试 构徏可以自动了,重点提高代码质量的单元测试呢Q如果每一天的代码Q每一个版本的代码Q都已经通过了我们的单元试Q这h们就能对代码的质?有了基本的保证。在构徏脚本的自动调用过E中Q通过ANT的脚本,可以加上JUnitQEMMAQFindBugs的ANT脚本调用Q每一ơ的构徏Q都?以把q些查工作自动的q行一遍测试。这些测试都要生成测试结果报告,RTC不能提供q些报告的展C,可以利用Hudsonq个开源工P集成试报告 来方便查阅?/p>
?7.自动试报告 步骤五:代码评审和重?/strong> 代码评审(CodeReview)是Java目开发过E中的一个重要步骤,代码评审可以帮助发现静态代码分析过E中无法发现的一些问题,例如 代码的编写是否符合编码规范,代码在逻辑上或者功能上是否存在错误Q代码在执行效率和性能上是否有需要改q的地方Q代码的注释是否完整正确Q代码是否存?冗余和重复。代码评审还可以帮助新进入项目组的成员快速学习和了解目Q促q经验分享,同时也能保证目成员的良好沟通。代码评审主要包括两UŞ式,同 评审(PeerReview)和小l评?GroupReview)。同U评审主要指目成员间的互相评审Q小l评审是指通过召开评审会议Q项目成员一?寚w目代码进行评审?/p>
Z提高代码评审的有效性和效率Q可以借助一些外部工P比较常用的代码评审工hJupiter和CodeStriker。Jupiter?一Ƒּ源的Eclipse插gQ允许成员将评审意见定位到真实代码的具体行,׃代码评审的结果以XML文g的Ş式保存,所以可以把l果提交到版本管?a class="fllink" target="_blank">服务?/a>q?行共享。图18昄了用Jupiterq行代码评审的界面?/p>
?8.Jupiter代码评审界面 在代码评审Q务创建后QJupiter代码评审分成三个阶D,个h评审阶段(IndividualPhase)、团队评审阶D?(TeamPhase)和问题修复阶D?ReworkPhase)。在个h评审阶段Q评审成员将发现的代码问题或者缺陯录下来,每个问题都会作ؓ一个记 录保存在评审表格中。在团队评审阶段Q团队的全部或者部分成员会一起对个h评审阶段发现的问题进行定性,如果问题实存在Q就该问题分配l某个成员去?冻Iq在Jupiter中将该问题设|成相应的状态。在问题修复阶段Q团队成员会修复属于自己的问题,q将相应的记录设|成已解决等正确的状态?/p>
Codestriker是一Ƒ֟于Web的常用代码评审工P对代码的评审可以针对某一具体行,也可以针Ҏ个代码文Ӟ评审意见会被保存?a class="fllink" target="_blank">数据?/a>中。评审h员可以同时看到其他h的评论,代码作者也可以针对某一具体的评 论回复。Codestriker支持邮g通知Q还可以同版本控制服务器q行集成Q以跟踪和显C文件内容的改变。图19昄了Codestriker的界 面?/p>
?9.Codestriker报告界面 在实践中Ҏ有代码进行小l评审会比较ҎQ所以可以根据实际情冉|挑选一些核心代码进行小l评审,或者在目的前期安排较多的组评审Q等?目组的成员对代码评审的标准和要求有较好的理解Q进行代码评审的l验提高后,可以逐渐减少组评审的次敎ͼ从而达到大部分代码即只进行同U评审也能保 证很好的质量?/p>
通过代码评审发现的问题要通过代码重构及时解决掉,较小的不涉及多h代码的重构可以由目成员自己借助Eclipse的重构功能完成,不同目 成员写的实现相同功能的不同代码要通过讨论整合成公qcL者方法。比较复杂的或者比较高层次的重构工作,例如整个目层面的代码组lŞ式的改变需要由?个项目组共同讨论完成?/p>
l论 软g开发没有一成不变、万能通用的流E和ҎQ希望大家能从本文得到启发和收益Q结合您的实际项目特点,实践以上步骤和方法,q加以完善和?q,共同打造高效高质量的Java代码Qؓ您的目成功奠定坚实的基?/p>
错误一Q错误的需求调研阶D,D很多目永远无法l束!
在Y件行业,在界面设计没有正式展现给客户之前Q所有的工作都处于需求调研阶Dc其实徏{行业已l给我们做好了先例:客户买房子之前是先要看看h 房和模型的,什么都看不到这房子你敢C?除非你不是自׃!
而在我们所学的软g工程概念模型中,q是三个阶段Q需求调研、需求分析、概要设计?/p>
在客h他们惌理的业务模块以及与之相关的业务数据Q流E,表单交付你的时候,你千万不要把q个阶段定性ؓ需要调研结束,写出《需要规D?书》就可以了。大量的实践证明Q在概要设计阶段所衍生出来的需求工作量是之前的5~10倍,甚至更多Q因要看设计人员的业务沟通能力和建模水^?/p>
有实施经验比较丰富的目理人员ȝ_在中国实施Y仉目,必须以咨询方式展开Q要推出自己的方案,而不能完全按照客h提需求作目。这是一 U很好的解决思\Q但无法解决所有实施项目的N。这U解x案的前提Q要么项目实施者有成熟的业务模型,要么有成熟的产品(包含了成熟的业务模型)Q否 则是不可能做到的。但如果没有3~5q在同一行业Q同一领域的实施经验和理论ȝQ没有哪家IT企业能达到这L前提要求?/p>
其实得出q样l论的深层原因,是因为国内多C业管理思想不成熟,更谈不上完善的业务模型,所以客L思维一定程度是发散的,q未形成pȝ。甚臌 有些客户的领|脑子中有很多新鲜的点子,他都有可能想在企业信息化的实施过E中加进来,q对把控目范围和项目实施效果来_都可能是N的开始?/p>
所以,要做好实施项目,实施者必L很好的业务徏模能力,快速的l客户展C合理的软g原型软gDemo?/p>
误住:软g实施目Q一定要l用L到样板房软gDemoQ才需求调研结?
错误二:IT技术h员不需要掌握项目管?/strong>
有这U看法的Z在少数。根据观察,之所以Ş成这U看法,一是对目的真正概念不清晰Q二是对理的概능话了Q把理理解成了高深莫测Q非一般h 能做的事情。首先有必要普及一下项目的概念?/p>
寚w目有很多Zq定义,目理圣经PMBOKW三?2004?的定义是Qؓ创造某个独特的产品或服务,或完成某独特的Q务所做的临时性努 力。围l这句话PMBOK做了详细的解释和举例说明Q很严}Q想了解的请学习PMBOK。因为都是翻译过来的定义Q翻译得q于术语化很Ҏ把hl进去,?国内不排除已l拿到PMP认证证书的专业h士还搞不清楚目I竟是什么。笔者在q里只想用汉语最通俗的语a来说明什么是目和项目管理?/p>
目Q就是在限定的时间要人完成的事。记住三个关键字卛_把握Qh、时、事?/p>
目理是参与者用什?知识、技能、工兗方?来圆满地q好qg事?/p>
明白了这些,你就会明白从日常生活的吃喝拉撒到国家理Q处处都是项目,处处都需要项目管理,也就能明白每个h都需要项目管理,也就能理解学会了?目管理将会多么受益无IP娴熟q用目理思维无往不胜!
但需要提醒大家一点,现在的PMBOK是把传统刉行业、徏{行业、IT行业{多个行业领域的目理知识p合C一P大而全Q但针对性不够好Q?所以很多h觉得PMBOK理论化太强,学完了觉得很多东西没用。现在国际知名的另外一套项目管理认证,IPMP是按照工作岗位能力进行了分Q也没有针对 行业q行分解。所以,无论拿到PMP或者IPMPQ很多h都会有同L困惑。据了解QPMI已经准备做这L改进Q这是一个很好的消息?/p>
错误三:忘记目目标
你看到这个题目什么感?很多Z觉得q样的错误怎么会发?几乎没有Z认ؓ自己犯这个错?忘记目目标有两U情形:一是从开始接手项目就没弄 清楚目的目标是什?二是虽然清楚目的目标是什么,但却q着跟完成项目目标无兟뀁甚x害的事?/p>
时刻铭记目目标是项目管理很重要的一个思维Q项目所有的zd都围l这个展开。可是随着目的逐步开展,其是复杂项目:人多、事多、周期长Q很?目l理会逐渐因ؓ个h喜好而忘C目的大目标Q比较典型的有:技术出w的目l理会沉q于技术细节,大量旉花在学习新技术或者一头闷在解x术难??脾气火爆的项目经理会因ؓ很多不值当的事情大发脾气,把团队搞得乌烟瘴?心眹{爱面子的项目经理会因ؓ某个l员无意的顶撞而怀恨在心,从此ȝ?I小鞋,搞得团队拉帮l派Q毫不团l?q有更糟p的Q比如爱玩游戏的Q爱喝小酒的{等。所有这些,无论原因是自w不成熟Q还是管理经验、管理能力不Il?果都一P那就是项目出问题Q甚臛_败?/p>
目l理最重要的一Q务就是跟t与控制Q时L握项目方向,保证目计划得以利执行Q偏差控制在可控风险范围内。但目L有太多意外因素,?其是周期长的目Qh们常用夜长梦多来形容风险会随旉的g长而增加,所以项目经理一定时刻都要保持头脑清醒,寚w目无益的事情不做Q对目有风险的事情 更不能做?/p>
M目在开展过E中都会不断面对Z和诱惑,目l理一定要能明项目大目标Q才能清晰地识别哪些是ə目成功的机会,哪些是会l项目带来风险的 诱惑Q才会少走弯路,早日成功。项目管理者联盟,目理问题?/p>
人是需要不断被提醒的,q由人性决定。智慧的够不断的反省从而自我提醒,愚笨的h会被挫折、外界的警示不断提醒Q这Ş成了成功与失败的差异?/p>
错误四:计划不能?/strong>
怎样才能保证目成功?计划Q计划,再计划,q是目理的最佛_?所以,做项目管理的一般都知道如何~制目计划Qƈ且很多h能熟l的使用 Project工具Q知?0时或?0时法则、WBS和关键\径的概念。每个项目经理都会记住计划一旦Ş成,׃格按照计划去执行Q而不受某个h?某g事的影响q个原则Q也明白q样做不仅能够减大量资源的费Q品的质量也能得到保障。所以,很多目l理排斥Q甚xl改变计划。坚持原则,q貌?没什么错Q但真的q样?
要弄清楚一件事是否有必要做Q首先就得弄清楚两个问题Q一、这件事Z么要?二、做了有什么好?
那我们首先问一下编制计划的目的是什?我们知道计划是项目管理的最佛_践,计划是保证项目成功的一U手D和ҎQ做qg事只有一个目的,那就是ؓ 了保证项目成功,但前提是Q这份计划是周密的、可行的。严格执行一份周密可行的目计划才能保证目成功。很多项目经理记住了上面的严格执行原则,但忘?了这个大前提?/p>
W二个问题,计划有什么好?目理的计划方法,把项目活动、持l时间、所需资源有机地结合在一Pq且有严格的先后ơ序、里E碑和关键\径,?以清晰地提醒目所有成员在什么时_做什么事情,保证每个目d都得以执?通过对计划的执行跟踪Q项目经理可以清晰地了解目q展情况和偏差情况, 评估q及时有效的控制目风险Q从而保证项目的成功?/p>
明白了这两点Q我们再来看IT目。对多数IT目Q尤其是软g实施目Q启动时都存在范围不够明晎ͼ需求不定的情c只有到软gDemo产生Q?才可能需求清晎ͼ范围定Q这些情况就军_了IT目计划需要根据项目的实际情况及时q行修正。如何压~范围确定的旉Q早日制定出周密可行的计划,是Y 仉目的一个重要课题?/p>
制定一份周密可行的计划是项目经理优U能力的体玎ͼ其是WBS的制定,对复杂项目有很大隑ֺ。在?008奥运目的管理体会时Q项目专家曹蕑ְ 提到奥运会项目最隄一点就是WBS的制?参见PMU|站?008奥运目的访?。要保证目的成功,p保证目的每个活动都能得以顺利执行。所 以,在项目情况发生变化,在原有的计划基础上有需求变更时Q就要把新的d补充到计划中Q修正计划,保WBS的完_保计划周密可行Q之后的工作才是 严格执行?/p>
Z提一句,有些目l理会走另外一个极端:因ؓ需求不定Q所以不制定目计划。这同样是对计划的错误理解。即使计划不够周密,但它可以提醒我们 目的大目标是什么,保证目团队所采取的行动不偏离大方向。Q何一大的项目,都可以拆分成很多项目,WBS的渐q明l,也是目必须完成的Q务之 一Q所有Q务的持箋旉都是要估的Q即使不够准,臛_可以作ؓl验累积Qؓ今后的准估做了准备。因此,目的Q何阶D都一定要有计划?/p>
错误五:目一定要盈利
目一定要盈利Q这句话被无数IT目l理奉ؓ真理Q也注定了要创造很多悲?Z辑ֈq个目的Q很多IT目l理甚至都在悉心研究厚黑学,学习 用什么办法把弟搞得热情高涨Q比民工累,从而用最低的成本创造最大的利润?/p>
目理作ؓ战术层次的管理手D,一定要服务于战略层ơ的大方向。商场如战场Q有胜利׃有失败。ؓ了战略胜利,很多战役要诱敌深入,必须打|仗?败仗不要紧,关键要弄清楚败到什么层ơ,损失CU地步,明确本次战役的真实目标,再去打这场战役,׃做到驾轻qQ从而不至于到最后Ş成不仅损光| ,q未能诱敌深入的局面?/p>
开拓市场、占领市场、站E_场、挖掘市场,q是每个公司发展必不可少的步骤。很多项目,对公司来说都是ؓ了占领市场,甚至虎口夺食。这L目Q公 总战略层面首先要求的绝对不是盈利,而是如何能把市场占领Q而站EI目l理必须明白q个战略意图?/p>
q是项目管理最为重要的一个思想Q从q去的做好质量、时间、成本项目三要素的^衡,到现在满相兛_pMh的需求,所有的最佛_践和理论研究成果Q?都绝不会提倡走极端Q杀机取?利润只是目的一个目标,q且一定要明白有短期利润和长期利润之分Q过分单一q求利润的项目注定要p|Q过分追求利润的?怹不会长久?/p>
该花的钱不能省,不该q׃分也不要花,目l理把成本控制在合理的预范围内Q就是成本控制的成功。万万不可ؓ了把一个注定要赔钱的项目做得盈 利而想办法、绞脑汁压~成本,从而让l员加班加点Q玩命干z,到最后,目q完了,Z走光了,q极有可能因工导致项目质量不合格Q客户不满意Q?那就真的赔了夫h又折?
目l要能保持激情高效,不能懒散拖沓Q项目经理一定要把握好这个度Q绝不能走极端。^衡是一门艺术,也是展示目l理能力水^的一个重要标?
错误六:C了科学,忘记了有?/strong>
学以致用Q就怕ؕ用。无论是产品、技术还是管理方法,都存在ؓ了更先进、更U学而罔儡实,盲目q的现象,l果先进和科学的技术、工具不仅未提高 生效率Q却成了累赘Q这L情况到处都是Q在IT目中也为数不少?/p>
国内大量p|的ERP目是q类错误的典型。有人把ERP目归结Z把手工程Q意思是只有领导重视q推动才能成功。领导支持是目成功很重要的 一个条Ӟ但绝不是有领导支持就一定能够成功。有些项目就是领导决{失误盲目上的,从开始就注定目要失败。一个信息化目的实施,对很多企业来说就是一 场大的改革,Ҏ有员工从思维、技能到工作习惯{多斚w都需要进行调整。如果企业的员工素质不能跟上Q纵然有各种各样的培训,但不֑工基和学习曲U, 用户不能真正掌握全新的系l,l果只能增加用戯担,而生不了期望的效果?/p>
很多IT目l理在学习了一些新的技术后QL立刻在项目中实践Q而不Ml分析这些技术在q个目中是否需要,是否适合。IT技术日新月异,不断 有新的理提出来,被翻译引q到国内。有些项目经理在一知半解,对这些技术还不是很熟悉的情况下,敢向h吹嘘他所掌握技术的U学性、先q性,q而强?要求在项目中实践。这可能是甲方的目l理Q也可能是乙方的目l理。因为技术选择错误D目p|的例子在国内q去有,现在也还?l对不可准备不Q?大范围引入全新的技术,待到目旉q去一半了Q才发现选择的技术不适用Q那时候一切都晚了。掌握Q何新东西都有学习曲线Q项目的旉限制是项目经理必?时刻牢记的要素,把握不好׃l项目带来极大风险?/p>
涉及到具体的IT目理QPMBOK的知识体pd谓博大,q有一些其他新的项目管理工P不能说不先进Q但是哪些知识、工兗方法适合本项目,需 要项目经理根据实情,认真分析后进行筛选用?/p>
U学、先q、好用等{修饰头衔这些都不是要选择的首要理由,需要、适用和有效才是首要考虑的事情。很多IT目l理因ؓq轻Q初生牛犊不怕虎Q胆?大,勇气I敢于在实践中引入新的工具、方法。敢于尝试不是坏事,但试验的风险一定要控制好。对于项目经理来_所有的决策都要围绕目目标q行。项目经 理的首要d是保证项目成功,如果同时能引入新的技术、工P增加l员的知识技能,提升目l工作效率,提高产品的质量和可靠性,l对是锦上添花,但绝?不能Z锦上添花而导致项目失控甚臛_败,捡了芝麻Q丢了西?