主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

在报价会议上（poker-plan），TEAM还不知道这些story里哪些会被PO挑选，哪些不会被PO挑选(其中经常有些story是PO拿出来试探价格的）。更加不知道谁的优先度更高（没价格哪里来优先度）。

所以即使大家心理猜想将来如何分配story，也都是徒劳的。因为在优先级被排出，以及story最后进入sprint之前，都是未知数。

我稍后会讲sprint。

所以平衡记分法很难使用。scrum和xp里面的point都不是man-day或者man-hour，它只是一个相对的评估值。比如我对某个任务的估算是3个velocity，那只是说明我做这个任务所需要的时间是坐另外一个1velocity的时间的三倍。那么熟手来做可能是1个velocity，新手可能是大于三个，所以这个是不能做量化指标的。

hp是一个销售硬件和服务为主的公司，所以他的工作可以比较容易量化，这时候用平衡记分法和全方位考核法都有相当的价值。但是我基本没有听到什么大的软件公司或者小公司用这种方式进行绩效考核的。

我们之前也曾经尝试过几年量化考核，采取的做法就类似哈库这样。比如一个任务我进行拍卖，这个任务做完有100块的奖金，你多久做完是你的事，初期看起来效果不错，当时到了中后期就发现，成本大幅度提高，不单是奖金成本，管理成本也大幅度提高，但是项目的进度和质量并没有显著变化。有些程序员为了多拿钱，7*12小时的工作。

这样的直接后果就是工作质量下降，后期维护成本增加，bug多了，收入就下降，积极性也跟着下降。

另外不同任务有不同的价格，大家都有明确的倾向性，虽然说是团队的考核也占一个比例，但实际做起来很难，所谓罚不责众，只要大家都想好钻空子，有的是办法。而且争议最大的就是任务的评估，很难真正做到公平公正，特别项目到了一定规模，而我们当时项目普遍都超过1万个功能点，计算这个任务的工作量可能就会耗尽核心程序员的所有时间。到了后期有些项目基本就是指定一两个人说了算，引起的矛盾也相当多。

另外还有个问题，项目经理（pm不直接从考核中拿钱，而是根据项目进展考核，和你说的类似）为了不得罪程序员，保证项目进度，所以很多时候挣一只眼闭一只眼，我自己统计过，大约70%的任务评估都是有水分的。而认真评估考核任务的项目，项目成员收入反而直线下降，项目经理反而被程序员集体造反，最后就出现假币驱逐良币。矛盾很大。

虽然对外宣传方面，我们当时有些部门吹嘘的还是很牛的，但是私底下都承认，几个软件部门采取的不同路子最后都失败了。其实道理也很简单，如果软件真的容易做到量化考核，软件危机早就不存在了。

我觉得这种模式可能在小公司小项目做还不错。管理成本增加不明显。

要避免一个功能模块只由一个程序员来开发。

1.为了规避风险，提高truck number

2.避免程序员形成各自为战的工作方式，强调要团队作业

3.基于代码共同所有的原则，就算是你开发的，别人也有权利修改和维护，所以一般团队成员都兴趣也有义务去了解别人的工作。老实说这点我刚开始挺不适应，自己写好的东西，有时会突然就被别人改了，特别是被改错的时候，砍人的心都有，呵呵。后来发现这逼迫自己多去了解别人的工作，直接改善了交流。这点我发现是国内程序员特别不能适应的地方。

agile的团队会极力回避传统开发方式在程序员之间建构的责任壁垒，建立互相信任的关系。 只要信任关系建立了，你的这些种种疑虑都可以打散。在一个崇善的环境，人人都回争着表现自己好的一面，这是agile很有意思的地方。以前在国外的时候，不同团队的老外可以放下手上的工作，化一整天时间帮你解决问题，越是牛人，化在帮助别人的时间越多，这和国内那种注重个人成绩的气氛完全相反。当然，下一次别人有问题的时候，你也就没有借口拒绝帮助，所以长期来看，还是挺好的。

不过很高兴和你探讨这些。也希望你多多指正我一些考虑不到的方面。

回到正题，其实SCRUM也好，平衡记分卡也罢，对任务的评估都是相对精确的，更重要的是它是在建立一种秩序。在这种秩序里，一些人可以比另一些人收入高而不会引起什么麻烦，同时，这种秩序可以帮助公司了解，评估当前进行的项目并作出决定。

而且对于评估每个item的价值，除了人工，时间两个参数之外，还有一个优先极的参数（或者叫贡献度）。比如说两个item，第一个只要1人天，或者按你的算法，1个velocity。但是它的贡献度是10，那么最后的点数是10。另外一个是4 velocity,但是贡献度只有1。那么最后这个item的点数是4。

优先极的确定，也是PM和team leader来共同确定的，team leader的意见则应该在组内先达成一致。由于有集体KPI的存在，在分配item的时候，会自然出现牛人先挑的情况，由于核心功能的实现往往同时具备大工作量和高优先极两个特点，那么核心功能的价值也会比较高。

其实平衡积分卡不适合小公司主要的原因是小公司一般是一个人或是几个人包打天下，没必要这么反复沟通啊。也没有什么silo effect之类的大公司专门病。

我觉得你提到的问题不是奖金，计件考核的问题，而是在于评估标准有点缺失。如同你后面所提到的，难点是考核。

其实我个人觉得，SCRUM之所以作为一种“革命性”的开发方式，就是多了挟“客”自重的一个部分。决定权交给客户，客户随时给予满意度评价。这样，开发内部的分歧和矛盾就被转移了。

当然，靠它来完全解决劣币驱逐良币的问题是很难的。

平衡积分法的核心就在于精确量化，这恰恰是软件开发无法做到的，你的例子恰恰说明是不可量化的，所以使用一些虚拟的量化指标来代替。过于追求量化的考核指标，最后往往得不尝试。如果软件能够真正意义上解决量化问题，那么也就意味着有了真正的银弹。这个问题两年前我在这和人讨论过。软件其实是人的思维方式和社会活动的一种延续，在这方面基础科学没有大的进步之前，是很难有什么真正解决方案的。软件开发过程的难点基本都集中在需求的二义理解和开发过程的不可量化准备评估上。

我曾经和一个主管销售多年后来转去管理软件开发的资深老总谈过这个问题，他认为软件团队和销售团队管理最大的差别就在这个上面，销售团队的工作是可以量化的，但是软件团队很难做到精确量化，刻意追求这种量化过程，最后往往都以失败告终，因为付出的管理成本及其高昂，但是得不偿失。

前几年的cmm就是对这种量化过程的一种极致表现，而现在流行的agile则是一种反之，即把软件开发更多的放在需求和沟通上，淡化量化和随之的管理问题。

而比较现实的是，这几十年随着信息技术的大规模普及，软件的使用环境发生了巨大的变化，体现在需求的复杂度和可变度都大幅度提高了，传统的软件工程和重量模型根本无法刚上这种变化，相对于管理科学的进步来说，这种变化要快的多。这迫使我们改变工作方式，接受这种变化。

在死亡之旅的第一版里，作者建议对于死亡项目的处理就是辞职闪人完事，而到了第二版，作者说，现在不可避免的，大部分项目都存在严重的资源，进度，需求问题，所有的项目都是死亡项目，回避已经不再可能，必须寻找新的出路，这也是agile的起源。

如果继续抱定可以精确量化软件开发过程的态度来谈论scrum，那么就是背道而驰了。

但是现实中，管理层从自身利益出发，都不可避免的试图尝试这个精确量化的过程，但是很遗憾，至今没有真正意义上大规模成功过的案例。

相对公平就可以了。

其实我并没有试图精确量化软件开发项目的想法。

其实，部分移动省公司的BOSS系统开发升级，就是遵循SCRUM的原则来的（当然，可能一直不叫这个名字）。而移动验收这些系统的方式，则是使用了移动一直在搞的平衡记分卡，把合作公司当成本单位的一个部门来作考评（当然，只把合作公司当作一个整体来考核，不进行个人绩效评估）。

按照移动计费中心同事的说法，我们合作公司在他们内部考核（个人绩效评估）也是用平衡积分卡的方式来搞的。

我也跟合作工程师开过不少次需求支持会议，（根据这些新增的需求）合作公司也开发上线了一些新模块。整体来说，合作良好。这也是我回这个贴子的原因。

在agile团队里，不存在老鸟和菜鸟的说法，大家地位都是平等，这是和传统团队很大的区别。甚至说一些打杂的成员，我们也是都算在团队成员里，每天也跟我们一起开会，参与所有的讨论和重大决定。

而最大的问题在于，积点考评的目的是通过竞争，利用利益驱动去鼓励团队成员多做事，做好事。而这点在我看来是agile不关心的。 agile并不鼓励你多做事，只提倡大家适度做事，所以你可以看到，所有的agile过程都反对加班。如果一个迭代，你做的velocity太多，这个时候老板不会奖励你，反而会找你谈话，分析原因， 是加班太多？还是评估过低等等，总之就不会有好果子。

agile强调的是适度工作，快乐工作，让程序员快乐起来，做自己喜欢做的事，而不是以利益诱惑为驱动力。不过中国人惟利是图，你这样玩，确实有比较现实速成的功效，但是在我看来和agile本意是背道而驰的。

以前在国外的时候，不同团队的成员，老鸟往往乐意花费自己1天甚至2天的时间帮你解决一个和他无关的问题。任何人都不会也不能拒绝别人的帮助要求，这里面根本就没有任何利益关系了。这种环境下，新手往往都有勇气去挑一些比较难的任务来做，所以成长相对来说比较容易一些。

至于这种环境是否容易导致大锅饭倒是不用担心，其实你个人是否能跟的上团队，能力如何，在沟通交流非常普遍，代码也是集体所有的情况下，是很难有例外的，人人都会知道你，你的优点会被放大，缺点也一样人人皆知。而在一个人人为善的环境下，人都会有潜意识的去展现自己优秀的一面。

我们在没有任何考核和奖金的情况下，程序员经常都需要你逼着下班才肯结束工作。这其实拼的是一个短期还是长期的行为了。

老鸟＝水平高，菜鸟＝水平低，不能因为agile不分老鸟菜鸟，我们就否认老鸟和菜鸟的存在，这里你误解了这两个词的初衷，这两词的运用不代表我不知道agile不分老鸟菜鸟。其实你看看我的poker-plan，多么平等。你们把‘打杂’的成员也算在团队里，这是对的，我也是这样做的。

你有点……怎么说呢？agile是谁？他凭什么‘强调’让程序员快乐？我不太喜欢强调这个词，因为必须给出‘强调的主语’到底是谁？公司的老板说，“我强调员工快乐工作”，于是大家就快乐了？我们真正需要的一套管理方法来使员工真正快乐起来。怎么才能让你快乐？惟利是图的情况下就不快乐了？商品经济大家惟利是图，人间就不快乐了？搞公社‘强调’大家生活快乐，于是大家就真的快乐了？

只有大家干得多，干得快，项目也干得漂亮，奖金也多多，这才是真正的快乐啊。

还有，群众感觉公平公正的分配奖金，那也是另一类快乐。

关于加班，这个问题我本来打算后面要写的，您再想一想agile和加班的关系，agile少加班的原因究竟是什么？新手勇敢的接了一个困难的story，他预计在‘价格时间’内完不成，那么他自己加班搞，当然可以。老鸟做完一个story，还想做更多的，当然可以。大家工作积极性那么高，老板笑死了，跑出来谈话？那么这个老板绝对陷入教条主义里了。

同理，在我的agile里只是没人逼你加班而已。为什么没人逼你加班？原理很简单？我做多做少是自己的事情，多劳多得，少劳少得，都是我这个程序员自己的事情，这才是真正的自主权下放。

两面性：没有人逼你加班，也没有人不允许你加班。无论你加班不加班，都不会因为你‘加班’这件事得到任何额外的好处或者坏处。

收获只与你能积的点有关。

还是那个考评问题，必须找到合适的考评办法，我的办法就是积点，没看出什么不好，如果有更好的考评办法可以提出来讨论。

还有，我的队伍里好多老外和中国人混在一起干活，没发现老外有普遍高于中国人的地方。也许特别好的老外没来而已。当然咯，我的评判就是指从干的点数上来看。相反，很多老外自以为是的脾气倒是很重，我虽然不喜欢，但我也不管他们，反正看他的活，什么脾气随便，在制度上，老外中国人平等。

对每个成员的要求很高，对负责重构的要求更高

只要存在大量需求变更，那么就一定会有那些你认为‘老手’来解决的事情。

agile-SCRUM只是来寻找一个途径来平衡。

传统模型对待需求变更的解决方案是--“商务谈判”，在开发前你得把需求定下来，如果中途有变更，要么排到下一版本开发，要么加钱加时间（这里的钱和时间会让客户有肉痛的感觉，呵呵）。

敏捷模型拥抱变化，积极响应需求变更，期待以小步快走的方式及时满足客户所需。这在web开发和很多应用程序开发方面确实做的很好。但在一些规模稍大的项目中，如果用户的需求变更影响到架构需要重新设计或做大的修改怎么办？大需求分解为小需求，小需求再由小组进行敏捷开发。这些小组间的同步和管理怎么办？个人感觉在国内这种开发环境下，只有靠开发人员的水平和经验了。而国外那种几个人十几个人完成个比较大的项目或创意的团队，那更是个人能力的体现。好像敏捷模型也就是从这类小团队的开发方式中总结出来的吧？

当然，在时间或效率不是第一位的情况下，这种方式我还是比较喜欢的。

对，这也是一种平衡，只是效率很低，遇到大量频繁的改动，不可能频繁的谈判。

无论如何分解，都无法避免这种修改的成本很高，这种成本将以point的形式直接让客户看到，客户有权力选择进行或者不进行，如果执意进行，那么要么追加工作人员或者工作时间来‘充实自己的钱包’，要么踢掉其他优先度低的需求。除此别无他法。（当然也可以逼迫员工加班，这个后果就不说了，大家都知道）

能力是不可能通过管理方式来短期提高的，能力差的就做的差点，能力好的就做的好点。这是无法回避的。但能力好和差只是个程度词，在能力范围内如何把事情做的更好，才是要讨论的问题。

而需求变化是项目环境恶化的因素之一，而同时创意就是以需求变化的形式产生的，如果好的创意都能是在项目一开始就能做出，那么就不存在需求变化，那么不在我的讨论范围之类。我一开始就已经说过既然要讨论，就要把项目环境考虑的糟糕一点。

在需求变化很多的状态下，极容易出现一种情况，就是原本可以干更多更重要的事情，却被不那么重要的事情耽误了时间，这才是SCRUM要解决的。

不变更，做不出好产品（市场变了，你也要变），变更吧，合同怎么办？

以至于外包的东西只能是外围的简单重复工作，跳不出来，但是合理运用SCRUM倒是可以解决这个问题的，如果解决的好，那么是否可以认为是挽救了外包模式呢？

人家装模作样天天加班到深夜，老板眼里就是用功啊。一起干活的当然清楚，但是又有什么办法呢？只要考评靠拍脑袋，老板觉得他用功，MVP就是他了。你气死也只能用脚投票。

所以说到底还是考评问题哟。