关于estimation的闲言碎语

[list]
[*] estimation只是一个开始,不是结束.好的estimation不是developer估的好,还要靠BA大人们来管理scope,不然就算developer牛成马了,estimation还是一坨.
[*] 相对于给出一个精确的绝对值来说,维护内在的相对关系更重要,一致性为王.
[*] story写得不好,再estimate也是枉费功夫.
[*] 不要总是关注story的大小,把一些story加起来构成一个完整feature的大小也很重要.对于客户来说,他们往往关注在feature级别.
[*] 一个feature的大小,往往还取决于BA对它写了多少了个story.
[*] 没有"一天"的story,请慎用最乐观的情况.
[*] 需求不明应对方案一,拒绝estimate,直到有人给你讲明白到你觉得可以estimate的时候为止.
[*] 需求不明应对方案二,做出假设,并且记录在案.但是不要做出明显不合理的假设.并要注意开发过程中对于当时假设的校验,BA要负责维护这些假设.
[*] change request要落到实处.至少要把假设被打破,estimation需要重新修改的情况,放到明处.
[*] 不要给出"10"作为估计.10不是estimation,10代表"你不知道".PM也不要天真的拿10去做release planning.
[*] 正常的story不会太大也不会太小,而且大部分的大小是相对一致的.estimation往往都是一些中间的数.
[*] story的大小,与参与的系统组建数量有关(纯客户端,客户端服务器,客户端服务器加新的表)
[*] story的大小,与变化点的数量有关(如果情况a,则如何如何,如果情况b,则如何如何)
[*] story的大小,与在同一块区域,过往story的复杂度有关(在一个复杂功能区域上添加新的业务规则,要难于新写一块)
[*] 学习新技术的时间,不明集成点,测试时间等,不便分配到每个story中.倾向于不添加到estimation中.而是以risk factor等其他形式体现出来.
[*] 砍掉的story,总是那些estimation高,实现起来容易的.留下的story,总是那些estimation低,难于实现的.想想吧,我们该如何做.不要抱有侥幸心理.estimate的时候,就要考虑如果这个story被砍掉了,你觉得你亏不亏.
[*] 拒绝用ideal hour做estimation,最小的单位不能小于半天(最好是一天)
[*] 在没有得到更多信息的情况下,re-estimate等价于对开发人员的连夜审讯,你必将被屈打成招.拒绝做这样无谓的事情.
[*] 好的BA,好的BA,好的BA....(好的标准是什么?温柔,贤惠,善解人意...)
[/list]