谈谈SCRUM执行上的困难
克强
难。
我看到的SCRUM的困难
1, Sprint Backlog确定依赖在团队的经验和诚实
经验不足可能导致选择有大偏差，不诚实可能故意减少。
2, 燃尽图的制作没有客观的依据，依赖主观判断
3, Spring Backlog的规模度量没有客观依据，无法在多个团队间共享度量方法。
请大家补充，请说说解决这些困难的有效实践
如果不是困难，请说说相应的有效实践
Xu Yi
不好意思，没看懂你的中文描述。。到底是什么困难？
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
Dayong Sang
1. 是说团队选择的Sprint Backlogs是否与团队一个Sprint内的开发能力匹配吗？团队为了安全起见，故意少做Sprint Backlogs的问题不是Scrum本身的问题。如果团队所选Backlogs过多或过少，或许是团队在Sprint Backlogs的大小（规模）估计能力方面不成熟、估计标准不大稳定（忽高忽低），也或许是Sprint Backlogs的颗粒度差别较大（人们往往会高估过小的Backlogs、低估过大的Backlogs）。
2. 如果按照Tasks的完成比例估算已经完成的工作量，的确会使燃尽图的客观性下降，因为Tasks是否完成无法由开发工程师以外的团队成员所验证。可以参考其他敏捷方法中的思路、放弃跟踪Tasks的进度，将Sprint Backlogs进一步细分后进行大小估计（如有些Scrum团队也使用XP的用户故事代替Backlogs），只有通过从最终用户的角度测试或验证的用户故事才记入已经燃尽（完成）的工作量。这一原则可以称作Done Done原则。
3. Sprint Backlog规模度量直接映射到人天，估计者会受到很多心理压力（估计工作更像是开发人员的一种承诺），感觉不如XP中的相对工作量估计客观。XP中相对工作量估计结果在不同团队之间是不可比的，但是估计方法是比较容易在不同团队中推广的。
ozzzz...@gmail.com
实际上scrum不是一个框架，更不是一个完整的方法，而是一个管理偏好的实践集合。这个属性，决定了其易溶于其他方法，也易于被其他方法所接纳。这个
属性，我认为如其是一个优点，也是一个缺点，不如说是一个特点。
然而问题也随之而来，由于其不完全性，所以需要同其他方法相配合，特别是需要同技术层面偏向的方法相配合使用。而可以说技术方面的实践是基础，是决定性
的。scrum更多的时候还是一种辅助手段，不是主体也不是主题。
这并非是scrum的一个缺点，也不是一个优点，而是一个特点。实际上我们看到的几乎所有的方法，都试图成为主体，成为主要方面。而我知道光有主题，光
有主体是不行的，红花还需要绿叶。scrum就是这个绿叶，是一种促进剂，也是一种粘结剂。使用这个方法，可以叫我们更少的耗费资源，更好的将各个环节
衔接在一起。
而进一步，scrum其实里面很多内容并没有规定的很详细，比如scrummaster究竟是一个什么东西，是一个角色还是一个职位；backlog里
面究竟应该放进去的是任务还是故事；一个sprint究竟是不是一个迭代周期；这些问题都是需要在实际的操作中去结合具体情况，做针对性的调节的。也就
是说，这个时候是应该依照主体方法，去对scrum的各个参数做调整。
我举一个例子，比如迭代周期和sprint周期的问题。我们知道，默认的sprint是4周。而我们普通的企业，一个活动周期是一个月。把这个
sprint加上一个启动日和一个完成接受日，就刚好是一个业务周期，也就是一个月。一般情况下，企业的管理层和财务周期，也都是一个月。这个是一个普
遍存在的情况。
但是我们的迭代周期往往是按照具体的情况做出的技术周期，目前我见到的绝大多数使用xp的组织都是使用小周期，也就是一周一个迭代。而我们可以把这些小
周期，按照不同的主题，放入一个sprint中。而往往发布的周期，也是按照月来分配。而提交给客户的周期，往往是按照周来衡量。
在这样的情况下，我们就可以4次传球，达成一次进攻。
类似的地方很多，关键还是在于对scrum这个方法的理解。同很多人的想法相反，scrum这个东西理解起来难度非常高，虽然面子上很容易懂，但是里面
的内容由于其辅助性和互溶性则很难把握的。特别是最近，很多杂音在scrum这个圈子里面吵吵，人的素质也比较低，问题更多。而且我发现，这里面的人往
往都是为了过程而过程，做的是面子，走的是形式，流于庸俗。
On 2月26日, 下午2时21分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/2/26 克强 <zhangkeqi...@gmail.com>
ozzzz...@gmail.com
就好比会计完全是一种辅助手段，但是却普遍的存在于最大多数的业务场景下。
张克强
本贴是谈SCRUM执行上的困难。
楼上在操作中有没有碰到一些呢？
比如scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？
我先来抛砖：
1，在得到领导支持(或者你就是领导）的情况下，在组织层面开展，可以挑选在SCRUM上有所认识和实践的人来提当SCRUMMaster，可以送出去
培训，这位SCRUMMaster应当指导多个项目，从工作量推断看，5个项目可能是最大值，scrummaster应当有独立于项目组的汇报途径,
scrummaster在过程中识别的问题应当有机制确保解决。把scrummaster作为一个职位，或者在现有职位中加入scrummaster的
职能，比如EPG或QA，我所在组织按CMM/CMMI框架，EPG直接担当了scrummaster的职能。
2,在不清楚scrum的情况下或领导不清楚scrum的情况下，在项目层面开展，让热心于Scrum的项目经理直接担当scrummaster，这时
scrummaster是个角色，我所在组织最早引入scrum时就是这样做的。
我的问题1：Dayong说的没错，就是我的问题，但不知解决方法是什么？
我的问题2：Thank Dayong, 我们当前执行的方法与你说的非常相似，使用了"用例“的状态转移来处理，但状态转移中仍然有百分比的设定。执
行上还是有不一致的情况。有没有其它解决方法？
我的问题3：Dayong说的就是我们碰到的问题，与第一个问题也相关，在管理者的角度上，总是有一种倾向：比较不同团队的表现，担心某些个团队会不会
故意夸大工作量，如果sprint backlog的规模度量有一定规则，那么可以比较不同scrum团队间的效率，也许这一点就与敏捷的自组织原则背
离，可是管理者的角度是不能不考虑的。 有何有效的实践？
Xu Yi
关于SCRUM的原理和适用性，偶还是知道一些的。本贴是谈SCRUM执行上的困难。楼上在操作中有没有碰到一些呢？比如scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？我先来抛砖：1，在得到领导支持(或者你就是领导）的情况下，在组织层面开展，可以挑选在SCRUM上有所认识和实践的人来提当SCRUMMaster，可以送出去培训，这位SCRUMMaster应当指导多个项目，从工作量推断看，5个项目可能是最大值，scrummaster应当有独立于项目组的汇报途径,scrummaster在过程中识别的问题应当有机制确保解决。把scrummaster作为一个职位，或者在现有职位中加入scrummaster的职能，比如EPG或QA，我所在组织按CMM/CMMI框架，EPG直接担当了scrummaster的职能。2,在不清楚scrum的情况下或领导不清楚scrum的情况下，在项目层面开展，让热心于Scrum的项目经理直接担当scrummaster，这时scrummaster是个角色，我所在组织最早引入scrum时就是这样做的。
ozzzz...@gmail.com
scrummaster就角色来说的任务是维护scrum流程的无障碍运转，其作用不在于领导和管理，而在于维护过程。他不是一个管理决策者，也不参与
开发的实际操作，其管辖的只是流程。但是这里也需要注意，scrummaster是负责维护流程，而不是改进流程。因为流程的改进是一个系统化的，多角
色参与，多角度共同协作的，并且应该有高层领导决策的任务。你们应用EPG做scrummaster还会造成自己对自己的工作做评估，这不仅失去了
scrummaster的初始意义，也失去了管理上最基本的管辖权意义。是一种典型的在误解驱使下的做法。
当然这样的问题不会马上在实际操作中造成后果，但是其影响必将是深远的。比如就scrummaster来说，或者就EPG来说，其工作的成果的自我评估
性，会造成管理层和执行层对于具体工作责任人的具体任务完成情况不清楚，也可能造成其任务目标根本就不清晰。而长此以往，这种问题会扩散到整个环境中
去。也就是说，在你们这样的条件下scrummaster很容易成为一个没有责任，没有义务，只有权力的人。
至于你的疑问，都是跟scrum方法没关系的，具体的技术层面的操作问题。scrum这种方法不会涉及这些内容，这些东西需要你去xp或者FDD，以及
up等方法里面去寻找。当然这些方法，还跟你们现在实施的现有方法和客观环境有关系。比如是跟踪task取得进度指标，还是跟踪story取得进度指
标，或者是使用feature，用例点，用例片，代码行，等等方式都是可行的。关键是要看你们的场景究竟适合什么。
简单的说，我认为你的问题都是完全跟scrum没啥瓜葛的问题，是软件开发中估算和评估方面的问题，是一种基本功。
张克强
天下不会掉下Scrummaster, 总是在一定的基础上来开展工作. 在看到Scrum有利于提高项目绩效的情况下, 是等待一位纯粹的
ScrumMaster, 还是在现有的框架内设法先做起来?
这个回答是显然的, 当然是先做起来,允许第一个项目先试起来, 有初步的成功之后再推广一些。 设置scrummaster职位可不是一件容易的事
情。
过程中理解有问题是完全正常的，scrum本身也在发展中，因此我来到这里，提出我的问题，希望得到一些解答，也分享一下自身的实践，请大家提提意见，
希望意见是建设性的，而不是打击型的。
有如下几点还想进一步探讨：
1，scrummaster作为团队成员的做法，虽然也许不推荐，但也是可行的，尤其在资源紧张的时候，这样scrummaster会参与开发的实际操
作
2，scrummaster发现并指出了团队执行流程的问题，如果团队不同意解决或者总是迟缓解决，应当如何处理？是否可以借助行政管理的力量来解决？
(我们这边会借助，实际效果可以。)
3，scrum有回顾会议（retrospective），scrummaster在此时提出改进，这个是应当做的吧，scrummaster应当具备
较普通成员更敏锐的观察力，更应通过改进以获得更好的效果。
4，回顾会议就是一个“自己对自己的工作做评估”的过程，叫scrummaster称号的人参加这个会议，与叫EPG的人参加这个会议，并没有实质的区
别。
5，在CMMI，EPG不是单独评估过程，有如下几种形式：SCAMPI A，B，C以及其它自定义的方法，不会出现EPG单独来评估，一般是QA肯定
会加入。EPG绩效评估也不是自己评的，EPG的行政领导评估EPG的绩效。
EPG的责任和绩效主要有两方面：1，评估中不能有过多过大的弱项 2，使项目组获得改进的实效，第1条在正式评估中如果做不好，直接就完了，非正式评
估时也有巨大压力，第2条如果做不好，项目组的抱怨和不配合也差不多让EPG完蛋，因此担当scrummaster职责的EPG不可能成为“没有责任，
没有义务，只有权力的人”。
6，楼上对这个问题“scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？”，有什么解答？如果已经回答过了，可否给个链接
7，原来的问题，虽然“与scrum没啥瓜葛”，但还是希望在这里寻求一些方法，毕竟要把软件编出来。我把问题场景化一下：有二支商业环境下团队，同属
一个部门，TeamA和TeamB，虽然都选择了名为用例点的方法，但是各自都有一些不同的调整，TeamA每次完成的人均用例点数量明显少于
TeamB，可以得到的解释是用例点定义方法不一样，但就有这样疑虑，TeamB有没有诚实问题，TeamA有没有经验能力问题？（毕竟奖金池是在同一
个部门，要分的啊），作为部门领导，如果强行要求两个Team统一用例点方法，有没有过于不利的后果？ 如果部门领导把这个问题给了
scrummaster，scrummaster可不可以要求两个Team采用完全一样的用例点方法？
btw:希望有一个讨论的气氛，照顾一下在基本功上没有过关的朋友
jayden guan
Xu Yi
谢谢回复
天下不会掉下Scrummaster, 总是在一定的基础上来开展工作. 在看到Scrum有利于提高项目绩效的情况下, 是等待一位纯粹的
ScrumMaster, 还是在现有的框架内设法先做起来?
这个回答是显然的, 当然是先做起来,允许第一个项目先试起来, 有初步的成功之后再推广一些。 设置scrummaster职位可不是一件容易的事
情。
兄台知否broken window理论？不合格的scrum master，就好比高楼大厦打的却是豆腐渣地基，不是每座塔都叫比萨斜塔，强烈建议你们能够招募一位有经验的scrum master。
“设置scrum master职位”这句话一看就让我觉得你们的scrum实施变了味。
楼主如果真是想要讨论，那么不妨抛开自己的某些前提条件，也去思索一下你所在的环境（政策、人员等）是否适合采用scrum方式。依样画葫芦，让其和现有框架完美结合并命名为scrum--易，真正从某个叫“scrum”的方法中获利--难。
张克强
这样TeamA和TeamB在这时在利益上是冲突的。
虽然现在一般不允许底下交流奖金，但作为部门的老大，还是想公平一些。
On 3月1日, 下午9时41分, jayden guan <jayden.g...@gmail.com> wrote:
> 要不楼主把问题7的情况说说清楚，也方便大家讨论。
> 比如说撒叫：毕竟奖金池是在同一 个部门，要分的啊。
>
> 2009/3/1 张克强 <zhangkeqi...@gmail.com>:
>
张克强
就算有此情况，幸亏我们在软件行业，不是在盖楼，还在积极地拥抱变化。
"招募一位有经验的scrum master" 与"设置scrum master职位"是关联的啊。
让当前可能"不合格"担scrummaster职责的EPG 变成合格的scrummaster，是我们当前最快速经济的方法。
我确实是"真是想要讨论"，带来的问题也比较实在，确实希望"真正从某个叫"scrum"的方法中获利"
我们已经有多个项目运行在敏捷方法之下，哪怕是名义上的，所以关于适合的问题就不再考虑了。
关于前提条件，每家组织都会有一些前提和历史，对吧？
总是在不同的基础上来引入scrum, scrum理论要和实践结合在一起，本论坛"聚合中国敏捷实践者的经验"
（以上是否就不用再讨论了，或者新开贴，本贴就聚焦在问题和实践上）
楼上兄台可否说说在问题6"scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？"上的实践？ 或者有没有现成的链接？
On 3月2日, 上午2时36分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/3/1 张克强 <zhangkeqi...@gmail.com>
>
> > 谢谢回复
> > 天下不会掉下Scrummaster, 总是在一定的基础上来开展工作. 在看到Scrum有利于提高项目绩效的情况下, 是等待一位纯粹的
> > ScrumMaster, 还是在现有的框架内设法先做起来?
> > 这个回答是显然的, 当然是先做起来,允许第一个项目先试起来, 有初步的成功之后再推广一些。 设置scrummaster职位可不是一件容易的事
> > 情。
>
> 兄台知否broken window理论？不合格的scrum
> master，就好比高楼大厦打的却是豆腐渣地基，不是每座塔都叫比萨斜塔，强烈建议你们能够招募一位有经验的scrum master。
>
> "设置scrum master职位"这句话一看就让我觉得你们的scrum实施变了味。
>
> 楼主如果真是想要讨论，那么不妨抛开自己的某些前提条件，也去思索一下你所在的环境（政策、人员等）是否适合采用scrum方式。依样画葫芦，让其和现有框架完-美结合并命名为scrum--易，真正从某个叫"scrum"的方法中获利--难。
Xu Yi
了解broken window,不过我根本没有联想到此，上述我介绍的情况让楼上联想到此？
我是担心你们的实施走了样，以后又来怪scrum而已。
"招募一位有经验的scrum master" 与"设置scrum master职位"是关联的啊。
可以说scrum master的任务就是让自己消失，恐怕没有哪个职位的任务是让自己消失吧？
让当前可能"不合格"担scrummaster职责的EPG 变成合格的scrummaster，是我们当前最快速经济的方法。
如果你能接受最快速经济方法的某些弊端，那么，your choice。
我确实是"真是想要讨论"，带来的问题也比较实在，确实希望"真正从某个叫"scrum"的方法中获利"
我们已经有多个项目运行在敏捷方法之下，哪怕是名义上的，所以关于适合的问题就不再考虑了。
有意思，如果你关注过好些相关的讨论组，你应该知道run着名义上的scrum或是其他敏捷方法，却想解决过程中遇到的许多问题，恐怕根本就是徒劳无功啊。scrum master的任务之一就是保证scrum不要走样，以及在尽可能的挑战企业各方面不够敏捷的地方。
关于前提条件，每家组织都会有一些前提和历史，对吧？
总是在不同的基础上来引入scrum, scrum理论要和实践结合在一起，本论坛"聚合中国敏捷实践者的经验"
oh yeah，那么兄台加油吧。
（以上是否就不用再讨论了，或者新开贴，本贴就聚焦在问题和实践上）
耶，难道以前有过类似的讨论？
楼上兄台可否说说在问题6"scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？"上的实践？ 或者有没有现成的链接？
天啦，我也不知道该如何介绍。。但我可以负责任地告诉你，最好的资源自然是www.scrumalliance.org；我不是要拉客哈，但谈到中国的scrum，http://tech.groups.yahoo.com/group/ScrumChina/ 这个yahoo上的讨论组应该更加的focus一些；最后，如果你有兴趣，欢迎参观指导我的博客相关部分http://damianji.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=cat%3dAgile%2526Scrum%2526Testing%2526TA。
scrum master不是个东西
。。是个角色。。负责观察及维护scrum的正常运转，帮助相应的scrum团队走在正确的道路上。很难讲在执行上有哪些可取的做法，因为总结经验总结下来，差不多还是书中或者官网上的内容，遇到的问题更多的是组织自身的不足。你的其他问题，等我稍后有时间再一一解答。
张克强
既要招人或安排人做scrummaster的事，慢慢地还要让scrummaster消失，
需要时间和实践后再说了，以后再来谈体会
Thanks,
I join http://tech.groups.yahoo.com/group/ScrumChina today.
and I visited your blog before you mentioned. It's colorful. Happy in
Finland
On 3月2日, 下午12时12分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/3/2 张克强 <zhangkeqi...@gmail.com>
>
> > 了解broken window,不过我根本没有联想到此，上述我介绍的情况让楼上联想到此？
>
> 我是担心你们的实施走了样，以后又来怪scrum而已。
>
> > "招募一位有经验的scrum master" 与"设置scrum master职位"是关联的啊。
>
> 可以说scrum master的任务就是让自己消失，恐怕没有哪个职位的任务是让自己消失吧？
>
> > 让当前可能"不合格"担scrummaster职责的EPG 变成合格的scrummaster，是我们当前最快速经济的方法。
>
> 如果你能接受最快速经济方法的某些弊端，那么，your choice。
>
> > 我确实是"真是想要讨论"，带来的问题也比较实在，确实希望"真正从某个叫"scrum"的方法中获利"
> > 我们已经有多个项目运行在敏捷方法之下，哪怕是名义上的，所以关于适合的问题就不再考虑了。
>
> 有意思，如果你关注过好些相关的讨论组，你应该知道run着名义上的scrum或是其他敏捷方法，却想解决过程中遇到的许多问题，恐怕根本就是徒劳无功啊。sc-rum
> master的任务之一就是保证scrum不要走样，以及在尽可能的挑战企业各方面不够敏捷的地方。
>
> > 关于前提条件，每家组织都会有一些前提和历史，对吧？
> > 总是在不同的基础上来引入scrum, scrum理论要和实践结合在一起，本论坛"聚合中国敏捷实践者的经验"
>
> oh yeah，那么兄台加油吧。
>
> > （以上是否就不用再讨论了，或者新开贴，本贴就聚焦在问题和实践上）
>
> 耶，难道以前有过类似的讨论？
>
> > 楼上兄台可否说说在问题6"scrummaster究竟是一个什么东西, 在执行上有哪些可取的做法？"上的实践？ 或者有没有现成的链接？
>
> 天啦，我也不知道该如何介绍。。但我可以负责任地告诉你，最好的资源自然是www.scrumalliance.org
> ；我不是要拉客哈，但谈到中国的scrum，http://tech.groups.yahoo.com/group/ScrumChina/这个yahoo上的讨论组应该更加的focus一些；最后，如果你有兴趣，欢迎参观指导我的博客相关部分http://damianji.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=B...
> 。
>
> scrum master不是个东西[?]
> 。。是个角色。。负责观察及维护scrum的正常运转，帮助相应的scrum团队走在正确的道路上。很难讲在执行上有哪些可取的做法，因为总结经验总结下来，差-不多还是书中或者官网上的内容，遇到的问题更多的是组织自身的不足。
>
> 你的其他问题，等我稍后有时间再一一解答。
> --
> - - - - - - - - - -
> Xu Yi, Kaverjody
> Agile Coach.CSP
> Test Automation Coach
> Blog :http://damianji.spaces.live.com
> - - - - - - - - - -
>
> 33D.gif
> < 1K查看下载
ozzzz...@gmail.com
信，现在国内有80%实施scrum的实际操作是在胡搞。并且我还相信，在国际范围内，这个比例会更高。而这也是最近围绕scrum争吵不断的根本原
因。
首先我觉得你还是混淆了scrummaster这个东西是角色还是岗位这个问题，这个问题的重要性，我想大家都很明白。我就不多说了。
这里我倒是要坦言一下另外一个问题，那就是是不是几个团队可以共享一个scrummaster？这个问题很微妙，是不是。当然我们会经常性的见到，基本
组织共享一个教练。那么共享一个master是不是也是可能的呢？实际上想明白这个问题，理解scrum也就差不多到位了。
当然这里还有另外一个问题，需要我们讨论。那就是是不是实施scrum需要基础，或者进一步说scrum需要同一些什么样的基础性实践结合才能更加起作
用？理解清楚这个问题，就可以对scrum的使用范围和使用的策略有足够的认识。
进一步，还有一个问题----原有的祖宗结构是不是会因为实施scrum发生改变，或者叫scrum的方法更适合在何种组织下实施。
以上是我对于初学scrum者的提示，这里没有标准答案，但是大概还是有个范围。
下面我要说另外一个问题，那就是CMMI组织的问题。这里也涉及到一个问题，那就是EPG究竟是一个角色，还是一个岗位。如果是角色，那么其作用自然比
较清楚。但是如果是岗位呢？而且就我见到的很多所谓高级别CMMI组织，这都是一个岗位。而这里恰恰是一个陷阱。
EPG究竟是评估流程实施的效果，还是评估流程的质量的？或者说EPG是应该对流程展开工作，还是应该对生产展开工作。而落实到这里就会有这样一种情
况，当进行回顾会议的时候，scrummaster究竟是一种什么样的态度去去面向流程呢？自然以我们知道的情况来说，他往往是希望不断的改进，不断的
优化。但是这个事情就要有个动机，他究竟是以增加生产力为导向的，还是以流程完善为导向的。虽然这两个问题看起来有内在联系，但是事实上在实施的时候是
差别巨大的。本质上说scrummaster是希望不断的调整，而EPG则是希望不断的收集数据然后讨论作出结论之后进行调整的。
其次我们还应该明白，EPG这个角色，应该是一个公共角色，是多个组织和多个项目共享的角色，而且越是共享性强，其效率会越高。而
scrummaster责任则是内敛型的，越是局促的在一个祖宗内部，其作用越是明显。这是因为scrummaster的一个最大作用是起到防火墙的作
用，而一旦一个人对多个组织负责，其隔绝作用就会虚弱下去。
再次，就工作绩效评估来说这里也有问题。绩效评估有一个原则，虽然你使用的方法可以不同，使用的理论不同，但是这个原则是一定存在的。所谓的绩效评估，
其实就是对于工作者的岗位的产品进行评估。落实到这里，具体的说就是评估EPG的绩效应该是看流程，而看scrummaster的绩效应该看在流程中的
组织。体会这两种情况的不同。打一个比喻，EPG是质检科的，而scrummaster是生产科或者是车间的。如果质检科直接下到生产线去负责生产会如
何？结果当然是乱套了。因为他们的职责本身就是有内在冲突的。
其次还要有一个问题我们必须明确cmmi是面向过程评估的，而不是面向HR评估的。SCAMPI今天不会，明天不会，后天也不会，并且其他任何新的评估
方法也不会去评估企业的绩效考核方法。
而对于你说的问题7，我感觉很遗憾。就你说的问题来说，我认为属于最最基本的项目评估和规模判断问题，如果以你现在的发言看，我认为你们还处于cmm0
级或者cmm1级。我虽然觉得cmm这个方法很荒谬，但是我认为他们这个基本问题还是解决了的。我希望你还是好好回去学习学习基本的管理学原理以及绩效
考核原理才是。这里你至少要知道，劳动生产率的评估和绩效评估是完全不同的两个问题。
再其次，组织间的绩效评估，也需要很多的措施。但是这里不过如何，都不应该走利益相互对立，搞此消彼长的事情。这里其实跟为什么EPG不能去做
scrummaster是有一些相同的地方的。
其次另外一个问题是，领导是不是应该直接可以决定下属的工资收入，这个一点其实很少需要讨论。我们往往要讨论的是，是不是需要下属知道这一点。当然对于
像你们这样粗放组织的情况，我们不需要讨论。因为在你们那里不管如何做，结果都一定是不好的。
以上是完全从管理和绩效角度的讨论，你完全可以无视，因为这些方面跟你开发软件关系不大。
我现在要说说软件开发的问题。实际上我们经常会遇到，两个组织协调的问题。而协调的第一步，就是协调计量衡和术语。按照你所说的情况，我既然是同部门，
那么术语的统一问题应该不大。统一的应该是计量衡问题。而在软件开发过程中规模问题，是首先要统一指标的一个问题。不过其实这并不是一个难解决的问题。
实际上难点是在于，如何能够对于规模进行计量。而现在你们这个问题，其实是在说如何对于计量的结果，进行单位统一或者单位换算公式的确立。
而就你第一次发言来看，你们的计量问题就没解决好。现在又出现了单位换算的问题。原则上计量问题不解决到一定解决，单位换算的问题就无实际意义。
同时我还要进一步说明，当领导把这个工作交给scrummaster的时候，作为scrummaster应该立即予以拒绝，因为这个是一种对于实施
scrum的干扰，是添加非实际的列入blacklog的任务。并且如果领导继续干扰，应该进一步上报，并最终排除这种无聊的扰动。不过如果领导把这个
事情叫给一个EPG，那么这个就是一个本职工作，这恰好属于他的工作范畴。
Xu Yi
1，scrummaster作为团队成员的做法，虽然也许不推荐，但也是可行的，尤其在资源紧张的时候，这样scrummaster会参与开发的实际操
作
scrum master和team member的职责在某些时刻会有冲突。同时担任两个角色最多作为应急的办法，而不应长期使用。如果一定要scrum master兼任，我更推荐他们做类似coach的事情，比如TDD coach，提高团队的TDD能力，等。
2，scrummaster发现并指出了团队执行流程的问题，如果团队不同意解决或者总是迟缓解决，应当如何处理？是否可以借助行政管理的力量来解决？
(我们这边会借助，实际效果可以。)
什么样的问题，能否详细点讲？
从长远的角度来看，借助行政管理的力量，会破坏团队形成“自管理”团队的成效，并不可取。
3，scrum有回顾会议（retrospective），scrummaster在此时提出改进，这个是应当做的吧，scrummaster应当具备
较普通成员更敏锐的观察力，更应通过改进以获得更好的效果。
retrospective是team总结过去、展望未来的机会，scrum master在此时更多的是作为facilitator的角色参与。即使scrum master同时也兼任team member，其他团队成员也难以正确理解其发言时所代表的角色，“究竟是另一个团队成员提出的尖锐问题，还是scrum master强行干涉我们的工作”。
说得空一点，需要给team犯错误的机会，他们才能够从中学习到更多。
4，回顾会议就是一个“自己对自己的工作做评估”的过程，叫scrummaster称号的人参加这个会议，与叫EPG的人参加这个会议，并没有实质的区
别。
scrum master并不为team指定流程，而是帮助team改进他们自己的“流程”。
7，原来的问题，虽然“与scrum没啥瓜葛”，但还是希望在这里寻求一些方法，毕竟要把软件编出来。我把问题场景化一下：有二支商业环境下团队，同属
一个部门，TeamA和TeamB，虽然都选择了名为用例点的方法，但是各自都有一些不同的调整，TeamA每次完成的人均用例点数量明显少于
TeamB，可以得到的解释是用例点定义方法不一样，但就有这样疑虑，TeamB有没有诚实问题，TeamA有没有经验能力问题？（毕竟奖金池是在同一
个部门，要分的啊），作为部门领导，如果强行要求两个Team统一用例点方法，有没有过于不利的后果？ 如果部门领导把这个问题给了
scrummaster，scrummaster可不可以要求两个Team采用完全一样的用例点方法？
一个product backlog只应该有同一个“用例点”定义方法，这里我假设你所指的是story point，用来估计product backlog里面的item大小，而且是relative point，并不会关联到具体的“人月”之类的单位。
统一“用例点”定义的目的是为了帮助产品负责人管理product backlog，从而可以根据product backlog（或者release backlog）中剩余item的总用例点以及产品开发团队们的velocity来估计潜在的产品发布周期或是在某一时刻可能实现的功能列表。
奖金分发可以通过其他的方式来决定，而不必和用例点或者说product backlog的管理扯在一起。
张克强
对于EPG，在不少企业，EPG是一个岗位，也有QA兼EPG的做法，但大多数的说来，EPG是岗位，不少企业也在招聘EPG，国际上也有SEPG大
会，苏州办了几年中国的SEPG大会。CMMI不再局限于Software后，SEPG改称EPG。关于EPG的职责和任职要求，已经有公论，也有大量
的资料，不过没有认证EPG的课程。
关于EPG质检科比喻是不恰当的，像质检科的是QA，EPG更恰当的可以比作是技术科（或工艺科），负责制定生产工艺，承担指导车间的责任，并根据实际
情况进行调整。生产绩效高不高，与技术科密切相关。
第7个问题，与绩效考核还是有些距离的，我在括号中说明“奖金要分”，是为了形象的说明问题，问题的本身是同一部门是否可以有不同的团队有不同的规模度
量方法，感谢Xu yi，给出了他的建议，我也认为还是应当有相同的方法为好。
就实际的试图引入scrum组织而言，存在着千差万别的情况，都受组织历史和现状的影响，出现80%的“胡搞”应当是正常的。出现很多杂音也是正常的，
出现问题也是正常的，至于人的素质，我相信大多数试图搞Scrum的软件工程师都是好样的。
我作为80%的一员希望在这里“多研究些问题，少谈些主义”。
如果不愿意讨论来自80%部分的问题，可以不回贴，如果愿意讨论，说说你的实践和困难或你见到的实践和困难。
如果本贴还会增长，超出实际问题和实践的贴子，我将不再回复。
如果本贴就此结束，我要感谢Dayong和Xu Yi, 从他们的贴子中得到了解答。
如果有上海Scrum沙龙或者有合适机会，很希望和大家（包括o6z)见面交流。
ozzzz...@gmail.com
其实很多东西目前都遇到了这样的问题。比如我们说质检，很多人以为就是QA或者QC。但是他们忽略了，质检和质监的区别。而这就造成企业在推行TQC时
候的种种误解和混乱。这一点在我刚毕业还在药厂工作的时候，就已经是一种被广泛讨论的事实，但是即使到了今天企业依然如故。所以说名不正则言不顺。而这
也就是造成80%的企业其实根本就可以不跟他们讨论，也可以不必跟他们讲实践的根本原因。因为他们的初衷就是错的，自然以后的实践也好不到什么地方去。
自然我们应该多讨论问题，少谈论主义。不过现在最大的问题就是主义问题，而不是实践问题。因为我相信绝大多数人都赞同，做对的事情，比把事情做对更加重
要。而把事情做对的第一步，就是将问题进行适当的分类，这是人类解决问题的普遍习惯。是管理问题，就应该着重使用管理手段解决；是HR问题就要用HR手
段。当然我们还要承认，企业问题往往是系统化的问题，但是不能因为是系统化的，就否认就不可以不加区分，没有重点。而我相信，由于各人在自己企业中的位
置不同，获得的资源和支持也不同，未必能够把所有的手段都用上，而且更多的情况下是根本就只能动用手中有限的资源和被辖制的有限手段。但是我们并不能因
此就不去关心，问题最佳的解决方式是什么，最佳解决途径是什么。而且解决的手段也因为是面对的是系统化的问题，也需要系统化。往往也是多种选择，多种组
合。但是我们必须清楚，自己动用的手段因为不一定是最佳的，其效果就可能不是最好的，结局也未必就那么理想。这才是一种工程师和商人做事情的应做到的本
分和态度。没有了这个态度，我觉得讨论任何问题就缺乏了最基础的可能性，也就是根本没有任何必要的。这是唯一务实的做法。
下面在说说规模评估的标准问题。这个问题可以说是一个从软件开发出现就已经存在的问题，并且也是一直研究的热点问题。而就一个组织来说，存在多种的规模
参数，使用多种的规模测算方法，是最最常见的情况。并且实际的情况也需要我们从多个层面，多个角度，使用多种方法，对同一个项目进行评估，得出不同的参
数系统。这不是能不能的问题，也不是应该不应该的问题，而是必须要如此，必须做的问题。我们唯一需要把握的，是引入多少方法和多少角度，做多少中评估，
并且保留多少指标的问题。同时我们还要知道，即使是一个指标，因为使用的方法不同，得到的数据也会不同。比如同样是测量温度，那么在实际的流水线中，测
量装置的位置，测量的频率，测量的持续性，都会对得到的数据有影响。这还是一种物理指标，就有这么多的不同。就不要说项目规模这种包括很多理念化的非客
观指标的参数了。
但是我们不能因为存在多种的参数，也存在测算的多种方法，以及多种不同的数据，就说没有必要测算了，也没有必要说这些东西就没有办法找到相对应的转换或
者对应关系了。而自然最佳的方法，是建立在物理指标的测算上，用牛顿跟千克进行物理换算，这是最容易，也最客观的方法。但是因为项目规模这块物理上的课
依赖数据很少，即使有说服力也很小，所以绝大多数情况下，不能使用这种方式。那么是不是就不能解决了呢？自然也不是。我们可以利用数据记录进行积累，应
用相互测试做对比，不断的进行分析和测试，逐步的形成一个比较稳定的转换公式。这个事情谁都可以做，也是谁都应该做的事情。因为规模测试，本身就是建立
在记录，积累，回溯，反馈，这样一个过程上的。而且这个方法可以说是目前唯一有效，也被证明有效，还被普遍认同的方法。即使忽然出来一个天才，一下子推
出一个什么系统，声称解决的规模参数的客观性问题，也需要用这个过程来进行印证以前的积累。这个事情其实非常非常简单，非常非常实际，也非常非常容易理
解。我不认为这些问题需要啥讨论，需要啥论证。我给大家讲这些，我自己都脸红。
素质啊素质，基础啊基础。如果scrum都是这些不知道做事情最基本方法的人在搞，你说这个方法能发展的好吗？能不困难吗？这样的胡搞应该停止了，这样
的讨论也应该停止了。因为不管出现什么样的天才，什么样的完美方法，什么样的最佳实践，都不能替代这些最最基础的准则和做事的方法。这里没有高深，也不
存在高手，唯一的就是把基础搞牢靠。我相信即使是天才的演奏家，也需要化大量时间在基本功上。
软件开发现在也需要基本功，并且我认为scrum目前最需求基本功。
停止胡搞，修炼基本功。
Xu Yi
喜欢这句话。突然想到，要不搞点T恤，印上agilechina的标志以及“停止胡搞，修炼基本功”，如何
Terry Yin
--
-------------------------
Blog: http://terry-yinzhe.spaces.live.com/
twitter: http://twitter.com/terryyin
Joseph Tseng
如果我的理解有误，请o6z指正。
ozzzz...@gmail.com
而其他的地方也要有基本功。比如做项目经理，你不去学点管理学的基础知识是不行的。而且进一步学习一些财会知识也是应该的。再进一步学点HR也是应该
的。但是我并不是说，要你报一个啥项目经理实物学习班，或者去考一个啥PMP证书。而是叫你找点最基本的，只讲大道理，不讲啥具体实践的书看看。我不是
说这些实践就不重要了，而是说你又不是做专职，你不需要搞那么实际操作。但是理念上你该有个轮廓吧，大概的思路是啥你该明白吧。别您非要搞啥代码行确定
生产率，bug数决定奖金数的瞎把戏出来。这块也是基础啊。
当然后面就是软件开发这块的基本功了，你大概每天写多少代码你该有数吧，手下一天大概一天写多少代码你也该有数吧。没数就去学学PSP，按照那个路数自
己下班走几遍，就有数了。这些事情你一生中只需要做几次，就有了感觉了，就不需要再做了。你要是在去做就真有问题了。但是除非你先天就有这种感觉，否则
你还是要做一做的好啊。
其次就是学会点在公司里面生存的技巧，当然这个是要论人的。比如我不管在啥地方都是强势出现，都是一个进攻性人格，都是一个鸟人。你叫我写文档，我
tmd就天天拿文档淹死你小丫的，看你还敢不敢拿文档来烦我。你丫叫我注意考勤，我tmd天天最最准时，你丫稍微晚到5秒，我都tmd要去问你一声，就
算你是领导，我都tmd在你进来的时候先看一下手表大声问你丫现在几点了。我就是这么一个人，就是这么一个生存方式。这个也是基本功。你要是做不到我这
个粉，那你就要学会自己的方式，该忍气吞声就忍气吞声，该嚣张跋扈就嚣张跋扈。
但是最基本最基本的一个问题就是你要实际一点，比如xuyi就跟我说他做scrummaster最大的动机就是收入会好一点。我觉得就很实际，因为其他
的任何理由在这个面前都苍白的不能再苍白。当然你收入提高的基础上，在干点具体的事情，提高一点自己的能力会更好，如果进一步再提高一点组织的能力就更
加趋近去完美。不过你别一个啥大道理给我摔过来，其实内心的想法却是从小算盘出发的。这个社会，对的事情未必就是必须要做的，好的事情也往往都是停留在
理论上的。我们探讨的时候，说说好跟不好，正确与错误，您别就以为这个东西你回去就要照做了。损害了你自己的利益，我说出大天你也回去别做。保持对自己
的诚实也是一种基本功，承认自己其实水准很差，你并不算什么。水准差的人多了，这个社会也不是看谁水平高谁就混的好。找到自己的生存之道才是重要的。生
活不是高考，你差一分就上不了大学。
说来说去，其实就是大家心理要有一个道理，如何做人做事的道理，几天的做法都可以探讨，都可以研究。但是这个大的方面不建立好了，不对自己有把握，那怎
么行呢？
说一个最基本的例子，这位张克强朋友说EPG相当于工艺科或者技术科，这个就是典型的想当然。工艺是要经过审批的，你去工厂看看是谁在跑质监局和药监
局，我告诉你是质检科，或者叫质检科出头组织。为啥，因为一个最浅显的道理在里面，你质检科在投产前需要去跑质量标准，而这些审查质量标准的人也是今后
审查工艺标准的人，你今天是这些人跑，明天是那些人跑，企业会这么搞吗？如果真的有人这么搞，那也是乱搞啊。这种事情你想都不应该去想，看起来各负其
责，是一个道理。但是后面还有一个更大的道理呢？说白了，就是你要把最大的道理搞明白才行。其他小道理，最终都会在大道理下面服软。
而做软件这个事情就有一个大道理，那就是基本功。其次下面还有一些稍微小点的道理，那就是做软件是精神活，应该保持思想集中，少打断。再小一号的道理就
是应该着重一点，你就别给手下步骤啥及要满足编程，又要考虑管理的事情，这样的事情是你这个做头目的人做的，不是他们老百姓做的。这样一个道理一个道理
的琢磨清楚，做事就自然靠谱。只会吭哧吭哧干活的人，在软件行业不会有啥发展。你去扛大个可能行，但是做软件还是别了。为啥现在agile的名声开始要
臭了，一个大原因就是只关心如何做的人太多了 ，没人关心为什么要这么做的人太少了。
当然这个事情在中国也有习惯了，比如你去看论语，那些人很少去问什么是仁 ，而都是去问如何才能仁。这样做在老祖宗那里是可以的，因为信息少啊，社会简
单啊，你不需要剔除啥干扰。但是今天信息爆多，社会复杂的跟万花筒套了一个干水缸一样，您还要上来就做，那就不行了。所以才需要从基本功入手，从基础道
理入手。老毛不总是说抓纲治国吗？虽然他那个刚选错了，但是抓刚这个说法是没错的啊。你别一口一个实际，一口一个这样太空泛，因为你那个才是最不实际
的，最空泛的。
当然我说这么多，未必大家都能一下子做到。那么就从最基本的开始，从记录，积累，回溯，反馈开始吧。我相信你要是这么做下去，你也会得到跟我相似的认
识。为啥，因为我也不是天才，我也是前辈这么教导着连滚带爬的过来的。只不过有些人容易开窍，能从前人和其他人的实践中学到东西，有些人只能靠自己一条
条感悟。水平差距就是出自这个地方，效率高的就多从别人那里吸取点，自然就快点。当然高的会吸取理念，低的会吸取做法。再高一点就是别人还没有理念，您
就从他们的实践里面吸取了理念了。但是最傻最傻的做法就是只去关心别人是如何做的，然后就跟着做的，这个有个词做专门的形容----东施效颦。
说了这么多废话，不求大家明白，因为我自己也可能就不明白。反正人生自由选择，傻瓜也有傻瓜活着的方法。我这个人比较弱智，只能从别人那里听道理，不喜
欢省事的跟着跑。
On Mar 7, 1:05 am, Joseph Tseng <airl...@gmail.com> wrote:
> 自己总结一下，ozzzzzz的话的核心意思就是：记录，积累，回溯，反馈是基本功，通过相对比较来得到结论（因为各种组织有各自特点，没有绝对客观的天才的标准）。缺少这些扎实沉稳的工作，任何所谓最佳实践都缺乏现实基础。在我看来，o6z的话其实就是温伯格反复强调的系统论的基本观点的表述。
>
> 如果我的理解有误，请o6z指正。
>
> 2009/3/6 Terry Yin <terry.yin...@gmail.com>
>
> > "素质啊素质，基础啊基础。如果scrum都是这些不知道做事情最基本方法的人在搞...."
> > 2001年的搞笑诺贝尔奖心理学奖颁给了来自Cornell University的Justin Kruger和David
> > Dunning，因为他们的一篇报告，报告所写的内容被称为"达克效应"（Dunning-Kruger
> > effect）。文中说到："无知要比知识更容易产生自信"(这话应该是达尔文说的)。
> > 专门与过一篇博客:
> >http://terry-yinzhe.spaces.live.com/blog/cns!92560BAA05230C71!297.entry<http://terry-yinzhe.spaces.live.com/blog/cns%2192560BAA05230C71%21297...>
>
> > 2009/3/5 ozzz...@163.com <ozzzzzz....@gmail.com>
张克强
关于EPG的比喻，如果真有兴趣，google一下，先拷一段过来“CMMI设计的软件企业的最主要的三个角色，EPG、QA和PM，让我们不难想起西
方社会的三权分立原则，其中EPG对应的是立法机构（议会），QA对应的是监督（司法／审计），PM则对应了执行管理（行政部门）。” 比喻到工厂，工
艺科或者技术科研究制定生产工艺，观察生产线，进行一些调整，比较象EPG；“跑质监局和药监局”的质检科则保证符合多个层面的标准，比较象
QA。
我对工厂不是特别熟，如果现在的工厂还是以上的分工，那我是“想当然”地比喻对了；如果现在有些工厂的质检科在大搞新工艺，新流程，那我是“想当然”地
比喻错了；
读了o6z关于自己人格特征的那段，明白他为何如此发贴了，确实与我的思路完全对不上。
这已经是离题万里了。
下面大家是否能够扣题来发贴
“我们可以利用数据记录进行积累，应用相互测试做对比，不断的进行分析和测试，逐步的形成一个比较稳定的转换公式。这个事情谁都可以做，也是谁都应该做
的事情。因为规模测试，本身就是建立在记录，积累，回溯，反馈，这样一个过程上的。而且这个方法可以说是目前唯一有效，也被证明有效，还被普遍认同的方
法。”
上述这段话在scrum中有哪些实践呢？
（实践并不是标准，而是存在或存在过的实际做法，不是说应该如何做。这是一个名为“敏捷中国”的论坛，相信大家都有“勇气”讲自己的实践和看法，我就有
勇气在极有可能被评为“大方面把握不好”“胡搞”的情况下首先谈谈，这些实践相信对80%的朋友有借鉴意义，比起理论上的大道理更有指导作用，希望给出
破坏性评定时，同时给出建设性意见建议）
1, PM记录sprint的估算用例点数和实际用例点数，开始日期，计划结束日期，实际结束日期，估算工作量和实际工作量，实际测试缺险数量
2, PM积累多个sprint的数据，计算得到生产率（实际用例点数/实际工作量) ，工期偏差（虽然按时间箱来处理，在实践中并不能100%符合，
所以计算了这个），缺陷密度。
3,团队回溯识别影响生产率的其它因子，有技术复杂因子，环境复杂因子，对用例点定义有所调整，总体方法上还是用例点方法，scrummaster参与
这个过程。
4,在下面的sprint规划中，使用以上结果，来指导sprint的规模和时间安排和人员安排
5,scrummaster收集以上数据，在多个项目组间提供借鉴和参照。
6，反复以上，持续更新
ozzzz...@gmail.com
的说是CMM制定者的错误。你只不过是一个被传染的病人罢了。
当然这里还有一个工艺的理解问题，我试着给大家进行解释一下，当然里面的问题并不仅仅是报批那么一点。什么是工艺呢？这个问题我觉得可以大家听我讲完自
己去理解。我们先从一个新产品的开发开始说。
一个全新的产品，而不是改进的产品，首先是要有一个全新的生产方法，这个方法主要是一种理念上的构思，是一种生产上的设想。然后为了要进行实际的生产，
要在不同的环境下进行小试，中试，生产环境下的实验，从小摸索出一套合乎要求的生产过程。但是这个过程还不是工艺，工艺还需要满足法律规定，企业制度，
财务原则，更重要的是还应该满足生产的可预测和可评估，以及可控制性，应该满足质量监督，和质量操作的属性。我们说工厂化的生产，跟原始作坊式的制作，
其根本区别，并不是在于生产的样式和方式，而在于工厂化生产是质量控制驱动的，而原始作坊式则是纯粹生产驱动的。原始作坊式的生产，并不保证产品合乎最
初的构想细节，而仅仅保证其大概的合乎要求。而工艺则需要将开始基于纯生产的导向的过程，与质量控制方法和手段，结合在一起。基本上前一个阶段，如果按
照常用的企业部门配置来说，是新产品开发部门，或者技术开发部的工作。而后一个部门则是质量部门。当然生产部门可能更早的进入这个环节，但是就概念上来
说他们是需要从质量部门得到一个生产流程之后，按照生产的规律制定工艺流程实施方案和计划。这些内容包括，投料配比的生产安排，电气的供应安排，人员的
安排，等等资源组织工作，和环境组织工作。
人们的普遍误解大多数就是来自对于生产科任务的认识，而实际上生产科最大任务就是确定一个生产什么时候开始，什么时候结束。而工艺则是对于生产环节的组
织和操作细节的要求。就工艺来说，很少会设计到投料多少，批量应该多少的具体数据。即使有，也仅仅是批量最小投料多少，最多投料多少，这样一个范围。而
生产工艺操作细节，或者叫工艺流程实施办法，则会考虑批次量等数据的经济数据等其他方面。就工艺来说，会有超脱与具体生产环境的一面，而工艺实施办法则
必须是紧密结合与具体的环境的。比如工艺就不会考虑，你这个锅是5吨的，还是8吨的，而工艺实施方法则需要考虑。同时工艺还往往是比较稳定而文字化的，
工艺实施方法则更加灵活和很多都仅仅是一种经验或者其他非文字的东西（当然也有工艺实施方法的文字的部分，但是未必是全部。比如麦当劳虽然说是流程标准
化，但是实际上我们都明白不可能用一个标准完全覆盖所以环境和环节，还是有一些临时根据具体情况自己把握的部分，这个地方就是生产工艺实施方法的部
分）。
这样大家就明白，生产科考虑的是经济性和生产的安全性以及整体的生产环境。比如他们可能为了一个整体的目标，会对个别批次的生产控制不追求最优化，会在
质量可以保证的情况下不追求质量最优化，会在生产按照工艺指导的情况下并不完全按照工艺上的顺序执行（例如他们可能会一次在前面一个环节多投料，并保存
中间体等等这般。当然这个容易理解，一个1吨的锅，是无法煮10斤稀饭的。）而质量控制那边则是有两个部分，一个方面是看生产是不是完全按照工艺要求的
控制指标和操作要求执行，一个是看其中间产品和最终产品是不是符合质量指标。所以你到很多单位去看，有的车间有自己的化验室，而质检则也有化验室，而搞
不好生产部还有自己的化验室。
而我们平时说的工艺改造，主要是指生产工艺，也就是质量部门搞的那个的改造。而工艺优化，则更多的是指生产部门在实施中的优化。
那么我们现在就要拿这些东西映射到软件开发领域，看看是怎么一个情况。大家参考上面几个帖子，我说的吧，看看是不是那么一回事。自然大家如果长期关注过
我对于cmm的讨论，就会明白我这里说的其实就是针对cmm质量控制的瞎搞，原理的错误，其理由之一就是这里。还可以明白，同时这里还涉及到一个隐含的
论题，其实cmm本身就是在搞一个原始生产做法。当然如果大家看过最近忽然流行的一本就《走出软件作坊》的书，也就会明白胡搞瞎搞的人到处都有，并且还
滋味很叫他们感觉受用。
我说了这么多cmm的坏话，别以为cmm就一无是处了。其实cmm的分析问题和组织问题的思想以及思路是非常好的，也是我最近在努力学习和吸收的最重要
内容。当然我这个是从一个高的层面和抽象的角度说的，并且我的这个说法有很多人是支持的，例如八叉之流。我们只不过是对cmm中实践层面的狠批，但是对
概念层面的还是很欣赏的。大家不要在这个地方有理解偏差。
我对cmm的观点，大概可以表达为，这个是一个好模式，好框架，好模型，但是做法太不学术化，实践又太学术化，再加上歪嘴和尚。
回到scrum的问题。由于scrum的不完整性，需要将其跟具体的实际操作流程结合。EPG会负责结合以及后续的改良工作。而QA则会负责这个流程的
具体化制定，以及后续的监控项目组的实施是否按照这个流程进行。具体的项目管理部门，和开发组织管理层，则负责具体的实施，并且将过程实体化。大的层面
来说，EPG是负责设计概念流程的；而QA则是将流程跟具体的生产实际挂钩的；生产部门则是将流失继续实施来跟具体项目结合在一起的。如果这个时候
EPG直接负责到具体的流程实施，那么他的设计就很难保证中立和非项目化，也就是容易出现为了项目而流程，或者出现为了流程而损害项目的利益。当然上面
也说过，这里还牵涉到绩效考察的一个问题，也就是生产者不能自己检测自己的生产成果，而应该由第三方检测。这个好理解。当然这里大家不要忘记，流程不是
一个产品，或者不是一个商品，大家搞这个不是为了制造一个流程，而是为了制造真正的产品。只不过为了制造产品，需要一个流程把资源和环境以及人员结合起
来。而EPG是为了把整个企业的流程做对象，QA则是把流程具体化到各个环节和项目，开发者则是为了具体的项目把流程来实施。所以这里还有一个EPG如
果具体到一个项目，会不会带来此项目同其他项目的流程冲突的问题。这个好理解，正规化的军队，正常情况下不会叫一个参谋长去兼下面一个团的团长、政委、
作战处长。
当然这里有另外一个问题，也就是有些组织的EPG不是专职的，也不是一个专门的岗位，更没有专门的部门。这个时候，有SCRUMmaster去兼任
EPG是可以的。但是大家注意这里的区别。同时这里由引申出另外一个管理上的问题，比如某个岗位的工作实在复杂，不能一个人完成。这个时候可以授权给其
他人做研究和某些操作层面的事务，但是负责和决策是绝对不能授权给其他人的。也就是说在scrummaster在兼任EPG的时候，他仅仅是具体的操作
事务和组织，而其实实际的责任和任务还是由一个另外的专门的人负责的。这个时候他的EPG其实仅仅是一个名称，而不是真正的岗位。这也就是一个角色与岗
位，以及岗位跟职位，它们之间在组织管理内部的一些情况。请大家仔细体会其中的内容。
实际上我们讨论问题的时候，由于不可能涉及太具体（除非我跟你在一个单位工作），所以名称等等都是概念化理想化的。你别到时候给我来一个，我们这里的
scrummaster其实就是pm换了一个名字之类的说辞来。严格的逻辑上说，白马都不是马，你只能说白马是一种马，你说是不是。
当然我们必须承认，胡搞也是搞，也可能很成功。但是我们不是去买彩票。我们要么是做学问，要么是搞工程，里面必须有一个道理，有一个内在的指导性的东西
的。我们不是马戏团，也不是教徒弟学相声的，来一个我这么做你就跟着做，做到家你就会明白。当然有些东西是只能做过才能明白，而且只能大量做过才可能明
白，或者只能认真的大量做过才有小部分可能明白。不过这样的事情，就还谈不上工程，也谈不上是学术。你去搞事情，也不应该走这个路子，也不应该去拜这样
一个师傅。这也是私塾跟现代学校教育和学习的区别。当然私塾更加中国，这点我承认。不过我是最坚决反对，读书破万卷下笔如有神，熟读唐诗三百首不会作诗
也会吟。这样的人去做文艺比较好，做技术和工程或者学术不合适。
当然，另外一个实际的情况是，有些有效的做法，我们确实还不能发现其背后的道理。不过这样的事情会越来越少，而且也不应该是我们的主要关注点。因为我们
的一个目标，就是叫这样的东西越来越少。
ozzzz...@gmail.com
实还是一样的。在这之前，我希望大家有机会去看看psp，那个里面开始就是说这块的东西。那个可以用来指导大家做个人的训练和积累，当然不需要没事就搞
一把，搞一辈子的做法。认真的搞几次，就足够了。如果有必要，在遇到新问题的时候，也可以再搞两下。做多了很繁琐，很累人，而且也不会有什么效果。关键
就是建立其一个感觉。
注意我这里用的词是感觉，实际上任何人类的评估和度量都是从感觉开始的，这点不需要讨论。而人们会验证他们的感觉，并且形成一种感觉系统。比如好疼，但
是比刚才好些了。也就是有了最初的感觉之后，要有比较。而之所以有比较，其实就是有记录——你之所以觉得比刚才好些了，是你记得当初的痛感，也记得现在
的痛感，而你的感觉这个时候就相当于做了一个计算，得出当时的痛比小的痛要小。这样搞过一次，你后面就不疼了。但是过了些日子，你又疼了，你再感觉，比
上次最开始疼的时候轻，但是比后面要好的时候重。这是因为你已经积累并且抽象出上次疼的一个过程，并且把这个过程进行跟现在疼的对比。这之中你可能会反
思，并且从别的方面得到信息。比如说你听说，人会对痛有耐受力，你就开始琢磨了，是不是你耐受了，实际上疼其实是跟上次开始的时候一样的，或者更强呢？
于是你就不仅开始进行根据疼的唯一主观感受做参照体系，而试图获得其他信息来源，并且不断的做判断，不断的根据判断再修正原来的判断。这个过程是一种自
然的过程，是人类自发的行为，也是一种习惯性的行为，自然也是长期进化获得的一种财富。
回到规模这块，也是一个路子。当大家都是开始的时候，先对项目做一个评估，得到一个感觉。然后再隔一段时间再评估一次，又一个感觉。你会这样不断的感觉
下去，并且在相关性由大到小的场景下，不断的建立一个感觉。并且由于是组织，大家还会交流这个感觉，从而形成一个逐渐学习的过程。
好了，事情到此似乎就结束了。但是慢着，是不是有了感觉，并且大家通过学习积累就完事了呢？当然不是，这个时候你还是仅仅建立的是感觉，不是数据，不是
可以传递的直接内容。这个时候你得到的东西是经验，而我们如果满足于此，就仅仅是一种经验。而我们要的是知识，是可以表达，可以传输，可以给其他人直接
学习从而获得的间接经验。于是我们需要对感觉做量化。
量化很容易叫人跟数字挂钩，但是我要说，最初的量化并不是数字的，而是对比与判断的。比如你说这堆土比那堆大，并且告诉其他人，其他人看一下也认同。然
后组织内部，达成一种关于土堆大小的共同认识，这就是最基本的量化。很多时候，人们量化的指标体系就建立在这个层面就够了。并且由于有现实的实例，也有
共同的经历，还有共同的语言，这个大小的例子就会不断传递下去，即便后面的人没见过当初的那两堆，也知道了大小的量化。当然这个时候，其实跟上面一个纯
感觉，纯自我经验的时期是很类似的，搞不好就是直接混在一起的。不过这个是基础，是后面发生的一切的基础。
再后面，你对大小的说法已经不满足了，希望更加进一步能够所谓数字化的表现。这个时候你就会建立一个共同的基础度量标准，比如认定这堆土就是一个基础单
位。另外一堆是5单位。然后你就推广这个说法，于是大家就都知道有一个单位，并最终经过几次传递之后，已经不在有人提当初的那两堆土的事情了。
事情似乎圆满了。但是慢来，我们上面说的是图，不是软件。而且即便仅仅就是说土，那么后面学习到单位的人，没有最初的感觉，也不知道大小，怎么办。
所以啊，要想进入数字化社会，还是需要点基础的，还是要先有点感觉才行，有点非数字化的东西才行。不过话说回来，数值化之后，应该可以更加容易的去经过
建立感觉的阶段。这就是说好的数字指标系统，应该容易被人的直觉所证明和认知。
道理大概说完了，不知道我说明白没有，不明白就说出来。不搞懂这块，后面的事情就不好办。而土堆好说，痛感咋办。这个咋建立数字指标体系呢，我卖个乖，
大家自己去找本软件度量或者认知学的东西去看吧。其实路子还是差不多。
只不过有了痛感，痛忍受力，痛感觉能力，痛感知能力，之类的一系列指标，用来说明这个事情。比如用一个标准针刺力量大小，刺激多少时间，刺激什么部位，
等等要求的刺激进行的量化指标罢了。要是你愿意，你也可以自己根据情况建立自己的私人痛感指标。
回到软件上来。首先我们会遇到一个难题，软件规模究竟是什么。同我们上面讨论的道理不同的时候，即便是痛感，也仅仅是一个物理指标，而规模则是一个涉及
到多种物理指标的系统。并且说这个词的人，往往也会随着背景和场景的不同，表达的是不同的意思。比如有的人说的是，时间概念，有的人说的是代码大小，而
有的说的是代码行（代码行跟代码的行数不是一个东西啊，别搞混了），当然其他还有些指标和意思。而这些数据之间似乎还有某些联系，比如说时间可以看作整
个代码的大小同单位时间代码大小的比值。不过再一想想也不对，因为你的单位代码大小，跟其他人的代码大小差别太大，虽然我们可以动用统计学，但是落实到
一个具体的项目，统计学就失效了（学统计学好的同学，可以出来证明一下我这个论断。没学好的，是学医的就打屁股。学机械的就敲脑袋。学数学的干脆就去死
了算了。你是学CS的，不懂可以原谅，统计学我记得不是你们的必修课。）而另外一个问题是统计学需要大量的数据做基础，我们不能等到他们把数据积累完了
再干活是不是，而且不干活谁能有数据。这个时候我们就可以规定，软件规模就是指一个意思，哪怕这个意思再sb，再不着边际，再令人呕吐，只要设定了，就
好过没有设定。也就是说，大家统一到一个规定，一个轨道，一个方言下来，吵架都会有效率，不会你说东他说西，鸡同鸭讲了。
有了前面的统一，那么你就开始建立共同感觉吧，这个好办，大家都在开始的时候把感觉记录下来，然后不断的在一定时间后再感觉一次再记录。这就是积累。然
后再在一定时间后，把其他项目的东西来组对比，把以前做的感觉再感觉一次，这就是做回溯。自然在收集信息，自己的，他人的，新的理论，新的认识，凡是相
关的，分析总结之后 ，对已经有的积累和结论做修正，这就是反馈。这些也好办。
难就难在设定一个单位，也就是开始引入一个数据计量系统。这里我要声明一点，我不认为已经有了比较好的软件规模统计数据系统，至少现有的几种系统都有明
显的缺陷，而且也都不直观和直觉友善。因此，感觉这个东西至少就目前还不能丢，还需要经验。但是有一个单位还是有好处，至少可以把经验有的放矢的发挥在
一个方向上。大家可以围绕一个系统进行感觉判断。怕就怕，你没感觉，而纯粹希望引进一个指标系统来建立感觉。这样你离死就不远了。
而进一步说，如果你有两个组织，貌似在使用一套指标系统，但是差别十分巨大，你想统一下来，这个事情也好理解。不过你回忆上面我的道理，就能明白，其实
看起来统一的系统，并不统一。虽然都是一个指标系统，但是他们的内在概念，和实施方法还是有不同的，判断的人也不太，过程也可能不太一样。所以虽然看似
一个标准，但是得到的数据差别却很巨大。这个时候，你首先想到的不应该是谁能干，谁不能干，而是要首先看看他们干的到底是不是一个东西，是不是按照一个
方法干的。比如你用那个所谓的用例点（好几年了，都忘记了还有这么一个鸟。），这里面道其实还是很多的。比如你们是否强制化的检验前置后置，场景粒度标
准是不是统一，用例的引用和被引用如何处理，包是如何规定的，等等很多方面都会造成对同一个东西由于测算方法的差异，而得到的数据也很有差异。因此统一
是势在必行的。
而这之后，还有另外一个方法。那就是叫一个组织对另外一个组织的工作进行评估和规模估算，并且同原组织的进行对比。当然问题在于你要是公开说，这么做是
用来做绩效考核的，那么数据会受到影响。所以尽量还是应该以保证质量和安全，促进组织协作为理由和目标进行此工作。这样即使最终不能得到统一，至少互审
一次还是有好处的，而且大家也得到的交流和互相学习的机会。
也就是说你可以开始着手做两个事情，一个是组织间互审，一个是统一。并且统一也是为了互审的方便，而互审也是可以达成统一。但是这个事情，恐怕就不是项
目经理能组织的。
但是这里有一个地方我不是很清楚，那就是你们的迭代是如何进行的。比如用例是不是由各自项目组自己协作完成，还是有其他部门的人写作，或者其实项目组同
其他部门协作完成。这里也有很大区别。需要做不同处理。不过我觉得这里也不是项目经理或者scrummaster这个层面可以解决的。
而进一步，因为你们使用scrum系统，那么一定也有blacklog，而那上面究竟是什么也是问题。比如是用例，用例判断，用例片段，还是
story，还是任务，还是风险点，还是其他什么东西。这里也是会对用例点系统的后续成果有重大影响的。我不清楚，所以不好做判断。但是这里有一条，这
样的问题，也不底层人士可以解决的事情。
不过我总是要强调的一点是，这里跟scrummaster其实关联性不大。当然可能跟挂scrummaster名头的那个人关系大，但是仅仅如此。
而另外一个层面上来说，问题如果这个指标是为了判断大家的绩效，那么就应该有HR牵头去委托技术研究部门搞，你们可以提建议，并且表达同意或者反对的意
见。自己搞，就是等于你们的部门老板，要财人物都一手抓。这样的人中国很多，外国也很多，还是不招惹他们为妙。当然这个是中国特色，初级阶段，满脸是狗
屎跑街上也兴许被认为是时尚。这样的事情，我就不好发表啥见解了。喷几下再回到原来的问题。
实际上项目规模判断这里还些事情要说一下。就一个人来说，他的经验，会决定其对规模的判断的准确性。并且目前来看，越是经验丰富，其判断越是准确。而越
是项目规模大，其判断的准确性越高，同最终的结果也越是接近。但是一般情况下，这样的人不多。而我们这里没有这么的老混混，只能是把大的笼统的项目，细
化之后一个一个部分的估算，然后统一在一起。然后加上修正值，和权重等，计算一下，出一个结果。不过如果在有老混混的情况下，你会发现他在细节层面的估
算可能会偏差很大，但是最终结果却是很好的。而你那些还没到混混地步的人，往往细节方面的估算很好，但是把它们叠加起来，反到是不能被接受。这说明项目
规模，绝对不是简单的各个部分相加的结果。而且我们如果做过记录和积累，你会发现类型或者内容相似的项目，细节和整体的规模数据似乎有函数关联。并且你
进一步去研究，会发现，随着这个过程的前进，最终细节同最终整体的简单算术关联性会越强，也就是你会感觉你最终可以把各个部分简单相加就等于整体了。这
个情况我认为有一个重要原因，是你将整体细分的合理性提高了，而不是你估算的水平提高了，或者说是喜欢合理性提高贡献的更多，估算能力提高贡献的较少。
而这里还有另外一个情况，你也会发现。并不是细节越细，或者叫粒度越小，对你的估算就越有帮助。而且人的估算能力会不断提高，也就是估算的粒度会有变大
的趋势。当这个粒度跟项目整体规模的比例到达一个合理的水平，就会产生上面说的整体等于部分之和的情况。而随着你不断的进行这样的工作，也可以保证那些
人最终不会走向混混，而长时间保持一个清晰的推理思路。
当然还有另外一个方面的问题。那就是项目规模，到底用一个什么单位表达的问题。我发现现在有两种设立单位的方式，一种是代码行，用例点，功能点。另外一
种是故事点，feature，标准工作时间，之类。前面一种更加物理化，但是跟广大的程序员的基本直觉相背离。后面一种主观性较大，但是程序员更容易用
直觉感知和认同。当然前一种，组织间可以对比性比较好，而后一种组织内统一新和有效性比较好。而你设立自己的标准系统的时候，不得不在组织间和组织内部
想考量。我建议，还是首先增强组织内，再在已经基本满足的情况下考虑组织间，并且时刻考察组织内，以避免因为提高组织间，将组织内降低到不可接受的水
平。当然推而广之，人和人之间也存在这个问题。
另外，规模估算还跟项目进度要求有很大的关联性。也就是一个长期项目的估算更加容易偏差大，一个短期项目偏差小。但是往往又是短期项目即使偏差小，但是
直接后果明显，而且没有退路。这里要区分，是责任感造成的偏差，和评估能力造成的偏差。这个地方在今后对其他数据做修正和分析的时候，千万要注意。很多
非规模的数据往往就出在这里。
最后我还要说点不好听的话。我最近特别不喜欢，拿个scrum或者agile鸡毛当令箭。到处说，作为一个scrummaster，或者一个Agile
方法，这里应该如何做。我喜欢讨论这个事情应该怎么做。当然作为scrummaster或者一个敏捷者会有自己充满个性的做法。但是这个是要建立在能做
这个事情的基础上的。在学会做这个事情之前，先别着急给自己贴上标签。说实在的敏捷是做出来的，不是自己说出来的。你做多了，自然就能知道敏捷这一套是
不是适合你的。其实不敏捷又咋样，把活干的漂亮点就行了。你再能，还能到自己搞个啥自创的敏捷，并声称别人没敏捷之前你就敏捷了，并且你的敏捷历史都是
几千年的积累了。这种事情搞咨询的人吹吹牛是可以的，你一个做实际开发的，说这些没啥益处。他们给你一个scrummaster未必就是叫你真去做
scrummaster事情，咱们讨论可以高来高走，就理论而理想。但是您别到实际中也就真以为你们scrum'了。而且他爱scrum还是cmm跟你
也没啥关系，主要还是干活要漂亮。自然讨论只能是高来高走，不然就会真具体问题具体分析，完全得不可知了。