论程序员的时间分配问题
内容摘要：在面对一个任务时，程序员往往不能正确、合理地时间安排，结果是延误项目进度，或程序质量低劣达不到要求，或导致返工增加成本。本文论述了程序员如何合理地安排时间，按照过程模型将任务分成几个阶段，每个阶段合理地分配时间，并考虑各种风险因素，强调程序员和项目经理等成员之间的沟通，将计划留有余地。
0 问题提出
在实际工作中，我们经常发现：某程序员接到一个任务，任务单上写明了任务的内容、时间要求，甚至还包括质量要求。这个程序员要不到时间交不了活，给项目经理若干理由，比如很忙，造成任务延期或者加班，最后造成整个项目的延期；要么交来的结果出乎了管理者的预料，根本就不是管理者所要的，不得不返工重来，浪费时间和精力；或者按时交了结果，功能也基本上是对的，但质量很差，在后面的系统测试中发现了大量的缺陷，修复起来很困难，有些甚至不能与系统其它部分集成[6]。
出现这些问题的根本原因是，程序员没有很好地分配自己的时间。在长期的软件开发管理实践中，我们发现，程序员最关心的是自己对编程方法的掌握，轻视设计、评审、测试和总结等重要环节，这样一来，他们提交的产品是不合格的产品，甚或是半成品[6]。
本文将讨论程序员如何将一个任务划分成若干小任务，然后对这些小任务合理分配时间。本文针对的是个体的行为，不是项目的行为；讨论的内容是当一个程序员个体接到一个任务后如何分解任务从而更合理地安排时间，而不是讨论软件生命周期模型问题；目的是交流如何合理安排程序员（个体）自己的时间，而不是讨论整个项目的进度安排。
文章分四个部分：第一部分介绍程序开发任务的分解，第二部分比较详细地描述各阶段任务；第三部分举例说明合理的和不合理的时间安排；第四部分介绍进度风险和计划余地；第五部分强调程序员要经常和项目经理沟通，以及时调整计划。
1 任务分解
一个软件模块的开发任务分下来之后，应该能分成几个阶段来完成：计划、可行性分析、设计和设计评审、编码和代码评审、编译、测试、交付、回顾与总结。下图是过程示意图[4]：
图1 过程示意图
计划阶段的任务是将分配到的要完成的任务划分成若干子任务，并按照时间排出进度；可行性分析是分析本任务是否能够在你的能力范围、时间范围内完成；设计阶段的主要任务是将你所分到的任务划分成几个程序子模块，并说明这些子模块之间的关系；设计评审是对设计的重新审视，发现问题并修改设计，直到设计满意为止；编码即用给定的程序设计语言编写程序；代码评审是按照一定的技术检查程序的正确性，检查代码中是否有遗漏和考虑不周的地方；编译阶段的主要任务是将代码用指定的编译器进行编译，发现编译错误并进行改正；测试主要指单元测试、几个子程序模块之间的集成测试，和其它系统模块之间的集成测试等等；交付阶段的主要任务是按照项目经理的要求或单位的相关规定，提交你的程序和相关文档；回顾与总结阶段分析这个任务的完成情况，有没有学到新知识和新经验，以利于下次任务更好更快地完成；如果尝试量化管理个人活动，还需要在每个阶段记录量化数据，并在这个阶段做数据分析工作[4]。
2 各阶段任务描述和时间分配原则
2.1 计划
计划是程序员接到一个任务后第一件要做的事情。首先要做工作量估计，根据自己的技能和知识面，估计每项任务完成的难度和所需要的时间，其中可能还存在一些不确定的因素需要在后续的工作中验证或校正，对于那些因为技术不熟悉、没有把握完成的工作，要安排专门时间来探讨，不能因为自己不熟悉，拖延时间进度。
根据以上的分析，安排出进度。做进度安排要注意以下几个原则：
1、 认真审题。面临的任务究竟是什么？很多时候，任务的内容和要求并不是很显然的。在审题时，不妨和项目经理做一次确认。
2、 留有余地。各种可能的突发事件，或者事先估计不充分等原因，都有可能造成进度滞后，因此在做计划时要留出缓冲时间，比如整个估计时间的20%留做缓冲，一旦上述情况发生，还有时间进行补救。因此工作量估算要尽量精确，对困难要估计充分。
3、 在脑海里装着整体计划。你所承担的任务是项目的一部分，项目经理对你提出的进度要求是整个计划的一部分，不能由于你个人的任务进度缓慢耽误了整体的时间进度。如果你的任务在关键路径上，要想方设法加快完成你那部分任务。
4、 及时沟通。估计能顺利完成的话，要向项目经理确认，让经理了解你的任务执行情况；如果估计不能按时完成的话，要及时和项目经理沟通，及早调整你的计划，以免耽误整个项目进度。也许和你的开发任务相对应的需求写得不够清晰明了，这时候，你要和项目经理或其它熟悉需求的人们沟通，直到彻底弄清楚需求为止。
因为程序员可能还面临着多个任务同时进行的情况，这时要给多个不同任务做优先级排序，决定先做什么、后做什么。
在实施PSP的团队中，每个程序员还应将估计的工作量、进度、任务规模大小填入相应的表格中[4]。
2.2 可行性分析
可行性分析包括理解本任务究竟是一项什么样的任务，反问自己以下问题：
我真的理解了分配任务的人的意图吗？有时候负责任务分配的人也没有完全写清楚，或者没有写具体，这时候要和分给你任务的人进行沟通；
这个任务可能涉及到哪些技术？哪些是自己已经有把握的，哪些还没有掌握？
分配给你的时间和其它资源是否充足？
该任务和周围的同事所承担的任务是个什么样的关系？
该任务和已有系统的其它模块之间是什么关系？
还有什么没有考虑到的？
这些问题看起来是很“显然”的，其实未必。等这些问题都有了明确答案，你需要优化调整上一步的计划，才能进行下面的工作，如设计等。
2.3 设计和设计评审
接下来，程序员要定义如何设计和构造这个产品。没有设计、或者设计不好，可能导致很严重的问题。设计工作的目标是计划和组织将要编写的程序代码。它把模块分成更小的几个小模块，定义各模块之间的关系[2]。这中间，可能涉及到程序流程设计，数据结构设计、类和接口设计等等。设计阶段一定要给文档书写分配充足的时间。
没有正确与不正确的设计方案，只有相对好和不好的设计方案[2]。一个有经验的设计者能充分考虑到设计方案对未来产品的稳定性、可扩展性、可靠性、性能等的影响。建议经验不足的程序员，在初次设计程序时，请求项目经理或有经验的程序员帮你做检查。
在初步设计做出来后，要做必要的评审，目的是找出设计方案中错误的地方、不符合标准的地方和遗漏的地方，以不断优化设计方案。
2.4 编码和代码评审
编码是对设计的实现，是用确定的编程语言（如C、C++、Java）等编写程序，实现本任务所要求的各项功能。编码本身并不是本文所讨论的重点，因为程序员们已经给予了足够的关注；本文所关注的重点是编码的评审工作。程序员，特别是初级的程序员最为关心的自己所编写的程序是否能通过编译，只要编译通过，基本功能实现、能够演示，他们就有了足够的成就感，以为任务已经完成。其实，产品质量问题往往出在这个阶段，程序通过了编译器的检查，没有发现错误，而实际上存在很多问题，以下只是很多类似问题的一小部分而已：
l 变量申明了，但未经赋值就被引用；
l 不同类型的变量之间进行运算，导致数据精度下降甚至出现错误；
l 除数可能为0；
l 下标超出了数组的边界；
l 一个打开的文件未被关闭；
l 一段占用的内存未被释放。
因此，代码评审是非常必要的，事实证明，代码评审阶段能发现很多产品质量问题，是一种很有效、很经济的查错方法。有很多现成的评审技术可供参考。评审可以是自己完成，也可以由同行完成，还可以小组的名义完成[3]。
2.5 编译
这个阶段的主要任务是将代码用指定的编译器进行编译，生成相应的可直接执行（或可解释执行的）二进制代码或可供调用的代码库。在这期间，可能发现编译错误，要逐个修正直到程序通过编译。
编译是检查程序错误的一个手段，但是程序的错误远不止编译错误，这是程序员容易疏忽的问题，特别是新手程序员，只要程序通过编译了，就以为程序编码的工作已经完成。即使是有经验的程序员，很多时候也不愿意把时间花在检查其它的程序错误上。上面提到的代码评审，以及将要提到的测试环节，都是为了检查程序其它错误而设置的步骤。
2.6 测试
在完成编码任务的时候，一定要进行测试。没有验证，就不能交付。
代码评审是一种静态的查错方法，而这里的测试是一种动态的查错方法。测试是把程序运行起来，看它的表现是否有问题，是否符合需求[3]。
这里的测试主要是单元测试，即最底层的模块测试，例如一个方法（类中的一个方法）或一个函数的测试。除了单元测试之外，还应包括此次任务之内的各模块之间的接口测试，也叫集成测试；还应包括和其他人承担的模块之间的集成测试、和已有系统中的模块间的集成测试。
l 发现了各子模块实现中的错误并予以改正； |
论程序员的时间分配问题[上]