Chen：
您好，我看了您些的关于Scrum sprint plan中规模估算的一篇文章（http://blog.csdn.net/zhangmike/article/details/6980334），觉得梳理和总结的比较好。
在我所服务的公司中，也在大力倡导Scrum模式下的敏捷开发；基于我个人的感受，在sprint
plan时，对于得到一个满意的estimation，觉得有些纠结。
我们现在采用的是基于历史数据作估算，对于前面几个iteration的相应规模如果有较大的起伏，我们采取了一种取历史上多个iteration规模取移动平均值的做法。
我注意到你在文中提到，资源利用率通常是在75%，对应的velocity似乎是6，我想这是个比较理想的利用率。在我所在的scrum
team中，team size是4， 但是资源利用率看起来似乎是56%左右，velocity相当于是 4.5个
ideal person-hour每工作日。
在如何看待这些metrics指标的事情上，我个人觉得脱离应用场景单看指标的做法没有太好的指导意义，就如同挣值算法中的cpi/spi。而实际我们尝试提高velocity的时候，可能会导致最终在task估算时候，task规模估算结果难免掺水；最终velocity上去了，但是生产率实际没有提高。同时团队成员也不大情愿做这样的事情，毕竟他们在这样的模式下已经工作了很久（不否认他们的productivity，team
size小，近距离的观察表明了没有明显损失效率的工作习惯）
在遇到此类两难问题时，我首先的立场是尽管velocity是4.5这个较低的水准，但是由于团队对task的估算结果使用了”干货策略“，而且即便如此也存在偶尔加班的情况，所以实际的生产率不会是4.5所体现出来的这么低；但是另一方面，4.5这个velocity在向PMO做汇报的时候，往往容易引起误解。
不为提高velocity而提高velocity，毕竟目标是提高productivity。不过就上述情形而言，我们的项目组织和流程上，是不是也存在一些问题？
我们现在用的是hours-burndown, 最近在看story point方面的内容，在这方面是否能够找到改进机会呢?
最后，稍微表达一下歉意，在邮件中串了不少英文单词，可能是因为习惯，很多时候觉得英文单词的意思会更准确些。期待你的答复，祝工作顺利！
Zhang：请问你们用什么来表示sprint的规模？ 是用理想人天吧，还是用户故事点数？
由于Scrum/Agile中的不少词没有确切的中文，只能夹杂E文。
Chen：我们采用了理想人天的方式，例如velocity是4.5，
表示一个工作日相当于是 0.56 个理想人天 ( 4.5/8), 以一个sprint两周来计算的话，sprint规模的计算公式是：
velocity * 项目人员数量 * 10个工作日 ， 这里的数量单位是： 人-小时数
由于现在的项目进度每日进度跟踪现在非常依赖于 JIRA，而JIRA目前只提供了hour-burndown,
所以故事点数暂时没有推行。
Zhang：敏捷是基于信任的，秉承的是Y假设。
敏捷本身不鼓励外面给团队设定velocity要求。
采用理想人天后，在技术手段上就更加没有特别好的手段来从外面给团队设定velocity要求。
什么算一个理想人天，由于处理的事情多种多样，是很难归纳的，我猜想你们也许没有一个恰当的定义。
我想推荐给你们的是 积累典型样例（不知道你们是否已经这么做了？）。 什么样的典型事务 算1个理想人天，什么样的算5IMD。
有了这些积累后，理想人天就相对客观。
当然这些积累不是不变的，随着时间推移要变的，否则可能会出现资源利用率大于 100%的事情来，这个解释起来更麻烦。
团队有了相当比较客观的基础后，就可以在样例和数字上做文章了。
以上也许只是数字的提高，真实的提高是要靠真正提升团队的能力、热情和氛围，敏捷团队建设不是个快速过程，不能照着某些敏捷文章描绘的美妙场景马上推进，小心敏捷的乌托邦。
如果采用Story point 或者 UCP，那么在技术手段上 会比IMD要多一些方法。你们可以看下。
但是不会改变敏捷的本质，如果你们开发团队认为IMD用得不错，只是PMO有点意见，那就没有必要改。
对付PMO，相信你有很多办法：）
Chen：谢谢您的答复，我得到了很多启发 :) 相信我已经得到一个比较合适的思路和方向
Zhang：能告诉我 你的思路和方向吗？
另, 可以把 你的问题和我的回答 放在我的blog上公开吗？
Chen：完全没有问题，我觉得把这个thread放到blog上，
能够获得更大范围的知识讨论和共享，对于各方来说都是件非常有益的事情。
关于思路和方向，在那个时间我当时的想法是针对于PMO的问题，我大致上可以有一些合理分析：首先是以什么样的标准，来界定日常工作中的某个时间是划分到ideal时间内，例如各个team是否统一这样的一个共识，这样横向比较的结果才更加客观。（例如A
team，对于research的讨论，不认为是ideal hour， 而B team则划归为ideal
hour，这样比较A和B的velocity，自然是不够客观。）基本上我认为这是个PMO需要澄清的问题。
现在我在想法上，更好的思路可能应该是，PMO提供支持和帮助，而对于上面提到的ideal标准问题，尽量避免尝试推行一个“放之四海而皆准”一个客观标准，因为这毕竟有X假设的倾向，而且不利于Scrum团队的自组织，但是可以推行一个参考而非强制的标准。
没有观察就没有发言权，如果你（PMO）有质疑，那么欢迎你抽出一些时间，作为chicken角色和观察者，抽出一些时间来参与并帮助我们分析和改进实际的生产力；如果只是要velocity的report好看，这个通过投巧的办法，实在是太容易做到了。
Zhang：PMO的X假设倾向 在有些组织里得到更高层领导的支持。
而且在以PMBOK为代表的项目管理理论上，并不排除X假设，并不全盘采用Y假设。感觉在PMBOK中，秉承的是中庸之道，XY各占一半。
PMO的X假设倾向做法虽然跟敏捷方法有抵触，但从公司级管理看，不会没有道理。敏捷的项目团队需要适应这种环境。如果一味的强调"团队决策自组织"，而与公司级管理措施抵触，我以为是没有必要的。 | 
