主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
我们现在就是这种状态，哈哈
都是苦命的人。如果我的文章能帮到你们一丁半点，是我的荣幸。
我们现在的项目做了快半年了，摸索出一些控制需求变更的方法跟你讲的还是有些神似的。
所以我也正在学习中，希望能够把握精髓 ^_^
感谢您坚持看到这里，对于不做管理的技术同学可能有点枯燥了，反过来说，如果您能坚持读到这里，我就不怕再讲深一点，我尽量往事物根源上讲。
同等科技水平下，什么样的生产关系就有什么样的生产力
人类经济活动组织形式的变革对于我们这个时代的人中国人算是深刻体会了。
计划经济体系约束了人的积极性，在充满粮票油票的时代也只能靠评先进个人或者评先进集体来激励人了，考评永远是那么让人觉得不公平。精神原子弹现在看起来短期内是有效的，但是长期看一定是低效的。不过这个低效要看和谁比，当所有人都在计划经济的时候也不觉得低效，“让大家紧张起来”是个榨取生产力的办法，战争期间进行战时计划经济感觉效率很高，有了一个短期内的危机感，人自然会激发潜能。但另一方面，即使劳动者的士气很高，计划的复杂程度也阻碍了计划的有效性。
计划经济的原罪是价格无法反映商品的供需关系。那么如果价格能反映供需关系，是否就可以计划了呢？我认为是，所以要找到一个反映供需关系的渠道，这条渠道不太好找，但是至少关系清楚了，反对的不是计划本身，反对的是缺乏信息情况下的计划。
如果有同学还是没有看懂我到底想说什么，我愿意说的直白一点。
瀑布式管理就像是计划经济体系。
需求方，或者说购买方，是老板，或者老板的老板，或者老板指定的某人，反正代表出钱的那方。所以也可以称为资方，甲方，以及他们的代表。
商品是什么？
商品实际上是劳动者付出或者将要付出的劳动力（而不是产品本身，因为产品本身就是劳动力换来的，本质还是劳动力）。
价格是什么？
价格其实是劳动者的工作时间。在计时制情况下，工作时间就等同于支付给这个劳动者的报酬。
这个价格来源何处？也就是说谁来回答“这个活要干多久”？这个工作量评估的工作恰恰是瀑布式管理中最难解决的环节，等同于在计划经济中物价局如何才能设定一个价格来让干活的人满意呢？在瀑布管理中，每个公司每个项目都有一套评估工作量的方法，无论怎么评估，如果能满足以下两个要求，那么就OK，1，能够快速的给出。2，能够让资方相信评估是准确的。
这两个需求通常是矛盾的，资方永远有一百个理由怀疑这个工作量评估，他不懂技术，但他有眼睛，可以看到A在加班，B却在上班时间上网聊天。当然可以说A能力不如B强，但是他一样会问为什么不能给B安排更加多的工作呢？还不是工作量预估的问题么？
于是稀奇古怪的潜规则就出台了，不要给老板看到你在聊天，让老板始终认为你很忙……我就不展开了。
好，先把楔子打在这里，接合我前面提到的SCRUM－poker-plan，这个评估工作量的方法显然更加符合：1，能够快速的给出。2，能够让资方相信评估是准确的。
于是同学们可能问，既然Poker-plan好，我能不能就学一个poker-plan作为一个模块来替代瀑布管理的工作量评估呢？
嘿嘿，poker-plan是很核心（所以我拿在最前面说么），但是没有配套是不行的。
1， 分配任务配套
2， 考评体系配套
先说分配任务
瀑布管理如何分配工作？
是lead吧，多么熟悉的计划经济模式啊。
你干什么都是别人计划中的一部分。你不想干怎么办？这个我就不展开了，大家都有体会。
市场经济下，你如果想开个店，当然是什么赚钱开什么店，盈亏自负，每人给你计划。
SCRUM里任务不是分配的，而是自己选的（当然也就自负盈亏）
还是看我那个例子
最后TEAM成员各自出价是：A5,B3,C5，SM宣布为平均数4.3。
A和C不会选，因为他出价是5。报价低于他心理预期，或者说他预期要2天半干完，现在这个报价是要求低于2天半。
B应该会去选，因为他觉得1天半就可以干完。
对于每个story来说，总有人报价低于(等于)平均数。那么总是有人选的。
极端情况下，有个特别强的人的报价永远低于大家的会怎么样？那么他在单位时间内他能赚的点数肯定将大于别人的。大家仔细想想是不是这样。
反之亦然。
既然讲到“赚到的点数”，就必须连带另一个配套机制——考评。
大家先想想自己在瀑布式管理中怎么被考评或者考评别人的——说到底三个字“凭感觉”，换三个字“拍脑袋”，都一个意思。评估体系搞了几十年，搞到今天用上了计算机帮忙打分，还是搞的成本巨大而怨声载道，因为无论搞出多少表格，写了多少个人目标小结，归根结底还是依赖人在拍脑袋。纠结在fact和opinion上的只字片语，最铁的fact还比不上考勤记录铁。斗半天还是斗嘴皮。大多数员工感受到的不公正待遇大都来自于考评结果，一来这个和钱包休戚相关，二来辛苦大半年还比不上某人天天装腔作势加班外加拍马屁的，气不过。
对于员工是这样，对于老板他同样处于一个困境，压榨员工的工资并不是他的本意，他需要的是留下人才，赶走蠢货。他搞那么多HR来做考评何尝不是一种巨大的开销呢？但是如何才能找到一个考评方法满足“快速”和“准确”呢？
所以员工和老板都是希望有个准确（公平）而且快速（廉价）的考评机制的。
这几乎就是计时制工作的一个死穴。
但记件制的工种可没有这种问题，做一个算一个，多做一个就多拿一份，真正的多劳多得。这就是我推崇的考评体系的溯源。
最简单的计件就是记录每个人实际做的点数。回忆我前面说的卧室房门的案例，夹板门要改实心门，没关系，前面夹板门的5个点已经被‘赚’到，后面做实心门的20个点和前面5点没关系，自然不会有抵触。
于是项目的每个阶段，都可以根据每个员工赚到的点数快速准确公平的得到他为项目做的贡献。而这正是员工和老板都希望的，除了那些偷懒的马屁精——计划经济的产物。
有问题随便问。
通常我和别人讲到这里的时候，接二连三的问题都该出来了。
当SCRUM规则运用正确时，自我学习将自发出现。
Scrum应该更强调团队合作，要考核也是团队的velocity，对个人是不做计件工资的，否则pp什么的都够呛，成员之间关系也会比较紧张。
但员工对团队的集体成果没有直接感受，他们还是对自己的实际收获感兴趣，残酷不？现实啊。
虽然他们的关系看似有竞争关系，但他们同时又是伙伴，他们虽然抢点数，但是他们有时候需要互相帮助，如果是个能够帮助别人的人，那么当他需要别人帮助的时候别人也愿意。如果他对别人是无用的，那么别人自然不愿意帮助他，那么他就渐渐被团队淘汰了。
只有在互相有利的情况下互相帮助才会成为常态。
我是更加遵从残酷的市场逻辑。
否则团队成员中的废材怎么淘汰出去？
关系适度紧张没啥不好的，市场经济中的同业经济体就是竞争关系，有竞争才紧张，竞争才能提高生产力。
欢迎继续讨论。
事实上在组内使用甘特图来控制流程的时候，也是会把工作量放到每个人头上的啊。
你说的情况解决方案也是现成的。在个人的KPI之上加一个集体KPI。 单独完成个人部分，可以拿到一部分奖励。完成集体目标，拿到更多奖励。
只要把个人奖励目标定的低于集体目标，就问题不大。
我忘了在哪里看到的。
凡是有‘艺术’存在的，就是‘人治’。
奖惩明细才能搞‘法治’。
尽量把项目管理搞成‘法治’是我的管理方针。
和秦军按人头分军工一样，简单的规则，刺激出的积极性最高。
一段时间之内跟不上，自然就淘汰了。我自己现在的小团队，说实话人人水平都不高，但是工作气氛好，大家也都很勤力，工作效率倒是比其他牛人辈出的团队要好。能力总是可以提高的。作软件就是一民工业，又不是搞火箭科技。
说实话，我接触的所有agile项目的开发效率都不是特别高。agile不是用来解决生产率问题的。
agile面向的都是需求变更比较多的项目，需求变更多效率当然就低了。
有些项目不适合agile的，后面我还会说到。
管理可以在一定程度上提高生产率。核心效率的提高还是要依赖程序员水平的提高，在哈酷讨论的这个层面不是用来解决这个问题的。
现在通常的做法都是一个功能模块只由一个程序员负责开发，那么关于这个功能模块的需求变更就只能由这个程序员出价了，其他成员都不熟悉这个功能，包括这个功能的业务领域知识和实现的技术细节都不了解，怎么出价啊。而那个负责程序员的出价显然多半是偏高的，PO一般也就无法接受了。