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

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

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

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

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

 

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

   。。。

日计划样例：2009-3-22程序员L工作计划

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

   。。。

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

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

 

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

效果嘛，关键是要执行。

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

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

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

<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怎么把握这个程序员当天的计划是足量，我以前遇到很多情况是要不太好了，要不太多，到后来发现根本1天做不完，这也就是说和PM的识别能力有关了

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

小项目确实没什么问题，有可行性。

不过，项目组100个人如何？日计划，谁来定，管理也是有成本的，管理也是有时间的，计划个人来定，总要汇报吧，100个人的汇报，你还要检查代码？确定完成没有？别想了，不要睡了。

当然啦，分20个小组，小组长给你汇报/日计划？ 你的工作轻松了，不过，最有效率的组织是扁平的，这样一天写一个报告，每天还有计划，实在是比较官僚的做法了，文档会很多的吧。