本篇是我给《程序员》写的敏捷实践分享的稿子，刊登在2009年12月号上面，经过编辑同意，转载在这里，和大家讨论。
前言
每个敏捷的圣贤都说：敏捷只是宣言，Scrum只是框架，换个意思就是他不会告诉你应该做什么--真是惨，我们到底应该做什么？
不过你可以看看别人做什么，并且分享一下自己做什么，于是我们来分享了。（注1）
此文适合：
1. 博览群书的你了解了敏捷，Scrum,Product Owner,Scrum Master，用户故事,BACK LOG,Sprint会议,每日站会, 回顾会议,Sprint DEMO（演示）等等概念。
2. 风风火火的你在公司里面上下腾挪最终推行了Scrum实践。
3. 热情似火的你对于团队成员迟迟不能领会Scrum要义，或者他们根本就不买这一套的帐感到着急。
4. 两头为难的你和你的BOSS都不能清楚的看到Scrum实施后的具体效果。
5. 愈挫愈勇的你对于Scrum能够帮助团队成功还有强大的信念。
再次套用圣贤们的话，我写此文不是想说你应该这么做，而是说在我们的情况下，我们这么做有效了，你要认为我们根本是错误的也可以。
我们的具体情况是什么，你可能需要关心：公司30来号人，4个团队，还没有完善的绩效考核系统，做的是面向一个很小的细分领域的ERP管理产品，才开始实施Scrum半年，作者我现在负责公司流程优化，信息化，暂时领导了一支5人团队，使用Rails开发公司内部使用的ERP项目，并负责IT支撑工作。公司几个管理层大都技术出身，读《程序员》《IT经理世界》，看《走出软件作坊》，热衷参加Qcon，艾瑞营销年会等活动学习。
回到正题，我们的敏捷实践是：团队迭代展示会议评审,我们叫它做 PAS（Party Achievement Show），它最直接的效果让团队成员的平均投入度从实施前的50%以下上升到70%以上，团队成员的紧迫感和成就感也都有极大上升，其核心是通过评分的手段在展示会议（DEMO）上来强调Scrum的一切有价值的实践。
如果你光凭名字就判定它不过是一个项目里程碑审核的变形，我会觉得不太贴切，我建议的理解方式是：这是一个每迭代运行迷你版本的Scrum成熟度评估机制，选择以PAS作为名称缩略语是为了描述方便不用每次都说迭代演示会议评审机制这么长的拗口术语之外还有深意，容后再表。
是作秀么缘起demo—我们为什么实施PAS
Henrik Kniberg 在他的大作《硝烟中的scrum和XP》（如果大家都看过infoq出品的这本迷你电子书，对你理解本文有巨大帮助 注1）说过：Spint演示会议是Scrum很重要的一环，但是他却经常被低估，他说对了，他就是容易被低估，至少在我们这里发生了。
公司4个团队，每个团队6-9人，经过了2-3个迭代过后，我们发现了我们几个团队迭代演示（DEMO）的如下一些共同问题。
l PROLEM1：谁来观看？是在浪费观看者的时间么？
对于应该有谁来查看团队迭代的演示大家莫衷一是，是由团队来选择邀请，还是领导指定，抑或是随便抓两个路人？
在实施Srcum方法之后的前两个迭代，由于原来没有这么样的机制，公司所有成员对于团对外的工作还比较有兴趣，但凡任意团队的演示，其他团队的成员都趋之若鹜，群情激动，参加2次之后，新鲜感就消除，加之本来自身的工作还要做，还有3周左右迭代不一定总会让产品带来让人讶异的变化，所以到后来，演示机制被邀请来的观众当成了一种负担，要么借口推辞，要么到了会上玩手机，睡觉甚至中途离场....
l PROLEM2：我们到底干得是好还是坏？
由于团队PO（Product Owner）就是原来的项目经理，他被算作团队内成员，公司里面最了解这个项目的人在组织演示，评价权就落在了CEO或者CTO身上，但迭代作为一个过短的工作周期，很多工作成果不能在财务上或者客户价值上凸显。而其他人呢，要么不了解具体情况没有概念，要么怯于身份不知道当说不当说，一般来说，除非展示很具有娱乐效果，与会者基本上看过就看过了，赞美，意见或者是建议都没有暴露出来，但是娱乐效果是我们需要的么？
l PROLEM3：应该是做秀么？
为了赢得观众的注意，凸显团队的价值，甚至创造娱乐效果，有一些团队把不是迭代的成果也拿来说，又花费过多时间对演示的用的ppt做足粉饰工作，只为赢得一片掌声或者惊异，没有思考过到底团队为公司带来什么价值，浪费了团队精力也没有给公司带来好处。
PAS出场了---PAS是什么
出于尝试解决PROBLEMS的初衷，我们在决定正式的标准化的评价团队，经过多方的讨论和努力，CEO颁布了一套PAS机制,其核心就是设立一个客户代表组成的评审小型团队，担任迭代的展示评委，他们可以是真正的客户（建议选取那些care你们努力的用户，如果纯粹过来当甲方，你们的会议也不好开了），也可以是其他团队成员，PO，或者具有一定相关知识的人，他们模拟客户身份，对于迭代中的每个故事给出他的等级评价，最后由总评委（CEO或者CTO，反正应该是一个够分量的人）给出一个综合总评等级结果，并根据这个总评结果给予奖励或者惩罚。本文后面部分，客户和评委相互指代。
具体的实现细节是：
1. 评委选定：
首先选出迭代总评委，由他和PO沟通后，甄选对于团队本此迭代的故事涉众，或者对成果有背景知识的评委团成员，保证他们能够给出有价值的意见。
2. 评分等级：
每个故事可以评分为，一塌糊涂 差强人意 功成名就 排山倒海 惊天动地 （5分制的成语版）
3. 评分过程以及标准：
1. 提交文档：要求在迭代初(一般是SPRINT 会议之后)，团队必须要向总评委提交故事一览文档，每个故事必须包含
- 名称
- 对于客户的价值描述
- 如何演示（how to demo）
- 估点
如果上述条目没有，该故事就直接一塌糊涂了，这是唯一一条客观的最高原则。
2. 在演示会议上，故事的演示结果基本符合预先设定的how to demo，那么该故事就是 功成名就了，当然如果演示期间出现bug，或者评委主观认为其不太符合，给出差强人意甚至一塌糊涂也在他权力范围之内。
3. 在功成名就的基础上，如果评委看到亮点，可以是技术的革新，界面上的亮点，生产力的提升，质量的提升，客户的满意，这些根据评委的背景会不一而足。评委们仁者见仁，智者见智，如果有1个到多个亮点，给出排山倒海或者惊天动地都是他们的权力，我们知道并且强调他是一个主观的原则，和评委背景密切相关。
4. 每个评委都必须把他看到的亮点，不足点，以及建议分别用不同的色卡记录下来，我们称之为，红花绿叶卡，一般来说，红色代表赞扬亮点请保持，蓝色卡代表建议或者点子请参考，黄色卡代表不足请改进。
4. 沟通交流：
每个故事之间设立一定时间沟通和提问，之后依据以上原则等级，评委在团队成员所有故事，展示完毕过后，由每个评委对团队，进行红花绿叶卡的描述，团队会直接直面客户的声音，享受赞誉也好，接受意见批评也好，客户可以Say It，而且可以 Say it loudly.
5. 综合总评：
最后团队成员退场，留下团队Scrum Master和PO申述，总评委主持综合评定，除了根据每个评委的意见，综合给每个故事定下最终等级之外，还要给出一个团队等级，现行的原则是所有的故事得分平均的取整加一，意思就是3.1分算4分.后期可能我们还会考虑加入评委重要程度加权平均以及四舍五入等改进措施。
6. 事后奖惩：
1. 总评功成名就的团队
可以享受每月的团队修整日，意味着在某一工作日团队可以申请以每人rmb100以上的预算，集体外出进行喝茶，聚餐，运动甚至K歌等集体活动。
2. 总评差强人意的团队
在余下一个月里面会“享受”到，上班时间提前半个小时的强制令（基于我们迟到买饮料给正常出勤同事的惩罚，不迟到的团队成员会乐意监督执行）等惩罚待遇.
3. 总评一塌糊涂惩罚的团队
会受到一个叫做 “Boss之怒”的惩罚，内容嘛是到时候随便Boss来定的，但它设立的主要目的不是发出，而是强调惩罚的存在，实际上我们很清楚他永远不会被发出来，为什么后面我们会讲。
4. 总评功成名就以上的团队
会额外享受平均100+元额外腐败金，或者更好椅子使用权，迟到豁免权之类的小荣誉奖励,当然团队也可以自己申请其他特殊奖励。但原则是尽量不使用现金，而且尽量到团队名下。力度么，根据分数的高低比较主观的变化，但原则是强调荣誉，不强调实质奖励。
那么，有效么？--在PAS 实施4个月后
仿效一些杂志把这一节叫做 “数字”，当然我们是一个很小的公司，目前这个阶段下，管理工具和基础设施的限制导致度量这些改变是不那么客观的，但是主观上的士气，和更高效的生产力是每个团队以及我们整个公司能够感受到的，以下数字只是一个参考
1. 15000rmb---因为所有4个团队的不到20次迭代里面，只有一个团队某次迭代是功成名就，其他都是排山倒海，公司一共多付出了不到15000元的奖励资金。
2. 70%----从人事总监的持续观察记录来看，公司的收获是，团队的投入度（度量在一个同事在工作的时间和工作总时间）平均值从原来的50%上升到了70%（注3）
3. 30%---项目完成速度比原来提速30%，这个是纯目测的，我们并没有严格度测产品完成度和速度的工具或者方法。
无心插柳--PAS实施的额外收获
有些东西是我们在设计PAS机制没有想要获取的，但是他们却自然而来到了，或者说应该是Scrum的功效只是被PAS机制在我们这里强化了。他们是：
1. PO的隐形权力：
我们公司还小，并且崇尚公平的管理环境，所以不管是原来的项目经理还是任何人，都是没有直接影响别人奖金多寡的权力的，没有把任命或者除名团队成员的权力下放，这样的好处是强迫你得说服每个人执行你的计划，坏处显而易见----不是每个人都可以被说服，但自从PAS机制实施以来，出色PO的需求分析和优先级排定赢得客户的赞誉，自然在以后的讨论过程中,他就获得了一种无形的授权
“OK，小王，我觉得你如果没有充分的理由反对我们讨论出来的方案，请先按照我写的来做，不然的话PAS上面，这个重要故事我觉得很有可能“差强人意”，我们团队会遭殃”
这样的社会压力，让PO有了话语权，当然，这种权力也是双向的，也没有哪个PO能够真正一意孤行作违反客户利益的事情。还有一个重要的变化就是，PO真正被团队认可成为团队的一员，而不再是“那个被Boss派来管我们的家伙”，他和团队一起战斗一起获得荣誉，也一起承担惩罚。
2. 集中交流：
我们的DEMO越来越变成了需求交流会，技术交流会，创新爆发会，在绿色卡以及黄色卡的讨论部分，来自各个专业以及职能部门的意见让产品收集到足够的意见，多方观点和创意，对于团队来说收获颇丰，如果是客户在场，纠正观念，挖掘深层次的需求，为下阶段工作提供指导，都是额外收获，每次团队记录员都会记得满满当当的回来。
3. 互相促进：
虽然是Scrum框架本身就提到演示会议价值，但是通过评委身份参与，了解与学习其他团队就变成了必然结果。他们被强迫思考自己团队和别人团队的差异性，看优点而暗自赞叹，积极追赶，看缺憾而习前车之鉴。
4. 团队成就感：
在Scrum master们给出的回顾会议报告中，绝大部分人都提到了，实施PAS之后自己的工作更加的被重视，导致现在工作上更有目的性，计划性，和成就感了，说简单点就是士气爆棚。
5. 对“事”不对人
确切的说是对故事不对个人，所以意见建议都能够更有效的表达，不会纠缠于人情面子。形成了一种良好的讨论范围，点子自然又多了。
知其然-还要之其所以然--PAS为什么有效的分析
Henry James说：Show！Don't Tell！
前面的部分都是Show，但作为理科人（我们也常自称理性人）分析一下现象背后的原因是必然之举，依据个人几年来对于敏捷，管理，心理学知识涉猎，我总结了一些PAS为什么有效的以下一些原因
· 无法保证目标管理的时候，可以考虑先保证过程管理
你要求团队正确高效做事的同时，再要求团队做正确的事，结果会好的机会很大。
· 无法客观衡量的时候，可以使用多人的主观来逼近客观
最简单的例子就是陪审团制度，虽然他也有弊病和漏洞，但是他至少比单人的主观更有说服力，你喜欢一言堂么！
· 人人都需要成就感
不管是马斯洛的的五层需求理论还是其他各种工业组织心理学理论都这么说。
在产品的开发周期冗长的情况下，产品发布、客户满意引发的外部给予的成就感缺失，我们可以尝试内部给予，而且正式的给予。而Scrum是西方人发明的方法，西方人都很能说我爱你，很愿意赞美其他人，所以也许他们的DEMO天生会热烈而生动一些。所以我们尝试用制度来保证每个人的赞美不留存在心里，起码目前看起来，很有效果，团队的成就感也来源于此。
我们坚持什么？--PAS机制设计原则
为什么，怎么做，结果怎么样，你都已经看过了，但真正的核心是我们遵循的原则，原谅我无法抑制住我想要模拟敏捷宣言的口吻来表达的冲动。
在每对比对中，后者并非没有价值，也绝对不是不要后者，只是在他们有冲突的时候看重前者，而且也只在这个机制里面才这么考虑，请不要误解了，这也是我在下面每个原则里面都啰嗦一个 “PAS机制中”的原因。
· PAS机制中 强调是否通过，over 强调追求高分
因为PAS的本质是过程管理，目标管理可以有其他的管理方法，就是说你有需求分析，你有how to demo，然后开发的符合预期就是符合客户期望的可以说，亮点么，让评委见仁见智吧，过于追求高分肯定会产生心理落差，能够处理心里落差的团队尽管追求，但是心理素质不好的团队就需要降低期望了，因为这是一个只有一条客观评价标准的测试，你的主观和评委的主观永远不会达到完美统一，这个也是我们最终选取了PAS来谐音pass（通过）来向团队传达这一理念的原因。
· PAS机制中 强调团队自我比较 over 强调团队间对比
因为团队间产品性质不同，外部条件不同，甚至使用的方法流程都有一定差异，如果团队间过于比拼，一方面造成不公平的消极心理，所以我们强调只要是功成名就的团队就是好团队，不要太在乎其他团队是什么分数，暗自较劲是可以的，但是不允许任何一个评委公开正式的点评一个团队比另外一个团队好。
· 最最核心的是PAS机制中强调惩罚可能性的存在 over 强调对于奖励的追求
我们的奖项可能并没有太大的吸引力，也不想要设计太高的吸引力，因为在迭代的周期上，团队工作和产品营收的关系还薄弱得很，如果要实施目标奖金管理，可以采取其他的并行管理方法，强调惩罚的存在，至少在我们这里的实施状况来说，没有一个人敢真正的不把PAS当一回事，这也是我们效率的基本保证，虽然惩罚从来没有落到任何人头上，而且惩罚其实也不算重。这是一个偏主观的评价体系，没有足够客观理由的惩罚不是一个好的管理措施。
· PAS机制中 强调正确的做事 over 做正确的事
又是目标管理和过程管理的老话题，但是暂时在我们公司内，在PAS内，要求有过程先：要求要有基于用户价值的思考带来的优先级正确性，要求有如何实现带来的方案完备性，要求有估值带来的计划准确性。被评委们在各个DEMO会议上强调了多次之后，这些已经深入人心，而且也为我们产品带来积极的变化。但谈及产品策略，中长期指标么，我们会放到其他的管理实践里面。
· PAS机制中 强调团队荣誉 over 实质奖惩
让团队有机会享受公司其他同事或者客户的赞誉，承担可能会成为 un-PAS 团队的压力，给予荣誉的代表物，尽量不和实际金钱挂钩起来，不要给团队成员以用金钱抵消他让团队un-PAS 的负疚感的机会，比如说团队内部实施一个用100块钱来惩罚 差强人意故事的责任人的举措(注4)，理论依据来自经济学家经常讲的以色列幼儿园家长迟到案例（大家有兴趣可以google一下，大致就是说幼儿园本为治理接孩子迟到现象的罚款举措成了家长们用5美元购买迟到负疚感的机会，反而加剧了家长迟到情况），而实际效果是我们一直坚持这个原则以来还没有谁斗胆犯众怒。
兴一利，必生一弊--PAS机制的弊端
PAS 机制为我们解决了scrum过程的执行问题，但就像任何一个管理机制一样，他也带来了或者强化了某些不良趋势的增长，我们评估过后认为这些弊端，认为当前情况下，他们都是人为可控的，或者说不是公司主要矛盾，是不影响到PAS机制的整体有效性的。我们会尝试解决他们，但不一定在PAS机制内，毕竟我们不能用一个机制解决所有问题，Scrum没有打算，我们也不这么打算，他们是：
· 张弛无度：
在某些迭代过度投入热情，之后的迭代筋疲力尽，迭代间比较有起伏，张弛有度还要团队学会把握。
· 忽略学习：
间或有团队成员抱怨，因为怕un-PAS而投入过高，导致每个人没有时间学习。
· 名誉熏心：
过度的用户价值导向，太想震惊客户，导致那些需要投入大量时间的质量提升故事被拖后。功在当下，利在千秋的事情就没有人做了。
· 绣花枕头：
制度无法杜绝的是有可能PO为了团队荣誉，少演示一些漂亮的故事，而声称其他的故事由于技术难度原因而砍掉了，或者PO团队任由团队正儿八经说废话，郑重其事磨洋工。在我们公司来说，目前只有CEO跟PO多沟通来发现和协商解决了，最低限度，CEO还可以用任免PO的尚方宝剑来威胁他。
· 忽视质量：
Scrum一再强调的质量是唯一不能妥协的维度，但目前为止我们还没有找到比不断四处重申更好的机制来保证他。
· 南郭先生：
暂时我们也是没有办法，只有靠团队内部的社会压力来减轻他出现的可能，但有几个团队已经采用了评选迭代MVP的方式来分配奖励给与内部的荣誉，这个是我们鼓励的尝试实践。
似是而非---PAS不是什么？
l 听起像个项目里程碑通过会议？
不！里程碑会议是本质是目标管理，是检验项目的各项指标支撑起来的目标是否达到预先估计，而PAS是过程管理，可以看做是每迭代进行的迷你版本的Scrum过程成熟度评估会议。
l 听起来越来越像瀑布开发里面的东西？
对！但也许本来就没有什么本质的不同，同是软件开发，我们也要做需求分析，也要用户价值导向，也要估计与实现，也要妥协客户价值和时间上的矛盾。但是愚以为，本质上，Scrum只是选择了，妥协价值而固定时间，选择了轻度设计而倾向于快速原型，而PAS机制只是再次强调了要”有需求分析，有设计，有估计“......等等Scrum强调不应该被忽略的东西。
l PAS可以演进成一个个人绩效考核系统？
不！我们不打算把他演进成为个人一个绩效考核系统，Scrum的目标是为了创建自组织团队来提高工作效率，绩效考核系统的是以目标管理（效）结合过程管理（绩）的考核方法来提高生产率。考核团队让团队凝聚成团而提升士气，考核个人让人人自危而各自为战，而且个人觉得从概念上以及误用的历史来说，绩效考核这四个字从来就是站在员工对面的一个管理层工具，他总是引起员工第一时间的反感，虽然他深受CEO或者人事总监们的喜爱。但在我们团队规模没有大到非用其不可的时候，我们不会考虑实施教科书意义上的的个人绩效考核。
开始行动吧，让我们正式的评价团队--写在最后
说了那么多，如果你隐约觉得这个实践可能对你的团队有帮助，那么就开始行动吧，抛开本篇文章，你不需要我们展现出来的这通篇细节，他是我们4-5个迭代之后，结合我们具体情况才演进出来的结果。你只需要一个最初想法：”我们把迭代展示搞得正式一点吧，他们这么努力，值得一个正式的公开评价，别让我们的含蓄损害了团队的积极性。“然后拟出一个草案，宣布它只是一个prototype，前提是你要能越过说服BOSS的那座大山，然后一边实行一边根据你们的情况修改，当然你可以不时回来参考我们的实践（注5），访问我的博客看看我们最新的变化，敏捷不就是这样的么？敏捷，我们还在路上！
注1：本文所涉及方法细节均为我们公司CEO李翔宇，CTO李鑫以及其他PO,SrumMaster,团队成员和我在实践中共同讨论制定，作者负责整理和撰写，感谢BOSS和各个团队的支持。
注2：在09年Qcon北京上，拿到Kniberg一本签名书倍感荣幸！
注3：是为均值，我们认为用管理方法驱动的最高投入度应该不会超过80%,超过的都是不可持续的或者应该只是爆发性的。
注4: 团队惩罚低分故事责任人是最容易想到的管理办法，但是也让他给了一个花钱买内疚的机会，我们其中一个ScrumMaster本来尝试这么做的，最终被讨论否决了。
注5：欢迎发送email和我联系讨论，我们期待在你们的来信中收获，把我们的PAS带到下一版。
欧阳丹-天爬者
关注：敏捷开发，云计算，营销创新等领域
联系方式：danoyang of gmail.com