制作小工程表时要注意哪些问题

 小工程表做为开发过程中的最小计划单位，在实际工作中有着指导工作内容、监督跟踪工作进度的重要作用。不恰当的小工程表不但不能指导相关人员的作业，而且还会给项目的监管者传递一些错误信息，从而导致对项目状况的错误判断。那么在制作小工程表时要注意哪些问题呢？

 一．做为计划单位的任务单元是否进行了完全的分解且可度量。经常看到这样的计划安排：
     任务：Button的单击处理
     作业期间：xxxx年xx月xx日～xxxx年xx月xx
     WT/CR：xxxx年xx月xx日
以上计划表面上看好像可行，任务已经细化到了Button的Click处理，其实对于简单的Button的点击处理也确实可行，但是对于当Button点击后，要执行复杂逻辑处理的Click事件，单独的制作一个Button的单击任务，显然是不合适的。我们必须根据Button单击后要实现的功能进行结构化分解，如以下方式就要比上面的方式具体的多：
     任务：Button的单击处理
       任务1：Button的单击后，画面状态设定处理。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
       任务2：当前数据状态和应用环境的保存处理。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
       任务3：逻辑计算需要的数据和应用环境的准备处理。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
       任务4：逻辑计算1。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
　　　 任务5：逻辑计算2。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
       ．．．．．．
       任务N-1：处理前的数据状态和应用环境恢复。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）
       任务N：画面状态恢复出来。作业期间：xxxx年xx月xx日～xxxx年xx月xx（0.5～1天的工作量）

 二．任务计划完成时间是否足够短，一个计划3～5天来完成的任务，很可能是任务单元分解不足，当然就会存在更多的隐形的工作量和未知的问题。因此透过任务的计划期间，就能判断出计划者对作业任务的认知程度。

 三．任务的难易程度与作业担当的能力是否匹配。软件作业不同于体力劳动，它不是简单的机械性的重复性工作，它需要完整而准确的思维过程以及恰当的实现方法和实现技巧。例如运用Java实现对XML文件的读写操作时，如果利用Java的反射机制，不仅能够有效的减少代码量，而且还可以提高代码的复用度。这对于不懂反射机制的程序员来说，实现方法就会简单机械，每当Xml文件中的节点发生变化时，都要他的实现方法做一些添加或删除，这样的代码不但不灵活，而且会浪费很多时间。

 四．不同任务间是否存在线性逻辑依赖关系，即一个任务的开始完全依赖于另一个任务的结束。对于这样的任务，如果计划开始时间早于依赖任务的完成时间，那么就会发生空闲等待时间。

 五．工程表中是否留有足够的对每个任务的审查时间以及对审查发现的问题的修正时间。在小工程表中不能只单纯的定义任务和完成任务的计划，还要体现任务的审查计划和问题修正计划。

 六．制作小工程表时，要抛开工期的约束，按照实际的工作需要和作业量进行计划安排。不能因为工期紧而压缩任务的作业期间或者减少相应的品质活动，这样做的直接后果就是无法保证作业品质。

 七．小工程表的计划期间不能太长，2～3周比较合适。实际工作中，每天都会发生一些不可预知的变化，对于计划期间比较长的小工程表，不能及时反映实时变化的工作环境，势必会给我们带来很多的工程表调整上的麻烦。