Chen:
您好,我看了您些的关于Scrum sprint plan中规模估算的一篇文章(http://blog.csdn.net/zhangmike/article/details/6980334),觉得梳理和总结的比较好。
最后,稍微表达一下歉意,在邮件中串了不少英文单词,可能是因为习惯,很多时候觉得英文单词的意思会更准确些。期待你的答复,祝工作顺利!
Zhang:请问你们用什么来表示sprint的规模? 是用理想人天吧,还是用户故事点数?
由于Scrum/Agile中的不少词没有确切的中文,只能夹杂E文。
Chen:我们采用了理想人天的方式,例如velocity是4.5,
Zhang:敏捷是基于信任的,秉承的是Y假设。
采用理想人天后,在技术手段上就更加没有特别好的手段来从外面给团队设定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各占一半。