精华内容
下载资源
问答
  • 全身体格检查基本项目.doc
  • 全身体格检查基本项目操作规范标准[详].doc
  • 项目立项检查单.xlsx

    2020-05-24 12:34:54
    总结了软件项目立项经常遗漏的关注点,经常犯的错误,从完整性、正确性方面对立项过程进行了全面的梳理,对关键点了较仔细的总结。
  • 项目健康状况检查

    千次阅读 2013-07-21 01:51:41
    项目天天救火,疲于奔命,项目健康状况到底如何呢?我总结了11问题,供大家自测一下,看看你的项目是活得...当然要诊断项目的健康状况,11问题是远远不够的,但这11问题应该足够的代表性,希望对大家帮助。

    项目天天救火,疲于奔命,项目健康状况到底如何呢?我总结了11个问题,供大家自测一下。当然要诊断项目的健康状况,11个问题是远远不够的,但这11个问题应该有足够的代表性,希望对大家有帮助。

     

    下面有11个问题,请根据感觉打分(1-5分)。

    问题1:客户向公司领导投诉软件的问题,你们的领导很火,要兴师问罪,要在项目组中找出责任人,你估计你们项目组会出现怎样的状况?
    1分表示:人人自危,尽量想办法将责任推卸。
    5分表示:每个人首先从自己角度找原因,主动承担自己的过失,并提出改进意见。
    你会给多少的评分?

    问题2:项目经理负责项目管理的工作,你觉得你们项目其他成员对项目经理的态度如何?
    1分表示:项目管理是项目经理的事,其他人完成任务便可。
    5分表示:项目管理是项目组每个人的事情,每个人在实际工作中主动积极地管好自己的工作,并为项目成功出谋献策。
    你会给多少的评分?

    问题3:你会如何描述你们项目计划与跟踪的实际情况?
    1分表示:基本上无计划可言,甚至没有专人负责项目管理的事情。
    5分表示:制定了弹性的不断优化的计划,并能持续跟进好各项任务的进展。
    你会给多少的评分?

    问题4:你如何评价项目需求文档的质量
    1分表示:文档质量极差,甚至没有文档可言。
    5分表示:有系统的需求文档,并且能持续更新和优化该文档。
    你会给多少的评分?

    问题5:对于客户频繁变更需求,你如何评价客户?
    1分表示:就算书面确认了,客户还是在变,这样的客户真难服侍!
    5分表示:我们是专业人士,有责任帮助客户找到真正的需求,我们应该好好反省一下自身的水平,而不是责怪客户。
    你会给多少的评分?

    问题6:你如何评价项目的设计状况?
    1分表示:基本上无设计可言,直接编码更爽。
    5分表示:有优秀、有效和必要的设计文档,并且能依据设计完成编码工作。
    你会给多少的评分?

    问题7:你如何评价你们项目中程序员的编码情况?
    1分表示:编码低级问题很多,编码也不规范。
    5分表示:有“零缺陷”代码的意识,编码质量高。

    问题8:你如何评价你们项目的测试状况?
    1分表示:测试人员无法全面理解需求,测试时间经常被压缩。
    5分表示:测试人员在项目前期就能准确全面地把握需求,并且有足够权力来影响需求。软件能按照测试计划、测试策略进行严格的测试。
    你会给多少的评分?

    问题9:你们项目加班情况如何?
    1分表示:返工很多,需要经常加班,甚至通宵加班。
    5分表示:很少返工,基本上很少加班。
    你会给多少的评分?

    问题10:软件即将发布,项目的缺陷情况如何?
    1分表示:超级多缺陷,严重问题也多,有些功能甚至没有完成。
    5分表示:缺陷在可控范围内,所有功能都能完成。
    你会给多少的评分?

    问题11:项目经理召集会议评审需求文档,你估计会有怎样的情况?
    1分表示:与会者未能事先仔细看文档,到会后提不出有价值的问题,各与会者姗姗来迟,甚至缺席。
    5分表示:所有与会者热情和投入,提出了很多有价值的问题。
    你会给多少的评分?

    计算一下你的得分,看看你的项目是属于哪个等级?
    40-55分:活得舒服。这是做项目的理想境界。
    30-39分:凑合活着。虽然比较累,但有时还是有些成功感。
    20-29分:百病缠身。天天在救火,天天疲于奔命,但得不到好果子。
    10-19分:投胎转世。生活在这样的项目,你恨不得马上结束这样的生活,重新开始!

    以上仅供大家参考,希望通过这样的题目能让大家发现项目潜在的一些问题。

     

     

    作者:张传波

    创新工场创业课堂讲师

    《火球——UML大战需求分析》作者

    www.umlonline.org 创办人

     

    展开全文
  • 一、影响软件开发项目进度的因素  要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。软件开发项目中影响进度的因素很多...

    一、影响软件开发项目进度的因素
      要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况:
    1、80-20原则与过于乐观的进度控制
      80-20原则在软件开发项目进度控制方面体现在:80%的项目工作可以在20%的时间内完成,而剩余的20%的项目工作需要80%的时间。这个80%的项目工作不一定是在项目的前期,而可能是分布在项目的各个阶段,但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉,使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了,就一块石头落地“总算交差了”,同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作,同时如果软件还不成熟的话,会给用户造成不好的影响。
    2、范围、质量因素对进度的影响
      软件开发项目比其他任何建设项目都会有更经常的变更,大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧,用户是想改就改,造成需求的蔓延,项目经理有时还不知如何拒绝,加上要说“我能”的心理因素,一般都会答应修改。这样集少成多,逐渐影响了项目进度。
      如果某项工作在进度上表面上达到目标了,但经检验其质量没有达到要求,则必然要通过返工等手段,增加人力资源的投入,增加时间的投入,实际上是拖延了进度。不管是从横向或纵向来看,部分任务的质量会影响总体项目的进度,前面的一些任务质量中会影响到后面的一些任务质量。
    3、资源、预算变更对进度的影响
      资源,最主要的还是人力资源,有时某方面的人员不够到位,或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源,就是信息资源,如某些国家标准、行业标准,用户可能提供不了,而是需要去收集或购买,如果不能按时得到,就会影响需求分析、设计或编码的工作。其他资源,如开发设备或软件没有到货,也会对进度造成影响。
      预算其实就是一种资源,它的变更会影响某些资源的变更,从而对进度造成影响。
    4、低估了软件开发项目实现的条件
      低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
      首先是低估技术难度。软件开发项目团队成员,有时甚至是企业的高级项目主管也经常低估项目技术上的困难。低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。软件开发项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验;
      其次,低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。软件开发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。
      另外,企业高级项目主管和项目经理也经常低估环境因素,这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。低估这些条件,既有主观的原因,也会有客观的原因。对项目环境的了解程度不够,造成没有做好充分的准备。
    5、项目状态信息收集的情况
      由于项目经理的经验或素质原因,对项目状态信息收集的的掌握不足,及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。某些项目团队成员报喜不报忧,不希望别人知道自己工作的不好的情况,例如软件程序的编制,可能会先编制一些表面的东西,现有界面,看起来好像完成任务了,实际上只是一个“原型系统”或演示系统。给领导造成比较乐观的感觉。
      如果项目经理或者管理团队没有及时地检查发现这种情况,将对项目的进度造成严重的影响。当然,如果出现这种需要时时刻刻都互相提防的氛围,管理人员就应该从管理的角度,从制度的角度检讨一下,进行改进,让大家实事求是地进行沟通。温伯格说:“无论你多么聪明,离开了信息,对项目进行成功的控制就是无源之水、无本之木。”
    6、执行计划的严格程度
      没有把计划作为项目过程行动的基础,而是把计划放在一边,比较随意去做。例如对于项目团队内部沟通或外部沟通,在计划中要说明清楚人员、周期、方式、方法,不能遗漏,但在实际项目过程中,可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。若项目计划本身有错误,执行错误的计划肯定会产生错误。如,计划制订者在计划系统框架设计考虑上的错误、进度安排上的失误等。实际的项目实施中,除了这种错误之外,还可能因为项目执行上的错误,造成项目的麻烦。例如,项目的客户及其他项目干系人没有及时为项目中出现的情况采取必要的措施或者所采取的措施的不适合具体的情况、没有效果或者有副作用等。另外,如果在项目中的某项工作(如某个子系统或模块、组件)被转包给第三方开发后,不能进行有效的管理,也会造成进度上的延误。
    7、计划变更调整的及时性
      渐近明细是项目的特点,特别是对于软件开发项目,并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些,随着项目的进展,特别是需求明确以后,项目的计划就可以进一步的明确,这时候应该对项目计划进行调整修订,通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业,日新月异是主要特点,因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式,随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ,需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系,所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ,根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细,无法对工作任务的分解、均衡分配和进度管理起参考作用,因此要随着需求的细化和设计的明确,对项目的分工和进度进行及时的调整,使项目的计划符合项目的变化,使项目的进度符合项目的计划。
    8、未考虑不可预见事件发生造成的影响
      假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响(即项目按时完成是基于如下假设:人力资源不会缺乏、人员不会生病、人员不会流动)。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑,在项目进展过程中也要不断地重新考虑有没有新的情况,新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题,而这些问题是一定要解决才能保证项目按计划完成;约束一般是难以解决的问题,但可以通过其他途径回避或弥补、取舍,如牺牲进度、质量等等;假设与约束是针对比较明确会出现的情况,如果问题的出现具有不确定性,则应该在风险分析中列出,分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题,因为任何人都不可能把所有以外的情况都考虑完整,实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患,但是有的时候也要冒一定的风险,同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响,则这种防范是没有必要的。
      9、程序员方面的因素对进度的影响
      程序员方面有两种常见的心态影响了进度的控制:一是技术完美主义、二是自尊心。
      技术完美主义的常见现象是,有些程序员由于进度压力、经验等方面的原因,会匆忙先做编码等具体的事情,等做到一定程度后会想到一些更好的构思,或者看到一些更好的技术的介绍,或者是觉得外部构架可以更加美化,或者是觉得内部构架可以更加优化,这样他们会私下或公开对软件进行调整,去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响,相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本,可能对软件开发进度造成较大的影响。
      自尊心的常见想象是,有些程序员在遇到一些自己无法解决的问题时,倾向于靠自己摸索,而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决,否则要花很多实践摸索。而如果向周围的人求教,可能摸索几天的问题别人早就解决了。
    10、未考虑软件开发过程的循环、迭代特性
      对软件开发的各个过程分类过于精细,制定进度计划时各项工作过于紧凑、没有弹性,造成的后果是,定期提交项目进度阶段报告的制度只有在表面上起到效果,按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”,强行的规定会使人产生一些错误的认识:如在项目计划中“规定”某个时间只能做某某类别的事情,那么严格执行的后果就是编码阶段就不能修改文档;另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了,而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误;如果上下阶段是同一个人,就可能非正式地修改上一阶段的错误,但占用的时间和精力却是下一阶段的,并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是,用户在合同中限定了提交软件系统的时间,实际上这个时间对完成项目任务来说是远远不够的,但计划只能按照合同来进行,所以要不用户让步,要不只能按照时间的约定提交实际上还未完成的软件系统,完成系统的安装,但这时候的“完成阶段任务”只是一个表面现象,系统虽然安装了,但可能是没有经过严格彻底测试的,也可能是只完成了部分的功能,省略了某些功能,有些是整块功能省略,有的是省略了某些功能的某个过程,如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能,而是实现了比较粗糙的功能。这样,系统交付并不意味着项目的完成,而在项目交付之后还要花更多的时间。
    11、其他因素
      以上这些因素是影响项目进度的几个主要方面,除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素,这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等,都会对项目进度造成影响,这是因为由于软件开发的特性。因为篇幅有限无法一一列举,只能在此分析一些常见的因素。
      不可否认,软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目,其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验,虽然我们说,顾客是上帝以顾客为中心,但并不是说我们要把主导权交给他们,而关键是我们如何去主导、引导、把握。因此,项目控制的好坏与相关人员人际关系方面的经验也有关系。
      尽管存在很多不可控的因素,我们的任务是首先分清哪些是可以控制的,哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域,减少不可控的领域,二是不要在“不可控”上花太多时间,而是多花一些时间把可控的工作控制好,做好防范措施,减轻不可控因素对项目进度的影响。
      项目进入实施阶段后,项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系,需要项目经理去平衡。
    二、项目进度控制的目的
      项目进度控制和监督的目的是:增强项目进度的透明度,以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。
    1、根据计划进行监控
      项目控制的第一个目的是根据计划对项目的各项活动进行监控,即根据已经制定并取得共识的软件开发项目计划来监控项目的实际表现和进度。为此应该根据项目计划来监控项目计划参数的实际值,这些参数包括进度表、项目成本、工作量、工作产品和任务的属性、使用的资源、项目成员的知识和技能;根据项目计划来监控项目团队所作的承诺是否已经或可能兑现、原来的确定的风险是否可以避免或减少损失,是否有新的风险出现;根据项目计划来收集、管理、使用项目数据;根据计划监督项目干系人的参与情况,监控各项任务承担人的参与活动;定期进行必要的进度评审,确定项目是否存在重大偏差、跟踪变更请求和问题报告直到变更或问题得到解决;在项目的里程碑对项目的成果进行评审。
    2、管理纠正和预防措施
      项目控制的另外一个目的是管理纠正和预防措施,即当项目进度或者结果已经或即将与计划有严重偏差时,对需要采取的纠正或预防措施进行管理。为此应当收集并且分析项目进行中可能存在的问题,并以此确定解决这些问题的纠正或预防措施;对已经确定的问题采取纠正和预防措施;监控要实施的纠正和预防措施,分析措施采取以后的结果,判断这些措施的有效性,确定和记录纠正与计划结果存在偏差的问题而采取的必要且合适的措施。
      项目执行过程中仅仅靠最初建立的一份“完善”的基准计划是不够的,最好的计划也未必会一直有效。根据项目任务渐进明晰的特点,特别是软件开发项目的特点,在项目进行过程中,肯定需要在适当和必要的时候对项目进行变更控制,这种控制过程包括定期搜集有关项目进展情况的信息,把实际进展情况与计划进展情况进行对比;如果实际进展情况比计划进展情况有差距,或可能会有差距,就应当采取纠正或预防措施。变更控制应当在项目期间定期进行,这里所说的变更控制不一定要进行真正的变更,而是说要定期对变更进行控制。
      如果在项目生命周期内的某一时间点,把实际进度与计划中约定的进度相比对,显示出项目已经延误或即将延误、超出预算目标或不符合质量要求,就必须采取纠正或预防措施使项目回到正轨上来,重新符合计划的安排要求。在已做出执行纠正或预防措施的决定之前,应评估一下纠正与预防措施的有效性和无副作用性,以确保纠正措施使项目回到项目的工作范围、时间和预算约束内,并对项目的其他目标不会造成太大的影响。
      3、在各种项目目标中进行平衡
      如果经过评估确定项目确实已无法控制,就应当下定决心以牺牲软件功能范围、工作成果范围(如某些中间文档)、成本预算、进度计划或软件质量中的某一项目标为代价,来保住项目最重要的那些目标,在各种项目目标中进行平衡,最终确定一个最合适的解决方案。有效的项目控制的关键是定期及时测量实际进程,并与计划进程相比较,如有必要就立即采取纠正或预防措施。指望不采取纠正和干预措施,问题就自行消失的想法是不现实的。问题越早发现就越好改正,造成的影响和损失越小。问题越提前发现就越好采取预防措施,可以用最小的代价避免造成损失。基于项目实际进展情况,就有可能准确预测项目进度计划和成本预算的实施情况,以便顺利完成项目。如果这些项目参数超出项目目标的限制范围,就必须马上采取纠正措施;如果发现这些项目参数有超出项目目标的限制范围的趋势,就必须马上采取预防措施。
      软件开发项目实施中进度控制是项目管理的关键,若某个分项或阶段实施的进度没有把握好,则会影响整个项目的进度,因此应当尽可能地排除或减少干扰因素对进度的影响,确保项目实施的进度。
    三、软件开发项目常用进度控制措施
    1、项目进度控制的前提
      项目进度控制的前提是有效地项目计划和充分掌握第一手实际信息,在此前提下,通过实际值与计划值进行比较,检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段,对项目进度进行监督、督促、影响、制约。及时发现偏差,及时予以纠正;提前预测偏差,提前予以预防。
      在进行项目进度控制时,必须落实项目团队之内或之外进度控制人员的组成,明确具体的控制任务和管理职责。要制定进度控制的方法,要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。
      项目进度控制应该由部门经理和项目监控人员共同进行,之所以需要部门经理参与,是因为部门经理负责项目一般要负责一定人事行政的责任,如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员,项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。
    2、项目进度控制主要手段
      项目计划书:作为项目进度控制的基准和依据,项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控,如果由于某些原因阶段成果提前或延后完成,项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的,应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施,在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整,以保证基准和依据的新鲜性、有效性。
      项目阶段情况汇报与计划:项目负责人按照预定的每个阶段点(根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等)定期在与项目成员和其他相关人员充分沟通后,向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划,内容包括:
      a、对上一阶段计划执行情况的描述
      b、下一阶段的工作计划安排
      c、已经解决的问题和遗留的问题
      d、资源申请、需要协调的事情及其人员
      e、其他需要处理的问题
      这些汇报将存档,作为对项目进行考核的重要材料。
      在计划制定时就要确定项目总进度目标与分进度目标;在项目进展的全过程中,进行计划进度与实际进度的比较,及时发现偏离,及时采取措施纠正或者预防;协调项目参与人员之间的进度关系。
      在项目计划执行中,做好这样几个方面的工作:
      检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据,积累资料,总结分析,不断提高计划编制、项目管理、进度控制水平。
      做好项目计划执行中的检查与分析。通过检查,分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。
      及时制定实施调整与补救措施。调整的目的是根据实际进度情况,对项目计划作必要的修正,使之符合变化的实际情况,以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周,或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑,计算调整后的各时间参数、关键线路和工期。
      3、进度控制内容
      从内容上看,软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容:
      (1)项目经理监督并控制项目进展情况;
      (2)进行项目分解,如按项目结构分,按项目进展阶段分,按合同结构分,并建立编码体系;
      (3)制订进度协调制度,确定协调会议时间,参加人员等;
      (4)对影响进度的干扰因素和潜在风险进行分析。
      技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视,有些技术问题可能需要特殊的人员,可能需要花时间攻克一些技术问题,技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。
      在软件开发项目中,合同措施通常不由项目团队负责,企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况,按计划通过计划进度与实际进度的动态比较,定期向客户提供比较可靠的报告等。
      软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是:预测信息,即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测;决策信息,即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人;统计信息,软件开发项目中统计工作主要由参与项目实施的人员自己做,再由项目经理或指定人员检查核实。通过收集、整理和分析,写出项目进展分析报告。根据实际情况,可以按日、周、月等时间要求对进度进行统计和审核,这是进度控制所必须的。
      4、不同阶段的项目进度控制
      从项目进度控制的阶段上看,软件开发项目进度控制主要有:项目准备阶段进度控制,需求分析和设计阶段进度控制,实施阶段进度控制等这几个部分。
      准备阶段进度控制任务是:向业主提供有关项目信息,协助业主确定工期总目标;编制阶段计划和项目总进度计划;控制该计划的执行;
      需求分析和设计阶段控制的任务是:编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划,控制相关计划的执行等。
      实施阶段进度控制的任务是:编制实施总进度计划并控制其执行;编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。
      为了及时地发现和处理计划执行中发生的各种问题,就必须加强项目的项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件,以适应项目实施情况的变化。
    5、关于进度落后时的“赶工”措施
      进度落后的情况下,有几种措施来弥补,如加人、加班、加激励等等,这些都是增加资源而又未必会见效的方法。根据Brooks原则,在某些项目进度延迟的情况下增加人手,有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说,对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加,可能会使项目的工作效率急剧下跌。而加班造成的疲劳会再次使工作效率降低。增加激励会造成工作成本却不断的向上攀升。这些措施并不是完全不可取,而是项目经理要考虑适度原则。最好是要全面分析项目进度延迟的原因,如果确实是不合理的项目交付时限要求,就应当通过沟通变更为合理的项目时限要求,以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响,最终导致项目最终的失败。否则应从技术、团队成员心态、环境等方面查找原因,找到提高效率、加快进度的方法。

    展开全文
  • 成功的软件项目经理

    千次阅读 2017-02-27 14:03:13
    要想成功的软件项目经理需要丰富的管理知识,同时要有全面的技术知识。 同时在知识的结合下在实际中应用管理学的计划,组织,控制,激励,领导等职能,发挥个人管理的长处,再项目组成员及客户前发挥亲和...

    做一个成功的软件项目经理

    概述

    要想做一个成功的软件项目经理需要有丰富的管理知识,同时要有全面的技术知识。

    同时在知识的结合下在实际中应用管理学的计划,组织,控制,激励,领导等职能,发挥个人管理的长处,再项目组成员及客户前发挥亲和力、领导力,并做好时间管理和沟通管理。

    最终带领整个项目团队不断成长发展并高效的完成整个项目过程。

     

    下面为软件项目管理成功相关联的要素:

    项目成功的要素

    软件项目经理就是要在有限人员,有限的技术,做好团队的管理让团队向自我管理发展并及时调节团队的冲突,让项目按时保质量的完成。

    总的来说软件项目经理需要知识:管理学,软件工程学,开发实践知识T技术知识

     

     

    项目成功度量

    项目管理成功最理想情况:“多、快、好、省”。

    “多”指工作范围大,“快”指时间短,“好”指质量高,“省”指成本低。

    这个目标是需要进行权衡那些是否有必要。

    目标明确内容:多与快、好、省是正面冲突的。

    所以要尽量减少“多”,做好“快”,“好”,“省”。

    即尽可能的限制需求,同尽可能的增加技术熟悉成员。

    通过计划,评审,考核推进整体项目进展。

    通过规范,考核,自我测试,自动测试做好质量的控制。

    同时要发动所有人员的积极性,高效完成任务。

    项目成败的关键点

    抽象分析

    为了分析项目成败的关键点对项目相关元素进一步的抽象分析。

    如下图:

    分析主要的成功因素

     

    说明:

    1.一个项目是否成功站在系统抽象化角度时(输入条件-> 处理 -> 输出结果)

    如果 要保证输出结果的正确:跟输入条件有关,同时在处理时起决定做用。

    分析情况如下四种:

    同上图:

     

    分析上图并通过机率算:输入条件影响成功占50%, 处理过程影响成功占 50%

    因为输入条件是不可控的,所以要提高成功率只能通过提高处理过程正确并及时纠正错误。

    所以做为一个成功的项目经理面对着资源,需求,时间,成本等条件的不合理时,

    必须第一时间强硬的进行纠正,否则项目再怎么努力将面临失败。

     

    2.通过对整个分析从抽象到具体细化关键点我们会进一步发现:

    如下图:

    同上图:

     

    对于软件项目更加主观化后:

    需求所占的比例很大:

    a.       关键用户需求合理?

    b.       用户和开发对需求理确?

    c.       文档清楚确认?

    d.       需求变更管理?

    所以做为一个成功的项目经理必须让用户及开发对需求理确正确,并形成文档及时签字确认。同时尽可能的限制要求.

     

     

    项目管理中又细分为:

    个人管理:权威树立、有力领导(执行力)

    a.       沟通 – 把信息及时传递给大家

    b.       亲和力 –  处理好人群关系

    c.       领导力 – 指令确保执行到位

    d.       时间管理 – 关键点,

    团队管理:高效团队管理

    a.       互补?(技术不成熟)

    b.       互助?互督?

    c.       冲突解决

    d.        

    项目过程管理:目标,计划,质量,风险等管理

    1.  目标清楚—任务明确

    2.  计划合理—执行有力

    3.  自我测试及时完整?集成测试有效

     

     

     

    总的来说:要想项目成功就要,多提要求,限制需求,做好沟通,做好团队管理,做好过程中的计划,质量,风险管理就可以把整体项目成功完成。

     

    成败因素汇总

    失败的最主要的原因是缺乏有效的项目管理。并且认为技术即不是问题也不是解决方案。问题和解决方案在于人和过程。

     

    需求不明确

    计划缺失 (计划不周,执行不周)

    50%以上的失败项目是由于计划不周而造成的。

     

    影响项目成功的因素:

    项目的目标、范围是否明确;

    是否获得领导的积极支持;

    项目的组织是否健全、稳定;

    是否建立了有序的、有效的、良好的沟通渠道;

    是否具有有效、全面的项目管理,严格的变更控制;

    是否建立了良好的、积极的、团队合作的工作氛围;

    项目经理PM的经验;

     

    项目失败的主要因素:

    项目目标不明确

    缺乏有力的领导

    缺乏高层管理者的支持

    技术问题没有解决

    不合理的预测

    跨部门协作不得力

    计划和控制不力

    过多的不可控变动

    责、权、利不清

    资源配备、供给欠佳

    缺乏有效的沟通

    项目经理缺乏魅力、影响力

     

     

    失败点:没有发动成员激急性,没有及时解决冲突,没有把困难分担下去。

    失败点:需求没有及时确认,并完整的确认,无用户需要的完整的需求文档。

    失败点:设计采用了不成熟技术,没有做好共用重复劳动。

    失败点:人员开发技术不熟练

    失败点:计划跟实际脱节

     

    技术人员的开发能力不行

     

    理解管理

     管理理论知识

    管理是通过计划、组织、控制、激励和领导等环节来协调各种组织资源,以期更好地达成组织目标的过程。

    计划就是探索未来和制定行动方案。(目标管理,可行的目标,可操作的时间表)

    组织就是建立企业的物质和社会的双重结构。(层级原则,管理跨度原则,统一指挥原则,责权一致原则,适当的授权原则,分工与协作原则,执行与监督分离原则,精简与效率原则

    并动态原则:职权和知识相结合的原则,集权与分权相平衡原则,弹性结构原则)

    指挥就是使其人员发挥作用。

    协调就是连接、联合、调和所有的活动和力量。

    控制就是注意一切是否按已制定的规章和下达的命令进行。

     

    马基雅弗利四项领导原理:

    1.  领导者必须要得到群众的拥护。(一,群众要拥护他作为领导者;二,领导者做事要征得群众的同意)

    2.  领导者必须维护组织内部的内聚力。领导者必须把组织的成员紧紧地团结在自已的周围,使自已及所在的组织具有吸引和。

    3.  领导者必须具备坚强的生存意志力。领导者要有坚忍不拔的精神,不软弱,不气馁,能为组织和自已的生存不断奋斗。

    4.  领导者必须具有崇高的品德和非凡的能力。

     

    法约尔管理14原则

    1.       劳动分工(专业化分工)

    2.       权力与责任(职位权力和个人权力,提高个人素质是避免滥用权力最好办法)

    3.       纪律(纪律来自于好的领导,尽可能明确而公平的协定,并合理执行惩罚)

    4.       统一指挥(一个下属只接受一个上级命令,防止双重命令)

    5.       统一领导(凡是具有同一目标的全部活动,仅一个领导者和一套计划,便于资源应用协调指向同一个目标)

    6.       个人利益服从集体利益。(领导必须经常监督并以身作则,以缓和两者矛盾,使一致)

    7.       合理的报酬(薪资制度应当公平,对工作成绩与工作效率优良者应有一定限度奖励)

    8.       适当的集权和分权(提高下属重要性采用分权,降低重要性采用集权)

    9.       跳板原则(两领导两下属之间直接联系,必须先请示,后汇报)

    10.   秩序(凡事各有其位,有效组织及审慎选人)

    11.   公平(努力使公平感深入人心)

    12.   保持人员稳定(鼓励职工做长期的服务)

    13.   首创精神(在不违背职权和纪律的情况下,鼓励和发挥下级的首创精神)

    14.   人员团结(严守统一指挥原则并中强情况的交流,多用口头沟通,尽一切可能保持和巩固人员的团结)

     

    梅奥人群关系理论:

    提高生产效率主要途径是提高工人的满足度。满足度越高,士气就越高,生产效率也就越高。

    1.  强调对管理者和监督者进行教育和训练,以改变他们对工人的态度和监督方式。

    2.  提倡下级参与企业的各种决策,以此来改善人群关系,提高职工士气。否定采取解雇和人事考核制裁等强制性手段迫使职工服从的管理方法。

    3.  加强意见沟通,允许职工对作业目标、作业标准和作业方法提出意风,鼓励上下级这间实行意见交流。

    4.  建立面谈和调解制度,以消除不满和争端。

    5.  改变干部的标准。重视管理干部自身的人群关系以及协调人群关系的能力。

    6.  重视、利用和倡导各种非正式组织。重视美化工作和宿舍环境,建设娱乐设施、运动设施、生活福利设施等。

     

    巴纳德的权威接受论:

    管理者的权威并不是来自上级的授予,而是来自由下而上的认可。管理者权威的大小和指挥权力的有无,取决于下级人员接受其命令的程度。最重要的是取得下级的同意、支持和合作。

     

     

    个人管理

    目标:

     

    项目经理的技能:

     

    1、领导能力

    2、人员开发能力

    3、沟通技巧

    4、人际交往能力

    5、处理压力的能力

    6、解决问题的能力

    7、管理时间的能力

     

    培养项目经理所需要的能力:

     

    1、获取经验

    2、寻求别人的反应

    3、自我批评总结,改正错误

    4、与一些具有你想学习的技能的项目经理进行探讨

    5、参加培训项目

    6、参加组织团体

    7、阅读

    8、参加自愿活动

     

    亲和力

    领导力

    时间管理

    个人修养—以身作则

    团队管理                      

    1、建立一个结构合理的项目组

    2、寻找合适的人选,熟悉他们技术方面管理方面的长处和弱点,了解他们的能力

    3、树立并保持项目组的团队精神

    4、争取管理部门的支持

    5、项目组内经常的有效的沟通

     

    团队的形式

     

     

    团队定义中的几个方面对我们理解一个团队是重要的。

     

    少量成员

    n       2-25人

    n       8-12个为最佳

    互补技能

    n       技术和功能方面的特长

    n       解决问题和决策技能

    n       人际技能

    对一个共同的和绩效目标做出承诺

    n       绩效的分离单元

    n       管理层通过在公司绩效需求之内定义权限的界限和范围来指明方向。一个共同的目的使团队揉成一个整体,总体力量大于单个个体力量之和

    n       团队将各种指标转换为具体而可衡量的绩效目标

    n       具体的绩效目标有助于团队跟踪进步

    共同的方法(APPROACH)

    n       成员间的社会契约与他们的目的相关联并指导他们如何一起工作

    n       参照目的与目标不断调整

    彼此负责

    n       在实现团队目的、绩效目标和方法的过程中,团队成员逐步形成默契的配合

    n       彼此承诺和信任

     

     

    很多情况适合小组运作而且能从小组协作中得益

    运用小组而不是团队,适合于以下情况:

    •          个人角色和职责对成果的影响是首要的因素

    •          工作成果的协议是在所有成员与领导之间确定,而不是基于相互的责任

     

     

     

    给出一个良好定义有助于澄清团队(TEAM)与团队工作(TEAMWORK)行为,后一点在任何组织形式中都是有价值的。

    基于的团队工作行为:

    •         相互监控绩效

    •         提供并接受反馈

    •         维持有效的、闭环的沟通

    •         愿意并且有能力相互支持

    •         在适当场合需要的不同灵活技能

    •         随时间变化和成熟

     

    SDWTs和SMWTs与传统的工作小组或需要指导的工作团队有着显著不同的特性

    特征

    工作小组或需要指导的团队

    自我指导和自我表现管理的团队

    领导

    强,以领导为中心

    分担领导的角色

    责任

    只有个人责任

    既有个人的也有共同的责任

    目标

    小组的目标与部门职责一致

    团队决定自己特殊的目标

    工作成果

    个人的工作成果

    集体的工作成果

    沟通

    运用有效的会议形式

    鼓励用完全开放的会议并提出有效的解决方案

    考评

    用他对其他人影响的程度间接的评估

    直接用集体的工作成果来评估

    工作风格

    讨论,决定和委派

    讨论,决定而且真正地一起工作

     

    团队工作可以影响的绩效和有效性

    团队工作使能的条件

    团队成功基于个体绩效

    团队是部分的总和,而不是一个表演者

    自身的成功取决于其它人的成功

    团队任务的完成取决于团队成员

     

     

    目前大部分公司员工是一个在指导下工作的团队。
    策略也经常被自我指挥的工作团队所修改。

     

     

    为使管理和员工向自主指导的工作团队方向转变,需要新的行为方式

     

     

    什么时候建立自我指挥的工作团队

    •         激励发起人、领导和成员

    --乐意接受新的文化

    --乐意承担新的文化

    --乐意学习与同事相互影响的新方法

    --敢于向现状挑战

    •         合理的逻辑考虑

    --小数量(8-12个成员为佳)

    --团队成员的地理位置

    --所有成员来自相似的业务部门

    --考虑一个或少量的业务合伙人作为团队成员

     

     

    新的管理范例
    今天的监督者/管理者的职责转变到教练/领导者的角色

    监督者/管理者

    教练/领导者

    检查

    促进

    指挥、管理

    教练、协调

    告诉

    建议、指导

    提供资源

    参与团队一起确认和保护所需的资源

    解决问题

    顾问、建议

    关注于群体工作结果

    在团队以外工作以获得团队目标支持

    发布正式和非正式的赞誉/承认

    加入并与团队成员共获成功

     

     

    有效的团队 团队特征

     

     

    团队工作形式的意义

    团队形成的过程

     

    高效团队建设的整个旅途

    关注点:

    确定团队运作指南:规范

     

    团队的组成

    项目过程管理

    沟通管理:

    让所有人参于规范制定与执行,风险识别与控制,

    要深入每个人的内部,了解大家并跟大家共处。

    管理风险

    要让大家明白项目是所有人的项目。

    把困难传达到项目组每个人,让每个人明白进展与遇到的困难。

    让每个人做好自我测试,并适当用自动测试。

    做好考核检查,总结,反思那里没有做好。

    范围管理:

    需求不清,范围不明

    需求确认过晚

    需求文档描述不清

    计划管理:

    如何写项目目标:

    •     我们要做什么?

    •     我们为什么要做它?

    •     它将与什么时候完成?

    •     需要哪些资源?

    •     如何评估它的效果?

    •     项目在哪里完成?

    •      

    计划的作用:

    1、计划是连通团体的经脉

    •     压力自上而下充分传递

    •     提高团队工作效率

    •     明确职责

    2、计划是走向目标的诺言

    •     确定工作总目标

    •     控制开发进程

    •     计划是工作的指南针

    3、计划是交流沟通的工具

    •     工作得以量化

    •     获得关键路径

    •     合理地调配资源

    •     清晰地反映产品状态信息

    4、计划是实现成功的保证

    •     规范开发活动

    •     约束和协调的依据

    •     问题的预警与防范

    一个完整的计划包括:

    计划制定的流程

     

    计划制定的原则:

    •     产品计划的制订是由上往下制订,由下往上修改的过程;

    •     在制订每一层计划时均要充分考虑上下层计划的约束关系;

    •     在与各相互关联的计划及与职能部门充分沟通和协调的基础上来制订产品的计划。

     

    计划制定的要素:

    完整性:

    •     是否包含了版本及所有特性的计划;

    •     是否全流程的计划(硬件、软件、测试、制造、市场技术、技术支援、生产等);

    •     是否产品卖出去的计划(资料、宣传、操作指导等);

    层次性:

    •     是否根据产品的特点进行了分层;

    •     每项活动是否分解到个人、时间不超过一周;

    •     各层次之间配合关系是否明确;

    •     特性是否归类

    合理性:

    •     计划进度是否符合市场需求;

    •     技术难度及解决情况是否支撑;

    •     资源需求是否合理;

    •     资源需求是否可以保证;

    •     各阶段、步骤、任务的时间安排是否合理;

    •     关键物料的货期是否影响计划;

    •     是否符合流程;

    •     是否设置了关键路径和里程碑;

    •     每个活动是否有结束的标志。

     

    WBS:

     

    项目计划形成之前,最好先画WBS表(Work Breakdown Structure),主要原理是:将任务逐级分解直至个人,在矩阵中体现为:先确定横向有多少结点,再将每一结点任务逐渐细化直到个人,工作分解图(WBS)实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元,这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成了一个个独立的我们能预测、计划和控制的单元,从而也就达到了对整个系统进行控制的目的。

    WBS示例:

     

    WBS的作用:

    1、将大系统变成具体的小工作单元,使复杂→简单,难以预测→易于预测,难以控制→易于控制

    2、是制定项目计划、编制项目预算、确定项目组织、分配工作的基础

    3、使我们对开发项目情况有了更加深入详细的了解,特别是对应做的工作有了更为透彻的概念

    4、便于了解整个项目开发系统的结构,便于合作、协调

     

    WBS分解:

     

    WBS分解的原则:

    将主体目标逐步细化分解,最底层的任务活动可直接分派到个人去完成;

     

    WBS分解的方法:

    自上而下与自下而上的充分沟通

    一对一个别交流

    小组讨论

     

    WBS分解的标准:

    分解后的活动结构清晰;

    逻辑上形成一个大的活动;

    集成了所有的关键因素;

    包含临时的里程碑和监控点;

    所有活动全部定义清楚;

     

    任务时间的估计和计算:

    •     让某项活动的负责人进行该项活动的工期估计是较好的做法。

    •     任命一位有经验的人进行他们所负责项目的工期估计

    •     历史数据可以作为参考

    •     估计应既富于挑战性,又符合实际,稍微激进些的估计比过分不保守的估计要好一些

    •      

    对高度不确定性任务时间的估算:

    采取对每项分工作估计三种时间的办法,然后加权平均计算出这项分任务的计划时间。

    1、最可能时间T可能

        根据以往的直接经验和间接经验,这项工作最可能用多少时间完成,也就是我们一拍脑袋所确定的时间   

    2、最乐观时间T乐观

        当一切条件都顺利时该项工作所需时间

    3、最不利时间T不利

        在完成过程中不利条件都在起作用时该项工作需要的时间

     

        计划时间T计划=(T乐观+4T可能+T不利)/6

     

    规范化的活动与经验数据库(模板):

    PERT:

    PERT(网络计划评审技术)是以网络图的形式制定计划,求得计划的最优方案,并据以组织和控制开发进程,达到预定目标的一种科学管理方法。

    1、用网络图来表达一项开发计划中各工作(阶段、模块等)的先后顺序和相互关系;

    2、通过计划找出计划中关键工序和关键路线;

    3、通过不断改善网络计划,选择最优方案并付诸实施;

    4、在计划执行的过程中进行有效的控制和监督,保证合理地使用人、财、物,按预定目标完成任务。

     

      “向关键工作要时间,向非关键工作要资源”

    PERT图示例:

    GANTT图:

    •     是对任务的一种罗列,标明任务名称、开始时间、完成时间、工期、资源名称等。

    •     采用GANTT图虽然没有PERT图直观,但罗列问题任务可较多,特别适合计划条理性不是很强的工作;   

     

    演练:各组根据自己的项目

           1、列出WBS表;

           2、画出PERT图;

           3、找出关键路径。

     

    项目计划控制的难点:

    1、研究与发展缺乏先例

    2、有未预计到的技术问题

    3、由于新技术或需求变动而造成的计划改变

    4、时间周期不定

    5、专业人员固有的乐观主意

    6、人的生产率的可变性

     

    计划监控

    •          各级监控点的设立遵循两个原则:

           A、重要的里程碑

           B、时间间隔比较合理

    •          监控计划的表现形式为:计划监控总揽图和计划监控一览表。

    •          计划监控总揽图将各级计划的关键点浓缩在一起,直观,便于控制。同时,各监控点在时间上也形成对应。

    •          通过计划监控一览表,严格定义了每一监控点的完成标志,以使监控点不会产生歧义性的理解。

    计划更改与状态转移:

    •          计划更改须经过评审,其评审批准部门同计划制定。一级计划更改须填写一级计划更改单,并修订相关计划。

    •          原则上,一级计划不予修订,二、三级计划要及时修订滚动。以保证一级计划最终按目标实现。

    •          在版本立项通过后,即为该版本建立状态转移表,直至版本转产,状态转移表是一级监控的检查档案。

    •           

    •          正规控制

    在每周末、每月末或每个阶段末进行情况汇报和检查等,通过PERT图和GANTT图以及预算报告和工作总结及阶段评审的报告等及时发现问题和进行评审

    •          非正规控制

    通过工作之外的交流和沟通进行控制,在非正规控制的场所要比在办公室更坦率、更诚实,这样能了解到正在酝酿的问题,这要比等到这些问题出现在情况报告中或某次会议上快得多

     

     

    项目控制的五个步骤:

    1、及时掌握最新情况和项目进展

    2、分析计划进度和质量产生偏差的原因

    3、处理偏差

    4、公布修改方案及滚动的计划

    5、周知管理部门

    项目经理如何召集会议:

    为明确计划和方案,项目经理应该定期不定期召集例会,例会可以讨论以下问题:

    •          里程碑计划为什么没有完成?

    •          其影响如何?

    •          工作何时可以完成?

    •          是否需要替补行动计划?

    •          何日才能回到计划进度上来?

    项目情况回顾检查会:

    回顾检查会准备:

    •          明确界定会议的目的

    •          议程要明确,并要提前进行准备

    •          邀请必要的人到会,尤其是关键人物入会

    •          如果有重要人物参加,最好让你的发言人预先演习

    •          以对你最有利的方式组织项目回顾检查会

    •          遵守议程

    •          自上次回顾会以来的主要成就

    •          进度状况、成本状况(实际与计划相对照)

    •          重大问题及行动计划

    •          下个阶段的计划

    •          特殊议题(具有紧迫性的议题)

    •          总结由本次会议产生的各行动事项,明确责任人和时间

    •          切勿超时

     

     

    质量管理:

    让每个人明白产品质量跟每个人有联系。

    让开发人员不断完善开发文档,必须思考清楚:日志完整,异常情况及处理,测试是否周全。

     

    规范工作

    把规范(设计开发测试规范)通过不同途径传达到每个成员,并要多次传达。

    途径1 会议上说明,培训, (保证规范被学习)

    途径2 检查规范情况,并通报执行情况 (保证规范被执行)

    途径3 多次沟通规范执行情况,是否需要完善, 让大家一起来制定规范(保证规范可执行)

     

    做好测试

    做好自我测试

    适当的自动测试

    做好回归测试文档

    做好测试记录

    文档管理:

    1、正规的文档要受控,要盖章,参考别人文档时一律以盖章的为准,未盖章的草稿文档不要随意放置

    2、文档必须要有审核后方能归档,作者和审核人不能是同一人,本着最了解的人最有权的原则,不能走形式

    3、版本升级后和版本文件要收回归档到文档管理部门,并注明版本已升级

    4、注意文档保密性,不要随意复印,草稿应在归档后销毁

    5、为保持科研成果,项目经理在批准项目组人员复印文档时,要注意是否与其工作有相关性

    6、养成良好的工作习惯,工作进行到一定阶段就马上形成文档,文档应当成为工作结束和计划完成的标志

     

    阶段评审:

        阶段评审是保证质量,提高效率的好办法,但要真正让它发挥作用,还必须认认真真地明确评议的要素,划分清楚评审的职责

    1、何时进行评审

    2、谁来评审

    3、评审什么(不要陷入细节)

    4、下什么结论(避免会议没有结果或形不成决议、无人下结论或拍板)

     

    产品测试:

    测试过程规范各阶段输出:

    1、产品计划阶段

           SVVP、WBS 

    2、需求分析阶段

           系统测试计划

    3、概要设计阶段

           集成测试计划

           系统测试方案

    4、详细设计阶段

           单元测试计划

           集成测试方案

           系统测试用例,规程

           系统预测试用例

    5、编码和单元测试阶段

           单元测试方案

           单元测试报告

           集成测试用例,规程

           系统测试用例,规程

    6、集成测试(执行)阶段

           集成测试报告

    7、系统测试(执行)阶段

           系统预测试报告

           系统测试报告

    标准化管理:

    •          公用基础模块是在不牺牲差异的情况下优化公用和重用

    可靠性管理:

    产品的可靠性主要包括三方面内容:

    1、产品的可靠性:在规定的条件下,规定的时间内,产品执行所需功能的能力。指标为可靠度和平均失效间隔时间MTBF

    2、产品的可用性:产品在一未知时刻,需要执行任务时,处于可工作可使用状态的特性,主要指标为可用度

    3、产品的可维修性:在规定条件下使用产品在规定的时间内,按规定的程序和方法进行维修时,保持或恢复到能完成规定功能的能力。主要指标为:平均维修时间MTTR

     

    可靠性与产品成本:

        故障成本是所有公司面临的一个问题,从成本角度来看,任何真正的质量改进,必须从降低故障成本入手,从经费的分配来看,只有增加预防成本才能有效地降低故障成本。

     

    可靠性管理包含的基本内容:

    1、系统、模块、外围设备及系统软件的可靠性要求

    2、失效报告分析与纠正系统

    3、设计质量的评审

    4、工艺质量的评审

    5、产品质量的评审

    6、已售出设备及技术状态的管理

     

    可维修性:

    可维修性包括:

    1、自含的计算机辅助故障诊断

    2、自检测

    3、模块设计

    4、模块化软件

    5、标准模块

    6、自建备件概念

    7、较少模块数量

    8、大量使用冗余技术

     

    如何在设计中构建质量:

    质量是设计出来的,在开发设计中应该注意质量的管理:

    1、文档的审核一定要全面

    2、所选元器件尽量从优选库中选择,如果是新的元器件,最好通过认证后再选取

    3、测试的过程要有详细的联调测试过程记录

    4、测试验收手册要经过详细的评审

     

    设计更改及维护:

    产品设计更改是开发过程中的经常现象,往往导致软、硬件版本的不一致和系统新的错误,项目的设计更改需要严格的控制。维护是软件在交付用户之后的设计更改,由于已经发布给用户,维护和版本升级更需要严格的控制。

    1、软件开发的很大一部分资源花在更改和优化原有的设计上,对设计更改决不能持一种“改一改就行”的态度,要充分重视

    2、维护占软件开发费用和软件生命周期的一半以上,设计更改更是大量地在维护中实现,由于维护阶段软件已经发布,维护时更加要注重质量,加大测试的力度

    3、软件的更改不是影响系统一部分的质量,而是影响很大一部分甚至是整个系统的质量,必须进行回归测试

    4、更改后的软件必须经过充分测试,相关部门审查通过之后才能归档和发布

     

     

     

    风险管理:

    公开讨论风险,让所有人动脑思考风险, 发现风险及时反馈。

    建立风险控制文档,让所有人一起动脑想解决方法。

    对上: 把问题困难反映到领导层,不要期待都要项目组自我负担.

     

     

    开发原则(RUP最佳实践)

    迭代展示价值

    实践1.管理风险

    实践2.在迭代中执行项目

    实践3.采纳并管理变更

    实践4.客观地度量进展

    持续关注质量

    实践5 测试你的代码

    实践6 适当利用自动测试

    实践7 产品属于每一个人

    平衡利益相关者优先级

    实践8 了解领域

    实践9 从用户的角度描述需求

    实践10按优先级实施需求

    实践11利用遗留系统

    团队间的协作

    实践12 建立高绩效的团队

    实践13 围绕架构进行组织

    实践14 管理版本

    提高抽象级别

    实践15 利用模式

    实践16面向组件与服务的架构

    实践17 积极推进重用

    实践18 对主要观点建模

    适应过程

    实践19 合理精简过程

    实践20 不断重新评价你在做什么

    项目经理实际操作

    项目启动

    项目一开始必须要不断给项目组灌输管理理念。

    对团队精神,互助,互督,沟通, 项目对每个人都很重要

    让每个人参于制定规范,执行规范,监督规范执行。

    做好自我测试,产品是属于每个人。

     

    项目组长 组成

    从项目启动并组织核心团队—项目组长

     

    项目开始:制定规范:

    1.       项目组开发设计规范

    2.       项目成员沟通规范

    3.       项目考核规范

    4.       项目现场行为规范

    5.       项目编码规范

     

    项目开始:制定文档模板

    制定各种文档模板(需求说明,数据库,概要设计,详细设计,开发说明)

    用旧的系统演示或采用(UI界面图进一步的演示)

     

    制定管理计划

    《管理计划v.1》

    《考核表v.1》

    需求阶段

    跟客户沟通需求-> 用户角度描述需求 :及时确认需求并现场签字确认

     

    跟客户沟通注意事项:

    1. 关键开发人员必须到场

    2. 及时把会议纪录汇总,签字确认

    3.  

    需求确认注意事项

    及时审查需求文档

     

    完成文档

    《需求规格说明》

    《计划时间表》

    《管理计划v.2》

     

    注意事项

    设计阶段

    要多次评审内部设计。

    对于共用的部份要及时推进。

     

    完成文档

    《数据库设计》

    《概要设计》

    《详细设计》

    《架构及共用设计》

    《开发说明》

    注意事项

    做好配置管理,

    做好版本控制

     

    开发阶段

    做好配置管理

    项目经理面临的困难及解决

    1.       项目人员不足(向领导追要人员当处理过晚不断向上反应)

    2.       项目人员开发经验不足(培训)

    3.       项目人员冲突(对事不对人,增加沟通机会)

    4.       需求确认过晚(当处理过晚不断向上反应)

    5.       需求规格未及时签名确认(当处理过晚不断向上反应)

    6.       开发技术不确认不成熟(关键技术必须要经过项目组评估)

    7.       进行重复相似工作(前期必须要把重复工作独立先做)

    8.       整体流程无法跑下去(关键点要先做,优先级完成需求)

    9.       道理明白可实际上却无法操作(把问题提出来,让所有人参于解决方案)

    10.   当遇到问题无法解决,及时向上反映

     

     

    参考文档

    敏捷与秩序—RUP最佳实践》Per Kroll , Bruce Macisaac清华大学出版社

    《现代管理学》张德 清华大学出版社

    《软件项目管理理论与案例分析》吴吉义 中国电力出版社

    《哈佛模式.项目管理》

    《亲和力》

    《领导力》

    展开全文
  • 项目检查各种情况,并在检测到异常行为时提供报告。 此项目捆绑了以下运行状况检查: 快取 数据库 贮存 磁盘和内存利用率(通过psutil ) AWS S3存储 芹菜任务队列 芹菜坪 兔子MQ 移居 编写自己的自定义运行...
  • 软件项目计划时常犯的一些错误: 1 任务的颗粒度悬殊太...3 只了工作量估计,没有规模估计  4 只凭1或者2个人的经验进行估计,没有采用规范的估计方法  5 没有计划偏离的控制阀值  6 没有获得项目组成员对计划



    软件项目计划时常犯的一些错误

    项目计划评审时的检查点(checklist)

    成功进行软件项目策划的基本要点



    软件项目计划时常犯的一些错误

    1 任务的颗粒度悬殊太大 
    2任务的识别不全面,如:
    没有识别出计划(PP,PPQAP,CMP,MAP等)评审的任务 
    没有识别出来计划修订的任务 
    模块间集成的任务没有识别出来 
    3 只做了工作量估计,没有做规模估计 
    4 只凭1或者2个人的经验进行估计,没有采用规范的估计方法 
    5 没有计划偏离的控制阀值 
    6 没有获得项目组成员对计划的承诺 
    7 在schedule中没有缓冲任务 
    8 当1个人干多个项目时,没有个人工作计划   
    9 没有书面的项目计划,任务安排依靠口头传达 
    10没有识别出关键路径 
    11没有定义项目的生周期模型 
    12没有识别出可以复用已有构件的活动 




    项目计划评审时的36个检查点(checklist)

    在多次的运行检查中,发现很多项目的计划存在一些共性问题,根据这些问题,归纳出来36个检查点供大家参考. 

    1   是否定义了项目的组织结构
    2   是否定义了每种角色的职责? 
    3   PPQA是否有独立的渠道和高层沟通? 
    4   如果有客户或客户代表的参与,是否定义了他们的职责? 
    5   是否定义沟通了机制?(和客户的,和其他外部和伙伴的,内部成员的,和上级的,和其他项目组的) 
    6   是否定义了度量数据、各种报告的报告机制? 
    7   是否定义了问题解决机制? 
    8   是否记录了选择生命周期模型的理由 
    9   是否划分了开发过程的里程碑? 
    10   是否定义了每个里程碑的结束准则?结束时间? 
    11   是否记录了选择某种估算方法的理由? 
    12   是否记录了借鉴的历史数据? 
    13   是否估计了系统的规模? 
    14   是否估计了系统的工作量? 
    15   是否估计了成本? 
    16   是否识别了项目的风险? 
    17   对于风险的描述是否详细而明确? 
    18   是否量化了风险的可能性、后果、时间区间与优先级? 
    19   是否对每个风险定义了缓解措施或者应急措施? 
    20   是否识别出了项目的关键路径? 
    21   是否每个人的工作量都饱满了? 
    22   是否有资源超负荷的情况? 
    23   是否明确识别了管理缓冲时间? 
    24   管理缓冲时间是否合理? 
    25   是否针对每个人的特点分配了任务? 
    26   是否每个任务的颗粒度比较均匀并控制在10人天以内? 
    27   是否明确识别了管理类的任务? 
    28   是否明确识别了集成类的任务? 
    29   是否明确识别了培训任务? 
    30   是否明确识别了评审活动? 
    31   是否明确识别了计划修订的任务? 
    32   是否明确识别了采购的任务? 
    33   是否定义了工作量、进度、质量、规模、成本偏离的控制阈值? 
    34   是否识别了本项目的交付物? 
    35   是否识别了每种交付物的管理方法? 
    36   是否定义了参考的资料,输入的资料,工作产品的管理办法?




    成功进行软件项目策划的九个基本要点

    古人云“万事预则立,不预则废”,项目要成功必须做好计划软件项目策划是项目管理过程中最基本的一个过程,软件项目策划的方法是软件项目经理必须掌握的。在实际的项目策划过程中,必须掌握以下的9个基本要点: 


    (1)掌握好项目策划的时机 

      软件项目策划过程的输出是文档化的项目计划书,在项目的不同阶段都需要进行项目策划,只不过在不同时机项目策划的目的不同,花费的工作量也不同。当有了概要的客户需求而没有形成详细的软件需求规格说明书(SRS)时,进行项目策划产生的是项目的概要计划或者是里程碑计划,当产生了详细的SRS 后,项目策划活动可以产生项目的详细计划,可以明确估计项目的规模、工作量、进度、资源等,作为项目管理的主要依据。当发生了需求变化或者项目计划与实际存在比较大的偏差时,可以对项目进行重计划。需要提醒注意的是在需求未确定的时候,进行软件的估计是比较粗略的,此时不需要在项目策划上花费太多的精力。 


    (2)任务一定要明确 

      在进行项目策划时,建立工作任务分解(WBS)是必须要做的工作,即把 
      工作拆分成一个个独立的、明确的任务,所谓明确的任务是指: 
      ● 该任务一定有一个输出结果; 
      ● 输出的格式有明确的定义; 
      ● 输出的内容有明确的检测手段与验收标准; 
      ● 任务的时间是有具体要求的。 
      上述4个判定标准有一个达不到就不能称为是一个明确的任务。在实践中,有一些任务难以定义的很明确,因为有些结果是难以预测的,比如说分析工作,具体的时间要求是难以准确预测的。任务如果不明确,就无从谈起任务是否做完了。 

      在项目组中往往由于前一阶段的工作没做好,造成后续阶段的任务难以明确定义下来。设计没有做完,编码的工作就不能定义的很清楚,就往往会造成实际的编码工作难以在要求的时间内完工,形成项目风险。 



    (3)识别的任务不要有遗漏 

      在软件策划时,常犯的一个毛病是:任务没有识别全。在项目的实际执行过程,经常出现计划外的、又必须执行的项目组的任务,而不是项目组外的干扰活动。为了识别的任务比较完备,可以建立任务识别指南以提醒项目经理。经常遗漏的任务包括: 
      ● 项目管理类的任务,如项目计划、计划的变更、计划评审等; 
      ● 横向关联类的任务,如集成任务、需求跟踪矩阵的制定与更新等; 
      ● 项目交付物的制作任务,如用户手册的编写、培训教材的编写等; 


    (4)任务的颗粒度要适中 

      在划分任务时,任务的颗粒度不能太大,也不能太小。颗粒度太大,就难以及时发现问题;颗粒度太小,就会增加管理成本。任务的颗粒度最小可以到半天,最大到周,一般以小于3天为宜,也就是说,项目经理能够在1周中至少检查2次成员的工作进展情况。适当的任务颗粒度一方面便于监控,另一方面也有利于调整任务。当出现任务拖期时,可以比较灵活地重新安排人员接手其他人员的任务。 



    (5)估计要尽可能的合理 

      为了保证估计的合理性,可以采用下面的措施: 
      ● 借助历史数据。历史数据是“经验”的量化,通过和历史项目的数据对比, 
      ● 可以降低估计的风险。需要注意的是,在借鉴历史数据的时候,要注意数据的可比性,要考察项目类型是否类似、生命周期模型是否类似等。 
      ● 采用多种估计方法互相验证。在估计时可以采用多种估计方法,然后对多种方法的结果进行对比,通过分析其差异以判断合理性。 
      ● 细分任务。任务拆分的越详细,就越容易估计,越容易和历史数据对比。 
      ● 任务要完备。在估计的时候,要识别出所有的工作内容,不要有遗漏。 
      ● 有估计经验的人参与估计。一方面要对参与估计的人员进行培训,另一方面需要在实践中积累估计经验,每次估计完成后,都要和实际的情况进行对比,经过3~5次的反复,则可以积累估计的经验,提高估计的准确性。 



    (6)识别清楚任务之间的依赖关系 
      任务和任务之间存在下面的5种依赖关系: 
      ● 输入输出关系。即A任务的输出是B任务的输入,A任务完成后,B任务才可以开始。比如编码和测试之间的关系。 
      ● 资源依赖关系。即A任务和B任务使用同一个资源,当资源为A使用时,就不能为B使用,当资源为B使用时,就不能为A使用。例如一个程序员不能同时做2个模块的开发,必须做完一个模块再做另一个模块。 
      ● 需求之间的接口关系。即A任务和B任务的输出存在接口,2个部分的输出需要组装在一起,如果组装的任务是C,则A,B任务未完成,C任务也无法开始。 
      ● 调用关系。主要是对编码任务而言,任务A的代码为任务B的代码所调用,则A必须先完成。 
      ● 采购关系。如果存在需要采购的外部构件的话,则采购行为必须先完成。 
      定义了任务之间的依赖关系,就可以识别出项目的关键路径,以重点关注关键路径。 



    (7)优先安排与系统架构有关的需求的开发 

      要优先安排关键功能需求、全局性功能需求、接口需求、非功能需求的开发,这些需求影响的范围比较广,一旦返工,工作量比较大,因此在安排任务前要先安排这些需求的设计、实现、测试与联调。在计划时若没有安排好任务的顺序,会造成在项目的后期阶段比如联调时,发现有些模块无法联调,需要写测试程序或者等待其他模块的完成。 



    (8)建立项目的里程碑 

      在项目进展的过程中,项目经理、PPQA、CM等从项目的不同的侧面对项目组的进展进行了跟踪,但是缺乏全面、系统地分析与评价,借助里程碑评审可以综合各方面的分析数据进行判断。在项目的里程碑处,一般是通过里程碑评审全面地对项目组外部的成员展示项目的进展,以判断上一阶段的工作是否完成,是否可以进入下一个阶段。很多企业往往将里程碑评审搞成了一种形式,成了走过场,这违背了里程碑评审的初衷。在里程碑评审时,要注意是否全面评价了项目组的进展?是否对项目组外面的相关人员展示了项目组的进展?如果里程碑评审仅有项目组内部的成员参加,则往往大事化小,小事化了,掩盖了真实的问题,不利于发现项目组中存在的问题。 



    (9)预留管理缓冲 

      在项目过程中总会存在突发事件和估计不准确的情况,因此可以在计划中留有缓冲时间。对于缓冲时间可以有2种设置方法,一是固定缓冲,即每周或者月等固定地留有一定缓冲时间,如半天或1天等。二是在所有的与关键路径接驳的任务之前留有固定比例的缓冲,如A任务是关键路径上的任务,B任务不是关键路径上的任务,但是B做完后,才可以做A,B和A是直接的先后时序关系,此时可以在B任务与A任务之间留有一定的缓冲时间,以降低进度风险。 

      管理缓冲应可以明确地识别出来,不要隐藏在每个任务中。 

      相信上述的9个要点一定能够给您的项目策划实践带来帮助! 


    展开全文
  • IT项目经理应该什么

    万次阅读 2012-09-28 15:02:48
    IT项目经理应该什么 经常看到这样的项目经理,一副整天忙得团团转的样子,电话不停地作响,一小时之内要发出几十指令,好像他所领导的团队离开了他就一天也活不下去。然后他还会说:"我很忙"或"我很累...
  • GitHub 上100优质前端项目整理,非常全面

    千次阅读 多人点赞 2020-06-11 20:46:58
    点击上方“Github中文社区”,关注看遍Github好玩的项目作 者:小明小明长大了来 源:https://www.jianshu.com/p/72ca8192f7b8这里整理收集了 ...
  • 为了提高项目管理水平,赢得市场竞争,特别是在加入WTO后在国内、国际市场上拥有与国际接轨的项目管理人才, --> 越来越多的业界人士正通过不同的方式参加项目管理培训并力争获得世界上最权威的职业项目经理(PMP)...
  • 现代品质治理体系(MQM)由3大系统:全体系统、工序保证系统、检查系统的共28个项目组成,全面及具体地从工厂全方位实施有效的品质治理及改善。以下对这28个项目进行简单的说明,从中一定可以感受到MQM带来的品质...
  • 体检项目介绍项 目 临床意义 一般情况身高、体重、血压 配合现场物理检查,了解身体的差异问题。 抽血 抽血(用于实验室检查) 抽取血液检查标本 X线检查 X线透视检查 利用Χ光透视胸腔,可能筛检出的疾病肺结核...
  • 个项目用什么框架?

    千次阅读 2018-06-19 12:08:20
    就拿我接触错的几种框架举例:yaf框架优点: 这框架特别nice ,速度快个人除了tp5久喜欢这框架啦用C语言开发的PHP框架, 相比原生的PHP, 几乎不会带来额外的性能开销.所有的框架类, 不需要编译, 在PHP启动的时候...
  • 在构建一maven项目的时候首先你需要你需要检查以下几方面的信息是否配置好首先你需要eclipse或者是myeclipse,然后将一svn配置到你的环境中(配置的步骤很简单一般就是直接把下载的svn的文件直接放到环境...
  • 毕业考研软件工程方向时,记得上考研辅导班老师句话对我影响颇为深刻: 软件工程是一问用工程化方法解决... 这句话对我的影响很大,我开始在日常生活中尝试应用这概念,小到作业,大到完成工作中的复杂项...
  • ThreeJs智慧城市项目后记

    万次阅读 多人点赞 2019-11-01 18:01:13
    只是会用一点ThreeJs,对于WebGl的原理并没了解过,这并不影响我们利用ThreeJs去做出一非常炫酷的项目。 开始 新世界的大门打开啦! 写在前面 不要因为不了解就被这种3D展示的项目给吓到 其实实现起来...
  • valgrind 常态内存泄露的检查

    千次阅读 2007-12-10 09:47:00
    嵌入式Linux软件中对于吃内存是比较忌讳的,嵌入式...valgrind是检测内存泄露的比较好的开源项目:http://valgrind.org/docs/download_docs.html,这是其官方帮助文档,比较全面另外有个网友写的博文介绍如何使用val
  • health4j—Java项目全面体检工具

    千次阅读 2015-01-26 19:11:02
    Java代码静态分析工具的聚合器。集成了三种主流的静态分析工具:pmd,checkstyle,findbugs。给你的项目进行全面体检,同时附带了归纳整理并提供邮件通知。
  • 禅道是易软天创出品的一款项目管理软件,集产品管理、项目管理、测试管理、文档管理、组织管理于一体,覆盖了项目管理和测试管理的核心流程。 华为软件开发云 (DevCloud )是集华为研发实践、前沿研发理念、...
  • Klocwork代码静态检查实践

    千次阅读 2017-05-03 10:43:14
    笔者曾用过两年多的Klocwork,它通过静态分析的方法,自动检测代码内存泄漏、空指针引用、缓冲区溢出、数组越界等运行错误,相比一些免费的检查工具功能强大很多,对于项目代码质量的改进作用还是比较明显的。...
  • 项目利用互联网+、大数据等新一代信息技术,构建监督检查系统,开展监督检查大数据场景应用,充分发挥新一代信息技术在监督检查工作中的作用,全面推进监督检查工作的线上线下同步开展。数据监督检查系统是思想...
  • 如何做项目或产品演示?

    千次阅读 2018-12-12 10:26:08
    项目或产品演示不是演讲,也不是答辩,更不是培训。 尽管在很多表达和现场互动技巧上,演讲,答辩,培训和演示都相通的地方。 演讲更侧重对某一问题看法的陈述,主要是交换观点,允许争鸣,听众可以不同意你的...
  • 100优秀前端开源项目

    千次阅读 多人点赞 2020-04-30 07:20:05
    codepen 一在线编辑前端项目的网站,其中一些前端大神的作品,也很多令人惊艳的前端效果,可以浏览和下载使用。 codrops 一系列具有相当具有创意且有趣的前端效果的集合,是非常棒的学习资料,可以欣赏和下载...
  • IT项目管理的三条件、五步骤

    千次阅读 2011-04-12 21:13:00
    项目是为完成某一独特的产品或服务所的一次性努力 。根据这定义,项目就具有了目标明确性、活动一次性及资源消耗性等特性。换句话说,具备前面三主要特性的活动,都可以看作是项目。现实中的项目随处可见, 如...
  • 数据结构与算法 继Java语言和Go语言的数据结构与算法之后的新一版(应该不会出Go语言版本的了)。对数据结构都加入了泛型支持,提供了相应...非常全面的边界检查。是真正可以运用在项目里的数据结构 Java版本:Go版本:
  • 如何参与一 GitHub 开源项目

    万次阅读 多人点赞 2014-04-12 20:46:13
    最近一年开源项目特别的热,很多技术大会或论坛都以开源项目作为主题进行探讨,可见这是一种趋势。...相信很多人都这方面的疑问,网上也一些参差不齐的教程教大家如何“pull request”、如何“commit”等

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 95,741
精华内容 38,296
关键字:

做个全面检查有哪些项目