l  子模块性能达到了规格说明书的要求；

l  和其他人新开发的模块一起能正确工作；

l  和系统中已有的模块一起能正确工作。

当以上条件都可以满足的时候，你就可以考虑交付你的产品。

2.7 交付

交付不只是简单的代码提交。在提交代码的同时，还应提交该代码对应的程序设计文档、测试用例和测试程序、程序的调用方法。

程序设计文档可以是程序流程图，也可以是设计文字说明，还可以是程序中的注释行。好的编程实践要求一定数量的注释行，用来说明这一段程序的编程思路，提高程序的可读性，以便于以后维护。

在有代码版本控制的团队中，每检进（Check in）一次代码，都须说明代码变更的位置和原因。这一点对于代码追踪和维护，是非常有帮助的。

如果实施了PSP，在提交产品的同时，还应提交PSP必须要求的表格[4]。

2.8 回顾和总结

对于分配的任务，你的工作似乎已经完成了。但是，一个好的程序员在每完成一个模块之后，会认真总结和回顾：在这一轮开发任务中，各个阶段有没有犯错误的地方，犯错误的原因是什么，今后如何避免？工作量估算和进度估计是否准确，估计值和实际值得之间有多大差距？有什么样的心得可以供别人和自己今后参考，少走弯路？程序中还有什么样的问题有待解决和优化？等等。

如实施PSP，对个体工作进行量化管理，还有填写相应的表格，如实际的完成时间、任务规模和缺陷数量等[4]。

2.9 时间安排原则

首先，个人计划要服从整体计划，如无特殊原因，要想方设法、克服困难在规定的时间内完成你个人的任务。

第二，上述各阶段都要分配一定的时间，不要企图跳过任何一个阶段。

第三，有时，多个阶段的任务可以同时进行，分配一个总的时间。例如代码编写和代码审查阶段可穿插进行，写好了一个代码片段，就可以立即进行评审，可不必等到所有代码都完成之后再做统一评审。再比如，可以将计划和可行性分析这两个阶段合并成一个，只分配一个时间。

第四，各个阶段时间分配的比例没有一定标准，要根据项目自身情况确定各阶段的时间长短。如关键系统，测试时间相对较长；如果系统是基于构件的设计，编码时间相对较短。

第五，充分考虑任务的风险因素，充分估计任务的难度，计划一定要留有余地。

第六，一定要经常性和周围的同事（特别是项目经理）沟通，及时动态地调整计划，以保证整体计划不因为你个人计划而延迟。

3 进度安排对比

下面通过几个例子说明，什么是合理的计划安排，什么是不合理的计划安排，以及其中的原因。

3.1 不合理的进度安排

现状令人担忧，很多程序员不是按照上述阶段安排时间，而是省却了很多过程，将进度安排成如下图这样。图中第一列是任务名称，第二列和之后的各列表示任务完成的时间长短，黑方框越长表示所花的时间越多。

图2 不合理的时间进度安排

不难看出，程序员将绝大部分精力用于他们自己认为重要的编程阶段，轻视了设计、忽略了测试。更有甚者，有些程序员还省去了设计阶段，一上来就编程。这样一来，看起来省去了很多时间，但实际上，因为程序没有充分测试，问题百出，程序质量得不到保证；事前没有很好审题，返工现象严重，耽误了整体进度；程序没有经过设计，结构紊乱，不易维护；没有总结和回顾，不利于程序员进步，也不利于后续的工作的改进。