程序员如何预估自己的项目开发时间?

时间: 2018-09-21阅读: 288标签: 程序员

项目时间的估算对项目的成败至关重要。项目时间管理包括了项目按时完成所需的各个过程。但是,在实际项目中,经常出现项目延期,估算严重不准确的现象。

预估时间本身就很难。每个程序员的估计都会跟真正需要的时间有些差距。估计时间短了说明有些事情被忽略了(编译,测试,提交代码)。估计时间超了说明任务太大,难以理解。

对于资历较浅的程序员,这种估计误差是混乱的,他们经常会轻视一些任务,同时又对一些稍微有难度的任务过分高估。我认为,对一个有经验的程序员,一个任务的时间应该在半小时到24小时之间,超出24小时的任务都需要拆分。程序员在脑中想一想可能会认为要60小时,但实际上即使是很有经验的程序员也需要将任务分成可控的模块再来分析做决定。

还有一个很重要的需要认识到的一点是,编程上的经验并不等同于时间估计上的经验。一个从没有做过工期估计的程序员不会擅长估计时间。如果不去拿真正需要的时间和估计出的时间进行比较,你不可能从其它反馈信息之得到正确估计时间的经验。

每个程序员都会用到评估技巧。为了提高你的这项技能,你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间,拿它跟你最终真正用掉的时间进行对比。这样,你不仅在对任务细节的理解上有提高,同时也提高了你对时间预估的技能。



霍夫斯塔特定律:实际时间总是比预期要长,即便你考虑到了霍夫斯塔特定律。

经常会有 PM 抱怨说,为什么公司的开发永远不能估计自己的项目时间?!然而机智的程序员早就对此司空见惯了。我甚至见过一个预计 2 天完成的项目最后花了 4 个月的时间,即使按照「时间翻倍」的经验法则来看也是挺夸张的。从高级层面来看,问题在于 —— 工程师和 PM 或者其他人员对时间估算的方法和思维方式不同。

大多数工程师的第一反应是,如果一切按照计划正常进行的话,写出一个原型所需要的最短时间。而 PM 或者其他下游人员的想知道的是,项目什么时候可以准备完毕,从此时到发布的这段时间是多长?因此这完全是两个不同的故事了。

所以对于工程师来说,掌握时间估算是一项必备技能,这意味着你是专业、稳定而高效的开发者。


为什么需要进行时间估算?

外部依赖

任何有效的事情都不会凭空发生。项目通常存在外部依赖性,比如跟职能团队的沟通(财务、PR、客户支持)以及客户的交流等。而跟这些外部依赖协调的往往是 PM 或者CEO的工作,这意味着最有资格做时间估算的人(工程师)并不是最需要做这些测算的人。这种不对称导致了根本性的紧张。


优先级

时间测算对确定优先级也很关键。工程领域中性价比是一项重要指标,哪怕你在做的功能是全世界最厉害的,经过时间测算发现需要很长时间才能实现的话,那这个功能的优先级也不会太高。

比方说你正在做一个项目,做成之后可以让网站快 50%,但用同样的时间你本来可以完成 2 个项目,而且每个项目都可以让网站快 40%。如果你不花点时间进行初步测算的话,你永远都不知道还可以做一个更快的网站!


初级时间估算

假设我们达成了时间估算非常重要这个共识,那么我们继续看一下如何估算。通常情况下,我们低估所需时间是因为我们想的是「写出一个原型需要多长时间?」。

但是,交付的东西往往要比原型大多了,你还需要考虑测试、调试、优化所花费的时间。还有开会、访谈、代码评审,甚至发邮件都是需要花费时间的。

低估所需时间的另一个原因是意外的问题,这些问题往往不能被充分考虑到,比如 IDE 更新而让你多花了一天去配置环境等等。

基于此,我们最好不要太相信所谓的经验和直觉。


Step 1:制定技术方案

在开始任何一个重要项目之前,你都应该有一份技术计划或者设计文档。这个文档的目的在于让别人知道你在做的事情,并能获得反馈。当你注意到其中的技术细节时,你就会更清晰知道具体所耗费的时间,比如把某个库更新到新版本,可能会多花一天的时间。你甚至还得自己写一个库。

颗粒度在这里是很重要的。如果有哪一部分让人觉得不清楚,要么是你应该了解更多相关知识,要么得把它分解为更细致的步骤。与此同时,如果一个步骤太细的话,又可能会太脆弱导致整个计划无效,所以要把握好这个度。

想要知道你的文档里应该考虑哪些东西,可以看看AliciaChen 的 这篇文章。关键在于跟 PM 沟通清楚,消除有歧义的地方,这样才不会导致最后要推翻重来。


Step 2:为每一步添加时间估算

文档里的每一步实现需要多少时间,这往往牵涉到对细节的研究(这个是不是已经有库了?)。因此视项目性质而言,先做一个简单的原型可以帮助揭示许多潜在的痛点。


Step 3:追加容错时间

现在你已经有了初步的时间估算,不过还有许多其他需要考虑的因素。

随时调试:Bug 难以避免,这取决于开发者对特定代码库的经验以及代码库的成熟度。会议和假期:开会或者放假时一般来说是不会敲代码的,所以真正敲代码有多长时间?因此时间估算时要好好看看日程表。最终测试:通常应该一边编码一边测试,但很多团队在发布前还需要做集成测试,因此在你的估算中留出这部分的时间。代码评审:在这个代码库中你一般需要进行几轮?每轮需要多少时间?要经过多少评审人?留意评审人的日程安排确保代码评审的时间。

当你把交付时间的开销也考虑进去,你就能看到自己的时间估算和项目的实际发布时间要匹配得多。尽管实际情况可能还会更长,你也可能会因压力而需要缩短工期。但当大家明白你的估算更准确时,也会更信任你。


Step 4:发布后评审上期时间估算

复盘还挺痛苦的,但是回顾能让你在下一次做得更好。每一个实际与预期时间不匹配的项目都发生了什么,找到原因并改进它。


总而言之一切在于沟通。提前沟通、经常沟通,了解彼此的日程和需求变更。

跟 PM 等相关参与者的沟通也能让对方提供可能会影响你估算的重要信息。一位设计师可能会说这个动画需要一周工期,干脆砍掉不要了。另一位 PM 也可能补充说这个原型只是对用户进行研究的而已,这次迭代不用处理太多 bug。

对于工程师来说,不要做不切实际的更短工期的妥协,开诚布公更显专业。对于 PM 和其他人来说,尊重这一估算可能需要一个过程,但要知道光靠唠叨是不可能缩短工期的。

项目时间估算不容易,唯有善于沟通、有同理心以及确定功能优先级才可以。


来源:https://segmentfault.com/a/1190000016481368

程序员表白被拒后,听过最狠的话

喜欢一个人,到了极限。就想跟她表白,但表白成功率并不是百分之百。所以被拒绝也事常有的事,下面看看程序员表白被拒后,听过最狠的话....

程序员如何赚钱

作为一个程序员,时常都会想以后自己干不动的时候该怎样办?努力工作、接私活赚外快、自由职业者、打造自己的品牌、知识付费

程序员黑话指南

黑话这个词,说起来各位都会会心一笑。各行各业都有自己的行业内的黑话,产品经理有产品经理的黑话、金融行业有金融行业的黑话,而程序员这个群体虽然虽然忠厚老实,但是却有着丰富的黑话史。

程序员猝死:年轻人要学的除了赚钱,还有惜命

当猝死成为一种标签,此类新闻屡次刷屏在朋友圈,相关度最高的人群:程序员,也在不知不觉中被贴上了最易猝死人群的标签,程序员们常戏谑自己是新型三高人群——高薪、高压、高危。

程序员入行指南_写给刚入行的程序员

作为前端开发者,使用双显示器能大幅提高开发效率。学编程最好的语言不是PHP,是English。自己做的东西交付之前先测试一遍。问别人之前最好先自己百度,google一下,以免问出太低级的问题。

程序猿搞笑趣图

客户需求vs最终产品、程序员的一天:寂寞的时候干什么?写程序写程序写程序,失恋的时候干什么?写程序写程序写程序,发骚的时候干什么?开发平台的差异、C++ vs C...You have no class(没地位,无级别)

程序员与性生活

人都是需要自我成长,而不是结对编程。永远年轻,永远热泪盈眶。看见优秀的代码依然会内心为之触动,看见那些垃圾代码忍不住想给它删个精光——这就是你要保持住的赤子之心啊。要记住啊,不忘初心,如果你当时只是为了挣钱而去做程序员,那么你是为什么走到了这里。

程序员出路_年过35岁的IT程序员都去哪了?

有人说程序员只能吃青春饭,企业在招聘时会很在意程序员的年龄,大龄程序员一旦离职找工作就会变得艰难。面对年龄很多程序员都表示束手无策。其实,程序员和其他职业一样,干的越久技术越熟

程序员改行创业_程序猿如何变为创业狗

在低头打工五年,有了一定的积蓄后,我再次萌发创业心。关于程序员如何零基础创业,我在这分享几点经验:1 创业方向选择,2 辞职前的准备,3 如何安排工作,4 如何拉投资,5 如何和投资人谈钱

快递员凌晨送件,将下班程序员误认成小偷

近日,杭州一位快递员深夜前往某小区送快递,却把深夜下班程序员误认为“小偷”的视频,在社交媒体上引发了关注。后来了解到这位业主是程序员后,小董表示:怎么看都不像是个修电脑的啊。干这行的不是应该穿西装打领带吗?

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

广告合作文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯