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

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

 袁光东 原创

如何提高项目的生产率，保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究，在《人月神话》、《人件》等书籍都有很详细的论述。研究表明，不同程序员之间的生产率最高差别在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.如果程序员不能完成日计划怎么办？如何才能够使程序员能够完成日计划？

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

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

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

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

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

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

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

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

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

    六、没有银弹

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

评论

15 楼 klyuan 2009-07-17  

tuti 写道

<div class="quote_title">klyuan 写道</div>
<div class="quote_div">
 

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

   。。。

<table border="1" cellspacing="1" cellpadding="1" width="600">
<caption>日计划样例：2009-3-22程序员L工作计划</caption>
<tbody>
<tr>
<td rowspan="2">开发人员 </td>
<td colspan="9">今日计划工作及完成情况</td>
</tr>
<tr>
<td>序号</td>
<td>工作任务</td>
<td>优先级</td>
<td><span style="color: #ff0000;">完成标准</span></td>
<td>是否完成</td>
<td>完成百分比</td>
<td>完成情况</td>
<td>未完成原因</td>
<td>检查人</td>
</tr>
<tr>
<td rowspan="2">L</td>
<td>1</td>
<td>订单管理模块DAO实现</td>
<td>50</td>
<td>单元测试通过</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>2</td>
<td>与用户确认页面原型</td>
<td>10</td>
<td>用户确认邮件</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
   。。。

    日计划强调提交可交付的成果。虽然事先<span style="color: #ff0000;">制定了标准</span>，但是程序员和项目经理可能会对可交付成果的理解不同。项目经理如果要清楚地了解到项目状况就必须要亲自进行检查。

    如何进行检查？项目经理一定要在现场工作，最好的办法就是让他演示给你看。对于不能演示的任务就进行抽查。因为事先已经制定<span style="color: #ff0000;">完成标准</span>，大家只需要按规矩办事即可。

 

</div>
    我的问题是 “设定任务的完成的标准” 这件事情是怎么操作的？

    比如 谁在什么时候去做，这个标准要定到一个什么样的程度？

    这个标准又是怎么与相关人员达成理解一致的？

 

    比如说“<span style="">订单管理模块DAO实现<span style="">” 这个工作任务， 完成标准是“<span style="">单元测试通过<span style="">”。 </span></span></span></span>

    什么情况下 才能算是 单元测试通过呢？那么这个功能应该通过哪些单元测试用例呢？

    这些测试用例，又是谁在什么时候制定的呢？

 

 

 

“标准”我个人的认为是可交付成果。但是对于标准的看法往往会在PM和程序员之间产生差异。有些标准可能会是通俗约定的。比如“单元测试通过”，在每个项目组中都会有相关的规范。时间长了就成了通俗约定。
另外，要从“可交付”这个角度来看。
比如一个要完成一个功能，就一定要能够演示出来满足需求。而不是仅仅把代码写完。
关于标准谁制定，我想如果是已经约定了的就按约定的做。没有约定或难以描述的可以用数据尽量使之量化。确实是没法描述的就由项目经理说了算。

14 楼 klyuan 2009-07-17  

从楼主这个例子来说，充其量只能说 技能和代码产生行数并不成正比。
完全的得不出“并不是技术水平越高的程序的生产率越高”这样的结论来。

楼主举这样例子想必是为文章主题服务，但所得出的结论和事例本身的逻辑关系非常牵强。

tuti 写道

klyuan 写道

程序员   技术能力   规模(代码行)
J          中     1500
L          低     3600
Y          高     6000

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

从楼主这个例子来说，充其量只能说 技能和代码产生行数并不成正比。
完全的得不出“并不是技术水平越高的程序的生产率越高”这样的结论来。

楼主举这样例子想必是为文章主题服务，但所得出的结论和事例本身的逻辑关系非常牵强。
还不如不要这个例子。

非也，事实已经证明通过有效的管理手段，完全可以提高项目组的生产率。

13 楼 tuti 2009-07-17  

klyuan 写道

tuti 写道

楼主实际照这你的说法实践过吗？
效果如何？

这些实践不是我想当然的，是在项目中亲自实践的。

效果嘛，关键是要执行。

在我亲自带的项目取得的效果是非常好的。项目没有加班，每天每个人都可以完成当天的工作。
项目的进度始终在控制之中。
在我监管的项目中90%的项目是成功的。主要还是要看项目经理的制行力。
也有失败的，失败的原因是项目经理不能够支持。
有一个项目是在已经陷入了泥潭时，我进行监管。把日计划开展了起来。项目按期交付。
当我走后，那个项目团队又回到了原点。这很无耐，因为需要项目经理要有很好的执行力。
如果项目经理陷入代码中不能自拔，那项目很难成功

项目结束后，有没有回顾总结的结论吗？
开发组的成员对这样做法有什么反馈意见？
再下一个项目里，开发组的成员愿不愿意继续采用这种方式？

12 楼 tuti 2009-07-17  

<div class="quote_title">klyuan 写道</div>
<div class="quote_div">
<p> </p>
<p>    1.每天8:30-8:35，项目组召开晨会。由项目经理列出每个开发人员的工作清单，并对每个工作任务标注优先级别，设定任务<strong><span style="color: #ff0000;">完成的标准</span></strong>，指明当日必须要完成的任务，并得到责任人的承诺。</p>
<p>   。。。</p>
<table border="1" cellspacing="1" cellpadding="1" width="600">
<caption>日计划样例：2009-3-22程序员L工作计划</caption>
<tbody>
<tr>
<td rowspan="2">开发人员 </td>
<td colspan="9">今日计划工作及完成情况</td>
</tr>
<tr>
<td>序号</td>
<td>工作任务</td>
<td>优先级</td>
<td><span style="color: #ff0000;"><strong>完成标准</strong></span></td>
<td>是否完成</td>
<td>完成百分比</td>
<td>完成情况</td>
<td>未完成原因</td>
<td>检查人</td>
</tr>
<tr>
<td rowspan="2">L</td>
<td>1</td>
<td>订单管理模块DAO实现</td>
<td>50</td>
<td>单元测试通过</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>2</td>
<td>与用户确认页面原型</td>
<td>10</td>
<td>用户确认邮件</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<p>   。。。</p>
<p>    日计划强调提交可交付的成果。虽然事先<span style="color: #ff0000;"><strong>制定了标准</strong></span>，但是程序员和项目经理可能会对可交付成果的理解不同。项目经理如果要清楚地了解到项目状况就必须要亲自进行检查。</p>
<p>    如何进行检查？项目经理一定要在现场工作，最好的办法就是让他演示给你看。对于不能演示的任务就进行抽查。因为事先已经制定<strong><span style="color: #ff0000;">完成标准</span></strong>，大家只需要按规矩办事即可。</p>
<p> </p>
</div>
<p>    我的问题是 “设定任务的完成的标准” 这件事情是怎么操作的？</p>
<p>    比如 谁在什么时候去做，这个标准要定到一个什么样的程度？</p>
<p>    这个标准又是怎么与相关人员达成理解一致的？</p>
<p> </p>
<p>    比如说“<span style="">订单管理模块DAO实现<span style="">” 这个工作任务， 完成标准是“<span style="">单元测试通过<span style="">”。 </span></span></span></span></p>
<p>    什么情况下 才能算是 单元测试通过呢？那么这个功能应该通过哪些单元测试用例呢？</p>
<p>    这些测试用例，又是谁在什么时候制定的呢？</p>
<p> </p>
<p> </p>
<p> </p>

11 楼 tuti 2009-07-17  

klyuan 写道

程序员   技术能力   规模(代码行)
J          中     1500
L          低     3600
Y          高     6000

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

从楼主这个例子来说，充其量只能说 技能和代码产生行数并不成正比。
完全的得不出“并不是技术水平越高的程序的生产率越高”这样的结论来。

楼主举这样例子想必是为文章主题服务，但所得出的结论和事例本身的逻辑关系非常牵强。
还不如不要这个例子。

10 楼 donitz 2009-07-17  

klyuan 写道

ayor 写道

精僻,但要达到成熟很难

两个方法有难度：一是任务的分解。这方面我想专门写一篇文章来讨论。
其实大家也可以看看SCRUM的做法。关于故事和任务方面的。这与传统的工作分配有非常大的区别。
我是在写完这篇文章之后再看的SCRUM，发现我的作法与他们的几乎一样。
我在实施时的前期并没有考虑对任务进行具体的工时估算。但是SCRUM会对任务进行具体的工时估算。这一点，SCRUM更好一些。
后来我也采纳了SCRUM的方法，为每个任务进行工时估算。

第二就是。执行力。其实项目的执行力与项目经理有非常大的关系。项目经需要识别风险，还要在把任务分配给程序员时要有预见性。在分配之前就要知道他会有什么问题。把任务分配给最佳人选。预见出现的问题和困难。并马上给予支持。但是很多PM做不到这一点。

这两个难度也是我现在遇到的，但是这两个难度有可以看成一个
问题就在于怎么能够保证程序员每天的计划和整体的计划匹配，也就是说PM怎么把握这个程序员当天的计划是足量，我以前遇到很多情况是要不太好了，要不太多，到后来发现根本1天做不完，这也就是说和PM的识别能力有关了

9 楼 freej 2009-07-16  

lz说的这些是对scrum的一些改进，不错，很有意义。

8 楼 whaosoft 2009-07-16  

younggun 写道

什么时候软件开发可以流水线作业的时候这个就有用武之地了

同意

7 楼 klyuan 2009-07-16  

ayor 写道

精僻,但要达到成熟很难

两个方法有难度：一是任务的分解。这方面我想专门写一篇文章来讨论。
其实大家也可以看看SCRUM的做法。关于故事和任务方面的。这与传统的工作分配有非常大的区别。
我是在写完这篇文章之后再看的SCRUM，发现我的作法与他们的几乎一样。
我在实施时的前期并没有考虑对任务进行具体的工时估算。但是SCRUM会对任务进行具体的工时估算。这一点，SCRUM更好一些。
后来我也采纳了SCRUM的方法，为每个任务进行工时估算。

第二就是。执行力。其实项目的执行力与项目经理有非常大的关系。项目经需要识别风险，还要在把任务分配给程序员时要有预见性。在分配之前就要知道他会有什么问题。把任务分配给最佳人选。预见出现的问题和困难。并马上给予支持。但是很多PM做不到这一点。

6 楼 klyuan 2009-07-16  

star022 写道

好文，条理十分清晰，案例十分生动，感同身受；

不过在以代码行数统计生产率方面，似乎有待改进，以前听朋友讲过，有些公司以代码行数为考核指标之一，导致很多程序员对于共性问题不采用工具类处理，而直接把代码拷贝一遍（-_-!），再加上项目管理水平有限，导致代码结构混乱，几千行的大类、几百行的大方法随处可见；
另外日计划的方式在理想状态下效果可能会很好，但执行过程中会有较多的细小步骤，如“日计划安排（这个对项目经理的责任心和能力要求很高）、程序员确认工作、下班前检查成果等”，程序员们是否对这种方式有抵触心理也很重要，因为会影响到团队工作氛围（工作氛围差的团队，貌似效率较难提升）。

本文先不想讨论工作量或生产率的计算方法。

主要讨论日计划。

其实日计划并不需要什么理想效果。
关于你说的“细小步骤”我在文中理解为任务。SCRUM中也称为任务的。
正是把这些“细小步骤”进行了管理，才使项目的进度一直在项目经理的控制之中。

至于程序员会不会抵触，我与朋友聊过。也考虑过这些问题。
最终的效果显示这些担心有些多余。
但是需要注意的是任务分配时，项目经理一定要对团队成员提供充分的支持。
如果90%的任务当天都不能完成，说明任务安排存在问题。
其次，PM要当好教练。教练就是要及时的发现程序员的问题。
我总是喜欢把一块白板放到项目组来。当我发现程序员理解不清或在什么地方被卡住了时，总是过去把他叫到白板旁边。一起分析问题，大家一起思考出思路。
办公桌前放多几支油笔，随时发现每个程序员的问题。一有问题就跟他一起讨论。

这样效果非常的好。

5 楼 klyuan 2009-07-16  

tuti 写道

楼主实际照这你的说法实践过吗？
效果如何？

这些实践不是我想当然的，是在项目中亲自实践的。

效果嘛，关键是要执行。

在我亲自带的项目取得的效果是非常好的。项目没有加班，每天每个人都可以完成当天的工作。
项目的进度始终在控制之中。
在我监管的项目中90%的项目是成功的。主要还是要看项目经理的制行力。
也有失败的，失败的原因是项目经理不能够支持。
有一个项目是在已经陷入了泥潭时，我进行监管。把日计划开展了起来。项目按期交付。
当我走后，那个项目团队又回到了原点。这很无耐，因为需要项目经理要有很好的执行力。
如果项目经理陷入代码中不能自拔，那项目很难成功

4 楼 tuti 2009-07-16  

楼主实际照这你的说法实践过吗？
效果如何？

3 楼 star022 2009-07-15  

好文，条理十分清晰，案例十分生动，感同身受；

不过在以代码行数统计生产率方面，似乎有待改进，以前听朋友讲过，有些公司以代码行数为考核指标之一，导致很多程序员对于共性问题不采用工具类处理，而直接把代码拷贝一遍（-_-!），再加上项目管理水平有限，导致代码结构混乱，几千行的大类、几百行的大方法随处可见；
另外日计划的方式在理想状态下效果可能会很好，但执行过程中会有较多的细小步骤，如“日计划安排（这个对项目经理的责任心和能力要求很高）、程序员确认工作、下班前检查成果等”，程序员们是否对这种方式有抵触心理也很重要，因为会影响到团队工作氛围（工作氛围差的团队，貌似效率较难提升）。

2 楼 ayor 2009-07-11  

精僻,但要达到成熟很难

1 楼 younggun 2009-07-11  

什么时候软件开发可以流水线作业的时候这个就有用武之地了