代码之外:项目规划
在”代码之外”系列文章中, 我会回顾那些使我开发更有效率的工具与流程. 我希望通过分享我的经验,可以从你们获得反馈,从而改进我工作的方式.
今天的主题是关于项目计划的. 其过程包括将项目分解为任务以及评估完成任务所需要的付出. 该过程的产物可以作为客户提案,可以用于为老板估计成本甚至可以作为项目文档的起点.
文件格式以及工具很重要
若从这段艰苦的过程中我只学到一件事情的话,那一定是:我现在所使用的工具不代表以后也会用. 也许是因为出现了更好的工具,也许我不得不换一个操作系统,而在该操作系统上,这个工具不再能用.
我会尽量避免使用私有格式的二进制文件. 这是我的第一要则:
规则 1: 经可能使用纯文本格式. 无论你使用的哪个平台,你都可以阅读及修改文本文件. 若恰好你所用时的平台载有许多上好的命令行工具(例如UNIX系的操作系统), 这意味着你已经有用了一个强大的查找,搜索以及转换文本文件的系统.
文本文件rock, 那么用那个工具来编辑它们最好呢? 作为一名开发者,你对使用文本编辑器应该并不陌生. 事实上,这应该你最高效,最适应的工具才对. 若你只能精通一件事,那就是精通使用你的文本编辑器.
项目管理的工具
有许多制定项目计划的工具. 然而所有这些工具所提供的功能并不比一个纯文本文件能提供的功能更多(all while working with nothing more than plain text files). 我的选择是使用Emacs搭配它那令人惊叹的Org-Mode包.
你完全可以根据自己的意愿选择任意的工具. 毕竟流程要比工具更重要一些. 但是不要会错意,一个好的工具可以极大的改善你的工作流程.
我喜欢Org-Mode因为它提供了很多功能, 同时归根到底,所有的一切都是纯文本. 这样我可以很容易地使用版本控制系统来存放项目文件,同时使用像Ruby和grep这些工具来管理他们.
将项目分解为特性(feature)与任务
指定项目计划的第一步就是将项目分解. 我会把它分解为一个扁平的继承体系:将项目分解为特征(feature),特征再分解为任务.
Features are usually the bigger chunks that your client or boss would know by name. 由于feature包含的东西太多了,因此在不对它进行进一步的分解前,你既无法正确地评估它,也无法清晰地思考它的依赖条件.
通过将feature分解为任务,你实际上是在梳理如何实现该feature. 你需要思考实现该feature依赖于哪些条件,实现时可能会遇到哪些问题.
当将项目分解为feature和任务时,不要分心于评估,只聚焦于流程. 在头脑中思考实际该如何实现这些feature,然后将这些步骤记录下来作为任务.
下面是一张Emacs的屏幕截图, 显示的是我为一个虚拟的社会网络应用程序所创建的一个大纲. Org-Mode允许我们在任意层次上折叠大纲. 截屏中显示的只是大纲的标题,内容是两个feature,每个feature又被分为多个任务.
Folded
当我在作feature与任务的分解时,我也记下了一些笔记,以防标题写得过于模糊,或者过了几个星期后,我会忘了当时所想.
下面是将上面的大纲完全展开后的结果. 你可以看到这些笔记. 在后面的工作中,这些笔记可能会被扩写,并用于项目文档或客户提案.
在Org-Mode中, 是使用 tab 来折叠/展开大纲的. 这样你可以很容易做到只看项目计划中,你所关注的那部分内容.
Expanded
评估任务耗时
我刚才提到过,一个feature本身很模糊,难于评估. 但当你将之分解为任务后, 你应该就有了足够的信息来评估要实现这些feature所需要的耗时了.
我不打算在本文中深入地讲如何评估耗时. That said, put your estimating cap on and let’s get to it.
评估任务的最好方法是先评估第一个任务,然后一个一个地评估它后面的任务,一次只评估一个任务. 我一般将对任务的评估精确到时和分,通常以30分钟为单位.
若你评估任务耗时超过了一周,则你需要将该任务再分解为几个子任务. 任务保持合适的颗粒度很重要,就我个人来说,我不喜欢超过5个小时的任务. 同时任务小于30分钟的任务也需要回头思考一下是不是有必要分得这么详细.
下面的屏幕截图显示出已经为各个任务评估了耗时. 我喜欢使用Org-Mode的column view功能来查看耗时,因为它可以将继承结构的大纲转换为表格的形式,使得我很方便的看到各个任务的耗时总和.
在下面的截屏中,我为各个任务分配的预估时间. 每个feature显示的其对应任务的预估时间的总和. 而最顶端的标题(也是项目名称)上显示的则是整个项目的总估时. 我只需要为最低层的各个任务(在下图中显示为紫色)分配估时即可,Org-Mode会自动为我累加估时.
Columns
展示项目计划
在对任务估时完成之后,你已经有了足够的信息来向客户展示方案或者向老板展示项目计划了.
你用于创建项目计划的软件一般都会有导出功能. Org-Mode可以导出为HTML, LaTeX, 甚至是好看的ASCII文本文件.
就算你指定计划时使用的软件并没有导出功能也不要紧,我们是码农嘛,自己写个脚本来作转换就好.
在这个例子红,我需要一份客户提案,我将该项目文件导出为一份漂亮的PDF文件并将之发给我的虚拟客户. 当然,若是一份真正的提案,我还需要添加诸如实施成本等其他内容.
在实施过程中使用项目计划
费了那么大力写分提案有啥用呢?难道仅仅放那蒙尘而已吗? 为什么不把它作为实施阶段的待办列表呢?
通过将各个已估时的任务看成待办事项,我可以使用Org-Mode来管理待办列表. Org-Mode允许我“clock in”一项任务(即开始一项计时器). 当任务完成后,我标记它为已完成,(Org-Mode会自动停止计时并计算出实际耗时). 这样我就能对比实际耗时和预估耗时了.
下面的截图中,我完全展开了一个已完成的任务. 你可以看到当我对一项任务开启计时器然后再标记它完成后,Org-Mode为该任务所添加的meta-data. 从中你也可以看到标题是如何被作为待办事项看待的.
Tasks
使用column view来对比预估耗时和实际耗时很直观. 下图中我再次使用column view来查看大纲,这次还显示了实际耗时的统计信息.
这是一个很好的例子,展示了Org-Mode是如何收集文本文件中的meta-data并以更为直观的方法显示給你看到. 你甚至可以编辑表格中的数据, Org-Mode会自动更新meta-data中的值.
Clocked
除了column view之外,Org-Mode还有许多其他方法从你的数据中生成报告. 其中我尤其喜欢agenda view.
在agenda view中,你可以查看某一天你计划要完成哪些事情. 我发现每天工作要结束时,花点时间规划一下第二天的工作很有用.
每天早晨,我都会回顾我的agenda,了解我今天的任务后再开始工作. 这样有助于缓解刚开始工作时的拖延倾向.
Article Artifacts and Further Reading
我在上面展示了那么多截图就是想告诉你当使用一个像Org-Mode这么好的工具来进行项目规划时是多么的美观. 使用Org-Mode的一个好处时,它完全是基于文本文件的,这样即使你使用其他文本编辑器打开它,也不会感到陌生.
下面是该文中例子的链接. 你用你喜欢的文本编辑器打开该项目计划然后与上面的截屏对比一下. 也可以试着用Emacs打开它看看会怎样.
若你想了解更多关于Org-Mode,它的官方网站上许多资料. 在那有写得很好的manual和活跃的mailing list.
