关于estimation的闲言碎语

• 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....(好的标准是什么?温柔,贤惠,善解人意...)

请教：

1.BA是什么意思？Business Analyzer？
2.“好的estimation不是developer估的好”应该如何理解？是指好的估算不应该由开发人员来做？
3.“不要给出"10"作为估计.10不是estimation,10代表"你不知道".”应该如何理解？如果10代表"你不知道"，那9或11又代表什么？如果使用1呢？还是说不应该使用代表某个点的值，而是表示某个范围的数据来表示估算结果？
4.“砍掉的story,总是那些estimation高,实现起来容易的.”中的“estimation高”能否再具体说说是什么东东高？

谢谢！

1. BA是Business Analyst的缩写,就是写story的人.
2. 好的estimation的含义是,这个estimation在事后证明帮助团队去正确评估了story的大小,帮助了对发布的计划.显然,一个estimation要起到效果,不是developer给出了一个数就行了的.这个数要被用好,被管理好,有BA的责任,也有PM的责任.
3. 10是一个统称,就是那些大得不靠谱的数字.基本上,只要estimation的结果大于一个iteration的长度,就不是一个可行的estimation.这种太大的estimation,基本上不是太乐观就是太悲观,根本不能去指导release planninig.祸害无穷,宁愿不要.
4. estimation高就是说我们认为工作量大.要砍story,往往砍掉的就是估计的时候认为工作量大,其实开发起来很容易的story.这是一个个人的经验,未经推理证明.