号称敏捷开发的大兄弟们，多少人在做敏捷估计？

[1000copy]

我的看法：

敏捷估计的方法，看起来罗里吧嗦的，有不少花样在里面。其原因就是想要有意避开具体时间，搞相对时间，搞点数，显得具体时间是洪水猛兽一样。

搞这些点数的，都无法回避一个问题，“纠结于点数 1 到底代表多长时间，是资深开发人员的一天，还是新手的一天”。也无法回避另外一个问题，“你到底要花多少天做完”？

估时对项目非常重要，而凡是重要的，你要避开，就必然看着遮掩。

我看大可不必。

其实大部分项目的大部分工作稍加分解，都是可以估时的，少量不能一次估时的，也可以设计,分解后估时。

直接估计时间就好。这方面也有系统的方法，就是 WBS 。

设置一个时间界限，做得完的就好，做不完的，就分解，分解不了就提交系统设计人员来，他们设计后在做 WBS 。

[CEBBCAT]

感谢分享，我常常估计不准工作需要的工时。

[1000copy]

@CEBBCAT 这其实是一个团队估计的问题。团队和个人是有差别的。类似这样的：

1. 每一个元件都不可靠，那么搭出来的系统是否可靠？可以。三极管与非门等都不可靠，各种收音机，各种电器的存在就是证明。冯诺依曼理论上证明过这一点。《概率逻辑与从不可靠组件合成可靠有机体》
2. 每一个颗粒都是无序的乱跑，但是作为整体是否有规律可循？可以。分子的布朗运动 vs.热力学三定律。

每一个团队分子估计时间都不可靠，是否可以给出整体可靠的估计？可以。自顶向下逐步求精。

依靠项目组织能力，作为冗余来补足个体估时的误差，逐步求精，在整体上降低误差到可靠的范围，有可能给出可靠估计。

[wenzhoou]

楼上举的两个例子和楼上的结论刚好矛盾。
这两个例子中，从无序到有序靠的不是组织能力。靠的是量变引起质变。
而这个量变和质变的分界点是很大一个数量级。
跟你的冗余啊，误差啊，可靠范围啊，完全不是一个概念啊。

[BugCry]

花里胡哨的，我选择直接乘以π

[1000copy]

@BugCry π太有棱角。不如乘以个自然常数 e ，自然些。

[1000copy]

@wenzhoou 我说的是工程方法，你说的是哲学。你说的可能都对，但是和我说的无关。