常用技术方案开发周期预估方法

下面内容是阅读《程序员的职业素养》记录的笔记。
       大家在产品或者模块开发过程中，或者面对某一异常提出解决方案时，有没有遇到预估的完成时间和实际完成时间偏差特别大的情况？

       预估开发周期应该是软件开发人员面对的最简单、也是最可怕的和无奈的活动之一吧。预估影响到的商业价值巨大，关乎声誉，也给我们带来了很多苦恼和挫折。预估是业务人员和开发人员之间最主要的障碍，双方之间的各种不信任，几乎都由预估引发。关于预估，最主要的问题是不同的人对预估有不同的看法。业务方觉得预估就是承诺，开发方认为预估就是猜测。两者相差巨大。承诺是必须做到的，是需要必须兑现的。兑现不了也是欺骗，只不过比公然的欺骗好一点。而开发人员口中的预估是一种猜测。不包括任何承诺的色彩。不需要任何约定，预估错误也无关声誉。我们之所以预估，是因为不知道到底要花多少时间。那为什么大多数预估都和实际偏差那么远呢？这其实并不是因为开发人员没有掌握预估的诀窍，而是根本就没有诀窍，预估偏差总是很大，原因在于我们并不理解预估的实质。预估不是一个定数，预估的结果是一种概率密度分布。

       不管它概率不概率乐，我们直接说这样的预估方法吧，我感觉挺实用。学名：德尔菲法。
办法很简单，一组人集合起来，讨论某项任务，预估完成时间，然后重复“讨论-预估”的过程，直到意见统一。德尔菲法台高大上乐，我们采用低成本方式：亮手指。
       大家围在办公室或者会议室，每次讨论一项任务。针对每项任务，都必须讨论这个任务涉及什么，有哪些开发任务量，什么因素会把它搞复杂，应该如何实现。然后所有参与者把手收起来，根据自己判断，伸出0-5个手指里表示自己认为的完成时间。注意要大家同时伸出，伸出手指之前彼此都不知道对方的手指情况。如果大家伸出的手指基本相同，就开始讨论下一个任务。否则就开始讨论为什么有分歧。如此重复，直到意见统一。预估的计量单位在会议开始时必须确定。可能是完成任务所需要的天数与手指数一一对应，或者完成所需天数与手指数乘3对应，也可以与手指数平方对应。重要的是，大家必须同时亮出手来，最不希望的就是有人根据他人的预估改变自己的主意。
       预估是非常容易出错的，所以才叫预估。如何减小预估与实际的偏差呢？那就是先把大任务分解成许多小任务，然后分别预估小任务再加总，这样的结果比单独大任务要准确很多。这样做之所以能提高准确度，是因为小任务更明确，估错误偏差会很小。而且拆分成多个小任务也更有利于理解任务本身及其它意外因素。