这个项目要多久开发完成？

　　英文原文：How long would this project take?

　　这个问题是我最常遇到的一个，也是我最难回覆的一个。对这种问题最好的回覆方式是用全职员工来推算天数。这很是容易，你只需要找出有几多个不重叠的功效特征，然后每小我私家卖力一个。一旦各个功效块被分成了不能再分的使命，你盘算需要几多人天，这就是你的谜底。你无论怎样都不行能用比这更少的时间开发完这个项目。

“一个女人生一个孩子要10个月，岂论你再增添几多个女人来做这事，都不会缩短这个时间”

“只有当一个使命的完成可以分配多人，而且不需要他们之间相互交流互助的情形下能完成时，人和月才气相互替换。”

“往一个已经延迟的项目里添加程序员只会使项目进一步延迟”(由于项目中现有的人需要培训新来的人)

-《人月神话》

　　不幸的是，大部门人只想知道一个项目需要几多时间完成。这现实是个伪命题，由于90%软件成本的发生是发生在软件公布之后。这些用度会发生于修复bug、增添欠缺的功效、性能的革新、对新平台举行支持(安卓就是一个大债主)或重写质量差的老代码来淘汰手艺债务。纵然是项目公布前，对于怎样合适的处置惩罚每一种报错情形，这也是无法预先预计全的。从某种水平上，你就是被别人问了这样一个问题：“我有一个问题，我想解决它，但我无法说清问题是什么。叨教解决这个问题需要几多时间？”

　　只管预估很难，但程序员最终要找到一种预估的制作软件要领。虽然无法知道一个确切的谜底，但我有3种要领能大致预计出一个软件项目要花几多时间：

想要搞清晰一个事情需要几多时间完成，这最好的要领是找一个程序员已经完成的、相似的项目。对一些简朴的网站和应用来说很是有用，或者那些使用尺度CRUD的项目也是适用。当项目小且简朴时这种要领最好用。这种要领可以用在软件1.0版本时，但以后的版本就不行了，由于这时你跟相参照的项目最先逐步的发生差异，这时写的代码是你以前没有写过的。我的好朋侪、而且是以前的同事John Walker(不是这个John Walker)喜欢用这种要领。把项目拆解成最小的使命。然后记载完成每个使命你以为可能需要几多小时、天、周、月。遵照这种原则，若是一个使命需要几小时，就是算成一天，若是需要数天，就是算成一周，若是是数周，就算成一月。若是凌驾一个月，那你就无法知道需要几多时间了，或你基础不知道要做什么。我有自己的预估要领，但事实上跟John的把使命拆分成最小的子使命的要领很是相似。我是以最坏的情形下每个最小单元需要的完成时间为尺度。汇总，然后乘以4。再向上取舍到最近的素数，就算是对我的这种没谱的要领的讥笑吧。

　　对于大型的、奇特的项目，程序员险些无法知道它需要几多时间开发。它就是像在问“需要花几多时间能找到治疗癌症的要领？”然而，大部门的治理部门都拒绝接受这种谜底，于是，程序员只好玩一些花招，先弄清晰老板们希望听到的时间，然后加入一些余地。还能有什么措施？通常都是超近路，这都是由于要去追赶谁人本不应该设置的最后限期。你需要明确，预估是难题的，需要运行企图上的变换。除非你的程序员能将使命拆分小于一个月的子使命，万万不要在软件公布时间上做任何市场运动企图。

　　这最后一件需要注重的事是，当你在一个现有的软件(好比2.0版，3.0版….)上增添新功效时，你需要追加20%用来对现有代码举行重写的时间(程序员称之为重构)。这是为了归还手艺债务，或为未来的行动铺路。人们以为Google是拿出20%的时间用来创新，但我敢赌钱，实在这大部门是来归还手艺债务的。

　　预计一件事情要花几多事情是很是难的，通常也是不行能的。虽然你曾在一些小项目上有乐成的展望，但随着项目的生长你会感受到越来越难。一个好的要领是给程序员留足分外的时间。许多年轻的程序员通常没有这方面的履历，以是，项目司理必须把他们预计出的时间乘以4。