主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
家园 【原创】闲聊敏捷开发——SCRUM（二） 总结上一篇，简单概括就是说，需求变更是不可避免的，可以认为是常态，SCRUM作为解决需求变更的机制应运而生。
我的理解，最最能够概括SCRUM机制的话只有一句：
SCRUM就是打算以市场经济体制来对应需求与供给。
每当我说出这句话，总有人会说“老白，你也太扯了吧，有关系么？”。
有的，我讲完以后也许你会发现哲学层面上，两者高度统一。
客户在SCRUM项目中的角色，不是发布指令的上帝，而是购买者。上帝说要有光，于是就有了光？不对，上帝要有光，先得问问搞个光花费多少，然后上帝想想还有没有必要有光，然后再决定要不要买。在SCRUM中，这样的上帝被叫做product owner，简称PO。可能不止一个人，但是他们的声音必须是一致的，如果不一致，回去讨论完了再出来。
在SCRUM中，PO只是购买者，市场供给者就是TEAM。PO花费的钱是未来一定时间内TEAM成员们的工作总时间，PO的需求叫做story。
如果TEAM的人数不变，TEAM未来一定时间内的工作总时间就是不变的。把这个总时间以point来计算，发到PO手里，然后让PO用这些Point来购买他们的需求。所有的需求加在一起成为客户最后的产品。
客户＝PO，
开发组＝TEAM，
开发组未来一定时间内的总工作时间＝PO可以花的‘钱’＝Point
客户的需求＝story。
PO拿着point来向TEAM购买他们的story。
既然是购买，那么总得有价格吧，每个story都有自己的价格，价格单位就是point。
此外还得有个规则的维护者，叫做SCRUM MASTER
先约定好一个point和时间的换算率，比如一个人工作1周为10个点数。那么如果TEAM里面有10个人，那么一周的总点数就是100点。我先不提其他什么factor，不重要，先就这样算。
演出开始了。
既然讲需求变更，那么第一个就是需求（story）能变更么？
能啊，如果这个story还没有开始做，就可以变更，不过如果story变更了，那么价格也变更了。（塑料的把手2块钱，镀铜的10块钱。我比较喜欢用装修的例子，容易换位思考，大家其实都当过客户）
如果这个story已经做过了，那么任何变更就是另一个story，随便你什么名字，polish, improvement, jump……，随便，都是另一个story了，另外花钱买。
较真党问如果正在做怎么办？我后面会详细说。
先要说一下价格怎么来？既然是市场经济体制，价格当然是市场定咯，注意，客户听到这里要光火了，TEAM自己决定？他开个天价我怎么办？等等，你怕不怕买到天价的面包？不怕，为什么？因为市场是有竞争的，不买你的可以买他的。那么我们这里的市场是TEAM和谁竞争呢？有些同学可能想到了Multi-TEAM，这个我先不说。由简入繁，只有一个TEAM的情况下，怎么处理呢？
SCRUM是这样解决的，开一个会，叫做Poker-plan meeting，用来给PO的story进行估价。在这个会上，PO先解释自己的story，比如这个story叫做‘卧室的房门’，需求是门上用镀铜的把手，油漆用清水的，贴面用胡桃木的，门正中央有个镀铜的福字……
如果TEAM觉得PO讲的还是不清楚，当场提问，比如，这个‘福’字要多大？镀铜的把手在什么位置，门朝里面开还是朝外面开？门套是不是一起做？……
PO（们）讨论了一下，回答完了TEAM的问题，然后TEAM可以估价了。
怎么估呢？每个TEAM成员自己手里拿一付扑克牌，从牌里抽出代表自己的价码的那张，说1，2，3一起摊牌。由于事先不商量，价码有高有低，通常差异很大，TEAM成员各自阐述一下理由，然后再出一次牌，如果还是差异很大，那么再商量出一次，一般不超过三次。第三次如果差异还是很大，那么SCRUM MASTER（以后我简称SM，想歪的去面壁）宣布价格为平均数，此时SM把各自谁出了什么价记录下来，将来有用的。
这个流程基本已经过滤掉‘天价’的可能性了。在我实际项目运用中也确实如此。
大概分析一下天价牌可能出现的几个情况：
1， 故意哄抬物价，由于TEAM成员此时出牌并不知道这个story将来会谁做，他故意出天价牌，看不到直接好处，由于他的天价牌，倒是需要他做出技术上的解释的。所以这种情况可能性很小。
2， 个别成员经验不足，那么第一次摊牌之后，大家商量一下，解释完了，第二次摊牌的时候这张天价牌也自然消失了，与此同时，在解释商量的过程中，这个经验不足的成员也因此学习提高了一下（这是个SCRUM的副好处）。
3， 大多数成员经验不足，只有极个别精英成员意识到这个story不像看上去那么简单，那么这个精英会和大家解释大家没有看到的陷阱。如果能说服大家，下一轮摊牌，大家会提高点数的。如果说服不了，那么也无所谓，精英保留自己的高价牌。SM会记录下各自的出价的。
但无论大家有没有达成共识，三轮以后，报给PO的价码只有一个。PO把刚才说过的细节写下来，然后TEAM的价格也填上去，SM作证。这个story就有点像是一个合同了（合同的交货日期不用现在定，后面再说）。
由于是‘市场经济体制’，这个决定story价格的会议非常重要，需求在这里由价格来反映。一定要好好开，需求问题都得问清楚，写下来。之后反悔就有字据了。我的经验表明，之后绝大多数问题追根溯源都能发现是这个poker-plan 没有开好。
总结这个poker-plan会议的要点。
1， PO充分表达story的细节
2， TEAM充分了解story的细节（觉得不清楚的要问清楚）
3， 出价过程要被记录下来
4， 价格一旦被敲定，story内容不再修改。
5， 如果story内容要修改，这个会重开，重新估价。
6， 如果因为其他story牵扯到这个story的价格必须出现跟进变化，这个story可以重新开会估价。
开过poker-plan会后，相当于客户去市场上逛了一圈，了解了一下他需求的东西的价格，至于买不买，先买什么后买什么，还没有定。之后就要讲到优先级和sprint了。
元宝推荐：铁手,
本帖一共被 2 帖 引用 (帖内工具实现)家园 我觉得让多个TEAM成员来开价不太可能 现在通常的做法都是一个功能模块只由一个程序员负责开发，那么关于这个功能模块的需求变更就只能由这个程序员出价了，其他成员都不熟悉这个功能，包括这个功能的业务领域知识和实现的技术细节都不了解，怎么出价啊。而那个负责程序员的出价显然多半是偏高的，PO一般也就无法接受了。
家园 agile里的做法相反 要避免一个功能模块只由一个程序员来开发。
1.为了规避风险，提高truck number
2.避免程序员形成各自为战的工作方式，强调要团队作业
3.基于代码共同所有的原则，就算是你开发的，别人也有权利修改和维护，所以一般团队成员都兴趣也有义务去了解别人的工作。老实说这点我刚开始挺不适应，自己写好的东西，有时会突然就被别人改了，特别是被改错的时候，砍人的心都有，呵呵。后来发现这逼迫自己多去了解别人的工作，直接改善了交流。这点我发现是国内程序员特别不能适应的地方。
agile的团队会极力回避传统开发方式在程序员之间建构的责任壁垒，建立互相信任的关系。 只要信任关系建立了，你的这些种种疑虑都可以打散。在一个崇善的环境，人人都回争着表现自己好的一面，这是agile很有意思的地方。以前在国外的时候，不同团队的老外可以放下手上的工作，化一整天时间帮你解决问题，越是牛人，化在帮助别人的时间越多，这和国内那种注重个人成绩的气氛完全相反。当然，下一次别人有问题的时候，你也就没有借口拒绝帮助，所以长期来看，还是挺好的。
家园 很好的问题，很多人问这个 开始poker-plan前很多人有这个疑虑。
但仔细想想，恰恰因为个别程序员了解这个模块，所以他开价应该比较低，其他人开的价是假设他们来接手的价码，自然稍高，那么平均价理论上高于那个‘个别程序员’，所以，这个个别程序员选择这个story就比较划算。
但是，如果这个个别程序员胁着‘别人不了解’而故意高开，那么就会‘暴露’。客观上，更加公平的找到了价格。
PO了解到这个层面，就OK了。
家园 这个poker-plan是否可以这样理解 客户邀请几家供应商来共同开会。会上大家充分讨论后，各家私下讨论报价，再共同开标？那么这个SM的属于哪方的？屁股坐在哪方都很难不偏不倚吧？希望老兄能解释一下哦！
家园 理解的不错 这个SM的屁股问题我在（四）里已经开始提到，下一篇还要讲SM，鉴于PO出去强势地位，屁股表面看是偏向TEAM的。
但是，由于他是执法者，而不是立法者，他的屁股其实是坐在规则之上。只是破坏规则的大多数情况是PO，所以这个SM的屁股表面上偏向了TEAM而已。
家园 没看完，先说一句 中国有句俗话：隔行如隔山。所谓用户需求的变化，我认为不是真正的变化，而是软件人员对真正客户需求的捕捉过程，以想当然的态度看待问题，对另一个领域貌似微不足道的关键部分的忽略。
当然，如果真碰到客户希望软件人员帮他们开发银弹的项目，我觉得这种项目绝对不会成功
家园 送花，感觉精彩的马上就来了 恭喜：你意外获得【通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望
我们在这个帖子里面玩儿个角色扮演怎么样？预设一个项目，然后各自扮演客户，SM，想想都好玩，老白你是楼主，还有代码老哥，软件工程这个坑你们带头刨出来的，组织一下吧，呵呵，越想越兴奋了。
ps：老几位慢慢儿想着，小羊先去面壁。。。
家园 提点意见 感觉说到目前为止，你描述的scrum和其他agile开发，比如xp没什么区别，呵呵。
- 复 提点意见
家园 有的，多了一个SM 后面的过程也是有区别的，耐心点。
另外，敏捷原则下各种方式并没有本质的区别。
家园 还是有一定差别的 现场客户，时间盒子，技术人员负责工作量评估，客户负责任务选择。强调尽可能多的减少管理人员和管理成本，让合适的人干合适的事，这些就算是基本原则了，大家都插不多。
但是不同过程在具体应用中有比较大的差别。scrum向传统的重型过程妥协的比较多一些，所以比xp更容易接受和实施。 比如scrum中的测试理论上还是可以安排传统的方式去实施的，这点是xp在很多公司很难被接受的地方。基本上scrum和cmm模型里面的2-4都可以吻合的比较好。xp就相对困难了。
另外scrum的需求方面和xp差别比较大，backlog就是一句话， xp至少userstory 背面还要写确认测试。怎么去run这个部分，就是各人自己理解了。po不负责任的时候，这句话就搞死人了，之前就是这样的。当然如果po不负责任，xp也一样完蛋，不过xp里面要求po负责写确认测试，这样至少会逼迫po认真思考他要想要做什么。相对来说scrum这部分随意性更大一些。
楼住能否加快进度？你们要兴趣弄个qq群，我们可以进一步讨论。
- 复 还是有一定差别的
家园 基本原则差不多 你总结的蛮好，我感觉SCRUM对于PO要求更低一点，更加适合对开发完全不懂的人来做PO。这也就是要安排SM的原因之一。
我QQ不常用。MSN是[email protected]