我的看法：
敏捷估计的方法，看起来罗里吧嗦的，有不少花样在里面。其原因就是想要有意避开具体时间，搞相对时间，搞点数，显得具体时间是洪水猛兽一样。
搞这些点数的，都无法回避一个问题，“纠结于点数 1 到底代表多长时间，是资深开发人员的一天，还是新手的一天”。也无法回避另外一个问题，“你到底要花多少天做完”？
估时对项目非常重要，而凡是重要的，你要避开，就必然看着遮掩。
我看大可不必。
其实大部分项目的大部分工作稍加分解，都是可以估时的，少量不能一次估时的，也可以设计,分解后估时。
直接估计时间就好。这方面也有系统的方法，就是 WBS 。
设置一个时间界限，做得完的就好，做不完的，就分解，分解不了就提交系统设计人员来，他们设计后在做 WBS 。
 |
1
CEBBCAT Nov 1, 2022
感谢分享，我常常估计不准工作需要的工时。
|
 |
2
1000copy OP  2
@CEBBCAT 这其实是一个团队估计的问题。团队和个人是有差别的。类似这样的：
1. 每一个元件都不可靠，那么搭出来的系统是否可靠？可以。三极管与非门等都不可靠，各种收音机，各种电器的存在就是证明。冯诺依曼理论上证明过这一点。《概率逻辑与从不可靠组件合成可靠有机体》 2. 每一个颗粒都是无序的乱跑，但是作为整体是否有规律可循？可以。分子的布朗运动 vs.热力学三定律。 每一个团队分子估计时间都不可靠，是否可以给出整体可靠的估计？可以。自顶向下逐步求精。 依靠项目组织能力，作为冗余来补足个体估时的误差，逐步求精，在整体上降低误差到可靠的范围，有可能给出可靠估计。 |
 |
3
wenzhoou Nov 2, 2022 via Android
楼上举的两个例子和楼上的结论刚好矛盾。
这两个例子中，从无序到有序靠的不是组织能力。靠的是量变引起质变。 而这个量变和质变的分界点是很大一个数量级。 跟你的冗余啊，误差啊，可靠范围啊，完全不是一个概念啊。 |
 |
4
BugCry Nov 2, 2022
花里胡哨的，我选择直接乘以π
|
Select Language