主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
看了代码ABC的测试驱动开发，不免有写点东西的冲动。再不写担心被河里其他大牛抢着写掉了。来西西河那么久了，自己就这么点货色，不抖一抖过意不去。
我要声明的是，我写的东西不代表SCRUM培训，如果我说的部分内容和你接受过的SCRUM培训老师说法有差异，不用奇怪，我并不推销这个，我只谈自己的想法。培训老师讲的东西很多太抽象，培训SCRUM的时候也经常有讲师被问倒问死的情况发生。
我自己运用SCRUM进行项目管理，我相信能够回答绝大多数问题，我经常在吃饭的时候给公司员工讲SCRUM，所以养成了尽量通俗的讲解习惯，也养成了回答问题的习惯。所以大家随便回帖提问。我发现这个东西要理解透就得一问一答才行。
我不打算像SCRUM培训那样一上来先介绍SCRUM 的那些复杂的规则，那些规则会给不了解SCRUM 的同学造成一个复杂繁冗的误解，我打算通过我的理解来推导出SCRUM 的规则，以使大家理解SCRUM的规则真正的本意。
如果你对SCRUM有所耳闻，就一定会对它复杂的规则搞的很头痛，在项目实践中，人们常常会问我或者问自己以下问题：
我们为什么要这些规则？这些规则到底对项目是起推动作用还是约束作用？
客户还会问“人类创造性的思想精华居然被规则束缚，这是好的管理方法么？”。
开发组员会问，“我们有必要开那么多会么？这些会难道不是浪费时间么？”
在我写完这个东西以后能够就回答完这些问题了。
我认为在讨论之前，必须先把项目环境假设的糟糕一点。为什么呢？因为我曾经遇到其他一些项目管理人员谈到他们SCRUM用的很顺利。但一问具体内容，他们并没有遇到恶劣的环境，在我看来很多谈不上是SCRUM的运用成功，只能说还没有遇到显示其SCRUM威力的地方而已。
那么什么是糟糕的项目环境呢？我先想到以下三个，如果你们想到更多，请跟贴，我看看SCRUM能否解决。
1， 客户的需求频繁变更
2， 项目组士气低落
3， 资金规模有限
SCRUM主要是为了解决第一个问题，如果运用得当可以顺带解决第二个问题，然后帮助你接受第三个问题。
需求变更相对于开发组的外部就是来自客户，这里客户是个泛指，如果是公司内部开发，那么策划人员就可以算作客户，反正谁提需求谁算客户。
一开始谁都不希望发生变更的，即使客户也是不希望发生的，大家都希望有个清晰的文档，按部就班做完拉倒。有时候开发组明知这是不可能的，于是他们的期待的是客户先给出一个大方向，然后在开发过程中渐渐细化这些需求。其实这里已经开始埋下隐患——由于需求并不清晰，所以对工作量的需求同样是不清晰的，之后的‘细化’极可能被演变成‘变更’。为了一个词去争论的事情多得不胜枚举，开发组认为是‘变更’，而客户能举出好几个词（polish, jump, improvement, 甚至debug也算）来夺取道德上的制高点，拒不承认‘变更’。
客户天生就是提需求的，同时对产品缺乏细节概念，更糟的是一边开发一边展开想象的翅膀自由翱翔，在翱翔的过程中产生无数灵感。甚至鼓励开发组员一起翱翔。但很快开发组员就对翱翔失去了兴趣，他们只希望谁能来把客户这个翱翔的翅膀收下来。渐渐的，开发组员对于项目管理人员‘好坏’的定义变成了谁能搞定客户的灵感就是达人，有些管理人员只能想方设法和客户套近乎，然后含沙射影的指出“您的某某提议不太可行，是否再考虑一下？”。形成这样的现象很多人认为是正常的，理由来自于那句“客户是上帝”，客户真的是上帝么？但是，为什么这个上帝对自己要的东西缺乏那么多的了解呢？这个上帝只是出钱或者代表了出钱的人而已，所以把客户捧成上帝的根源只是把钱当作上帝。
我们都知道这个客户并非真正的神，他不可能无所不知，开发组员把怨气出在这个客户的无知上其实是不对的。因为如果开发组员期待一个“很懂，很有远见”的客户出现，那么和等待“神迹”没什么两样。
对当今变化迅速的市场来说，半年的开发时间内就可能遇到竞争对手拿出新创意和新想法，于是别人的新想法也会冲击到自己正在进行的项目设计上。即使没有竞争对手的产品来影响客户的想法，客户自己随着产品的日趋成形，也会冒出‘灵感’来‘完善’和‘改进’产品，如果客户不这么做，拘泥于‘当初说好这样，所以只能这样’的约束，结果很可能是这个产品还没有上市就要被淘汰了。那么有没有预见性特别强的客户呢？当然是有的，但是这样的客户是可遇不可求的，更何况，再强的预见性也是有时限的，来个两三年的开发周期也很正常，当初哪个‘上帝’能预见到两三年后市场的变化和自己想法的变化呢？前者也许预见起来还稍微容易点，而后者是不可能预见的。
既然如此，对于开发组来说就要理解需求变更其实是常态，需求不变更反而是理想主义。
我们真正需要的不是好的客户，而是好的机制来对应需求变更。SCRUM正是为此而生的。
在公司里讲到这里的时候，有些同事会问：老白，你是不是要说什么加强沟通之类的话了？
不，在我看来那是屁话，废话。先不说沟通本身也是要成本的（时间成本，茶水成本，打印成本，翻译成本……），关键是具有不同知识背景的客户和项目组沟通困难是显而易见的，项目组花费大量时间给客户解释为什么你的需求不可行，客户花费大量时间给项目组解释这个需求多么重要，项目组骂客户你们为什么一开始不想到这种需求并写进文档，客户说这不是和你们讨论嘛……最后大家精疲力尽还是你要什么就什么吧。
在我管理的项目中，如果项目组员有热情参与客户的需求讨论，那是最好，如果不愿意也无所谓。客户本来就是提需求的，客户的需求可以认为代表着市场方向，客户的出发点是从市场方向来主导的，而项目组出发点是迭代啊底层啊客户端啊服务端之类客户听不懂的单词，在两者知识结构差异下，这种沟通经常就是鸡同鸭讲。
很多项目管理会采用一个简单粗暴的手段来解决需求变更，就是规定一个时间点，一刀砍下，很早就告诉客户，那个时间点以后不要再变更了。显然时间点定的越早，项目组越高兴，但客户越不满意，因为他们无法对应市场或者自己的灵感来‘改进’产品了。
这个方法不能说没有用，但并没有解决问题，因为那个时间点之后的需求就禁止变更了，只是把矛盾累积到最后去了而已。先不说扯皮扯出那个时间点是个很费口水的事情，就算达成了那个时间点的共识，过了点以后，客户往往还是不甘心，还是会以各种各样的理由来把自己的变更加进去。
那么还是那个问题，依然是需要一个机制来对应需求变更。
本帖一共被 2 帖 引用 (帖内工具实现)
印象中这个似乎有一个认证的
2天的课。讲的一般般，其实不如听我讲，哈哈。
总结上一篇，简单概括就是说，需求变更是不可避免的，可以认为是常态，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 帖 引用 (帖内工具实现)
您继续，我对和客户打交道这事总感觉是欲说还休。多年来领导们总说我写代码太浪费了，但我对XX经理、总监的职位一直提不起兴趣。
感觉说到目前为止，你描述的scrum和其他agile开发，比如xp没什么区别，呵呵。
后面的过程也是有区别的，耐心点。
另外，敏捷原则下各种方式并没有本质的区别。
现场客户，时间盒子，技术人员负责工作量评估，客户负责任务选择。强调尽可能多的减少管理人员和管理成本，让合适的人干合适的事，这些就算是基本原则了，大家都插不多。
但是不同过程在具体应用中有比较大的差别。scrum向传统的重型过程妥协的比较多一些，所以比xp更容易接受和实施。 比如scrum中的测试理论上还是可以安排传统的方式去实施的，这点是xp在很多公司很难被接受的地方。基本上scrum和cmm模型里面的2-4都可以吻合的比较好。xp就相对困难了。
另外scrum的需求方面和xp差别比较大，backlog就是一句话， xp至少userstory 背面还要写确认测试。怎么去run这个部分，就是各人自己理解了。po不负责任的时候，这句话就搞死人了，之前就是这样的。当然如果po不负责任，xp也一样完蛋，不过xp里面要求po负责写确认测试，这样至少会逼迫po认真思考他要想要做什么。相对来说scrum这部分随意性更大一些。
楼住能否加快进度？你们要兴趣弄个qq群，我们可以进一步讨论。
上一篇讲了poker-plan。理论上，应该是先讲STORY的，因为先有story在前，再有poker-plan的，总是先PO说明要什么东西，然后TEAM再给价格嘛，很合理。但是我为什么先写poker-plan呢？
因为实际情况里，由于story是需要PO写的，PO经验不丰富，对技术细节不了解，所以通常story写的不好，在Poker-plan前写的story经常是废纸。其实这也是很正常的，PO不懂具体技术，于是在pork-plan会上被当场问死，甚至在TEAM的提问中当场发现自己设计自我矛盾的情况也非常多。我自己家里装修的时候，我自己做设计，施工队问我具体某个角落的细节设计，我突然发现从来没想到过这个问题，于是当场懵掉，最后我会丢下一句，你们自己看着办。如果在pork-plan会上，PO丢下类似于“你们自己看着办”之类的话，TEAM最好拒绝这个story，如果PO坚持有些细节由TEAM自己做主，那么最好也写上XX细节由TEAM自己做主。将来有凭据。
对于程序来说，逻辑上也许遇到这类事情可能还不算多，但凡涉及美感的东西，这种情况就比较多了，PO在看到实物之前想象不出效果是很正常的，而好看不好看这样的事情每个人的理解更加千差万别，我通常在PO里面安排一个美术总监之类的人物，他可以画好mockup或者concept来明确具体实现后的效果，其他PO也可以先有个了解，这样story就比较清晰,TEAM也容易估价。同理，装修之前画个效果图会比较好，不会画就请人画，仅仅丢下一句“弄的好看点”最后是要吃苦头的。
总之，story的填写，其实是在Poker-plan会上真正完成的。如果某个SCRUM项目说他们的story都是在poker-plan会之前就填完了，然后Poker-plan会议无比和谐顺利的进行估价，那么我看只有两种可能，一，你们PO确实很强，很有经验。二，你们poker-plan没好好开。后者居多。
因为就我观察，poker-plan会议有一种虎头蛇尾的倾向。
当PO觉得很多细节他没能仔细考虑的时候，他（们）有一种‘做出来再看看’的倾向。
而TEAM觉得PO没有讲（想）清楚的时候，他们有一种‘不一定是我做这个story，我不必问那么清楚’的倾向。
当大家有点疲惫的时候，这个会议就有潦草结束的倾向。PO草草解释，TEAM糊里糊涂估价，累积下来的问题会在未来爆发出来。
这种恶化的倾向是正规的SCRUM认证培训里不怎么提到的。幸好，SCRUM本身却有个机制恰好可以缓解这种倾向。这就是自我学习过程，后面会提到。
SCRUM中对客户（PO）是有点要求的，甚至是有挑战的。排列优先级是其中之一。为什么说这是挑战呢？因为每个Story都得排出优先级来，听起来容易，实际蛮难得。举个经典例子：令堂和令爱同时落水，您先救哪个？难以决策吧？但是一定要决策，痛苦的决定是PO必须下的。但这还不是最困难的情况，因为理论上，这两个story（救令堂和救令爱应该是两个story）的价格是一样的，反正都是下水一次，您要是喜欢令爱多一点，就不用犹豫了。
有了成本的区别以后，就更加难以决策了，例子生活中很多，还是说装修，具体到这种卧室门板的材质，一般客户最早的设计大纲里面多半没有写，就算之前讲了个材质，等具体做到门板早就新想法了。此时PO提出两个story，一个是实木的门板，想想就觉得爽。另一个是夹板贴面的，想想就知道手感一般了。好了，如果没有SCRUM，大概客户已经开始说实木门板多么重要了。现在不然，先poker-plan一下，价格出来了，实木的20点，夹板的5点。显然这两个story互斥，只能选一个，选吧，敬爱的上帝。难题已经丢给了上帝，现在上帝做什么样的决定开发组都不应该反对了。（刚才风北客也总结了一句：技术人员负责工作量评估，客户负责任务选择）
情况一：PO一开始先选了个次的，做完以后实在觉得不能忍，又要改做实木的，看，典型的需求变更哦。没关系，再花20个点。最后，花费了25个点做了两个门，扔掉前一个。对于开发组而言意味着白做一个门（但5个点的“钱”还是收到的），更心痛的是PO，他们白白浪费了5个点，这5个点是一去不复返的。不过，当PO决心推翻前一次选择的时候已经痛苦思考过了，既然他们认为还是推翻更加值得（即使浪费5个点也在所不惜），那么理所当然要尊重他们的选择。
情况二：PO一开始尽挑好的上，先选择了高价的实木门，最后发现没钱买木门套了，只能买个塑料门套了，效果上还不如当初搞个夹板门外加木门套呢。这种情况对于不成熟的PO也会很常见，原因有二，1，PO的心理还在上帝的位置上没有下来，不珍惜point（钱），花到最后没钱了 2，确实是PO没有规划好，没有留足木门套的钱。
当然这是比较极端的说，PO再蠢也不至于到最后一天才发现木门套钱不够吧，常理下，当PO发现钱不是很多的时候，就已经重新开始调整优先级了，比如实在想要木门套，看看能不能在地板上省点，用个便宜的。好的PO，在一开始就不断数自己剩下的point，从而不断调整自己story的优先级。
story永远是做不完的，甚至是不需要做完的，但只要有了优先级就行，如果PO珍惜point，那么他精心挑选下排列的优先级，一定是代表着他（们）心目中最有价值的产品feature了。
但优先级里面还有一个不是PO能够决定的情况，就是当story出现互相依赖。那么被依赖的story只能先进行，也就是说，PO排完优先级以后，TEAM要从技术角度调整一次。这种依赖关系TEAM应该在poker-plan的时候就提醒PO，如果可能，可以把有依赖的story打包合并，但不是必须（后面还会提到story不宜太大）。
小结：
1，优先级是在story有了point以后才能排列的。
2，未进行的story的优先级是可以不断调整的。
3，优先级里已经考虑了story的依赖关系
本帖一共被 2 帖 引用 (帖内工具实现)
你总结的蛮好，我感觉SCRUM对于PO要求更低一点，更加适合对开发完全不懂的人来做PO。这也就是要安排SM的原因之一。
我QQ不常用。MSN是[email protected]
恭喜：你意外获得【通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望
我们在这个帖子里面玩儿个角色扮演怎么样？预设一个项目，然后各自扮演客户，SM，想想都好玩，老白你是楼主，还有代码老哥，软件工程这个坑你们带头刨出来的，组织一下吧，呵呵，越想越兴奋了。
ps：老几位慢慢儿想着，小羊先去面壁。。。
既然你问题中问了‘总’，那么就是两个‘总’相乘。我一般是1个人周算10点，那么10个人的开发组干24周（约半年）就是240个点。
我最大的一个项目是70多个人干了1年，你算算多少点？
呵呵，好不容易碰上个不花钱的培训老师，小羊就敞开了问了阿
我现在手头有一个正在接洽的项目，不算小，甲方没有具体的截止时间要求，目前是提出了一个纲要性的需求，这种情况下，是不是我们按照这个纲要性的需求定义项目参与人数和项目周期？