主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
家园 同问。 是不是一般签个框架协议什么的？
家园 你就是传说中的老白？ 在公司里讲到这里的时候，有些同事会问：老白，你是不是要说什么加强沟通之类的话了？你就是传说中的老白？
家园 老邓你下面是不是要说 珍珠翡翠白玉汤？
家园 【原创】闲聊敏捷开发——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点没关系，自然不会有抵触。
于是项目的每个阶段，都可以根据每个员工赚到的点数快速准确公平的得到他为项目做的贡献。而这正是员工和老板都希望的，除了那些偷懒的马屁精——计划经济的产物。
有问题随便问。
通常我和别人讲到这里的时候，接二连三的问题都该出来了。
家园 那会不会出现这种情况 Team不大，比如你的例子，一共3位。要是这3位团结起来，一起报高价呢？那么怎么办？虽然市场竞争是好事，但如果市场小，也很容易垄断。至于如何解释这个高价，如果PO不懂技术（大多数情况），那么这个团结的team是很容易解释的。
家园 这个问题不错，我最近正打算继续写点不适合SCRUM的案例 SCRUM TEAM的大小确实不能太小（3个人少了点），举例用3个人是为了举例方便。
一方面说，3个人的team要用SCRUM管理也可以，但不会起到特别优势。
另一方面说，如果三个人能联合起来对付PO，哪怕不用SCRUM管理，这项目也一样很难办。
家园 送到第五贴 终于有宝来谢楼主了...
谢谢：作者意外获得【通宝】一枚鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
[返回] [关闭]
好文章,受益匪浅...
家园 这样团队内的牛人岂不是要负责所有的工作了 因为他的出价永远低于其他人啊，那其他人还干什么。
家园 一路送花，但是 感觉这样针对的是软件蓝领。一方面，大多数软件开发其实就是蓝领工作，用市场经济方法来调节是提高效率的好方法；但是另一方面，对真正有创造力的大牛来说，他们要需要的是自由的环境，比如我很难想象James Gosling 会在这种环境下开发出Java来，对他们来说，也许类似学院的tenure制更适合。Google的20%业余时间和12week轮换也许更适合新软件的创造。
家园 问的好啊，到点 如果牛人意识到他们干的多就拿的多，那么他自然会拼命干啊，按照我的评估体系，那是直接挂钩啊。
别的人怎么办？只能抢牛人剩下的story干。谁让你不能象牛人那样快速解决story？很残酷，但绝对促进学习热情。
楼下已经提到比较优势了。
比如报价，A1(超牛），B4,C5
平均价格3.3
虽然A报1，但是A手上在干别的story。B和C如果没有别的story可选，B相对C，选这个3.3的story不算太亏，B选了再说了，但他选完肯定会回忆一下Poker-plan会上A肯定做过的解释了，A也许指明了一条捷径，B会想不妨一试。
- 复 问的好啊，到点
家园 个人感觉agile是老手们的游戏 对每个成员的要求很高，对负责重构的要求更高
家园 这种感觉的根源不是agile，而是需求变更 只要存在大量需求变更，那么就一定会有那些你认为‘老手’来解决的事情。
agile-SCRUM只是来寻找一个途径来平衡。
家园 我不这么认为 传统模型对待需求变更的解决方案是--“商务谈判”，在开发前你得把需求定下来，如果中途有变更，要么排到下一版本开发，要么加钱加时间（这里的钱和时间会让客户有肉痛的感觉，呵呵）。
敏捷模型拥抱变化，积极响应需求变更，期待以小步快走的方式及时满足客户所需。这在web开发和很多应用程序开发方面确实做的很好。但在一些规模稍大的项目中，如果用户的需求变更影响到架构需要重新设计或做大的修改怎么办？大需求分解为小需求，小需求再由小组进行敏捷开发。这些小组间的同步和管理怎么办？个人感觉在国内这种开发环境下，只有靠开发人员的水平和经验了。而国外那种几个人十几个人完成个比较大的项目或创意的团队，那更是个人能力的体现。好像敏捷模型也就是从这类小团队的开发方式中总结出来的吧？
当然，在时间或效率不是第一位的情况下，这种方式我还是比较喜欢的。