主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
家园 软件的问题是不能精确量化 所以平衡记分法很难使用。scrum和xp里面的point都不是man-day或者man-hour，它只是一个相对的评估值。比如我对某个任务的估算是3个velocity，那只是说明我做这个任务所需要的时间是坐另外一个1velocity的时间的三倍。那么熟手来做可能是1个velocity，新手可能是大于三个，所以这个是不能做量化指标的。
hp是一个销售硬件和服务为主的公司，所以他的工作可以比较容易量化，这时候用平衡记分法和全方位考核法都有相当的价值。但是我基本没有听到什么大的软件公司或者小公司用这种方式进行绩效考核的。
我们之前也曾经尝试过几年量化考核，采取的做法就类似哈库这样。比如一个任务我进行拍卖，这个任务做完有100块的奖金，你多久做完是你的事，初期看起来效果不错，当时到了中后期就发现，成本大幅度提高，不单是奖金成本，管理成本也大幅度提高，但是项目的进度和质量并没有显著变化。有些程序员为了多拿钱，7*12小时的工作。
这样的直接后果就是工作质量下降，后期维护成本增加，bug多了，收入就下降，积极性也跟着下降。
另外不同任务有不同的价格，大家都有明确的倾向性，虽然说是团队的考核也占一个比例，但实际做起来很难，所谓罚不责众，只要大家都想好钻空子，有的是办法。而且争议最大的就是任务的评估，很难真正做到公平公正，特别项目到了一定规模，而我们当时项目普遍都超过1万个功能点，计算这个任务的工作量可能就会耗尽核心程序员的所有时间。到了后期有些项目基本就是指定一两个人说了算，引起的矛盾也相当多。
另外还有个问题，项目经理（pm不直接从考核中拿钱，而是根据项目进展考核，和你说的类似）为了不得罪程序员，保证项目进度，所以很多时候挣一只眼闭一只眼，我自己统计过，大约70%的任务评估都是有水分的。而认真评估考核任务的项目，项目成员收入反而直线下降，项目经理反而被程序员集体造反，最后就出现假币驱逐良币。矛盾很大。
虽然对外宣传方面，我们当时有些部门吹嘘的还是很牛的，但是私底下都承认，几个软件部门采取的不同路子最后都失败了。其实道理也很简单，如果软件真的容易做到量化考核，软件危机早就不存在了。
我觉得这种模式可能在小公司小项目做还不错。管理成本增加不明显。
家园 咱俩可能歪楼了。呵呵 不过很高兴和你探讨这些。也希望你多多指正我一些考虑不到的方面。
回到正题，其实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的原则来的（当然，可能一直不叫这个名字）。而移动验收这些系统的方式，则是使用了移动一直在搞的平衡记分卡，把合作公司当成本单位的一个部门来作考评（当然，只把合作公司当作一个整体来考核，不进行个人绩效评估）。
按照移动计费中心同事的说法，我们合作公司在他们内部考核（个人绩效评估）也是用平衡积分卡的方式来搞的。
我也跟合作工程师开过不少次需求支持会议，（根据这些新增的需求）合作公司也开发上线了一些新模块。整体来说，合作良好。这也是我回这个贴子的原因。
家园 按照SCRUM培训的内容确实不是这样的 但员工对团队的集体成果没有直接感受，他们还是对自己的实际收获感兴趣，残酷不？现实啊。
虽然他们的关系看似有竞争关系，但他们同时又是伙伴，他们虽然抢点数，但是他们有时候需要互相帮助，如果是个能够帮助别人的人，那么当他需要别人帮助的时候别人也愿意。如果他对别人是无用的，那么别人自然不愿意帮助他，那么他就渐渐被团队淘汰了。
只有在互相有利的情况下互相帮助才会成为常态。
我是更加遵从残酷的市场逻辑。
否则团队成员中的废材怎么淘汰出去？
关系适度紧张没啥不好的，市场经济中的同业经济体就是竞争关系，有竞争才紧张，竞争才能提高生产力。
欢迎继续讨论。
家园 scrum是要资深程序员的 是老美程序员对那种工程可以机械细分到高中生水平的印度外包模式的反击。
家园 外包模式的死穴恰恰是变更 不变更，做不出好产品（市场变了，你也要变），变更吧，合同怎么办？
以至于外包的东西只能是外围的简单重复工作，跳不出来，但是合理运用SCRUM倒是可以解决这个问题的，如果解决的好，那么是否可以认为是挽救了外包模式呢？
家园 团队成员是否是费材大家都心里有数 一段时间之内跟不上，自然就淘汰了。我自己现在的小团队，说实话人人水平都不高，但是工作气氛好，大家也都很勤力，工作效率倒是比其他牛人辈出的团队要好。能力总是可以提高的。作软件就是一民工业，又不是搞火箭科技。
家园 在敏捷团队中分配奖励就像刀锋上的舞蹈 我忘了在哪里看到的。
家园 我不喜欢艺术，我喜欢直接明了的 凡是有‘艺术’存在的，就是‘人治’。
奖惩明细才能搞‘法治’。
尽量把项目管理搞成‘法治’是我的管理方针。
和秦军按人头分军工一样，简单的规则，刺激出的积极性最高。
家园 就这个意义上，你是和agile向背的 说实话，我接触的所有agile项目的开发效率都不是特别高。agile不是用来解决生产率问题的。
家园 生产率的问题更多是团队的水平 管理可以在一定程度上提高生产率。核心效率的提高还是要依赖程序员水平的提高，在哈酷讨论的这个层面不是用来解决这个问题的。
家园 可以举个例子说明 不考虑需求变更的时候，用传统方式往往有更高的效率（不要讨论文档，测试那些问题）。 在非agile项目里，我们接到一个任务一般是这样做。
1.招募一个核心牛人，以其为核心组建团队
2.牛人对任务进行分解，自己承担核心部分， 再把其他边角料分散给食物链各级人员。
这个模式的开发效率往往都比较高，只要找对了核心人员，就基本上成功了。
但是问题也很突出
1. 高风险性，牛人变成truck number。一旦闪失，整个项目就完蛋。
（虽然有cmm，有各种重过程各种文档，但是几十年下来大家还是发现，传统模型基本还是这个调子，那些文档和过程装饰性作用比较多）
这点对小公司可能无所谓，对大公司就是个大问题。大公司运营，关键考虑的是风险。当年我在某家公司做agile的时候，老板最满意的不是生产率，而是我解决了人员流动的风险。
2. 食物链低层人士得不得足够的成长机会，时间久了，流失难免。
项目经理只会考虑进度和质量，工作安排上只能尽可能考虑效率，不会太关心个人成长。
3. 牛人不的不长期担任核心工作，压力大，和团队人员梳理感也重，资历越老，加班时间和压力也更相应增加，过了一定年纪考虑再考虑家庭原因，很难长时间持续。再考虑到项目需求不断变更带来的压力，也往往就意味着更多的加班，更多的压力。
这种模式下，虽然有少数食物链底层可以凭自己能力出头，但是也基本摆脱不了做牛人的命运。我认识很多技术强人过了30就转行，主要不是钱的问题，还是做下去已经没有什么乐趣了。
但是要说生产率，那还真是不错，当年我年轻的时候高峰期一天要写2k代码，而且错误率很低。
现在做agile就不一样了。团队里理论上是没有金字塔结构的，人人平等， 一个任务接下来，如果你还按这种模式做，其他菜鸟就不干了，每次回顾的时候就会说，没学到东西，老板也会找你谈话。所以架构也要做，任务也要分解，但是这个过程中，你必须考虑到所有人的参与感。以前做设计，2个人核心人员讨论完了就完了，再另外找个人核心人员评审，这就算完了。现在不同，团队里所有人都要参与讨论，不懂得地方你还要耐心解释。设计弄完，开发的时候也是代码共同所有，谁都可以改，谁找你要求解释，你也必须回应。这么下来，效率怎么可能高？
但是回头来说， 其他人的成长机会就多了。 长期看，效率问题可以有所缓解，更重要的是项目风险降低了，因为责任不再由单纯的1，2个人承担了。另外这个过程中，因为交流沟通比较频繁，所以团队人员之间的关系会比较流畅，工作气氛也会比较好。比如自己年轻的时候，总是一个人带着耳机干活，现在基本上都和一些小孩子做pp，一天有说有笑的就过了。
而且这个过程，加班是不ok的，老板不能因为项目进度要求你加班。你说这么玩法，程序员能不喜欢么。所以现在搞agile的，叫的最欢的就是一些大公司。