精华内容
下载资源
问答
  • 软件项目管理实践之日计划 .

    万次阅读 2015-06-18 17:11:32
    软件项目管理实践之日计划 . 转载自http://www.iteye.com/topic/422908 袁光东 原创 如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究,《人月...

    软件项目管理实践之日计划 .

    转载自http://www.iteye.com/topic/422908





    袁光东 原创


    如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究,在《人月神话》、《人件》等书籍都有很详细的论述。研究表明,不同程序员之间的生产率最高差别在40倍以上。虽然笔者没有亲睹这种样例,但是笔者的开发和管理生涯中所发现的相同技术水平程序员之间的生产率最大差距可达4倍。这个数据就发生在笔者的一个项目中,这让笔者感到非常的震惊。如果说40倍的生产率差距可能会有技术能力、工作经验、熟悉程度诸多因素的影响。那么,笔者所发现的4倍生产率差距却更让笔者感到不可思议。


    案例


        程序员J:四年开发经验


        程序员L:三年开发经验


        程序员Y:五年开发经验


        技术能力:Y > J > L


        J,L,Y同时进入一个项目组,开发时间为30个工作日,即6周,包括需求分析、设计、编码和集成。其中编码和单元测试时间为10个工作日(2周)。产生的工作绩效为:


     


    程序员 规模(代码行) 
    J 1500 
    L 3600 
    Y 6000 


        可见,当程序员的技能达到一定水平后,技能与生产率并不成正比,并不是技术水平越高的程序的生产率越高。


    一、最后期限


        很多程序员都会有类似的经历:


        1月1日,项目经理说:“小张,在1月5日之前把这项工作做完,详细的需求文档我已经发到你的邮箱中。”


        1月1日,小张对需求文档瞥了几眼,估计2天就可以完成,嘀咕:“现在才是1月1日嘛。这项任务要1月5日才提交。我还有时间,不用管它,还是先看我的小说吧。”


        1月2日,小张继续看他那心爱的小说......


        1月3日,小张继续看他那心爱的小说......


        1月4日 9:00,小张开始看需求文档,2小时后中断,因为他需要修复系统的一个Bug。


        1月4日 18:00,小张正在埋头苦干,因为明天就要提交工作,可是一个代码还没有写呢。


        1月4日 23:00,小张完成大部分工作,下班走人。


        1月5日 9:00,项目经理问:“小张,那个功能做完了吧?”小张答道:“就快了,今天提交没有问题。”


        1月5日 14:00,小张发现有一部份代码需要重写。用户的要求是需要一个可配置的功能,而小张却写成了硬代码。


        1月5日 17:00,项目经理来到小张面前:“小张,你中午不是说今天提交没有问题吗?怎么现在还没有看你提交代码?”小张委屈地答道:“经理,遇到一点小麻烦。不过相信我,下班之前一定完成。”


        1月5日 18:00,项目经理急匆匆赶到小张的座位旁:“小张,请马上提交代码,不然就来不及了。”小张这时也急了:“你不要催我。这个功能麻烦大了,没有想象得那么简单。我今天晚上得加班。”项目经理无可奈何地走了。小张加班到凌晨1点。但程序还是有一些问题。


        1月6日,小张仍然在修改程序......


        1月7日,小张仍然在修改程序......


        1月8日,总算是修改完成。已经拖了三天,来不及测试,只能匆匆把代码提交。


        后来,又经过5次修改,直到1月20日,这个功能总算是彻底完成。


        小张向项目经理请了一周假。因为这两周来几乎每天晚上都是加班解决问题。


        许多的程序员还会有这样的经历:


        4月1日,项目经理:“小王,这个功能交给你,需求你看了吗?你看需要多长时间完成?”


        小王:“哦,经理,这个功能我刚看过,大约需要1周时间。”


        项目经理:“那就是4月5日可以提交啦?”


        小王:“是的,经理。这个功能内容很多,还要实现一个邮件功能,4月5日能提交已经是我的极限了。”


        项目经理:“那就4月5日吧。”


        4月2日,小王发现:系统中已经有一个类似的邮件功能,直接使用就可以。


        4月2日 18:00,小王已经把功能都完成了。


        4月3日 9:00,小王把功能都测试通过,并且还私下请用户帮他进行测试通过。


        4月3日 11:30,项目经理:“小王,那个功能做完了吗?”


        小王:“经理,正在做呢。你看,昨天你又叫我修改另外一个Bug。不过,经理你放心吧,4月5日一定可以提交。”(小王已经做完工作,但声称没有做完。)


        4月4日,小王专注的看着一本电子书,名字叫《The Deadline》。


        4月5日 15:00,小王把代码提交,并向经理发邮件,主题是:XXX功能已经完成。


        4月6日 9:00,项目组开会,项目经理表扬了小王,要求大家向小王学习。因为这次发布只有小王按时完成了工作。


        简直不可思议,我们的程序员就是这样工作的。是的,我也认为不可思议!可是哪个程序员敢保证自己没有这么干过呢?这就是所谓的最后期限:人们总是在最后期限才开始工作


    二、热衷于加班


        在所有的软件项目组中,加班已经成了天经地义的事。甚至有些管理层认为,如果一个项目组不加班,说明项目组没有尽全力的去做事。我至今不明白这是什么道理,工作是否尽力与加班到底有何关系?工作的绩效又与加班有何种关系?


        在笔者的项目组中,笔者的客户方也曾对笔者要求项目组必须加班,遭到了笔者的拒绝。在保证每个阶段在不加班的情况下按期完成,客户方才勉强同意。事实证明,不加班也是可以把项目做完的,而且可以做得更好。


        在我的程序员生涯中,曾经两次长达4个月的封闭开发期,被要求每天从19:00-22:00集体加班。但实际情况是,每天都可能要在23:00之后才可以下班。因为项目经理没有走,所以其它开发人员也只能留下。痛苦的是,我在那段加班时间里除了看技术电子书外,找不到任何可做的事情。我相信,当时项目组有太多的人跟我一样。当我每天23:00回到宾馆时,已经完全麻木了。我无时不想那该死的项目早一天结束。在那段时间里,我最大的收获时进行了大量技术积累。项目结束时,我的加班记录累计长达30人天。


        甚至有些程序员在正常的工作时间里也是不做事的,下班前开始忙碌,加班干活。想想这样的加班又有什么效果呢?


    三、工作成熟度与团队成熟度


        因此,我一直致力于研究提高个人工作绩效的方法和提高项目组工作绩效的方法。


        在长期的学习、摸索、实践中,我发现全心的投入工作,干好4个小时就足以把工作做好。这种全心投入产生的绩效要比以前一周所干的还要多。如果每天努力干好8个小时,你会比周围的人产生2倍以上的绩效,当然也会非常疲惫。


        在管理一个40人规模的团队时,我每天投入仅仅4个小时就足够。为什么会有这么高的工作效率?主要是长期坚持下面的方法:


        1.日计划,列出工作清单(列出当天需要做的事情)


        2.为任务划优先级(标出当天必须完成的事情)


        3.只做最重要的事情,而不是最紧急的事情


        4.绝不拖延,计划当天必须完成的事情就一定要做完才走。


        笔者长期以来在思考,这个方法能否帮助团队提高工作绩效?能否让项目组提高生产率?能否使项目按期交付和提前交付?能否帮助程序员在不加班的情况下把项目做好?


        在笔者带项目和监控项目的过程中发现,程序员工作效率不高的原因除了技能因素外,还有几个重要的因素在影响着程序员的工作绩效:


        1.工作无计划:很多程序员根本不知道每天要做哪些事情,每天必须做完哪些事情。很少有程序员对当天的工作进行计划,


        2.工作无重点:很多程序员通常按事情发生的先后顺序来做事。有时,有些程序员忙碌了一天下来却发现当天其实没有做什么有用的事情。


        3.工作无目的:程序员不知道当天要把事情做到什么程度,完全是凭心情做事,凭良心做事。事情没有做完,别人下班自己也跟着下班,认为反正明天还有时间,还没有到最后期限。


        4.工作不到位:工作起来总是觉得差不多就行。把代码写完和功能能够运行当作两回事情。工作到位就是一次就把工作做好,达到可交付。


        5.工作无积极性:被动式工作,就算工作做完也不提交,一定要等到最后期限才提交。如果比承诺时间提前提交工作,马上就会带来新的工作,多干和少干一个样,谁愿意多干呢?


        我们可以提出一个概念叫做“工作成熟度”。工作成熟度高的程序员通常会有计划性、工作有重点、有目的性、工作做到位。而成熟度低的程序员通常是无计划的,工作不分轻重,很容易被突发事件打断当前工作,工作要通过多次修改才能够完成。所以,我发现,工作成熟度对程序员生产率造成最直接的影响。


        笔者在监控项目的过程中也发现造成项目组效率低下、进度落后的一些因素:


        1.项目经理不了解项目当日状态。是的,有些项目经理根本不知道今天每个程序员会干些什么?该干些什么?


        2.项目经理不了解项目实情。没错,项目经理根本就不知道每个程序员当天干了多少活,干到什么程度,还要干多久?也就不知道项目到了什么程序,还有多少工作量要做?


        3.项目经理不知道每个人是否能够按期交货。项目经理只能是望天收成,期望程序员凭良心、凭职业道德做事。但是,至于程序是否能够按期交货,只有鬼才知道。


        4.项目经理不知道工作的重点是什么?哪些工作是本阶段必须要完成的?哪些是可以拖后的?


        5.不良沟通。项目组的沟通不良,产生大量重复代码。甚至会有两个程序同时开发一个功能,但是彼此间却不知道。


        6.信息不能共享。程序员彼此之间不知道别人干得怎么样?也不知道项目整体情况到底怎么样?这也难为程序员了,因为项目经理也不知道。


        糟糕的项目都存在着一个黑洞。通常会是在编码阶段,整个项目组就像在黑洞中穿行一样,谁也看不清对方,不知道黑洞的尽头在哪里,谁也不知道走过多少地方,还要多久才能走出黑洞。总之,项目经理只能拼命的喊:“快点,快点,兄弟们,我们的时间不多了。”所以,项目经理只能让所有的人每天加班,星期六不能休息,到最后,星期天也不能休息。


        这就是我们可以提出的另一个概念——“团队成熟度”。


        “噢,伙计,我已经听烦了。好像是有那么回事!可是又能怎么样呢?所有的项目不都是这样过来的吗?”


    四、日计划做什么?


        程序员的工作成熟度直接影响了程序员的生产率;项目的团队成熟度直接影响了项目的生产率。如果我们能够提高程序员工作成熟度和团队成熟度,就一定可以提高项目的生产率。


        而程序员工作成熟度和项目团队成熟度的共同核心点就是计划。在笔者的研究和实践过程中,可以通过在项目中实施日计划来提高程序员的工作成熟度和项目的团队成熟度,从而提高程序员的生产率和项目的生产率。


        实施日计划的流程:


        1.每天8:30-8:35,项目组召开晨会。由项目经理列出每个开发人员的工作清单,并对每个工作任务标注优先级别,设定任务完成的标准,指明当日必须要完成的任务,并得到责任人的承诺。


        2.每天下班前20分钟,由项目经理依次检查开发人员的工作。评定工作是否完成。如果有开发人员未能完成任务,一起分析任务未能完成的原因。然后召开一个简单的会议,介绍当天工作的完成情况及当前阶段的项目状态,未完成任务的开发人员需要加班完成。


        每天早晨的会议我们称之为晨会,下午的会议称之为夕会。


        日计划的实施环节:设定目标,制定计划,检查,反馈。


        日计划的特点:


        1.开发人员每天在晨会承诺完成的任务必须当天完成,提倡日清日结。


        2.提交可交付的成果。(事先制定任务完成的标准,并由项目经理进行检查,评定任务是否完成。)


        3.做最重要的事情


        4.保证把工作做完


    五、我们是怎么实施日计划的?


        日计划看起来非常简单,下面我们将对日计划的实践进行讨论。


        1.实施日计划对项目有什么作用?


        · 实施日计划,使项目有良好的沟通机制。每个开发人员都非常清楚项目的当前情况:项目已经完成了多少?还有多少工作没有完成?


        · 日计划提倡可交付的成果,也就是每天完成的工作都一定是可交付的。


        · 日计划提倡只做最重要的事情,使项目抓住了重点。


        · 项目经理通过实施日计划,非常清楚每个开发人员每天需要完成哪些任务,每天必须完成哪些任务,以及每个人的完成情况怎么样?项目经理充分地掌握了项目的情况,可以及时调整计划,应对各种变化。


        · 日计划实现了项目的良好沟通,每项任务都由开发人员和项目经理达成一致。


        · 日计划通过晨会和夕会实现了项目组的信息共享。


        2.实施日计划对程序员的作用


        · 日计划列出了程序员每天要做的任务清单,并且对任务确定优先级。


        · 对程序员的工作指明方向,并且要求程序员优先做最重要的任务,使程序员抓住了工作重点。


        · 日计划要求提交可交付的成果,要求程序员把工作一步要做到位,养成良好的习惯。


        · 日计划提高了程序员的工作绩效,程序员可以回到正常的工作时间,减少无谓的加班。


        · 程序员比以前完成更多的工作而获得奖励。


    3.在实施日计划时,与传统项目管理的工作分配有什么不同?如何进行工作分配?


        传统项目管理的工作分配中,工作项的粒度比较粗。每一个工作项通常指一个功能。通常是把一个功能分给某程序员,甚至把一个模块分派给某个程序员。工作项的工时以周为单位,通常是一周或者两周。


     


    传统项目管理任务分配表 模块 功能  当前状态 计划开始 计划结束 实际开始 实际结束 责任人 
    订单管理  订单信息查询 已开始 2009-3-1  2009-3-7 2009-3-1    L 
    新增订单 已开始 2009-3-1  2009-3-7 2009-3-1    L 
    订单管理 修改订单 未开始 2009-3-1  2009-3-7     L 
    删除订单 未开始 2009-3-1  2009-3-7     L 


        实施日计划的工作分配中,“工作项”的粒度更小。如果按照XP和Scrum的说法,功能就是指一个“故事”,完成“功能”的步骤或事件叫“任务”。


        传统项目管理的任务分配是以“故事”为最小粒度。日计划的任务分配是以“任务”为最小粒度。“任务”是指完成某一个“功能”的步骤或事件。每个人当天的任务工时总合为1人天。


        故事和任务的区别:


     


    故事 任务 
    订单信息查询 DAO编码  
    DAO单元测试  
    业务层编码 
    JSP表示层编码  
    集成测试 


        要实现订单信息查询就由右边的那些任务组成。


        开始,我不知道怎样来描述一个“功能”和实现一个功能细化的“任务”。后来,当我看到Scrum的书籍后,看到Sprint和任务板时,才知道自己的实践与Scrum的某些实践竟有如此相似之处。我困惑很久,想不到用什么词来表示一个“功能”和实现一个功能所需要的“步骤”。Scrum使用“故事”和“任务”来定义它们,我认为非常的准确到位。


        但是日计划的工作分配与Scrum的工作分配是不同的。实施日计划是由项目经理主导的;而Scrum强调由程序员主导。至于这两种方式,哪一种更好。我觉得可以结合具体的情况进行不同的实践。


        如果是程序员成熟度比较高的项目,可以由程序员来主导。程序员成熟度较低和工期很紧的项目,可以由项目经理来主导。总之,这都需要程序员和项目经理达成一致。程序员需要向项目经理承诺。


        Scrum会对每个任务进行事先估算,而日计划分配工作任务前才会进行估算,并且只为每个人分配工作量为1人天的任务总和。


     


    日计划样例:2009-3-22程序员L工作计划 开发人员  今日计划工作及完成情况 
    序号 工作任务 优先级 完成标准 是否完成 完成百分比 完成情况 未完成原因 检查人 
    L 1 订单管理模块DAO实现 50 单元测试通过           
    2 与用户确认页面原型 10 用户确认邮件           


        程序员L任务1的优先级为50,任务2的优先级为10。这并不表示两个任务的重要程度相差40,而是表示L当天应该先做任务1,再做任务2。


        笔者认为这种日计划更加灵活。因为项目经理可以灵活的设置任务。Scrum的任务都是依据故事。日计划甚至可以把与开发根本不相干的事情包括进来。


        当天要完成哪些任务是由项目经理先计划的,但是程序员可以提出不同的意见。双方达成一致。并且任务是可以量化和检查的。因此,事先还要设置完成标准。一旦程序员与项目经理达成一致,就相当于程序员向项目经理承诺,今天可以完成这些任务。


        对于成熟度比较高的程序员,完全可以由程序员先提出计划。然后,由项目经理进行评估和检查。双方达成一致后,就把任务放入日计划的工作任务表中。


    4.为什么要检查?怎么进行检查?


        如果没有检查,计划就是无效的。


        日计划强调提交可交付的成果。虽然事先制定了标准,但是程序员和项目经理可能会对可交付成果的理解不同。项目经理如果要清楚地了解到项目状况就必须要亲自进行检查。


        如何进行检查?项目经理一定要在现场工作,最好的办法就是让他演示给你看。对于不能演示的任务就进行抽查。因为事先已经制定完成标准,大家只需要按规矩办事即可。


        并且一定要填写完成情况,以便后期的跟踪。


        5.如果程序员不能完成日计划怎么办?如何才能够使程序员能够完成日计划?


        程序员不能完成日计划时,也就是进度出现了偏差。项目经理一定要与程序员一起分析偏差的原因,并记录下来。进度发生偏差最有可能的两个原因:计划不合理和计划执行不力。


        计划不合理包括:对任务的难度和工作量估算失误,对程序员能力的估算失误,或者程序员的工作方法存在问题,需要支持和协助等。


        如果是对任务估算发生失误,就需要重新进行估算。这正是日计划和检查带来的好处。项目经理需要重新调整计划。


        如果是对程序员能力估计失误,项目经理也需要重新进行调整,如换人,或延长时间。


        如果是程序员工作方法存在问题,就一定要进行指导,或者安排其它人员进行协助。


        如果是计划执行不力,也要找到最核心的原因是什么?是意愿不高?中间去做其它事情?工作习惯如此?都需要找到核心原因,方可对症下药。


        在我的团队中,绩效考核的几个核心指标:工作效率*工作效果*工作量


        不能完成日计划,会直接影响到月底的绩效和奖金。


        如何才能够使程序员完成日计划?首先是计划一定要合理,要考虑到个体差异,分配任务在其能力范围之内。日计划一定要获得当事人的承诺。检查和跟踪一定要到位。要与考核挂勾,做到会得到什么?做不到会有什么后果?


        六、没有银弹


        是的,没有银弹。没有任何一种方法可以保证项目一定能够成功。日计划也一样。目标、计划、执行、控制构成管理的核心。所谓工作成熟度和团队成熟度其实都可以归纳为“执行力”。日计划只是一种管理实践,在不同的环境可能会有不同的实践方法,并不是一层不变的。
    展开全文
  • 软件项目管理实践之日计划

    千次阅读 2014-12-03 15:49:08
    袁光东 原创 如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。...虽然笔者没有亲睹这种样例,但是笔者的开发和管理生涯所发现的相同技术水平程序员之间的生产率最大差距

    转载自http://www.iteye.com/topic/422908

    袁光东 原创

    如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究,在《人月神话》、《人件》等书籍都有很详细的论述。研究表明,不同程序员之间的生产率最高差别在40倍以上。虽然笔者没有亲睹这种样例,但是笔者的开发和管理生涯中所发现的相同技术水平程序员之间的生产率最大差距可达4倍。这个数据就发生在笔者的一个项目中,这让笔者感到非常的震惊。如果说40倍的生产率差距可能会有技术能力、工作经验、熟悉程度诸多因素的影响。那么,笔者所发现的4倍生产率差距却更让笔者感到不可思议。

    案例

        程序员J:四年开发经验

        程序员L:三年开发经验

        程序员Y:五年开发经验

        技术能力:Y > J > L

        J,L,Y同时进入一个项目组,开发时间为30个工作日,即6周,包括需求分析、设计、编码和集成。其中编码和单元测试时间为10个工作日(2周)。产生的工作绩效为:

     

    程序员规模(代码行)
    J1500
    L3600
    Y6000

        可见,当程序员的技能达到一定水平后,技能与生产率并不成正比,并不是技术水平越高的程序的生产率越高。

    一、最后期限

        很多程序员都会有类似的经历:

        1月1日,项目经理说:“小张,在1月5日之前把这项工作做完,详细的需求文档我已经发到你的邮箱中。”

        1月1日,小张对需求文档瞥了几眼,估计2天就可以完成,嘀咕:“现在才是1月1日嘛。这项任务要1月5日才提交。我还有时间,不用管它,还是先看我的小说吧。”

        1月2日,小张继续看他那心爱的小说......

        1月3日,小张继续看他那心爱的小说......

        1月4日 9:00,小张开始看需求文档,2小时后中断,因为他需要修复系统的一个Bug。

        1月4日 18:00,小张正在埋头苦干,因为明天就要提交工作,可是一个代码还没有写呢。

        1月4日 23:00,小张完成大部分工作,下班走人。

        1月5日 9:00,项目经理问:“小张,那个功能做完了吧?”小张答道:“就快了,今天提交没有问题。”

        1月5日 14:00,小张发现有一部份代码需要重写。用户的要求是需要一个可配置的功能,而小张却写成了硬代码。

        1月5日 17:00,项目经理来到小张面前:“小张,你中午不是说今天提交没有问题吗?怎么现在还没有看你提交代码?”小张委屈地答道:“经理,遇到一点小麻烦。不过相信我,下班之前一定完成。”

        1月5日 18:00,项目经理急匆匆赶到小张的座位旁:“小张,请马上提交代码,不然就来不及了。”小张这时也急了:“你不要催我。这个功能麻烦大了,没有想象得那么简单。我今天晚上得加班。”项目经理无可奈何地走了。小张加班到凌晨1点。但程序还是有一些问题。

        1月6日,小张仍然在修改程序......

        1月7日,小张仍然在修改程序......

        1月8日,总算是修改完成。已经拖了三天,来不及测试,只能匆匆把代码提交。

        后来,又经过5次修改,直到1月20日,这个功能总算是彻底完成。

        小张向项目经理请了一周假。因为这两周来几乎每天晚上都是加班解决问题。

        许多的程序员还会有这样的经历:

        4月1日,项目经理:“小王,这个功能交给你,需求你看了吗?你看需要多长时间完成?”

        小王:“哦,经理,这个功能我刚看过,大约需要1周时间。”

        项目经理:“那就是4月5日可以提交啦?”

        小王:“是的,经理。这个功能内容很多,还要实现一个邮件功能,4月5日能提交已经是我的极限了。”

        项目经理:“那就4月5日吧。”

        4月2日,小王发现:系统中已经有一个类似的邮件功能,直接使用就可以。

        4月2日 18:00,小王已经把功能都完成了。

        4月3日 9:00,小王把功能都测试通过,并且还私下请用户帮他进行测试通过。

        4月3日 11:30,项目经理:“小王,那个功能做完了吗?”

        小王:“经理,正在做呢。你看,昨天你又叫我修改另外一个Bug。不过,经理你放心吧,4月5日一定可以提交。”(小王已经做完工作,但声称没有做完。)

        4月4日,小王专注的看着一本电子书,名字叫《The Deadline》。

        4月5日 15:00,小王把代码提交,并向经理发邮件,主题是:XXX功能已经完成。

        4月6日 9:00,项目组开会,项目经理表扬了小王,要求大家向小王学习。因为这次发布只有小王按时完成了工作。

        简直不可思议,我们的程序员就是这样工作的。是的,我也认为不可思议!可是哪个程序员敢保证自己没有这么干过呢?这就是所谓的最后期限:人们总是在最后期限才开始工作

    二、热衷于加班

        在所有的软件项目组中,加班已经成了天经地义的事。甚至有些管理层认为,如果一个项目组不加班,说明项目组没有尽全力的去做事。我至今不明白这是什么道理,工作是否尽力与加班到底有何关系?工作的绩效又与加班有何种关系?

        在笔者的项目组中,笔者的客户方也曾对笔者要求项目组必须加班,遭到了笔者的拒绝。在保证每个阶段在不加班的情况下按期完成,客户方才勉强同意。事实证明,不加班也是可以把项目做完的,而且可以做得更好。

        在我的程序员生涯中,曾经两次长达4个月的封闭开发期,被要求每天从19:00-22:00集体加班。但实际情况是,每天都可能要在23:00之后才可以下班。因为项目经理没有走,所以其它开发人员也只能留下。痛苦的是,我在那段加班时间里除了看技术电子书外,找不到任何可做的事情。我相信,当时项目组有太多的人跟我一样。当我每天23:00回到宾馆时,已经完全麻木了。我无时不想那该死的项目早一天结束。在那段时间里,我最大的收获时进行了大量技术积累。项目结束时,我的加班记录累计长达30人天。

        甚至有些程序员在正常的工作时间里也是不做事的,下班前开始忙碌,加班干活。想想这样的加班又有什么效果呢?

    三、工作成熟度与团队成熟度

        因此,我一直致力于研究提高个人工作绩效的方法和提高项目组工作绩效的方法。

        在长期的学习、摸索、实践中,我发现全心的投入工作,干好4个小时就足以把工作做好。这种全心投入产生的绩效要比以前一周所干的还要多。如果每天努力干好8个小时,你会比周围的人产生2倍以上的绩效,当然也会非常疲惫。

        在管理一个40人规模的团队时,我每天投入仅仅4个小时就足够。为什么会有这么高的工作效率?主要是长期坚持下面的方法:

        1.日计划,列出工作清单(列出当天需要做的事情)

        2.为任务划优先级(标出当天必须完成的事情)

        3.只做最重要的事情,而不是最紧急的事情

        4.绝不拖延,计划当天必须完成的事情就一定要做完才走。

        笔者长期以来在思考,这个方法能否帮助团队提高工作绩效?能否让项目组提高生产率?能否使项目按期交付和提前交付?能否帮助程序员在不加班的情况下把项目做好?

        在笔者带项目和监控项目的过程中发现,程序员工作效率不高的原因除了技能因素外,还有几个重要的因素在影响着程序员的工作绩效:

        1.工作无计划:很多程序员根本不知道每天要做哪些事情,每天必须做完哪些事情。很少有程序员对当天的工作进行计划,

        2.工作无重点:很多程序员通常按事情发生的先后顺序来做事。有时,有些程序员忙碌了一天下来却发现当天其实没有做什么有用的事情。

        3.工作无目的:程序员不知道当天要把事情做到什么程度,完全是凭心情做事,凭良心做事。事情没有做完,别人下班自己也跟着下班,认为反正明天还有时间,还没有到最后期限。

        4.工作不到位:工作起来总是觉得差不多就行。把代码写完和功能能够运行当作两回事情。工作到位就是一次就把工作做好,达到可交付。

        5.工作无积极性:被动式工作,就算工作做完也不提交,一定要等到最后期限才提交。如果比承诺时间提前提交工作,马上就会带来新的工作,多干和少干一个样,谁愿意多干呢?

        我们可以提出一个概念叫做“工作成熟度”。工作成熟度高的程序员通常会有计划性、工作有重点、有目的性、工作做到位。而成熟度低的程序员通常是无计划的,工作不分轻重,很容易被突发事件打断当前工作,工作要通过多次修改才能够完成。所以,我发现,工作成熟度对程序员生产率造成最直接的影响。

        笔者在监控项目的过程中也发现造成项目组效率低下、进度落后的一些因素:

        1.项目经理不了解项目当日状态。是的,有些项目经理根本不知道今天每个程序员会干些什么?该干些什么?

        2.项目经理不了解项目实情。没错,项目经理根本就不知道每个程序员当天干了多少活,干到什么程度,还要干多久?也就不知道项目到了什么程序,还有多少工作量要做?

        3.项目经理不知道每个人是否能够按期交货。项目经理只能是望天收成,期望程序员凭良心、凭职业道德做事。但是,至于程序是否能够按期交货,只有鬼才知道。

        4.项目经理不知道工作的重点是什么?哪些工作是本阶段必须要完成的?哪些是可以拖后的?

        5.不良沟通。项目组的沟通不良,产生大量重复代码。甚至会有两个程序同时开发一个功能,但是彼此间却不知道。

        6.信息不能共享。程序员彼此之间不知道别人干得怎么样?也不知道项目整体情况到底怎么样?这也难为程序员了,因为项目经理也不知道。

        糟糕的项目都存在着一个黑洞。通常会是在编码阶段,整个项目组就像在黑洞中穿行一样,谁也看不清对方,不知道黑洞的尽头在哪里,谁也不知道走过多少地方,还要多久才能走出黑洞。总之,项目经理只能拼命的喊:“快点,快点,兄弟们,我们的时间不多了。”所以,项目经理只能让所有的人每天加班,星期六不能休息,到最后,星期天也不能休息。

        这就是我们可以提出的另一个概念——“团队成熟度”。

        “噢,伙计,我已经听烦了。好像是有那么回事!可是又能怎么样呢?所有的项目不都是这样过来的吗?”

    四、日计划做什么?

        程序员的工作成熟度直接影响了程序员的生产率;项目的团队成熟度直接影响了项目的生产率。如果我们能够提高程序员工作成熟度和团队成熟度,就一定可以提高项目的生产率。

        而程序员工作成熟度和项目团队成熟度的共同核心点就是计划。在笔者的研究和实践过程中,可以通过在项目中实施日计划来提高程序员的工作成熟度和项目的团队成熟度,从而提高程序员的生产率和项目的生产率。

        实施日计划的流程:

        1.每天8:30-8:35,项目组召开晨会。由项目经理列出每个开发人员的工作清单,并对每个工作任务标注优先级别,设定任务完成的标准,指明当日必须要完成的任务,并得到责任人的承诺。

        2.每天下班前20分钟,由项目经理依次检查开发人员的工作。评定工作是否完成。如果有开发人员未能完成任务,一起分析任务未能完成的原因。然后召开一个简单的会议,介绍当天工作的完成情况及当前阶段的项目状态,未完成任务的开发人员需要加班完成。

        每天早晨的会议我们称之为晨会,下午的会议称之为夕会。

        日计划的实施环节:设定目标,制定计划,检查,反馈。

        日计划的特点:

        1.开发人员每天在晨会承诺完成的任务必须当天完成,提倡日清日结。

        2.提交可交付的成果。(事先制定任务完成的标准,并由项目经理进行检查,评定任务是否完成。)

        3.做最重要的事情

        4.保证把工作做完

    五、我们是怎么实施日计划的?

        日计划看起来非常简单,下面我们将对日计划的实践进行讨论。

        1.实施日计划对项目有什么作用?

        · 实施日计划,使项目有良好的沟通机制。每个开发人员都非常清楚项目的当前情况:项目已经完成了多少?还有多少工作没有完成?

        · 日计划提倡可交付的成果,也就是每天完成的工作都一定是可交付的。

        · 日计划提倡只做最重要的事情,使项目抓住了重点。

        · 项目经理通过实施日计划,非常清楚每个开发人员每天需要完成哪些任务,每天必须完成哪些任务,以及每个人的完成情况怎么样?项目经理充分地掌握了项目的情况,可以及时调整计划,应对各种变化。

        · 日计划实现了项目的良好沟通,每项任务都由开发人员和项目经理达成一致。

        · 日计划通过晨会和夕会实现了项目组的信息共享。

        2.实施日计划对程序员的作用

        · 日计划列出了程序员每天要做的任务清单,并且对任务确定优先级。

        · 对程序员的工作指明方向,并且要求程序员优先做最重要的任务,使程序员抓住了工作重点。

        · 日计划要求提交可交付的成果,要求程序员把工作一步要做到位,养成良好的习惯。

        · 日计划提高了程序员的工作绩效,程序员可以回到正常的工作时间,减少无谓的加班。

        · 程序员比以前完成更多的工作而获得奖励。

    3.在实施日计划时,与传统项目管理的工作分配有什么不同?如何进行工作分配?

        传统项目管理的工作分配中,工作项的粒度比较粗。每一个工作项通常指一个功能。通常是把一个功能分给某程序员,甚至把一个模块分派给某个程序员。工作项的工时以周为单位,通常是一周或者两周。

     

    传统项目管理任务分配表
    模块功能 当前状态计划开始计划结束实际开始实际结束责任人
    订单管理 订单信息查询已开始2009-3-1 2009-3-72009-3-1  L
    新增订单已开始2009-3-1 2009-3-72009-3-1  L
    订单管理修改订单未开始2009-3-1 2009-3-7  L
    删除订单未开始2009-3-1 2009-3-7  L

        实施日计划的工作分配中,“工作项”的粒度更小。如果按照XP和Scrum的说法,功能就是指一个“故事”,完成“功能”的步骤或事件叫“任务”。

        传统项目管理的任务分配是以“故事”为最小粒度。日计划的任务分配是以“任务”为最小粒度。“任务”是指完成某一个“功能”的步骤或事件。每个人当天的任务工时总合为1人天。

        故事和任务的区别:

     

    故事
    任务
    订单信息查询 DAO编码
    DAO单元测试
    业务层编码
    JSP表示层编码
    集成测试

        要实现订单信息查询就由右边的那些任务组成。

        开始,我不知道怎样来描述一个“功能”和实现一个功能细化的“任务”。后来,当我看到Scrum的书籍后,看到Sprint和任务板时,才知道自己的实践与Scrum的某些实践竟有如此相似之处。我困惑很久,想不到用什么词来表示一个“功能”和实现一个功能所需要的“步骤”。Scrum使用“故事”和“任务”来定义它们,我认为非常的准确到位。

        但是日计划的工作分配与Scrum的工作分配是不同的。实施日计划是由项目经理主导的;而Scrum强调由程序员主导。至于这两种方式,哪一种更好。我觉得可以结合具体的情况进行不同的实践。

        如果是程序员成熟度比较高的项目,可以由程序员来主导。程序员成熟度较低和工期很紧的项目,可以由项目经理来主导。总之,这都需要程序员和项目经理达成一致。程序员需要向项目经理承诺。

        Scrum会对每个任务进行事先估算,而日计划分配工作任务前才会进行估算,并且只为每个人分配工作量为1人天的任务总和。

     

    日计划样例:2009-3-22程序员L工作计划
    开发人员 今日计划工作及完成情况
    序号工作任务优先级完成标准是否完成完成百分比完成情况未完成原因检查人
    L1订单管理模块DAO实现50单元测试通过     
    2与用户确认页面原型10用户确认邮件     

        程序员L任务1的优先级为50,任务2的优先级为10。这并不表示两个任务的重要程度相差40,而是表示L当天应该先做任务1,再做任务2。

        笔者认为这种日计划更加灵活。因为项目经理可以灵活的设置任务。Scrum的任务都是依据故事。日计划甚至可以把与开发根本不相干的事情包括进来。

        当天要完成哪些任务是由项目经理先计划的,但是程序员可以提出不同的意见。双方达成一致。并且任务是可以量化和检查的。因此,事先还要设置完成标准。一旦程序员与项目经理达成一致,就相当于程序员向项目经理承诺,今天可以完成这些任务。

        对于成熟度比较高的程序员,完全可以由程序员先提出计划。然后,由项目经理进行评估和检查。双方达成一致后,就把任务放入日计划的工作任务表中。

    4.为什么要检查?怎么进行检查?

        如果没有检查,计划就是无效的。

        日计划强调提交可交付的成果。虽然事先制定了标准,但是程序员和项目经理可能会对可交付成果的理解不同。项目经理如果要清楚地了解到项目状况就必须要亲自进行检查。

        如何进行检查?项目经理一定要在现场工作,最好的办法就是让他演示给你看。对于不能演示的任务就进行抽查。因为事先已经制定完成标准,大家只需要按规矩办事即可。

        并且一定要填写完成情况,以便后期的跟踪。

        5.如果程序员不能完成日计划怎么办?如何才能够使程序员能够完成日计划?

        程序员不能完成日计划时,也就是进度出现了偏差。项目经理一定要与程序员一起分析偏差的原因,并记录下来。进度发生偏差最有可能的两个原因:计划不合理和计划执行不力。

        计划不合理包括:对任务的难度和工作量估算失误,对程序员能力的估算失误,或者程序员的工作方法存在问题,需要支持和协助等。

        如果是对任务估算发生失误,就需要重新进行估算。这正是日计划和检查带来的好处。项目经理需要重新调整计划。

        如果是对程序员能力估计失误,项目经理也需要重新进行调整,如换人,或延长时间。

        如果是程序员工作方法存在问题,就一定要进行指导,或者安排其它人员进行协助。

        如果是计划执行不力,也要找到最核心的原因是什么?是意愿不高?中间去做其它事情?工作习惯如此?都需要找到核心原因,方可对症下药。

        在我的团队中,绩效考核的几个核心指标:工作效率*工作效果*工作量

        不能完成日计划,会直接影响到月底的绩效和奖金。

        如何才能够使程序员完成日计划?首先是计划一定要合理,要考虑到个体差异,分配任务在其能力范围之内。日计划一定要获得当事人的承诺。检查和跟踪一定要到位。要与考核挂勾,做到会得到什么?做不到会有什么后果?

        六、没有银弹

        是的,没有银弹。没有任何一种方法可以保证项目一定能够成功。日计划也一样。目标、计划、执行、控制构成管理的核心。所谓工作成熟度和团队成熟度其实都可以归纳为“执行力”。日计划只是一种管理实践,在不同的环境可能会有不同的实践方法,并不是一层不变的。

    展开全文
  • 公司管理实践

    万次阅读 2019-04-30 17:35:34
    研发团队管理原则:定目标,查计划,跟进度,验结果。 定目标和列计划采用SMART原则;具体执行任务采用PDCA原则。 1 绩效考核 每个季度进行绩效考核。 1.1 考核前 发送绩效考核表,目的是让员工自评和互评,了解...

    研发团队管理原则:定目标,查计划,跟进度,验结果。
    定目标和列计划采用SMART原则;具体执行任务采用PDCA原则
    管理就相当于教练,发现各个人的优缺点,让优点不断放大,尽量改进缺点。

    1 绩效考核

    每个季度进行绩效考核。

    1.1 考核前

    1. 发送绩效考核表,目的是让员工自评和互评,了解情况;
    2. 针对每个直接管理的员工,梳理这一段时间的评价;
    3. 按照一对一对话清单,列出此次谈话点;(文末参考资料)
    4. 请每个直接管理的员工做一些简单准备,明确告知谈话时间点。

    1.2 考核中

    1. 愉悦沟通;
    2. 提出成长点;
    3. 说明存在的问题以及如何改进。

    1.3 考核后

    1. 整理考核材料,备份到个人档案中;
    2. 文档发给谈话员工。

    2 每日站会

    昨天晚上编写日报,当天早上站会会议汇报如下三点:

    1. 昨天做了哪些事情,做到何种程度
    2. 需要他人帮助或者协调
    3. 今天计划做什么事

    3 每两周迭代计划会&回顾会

    每两周周六下午3点开会,会议内容包含:

    1. 我们想做什么,未来成长成什么样,当前做到了什么程度
    2. 这段时间哪些方面工作做得好
    3. 这段时间哪些方面工作做得不好,需要哪些帮助(做的不好的地方需要列到清单,未来会议讨论改进方案)
    4. 未来两周计划

    4 每月分享会

    每次一位员工进行分享,分享自己的成长,主题不限,可以是工作中的成长、学习、生活、阅读、旅行等多方面。需要制作成PPT形式。

    参考资料

    《关键对话》
    《重新定义公司》

    一对一对话清单

    • 工作表现
      • 可以是产品交付情况或有关产品的重大进展
      • 可以是销售数据
      • 可以是消费者的意见或产品质量
      • 可以是预算数目
    • 与同事之间的关系(这对企业成员的团结一致非常关键)
      • 产品人员和工程人员的关系
      • 市场人员和产品人员的关系
      • 销售人员和工程人员的关系
    • 领导与管理
      • 你有没有对你的人员起到指导和帮助的作用?
      • 你有没有把“害群之马”清除出团队?
      • 你有没有在人才招聘上下功夫?
      • 你能否激励员工做出创举?
    • 创新(最佳实践)
      • 你是否一直在进步,是否一直思考着如何才能变得越来越好?
      • 你是否经常对新的技术、新的产品及新的方案进行思考和评估?
      • 你是否将业界或世界上最顶尖的人或企业作为对比标杆?
    展开全文
  • 实践中的增量计划

    千次阅读 2002-03-14 10:15:00
    实践中的增量计划未经允许,严禁转载本栏目内容本文经许可转载自软件工程专家网www.21cmm.com,未经CSDN许可,请勿随便转载,谢谢合作 随着系统新的增量在原增量已实现了的函数的基础上的精心设计,整体目标和约束...

    实践中的增量计划

    未经允许,严禁转载本栏目内容

    本文经许可转载自软件工程专家网www.21cmm.com

    未经CSDN许可,请勿随便转载,谢谢合作

      随着系统新的增量在原增量已实现了的函数的基础上的精心设计,整体目标和约束上的增量式开发将逐步成长为系统。这就是说,一个增量中新的函数将插入预先定义结构的早期增量,而且应满足需求一致的子规范。这种函数分配过程是引用透明性在增量式开发计划中的实际应用。因此,对增量函数的逻辑分配是基于函数间的相互关系,本身函数从属性将依赖增量内容的定义。例如,在数据库系统中,增加数据的函数通常先于删除数据的函数。在统计系统中,悼念和输入的函数通常先于分析数据和报告结果的函数。

      在一个函数依赖的系统框架项目中,大规模的管理和技术因素同样影响增量计划。

    用户需求

      用户希望某些系统功能在系统完成之前能够操作使用,这些功能一般安排在早期的增量计划中。

    明确需求

      迭代开发方法背后的共同的动机是基于这样的事实:在项目的开始,需求很少能确切地建立。利用增量式开发,用户通过对可执行增量的直接操作,提供一个待扩展系统的反馈,相对清晰的需求以两种方式影响增量计划。易变的需求实现于早期的增量,这样容易澄清。另一种方式,当影响需求的问题确定下来后,不稳定需求可能计划为稍后实现。例如,如果用户接口没有较好地建立,这种方法是早期增量的理想选择(有人会说,用户接口总是系统中最易变的,应该在早期增量中实现)。另一方面,通过一致的研究决定的需求或许安排在后期增量中。

    操作使用概率

      功能使用分布是顶层净室软件规范的一部分。系统功能期望的使用概率是由历史数据和用户估计提供建立的。期望使用概率高的系统功能在系统中得到普遍地使用,因此对测试有益。由于增量是逐步累积的,早期增量中设计的功能,在新的增量进入测试过程时,每次都需测试。因此,期望得到用户的频繁使用的系统功能应计划在早期增量中,低使用率的一些功能或许认为是可选的,如果时间允许,应计划在最后增量中实现。

    可靠性管理

      渐渐地,客房关注形式化的软件可靠性需求。Poore、Mills和Mutchler(1993)描述了基于高层设计的子系统可靠性需求的增量式计划的途径。给定一个整修系统可靠性需求和子系统间的转移概率,每个子系统的可靠性需求将被计算出来。高可靠性需求的子系统对整个系统的可靠性影响很大,应计划在早期的增量中。

    系统工程

      控制迭代在硬件设计中是一个关键的工程理论。最小机器通常在最早迭代中构造出,然后重复迭代直到完整机器被制造出为止,软件的增量式开发完全与标准硬件设计途径一样。嵌入软件的机器必须在硬件工程师和软件工程师间协调一致地工作,增量式开发是这种协调的理想构架。例如,机器在使用前必须通电。因此,系统启动软件应在嵌入式软件项目的早期增量函数中实现。

    技术挑战

      新颖的或特别复杂的组件或许对进度是一种冒险,甚至是对项目生存能力的一种冒险。如果这种工作安排在早期的增量中,这种实践将支持已存在的计划或者建议去修改计划。如果不仅项目本身是新颖复杂的,其复杂性体现在小组的实践中,那么应该对小组的工作和进度灵活性尽早做出评估。

    重用的影响与作用

      净室过程强调其经济性是通过项目中组件的重用来体现的,并在系统中设计可多处使用的“共同服务”组件。当已存在的组件标识为潜在可重用时,要在新系统中为使用而剪裁、删节、开发新组件,开发小组必须评估其相对效果。如果评估赞成重用,小组希望在早期的增量中包含这些组件,证实他们所期望的性能。新的“共同服务”组件同样期望安排在早期的增量中。因为“共同服务”组件在系统中多处使用,它们相对其他单个固定组件对系统的可靠性影响更大。因为已存在的对象或许是可重用组件,在增量开发计划中对象开发合理性通常与组件可重用的合理性相一致。

    展开全文
  • Microsoft Project项目管理实践

    万次阅读 2019-06-24 11:57:11
    目录 前言 用户使用,从认识工作界面开始 Project软件常用的功能 一、人员管理(图略) 二、进度管理(图略) ...推荐书籍:《Microsoft Project 管理实践》 前言 为了配合项目管理工作的进...
  • 管理实践总结

    万次阅读 2010-06-10 15:43:00
    华为公司研发项目经理研讨会成果汇集PSMT 质量和流程管理部整理华为技术有限公司版权所有侵权必究目录1.... 前言... 62.... 研讨实践... 62.1 场景概览... 62.2 估计困难——怎么办?... 62.2.1 估计人员经验不足...
  • 项目管理实践(一)

    万次阅读 2018-11-06 17:15:50
    项目管理实践(一)为什么要写本文本文主要内容本文适合人群1.概念篇1.1项目是什么,一句话,万物皆项目1.2项目管理是什么,一句话,管理项目1.3项目和运维的区别1.4信息系统项目1.5项目管理体系1.6项目组织结构1.7...
  • 软件质量管理实践总结

    千次阅读 2018-04-16 15:00:49
    软件质量管理实践总结文章版权由作者小小小丝和博客园共有,若转载请于明显处标明出处:http://rpc.cnblogs.com/metaweblog/xxxs目录第一章:缺陷综述第二章:需求开发与管理第三章:配置与变更管理第四章:同行评审...
  • 中国管理实践的大趋势

    千次阅读 2012-11-25 07:16:20
    中国改革开发的三十多年来,伴随着经济的腾飞,各种商业模式与管理理念接踵而至,决定商业格局与管理实践的各种因素,大商业时代背景下的驱动力无疑是决定管理实践的关键因素。然而自20世纪末跨越21世纪的三十...
  • 结合git flow,使用gitlab作为远端仓库管理实际的项目是一种可行的方式,而且这种方式对与复杂大型的项目有较好的适应方式。 git flow git flow源于Vincent Driessen2010年提出的一个分支模型: ...
  • 因新冠肺炎疫情,学校延期开学。在家时间不浪费,提高技能好机会。阿里云弹性计算联合开发者社区,推出高校“在家实影”计划,... HTPS协议互联网应用起到的安全作用是(B)6. 软件系统的可维护性评价指标不包括(.
  • IT项目管理实践经验分享

    千次阅读 2007-09-15 00:51:00
    其实我本来是想找PMP考友的,但是无人应征,又看到版主的号召,所以就贴个实践经验分享贴,也找点志同道合者交流交流实践经验吧。我的msn ccjjgg79310@msn.comEmail ccjjgg79310@yahoo.com.cn有兴趣交流的,加我吧先...
  • 软件开发过程的测试管理——软件开发项目管理的案例解说系列(五) 文/栾跃从上一期中
  • 项目管理知识实践应用浅谈

    万次阅读 2007-05-30 22:49:00
    项目管理知识实践应用浅谈 摘要: 随着信息技术的飞速发展,IT系统集成项目越来越复杂,规模也越来越庞大。由于系统集成项目的创造性及多学科参与的特点,引入项目管理,加强各学科协调配合成为IT企业当务之急。...
  • Scrum管理中的几个会议与我们的实践

    千次阅读 2013-05-10 22:33:28
    根据Scrum in Action一书第一章,可以看到有如下几个会议。Release planningProduct ...举例,该会议结束时,应该有一个类似下表一样的发布计划:如何得到上面的表,是需要一些过程和方法的,这里暂时不表。Sprint plan
  • 数据库,空值是指( C) A. 数值0 B. 空的字符串 C. 未知的值 D. 任何值 单选 2.数据库管理系统是( B) A. 操作系统的一部分 B. 操作系统支持下的系统软件 C. 一种编译系统 D. 一...
  • 按照PMBOK项目进度管理知识领域,首先项目的规划期的任务包括(1)规划进度管理(2)定义活动(3)排列活动顺序(4)估算活动持续时间(5)制定进度计划 下面我们逐条讲解一下项目进度管理知识...
  • 续:软件项目量化管理(CMMI高成熟度)实践经验谈——之概述篇
  • 而软件开发的项目管理,虽然也属于传统项目管理的范畴,但是由于软件工业本身的特点,很多传统项目管理理论中被证明行之有效的理论和方法,拿到软件开发的项目实践中却常常达不到预期的效果。软件开发的项目管理与...
  • 2005-06-27 10:56:19 ↑『璞玉』请教大家一个问题 2005-06-27 10:56:50 ↑『璞玉』项目开发计划 应该给哪些人看?谁又是最需要看的? 2005-06-27 10:58:29 青润所有相关的人员都应该看。没有谁更需要,只有根据任务...
  • 考试管理系统【软件工程实践课设报告】

    千次阅读 多人点赞 2021-02-01 14:55:43
    培养学生项目管理与团队协调沟通的能力; 掌握数据库模式设计与实现; 掌握软件工程项目的测试流程; 熟练掌握UML建模、开发、数据库设计和测试工具的使用。 二、软件工程实践需求分析能力培养 1.实践目的 ....
  • 本文描述集成测试的测试计划、测试活动过程、测试用例及执行等三部分内容实践,每部分仅举例部分实际内容供参考,以及相关测试规范。 文中推荐使用UML时序图做为测试用例测试步骤描述。
  • CTO企业技术创新作用和地位

    万次阅读 2010-07-02 12:02:00
    本文通过企业技术管理人员成功创新过程发挥的作用,从不同层面阐述了对CTO企业技术创新所起作用和地位的认识,指出CTO的成败关乎整个企业进步的成败。  〖关键词〗企业、技术管理、技术创新、CTO。 ...
  • IBM InfoSphere DataStage 集群配置管理与应用实践 跳转到主要内容 登录 (或注册) 中文 技术主题 软件下载 社区 技术讲座
  • 最佳实践:我的最小项目管理工具集 http://news.csdn.net/n/20060430/90026.html2006.04.30 作者:江南白衣 2006年JOLT大奖(http://www.sdmagazine.com)的得奖名单:企业项目管理:WelcomRisk 2.6(Welcom)缺陷...
  • 从“DMAIC”到“DMADV”阐述了六西格玛已经从单纯的六西格玛改进(IFSS)发展为六西格玛设计(DFSS),实现了质量经济性管理的新实践,论述了六西格玛管理的发展途径及其我国企业的实施六西格玛设计的前景。...
  • 计划管理法则:PDCAR

    千次阅读 2006-05-31 16:34:00
    PDCAR属于舶来品--plan计划,do it 立即实施,check it 实施检验, action again吸取教训后再次行动, record 继续备案供以后借鉴。 翻译过来又十分熟悉,只是把中国的一些传统理论变形整理,系统化一个自我修炼...
  • 敏捷开发QA如何做质量管理

    万次阅读 2017-05-18 09:08:28
    这些问题以前也思考过,笔者就是QA出身的,曾经中兴通讯做过两年多的PQA,中兴通讯的敏捷转型也遇到过这些问题。 先总结一下敏捷转型遇到的问题吧,QA的工作也是要围绕这些问题展开的: 很多公司希望采用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 56,679
精华内容 22,671
关键字:

在管理实践中计划的作用