老兄，你的进度表

 

老兄，你的进度表

周银辉

据说XPlanner在Team中流行过一段时间，但后来被默默地扫入历史的垃圾箱。（注：XPlanner是一个基于Web的XP团队计划管理和跟踪工具。XP独特的开发概念如Iteration、User Stories等，XPlanner都提供了相对应的管理工具，XPlanner支持XP开发流程，并解决利用XP思想来开发项目所碰到的问题。 XPlanner特点包括：简单的模型规划，虚拟笔记卡(Virtual Note Cards)、Iterations、User Stories与工作记录的追踪，未完成Stories将自动迭代，工作时间追踪，生成团队效率，个人工时报表，SOAP界面支持）到后来我们意识到这是极其可惜的，虽然在一个月前的“回顾大会”上就使用XPlanner的问题不少同事仍然很犹豫，但我和部分同事仍然坚持将其利用起来的观点还是得到了大家的支持。现在看来那时的坚持是很正确的。至于部分同事的犹豫是可以理解的，因为我也有过类似的担心：对于任务的划分和时间的估算的确是一个挑战。但没有进度表的开发无异于自杀行为。虽然说在开发人员所能掌控的范围之上肯定有一个更粗粒度的时间表（比如什么时间发布新版本），但仅仅依靠这个我们无法知道开发的最新情况，更不知道能不能按时发包，我想谁都不愿像网景公司一样由于产品迟迟不能发布而丢失绝大部分市场份额而成为众多书籍中的反面教程。

其实对于任务时间的估算，不仅仅对开发人员是一个挑战，对老板们同样是一个挑战，老板们也害怕自己一时冲动拍着胸脯说：“OK，三个月”。然后自己都没法知道自己的团队实际需要6个月才能搞定。一个比较搞笑的说法是“开项目时拍胸脯，项目中拍大腿，项目结束后拍屁股”。坚持制定计划表可以大大避免这种情况的发生，一是结果长时间的摸索，老板能了解到自己的团队能力，能很好的估算项目时间，二是通过计划表能尽可能早地发现时间不够的情况，然后可以采取相应的措施，比如砍掉一些相对不重要而耗时较多的功能特性而将时间节约给那些很好很重要的功能特性。对于开发人员而言好处也是很明显的，我们可以很好的安排任务和对自己在目前这段时间能完成的任务量和进行估计，一是可以让自己的工作更有条理性、效率更高，二是能及早发现存在的风险（比如某个任务的确很费时间，除了工作量外还学习一些新知识才能完成）然后你可以在任务进行的最初期发现这些风险并及时跟你的老板提出来，而不会等到快发包时解释说“我真的很努力，但真的搞不定了，任务太多了”，那就死定了。不要害怕任务时间估计不准确，没有准确的（我们又不能完全预知未来），但这是可以积累的经验，经过长时间的经验积累，你所估算的时间就越能接近真实消耗的时间。

1，这篇文章不是XPlanner的广告

要声明的是，之所以文中很多地方提到了XPlanner，是因为我目前正在使用它，而且觉得很不错，然后本文的主要目的是表明进度表的重要性以及相关经验教训。至于到底使用什么样的工具，我不能做出好的推荐，这方面我的经验不足，需要更多地了解XPlanner可以访问这里：http://www.xplanner.org/ 。但据说在此方面Microsoft Project等也有着杰出贡献，其实Microsoft Excel也是一个不错的选择。

2，进度表不是工时报表

还好，我们不是钟点工，否则进度表极其可能沦为工时报表。遗憾的是，进度表不具备这项功能。如果有人想这么做，可能其大错特错了，员工进度表中的任务时间可能被拖得很长以及员工恨不得将开机关机都计入进度表以表明自己一直在干活。

3，进度表不是老板们的工作

这里讨论的进度表不是由老板们来安排的，而是由开发人员自己来计划与填写的，一个很简单的道理是，只有开发人员自己知道完成该任务需要做那些事情，需要多少时间。如果让你的经理来为你填写计划表那就太糟糕了，除非他比你还了解你自己以及任务细节。这就有牵扯到一个问题（但至少我们还没有也不会遇到，但可能其他个别团队会遇到这样的问题）：你的经理认为你将一个小小的任务安排了过多的时间。这是一个很糟糕的问题，我感觉老板应该关注你的计划安排的合理性并给予适当的指导，而没有理由让你压缩时间，毕竟你才最了解任务耗时在哪里。遇到这中情况不必紧张，可以将预计时间修改为老板认为合理的时间，但在备注中保留你认为合理的时间。反过来说，作为开发人员的我们有义务和职责将进度表安排得更合理。

4，进度表的结构

按照XPlanner的结构而言，主要有Story和Task，一个进度表包含若干Story，一个Story包含若干Task。对于Story的理解可以是Feature也可以是Case，其粒度比Task大，而Task就是我们所说的在该Case下的若干任务。就我们的经验而言，我比较喜欢按照任务的流程进行划分，比如从需求的确定到写设计文档到编码（当然实际Task的粒度要比这几个词汇的粒度小得多，Task粒度应该小，小到以“小时”为单位，而不是以“天”，这稍后为谈到）。然后一个Task至少应该包含以下几项内容：任务名称、任务内容、其所在的Story、任务的实施者、任务的跟踪者、优先级、计划时间、已使用时间、剩余时间、完成任务的实际使用时间等。但我仍然坚持Task也应该保持简单明了，一是一目了然，二是节约时间，三是防止团队成员的抵触情绪，所以Task中需要填写的字段不亦过多。

5，任务粒度要小

任务的粒度绝对不能大，大的是Story而不是Task。推荐的粒度是按“小时”为单位，而不是按“天”为单位，我的一位同事的不错的经验是将任务细化到4小时或8小时以内，并且尽量保持任务的完整性（意思是说，不应该出现事情刚做一半就下班了的情况），这有利于“每日检入”（Daily Check in）和“每日构建”（Daily Build）。粒度太大很明显的缺点是时间估计的误差很大，如果是一个全新的任务（而不是被你重复过无数次的任务）而给出一个“我大概需要三天”的时间估算的参考意义是不大的。另外，我也有一个失败经验，当我用Outlook的“任务”工具为自己指定一个任务时，如果我仅仅指定某个任务应该在未来3天内完成，那么该任务往往被推迟到第三天才真正开始做，甚至被拖延更长的时间，正确的做法是，即便该任务需要3天，那么应该将该任务拆分成3部分（或更多）然后分配到每一天中去，做到今日事今日毕。

6，调试、集成，以及其他乱七八糟的事情耗费的时间呢

特别是调试所耗费的时间是让人头痛和不可避免的情况，如果你常常发现理想中只需要花20秒修改一行代码的任务，往往从打开项目，检出（Check Out）文件，到修改代码和Build项目以及最后调试通过将花费理想状态下数十倍的时间。可能我举的例子有些极端，但总的说来，调试所耗费的时间是编码的1~2倍。请不必感到惊讶，并且你绝对不能忽视掉这些因素。虽然调试时间是如此的难以估算，但你必须将其考虑到任务时间估算中去，否则你的时间会显得如此之紧而不得不加班（然后老婆又抱怨没有时间陪她以及从不照看孩子…）。而其他的一些事情，比如升级开发工具等等耗费的时间应该成为进度表中的一个条目。

7，进度表中加入缓冲

这是一个值得大家讨论的问题，因为目前我们的进度表似乎没有设置缓冲，也就是说没有富余时间用于对付以下情况：一是任务耗费的实际时间比预计时间要长很多，这有可能是我们估计失误也可能由于其它原因耽误了开发；二是新加了任务或是原来被砍掉的功能特性必须重新追加进来，虽然从理想的角度而言是不易出现新加任务的情况的，但不排除，并且从市场的角度而言我们必须将某个功能特性追加进来而使产品处于更有利的地位时。

8，每日更新进度表

既然使用进度表的目的之一就是真实反映目前项目的进展情况，那么进度表的每日更新就是非常必要的了，这仅仅需要花费你不到了分钟的时间。但我们也有不小心搞忘的时候，目前的措施是使用Outlook群发一个Meeting Request 然后每日定时提醒（比如下班前半小时），还有就是在“站立会议”（Standup Meeting）上一个一个过进度表，谁没有更新的话，大家都知道了（呵呵…）。

9，分析进度表

如果你了解XPlanner或Project，其会给出很多图表以分析进度表所反映的问题，至于如何使用这些图表来分析这些进度表，你可以查阅相关文档，这里略过。不过值得提醒的是，在制定进度表的过程中要注意那些会影响这些图表的地方，以便让图表能更真实地反映问题。