“对不起,项目要延迟一周”
“我们的项目延迟了,但是我找不到原因”
“我们已经完成了80%的东西,项目按计划进行,但是系统还不能跑起来”
你是不是遇到过这些情况呢?有时候我们的项目要延迟,有时候项目延迟了却找不到原因,有时候项目按照计划进行但是客户询问进展的时候我们却拿不出一个成型的东西。这里所有的状况的原因都可以归结于---时间资源紧缺。
怎样的有效的利用时间?安排满满的计划就算是有效利用么?这就是我们的本周话题:软件开发中的时间管理。
我们来分析上面的问题:项目为什么延迟?为什么找不到延迟的原因?这说明项目执行计划是没有做到足够细化的,这里说的细化并不是一个极端,而是细化到这样一个程度:通过它你可以有足够的线索来对项目进度实行监控,对计划做出实时调整。这就是我们说的第一点:<b>软件开发过程中最基础的时间管理是安排一个帮助你能掌控大局的任务时间表。</b>
下一个问题,我们的项目没有延迟,我们的客户或者测试人员询问的时候我们却拿不出一个可以暂时能跑起来的系统。很无奈,我们说没有延迟,好像只有我们自己相信自己。当然开发过程不能让外界力量左右,但是,为什么不能先出来一个可预览的系统呢?这就是第二点:软件开发中的时间管理很重要的一点是---<b>开发任务的优先级:优先级处理的作用就是帮助你用最小的投入获得收益最大化。</b>
<b></b>
<b>怎样安排任务的优先级呢?</b>我的文章总是要给出一个可执行的方案,而不仅仅是提出问题,我的答案是:<b>CEARVR</b>
<b>CEARVR</b><b>是军事打击中总结出的原则,有的写成:CARVER</b><b>,我按照思考顺序做了一个调整。CAERVR</b><b>是经过血肉检验的实践原则,在软件开发过程中进行实践,会感觉到这个原则的伟大。</b>
<b> </b>
<b>C</b><b>:Criticality</b><b>重要性;</b>一个邮件发送接收的dll会影响整个流程是不是能够顺利跑通,那么它是具有重要性的。一个处理页面中文繁简体的dll相比之下可以推迟一下实现时间。
<b>E</b><b>:Effect </b><b>影响性;</b>开发本身有deadline,前台和后台管理页面的页面美化工作都没有做,但是后台管理页面暂时有开发人员负责,是不是美化影响不是很大。前台页面是系统的门面,其影响巨大,所以要优先。
<b>A</b><b>:Accessibilty </b><b>可进入性;</b>任务可以直接着手解决, 还是有一些在做它之前必须完成的事?如果你要写的Service需要十几个dll的引用,而这些dll还没有完成,那么我们认为这个Service是没有Accessbility的。
<b>R</b><b>:</b><b>Return </b><b>回报;</b>军事上很注重一个军事行动的回报,因为每一次军事行动的代价都是很大的。没有适当的回报,这次军事行动就是失败的。一句话将就是你花费多少成本说会多少回报?一味的提高单元测试覆盖率,而影响了开发进度就是没有回报的,或者回报率很低的;因为对于用户你告诉他你的单元测试覆盖率达到89%,他不感兴趣,他要反问你:项目能不能按期交付?
<b>V</b><b>:</b><b>Vulnerability</b><b>易完成性</b>; 你的目标容易实现么?这个任务需要多少人多长时间?
<b>R</b><b>:</b><b>Recognizability </b><b>具体性</b>;“星期一系统要完成80%”“星期二整个流程要跑通”这样的计划描述方式是没有意义的,因为它缺少最基本的可操作性:一方面任务的内容是不具体的,另一方面可度量而无法度量。对于与你协作的同事更郁闷:我具体要做点什么呢?
<b>总结:开发过程中进行时间管理,有一张时间表是十分重要的,而且它需要有一个你能够接受的细化。时间表上安排任务是有优先级的,如果需要一个安排优先级的建议,我推荐:</b><b>CEARVR</b><b>;</b>