主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
家园 【原创】闲聊敏捷开发——SCRUM（三） 上一篇讲了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 帖 引用 (帖内工具实现)家园 关于排列优先级，是否可以用Pareto Voting Pareto Voting：基于二八原则。也就是说有10个Story，会有80%的人投票给其中的2个。那就把这2个给排成最高优先级。然后以此类推，排出所有优先级。
家园 优先级不是投票得来的 优先级是PO决定的，不是TEAM，TEAM只能报价，PO决定“买”什么以及“先买什么”，所以不涉及投票一说。
家园 开发者将责任推给用户，而已。 用户要是能清楚自己真正需要什么，能描述出来还要你们干什么？
家园 现在我遇到的问题是PO根本不在乎POINT 因为我现在这个项目是个内部客户项目，最大的领导已经下了死命令必须在年底完成，但并没有说具体要完成哪些需求。所以PO有恃无恐，知道最后的验收只能由他来决定是否通过，所以他只管不停地提出各种需求变更，至于开发团队能否完成不是他考虑的事，就算完不成，最后的板子也不会打在他的屁股上，所以连Poker-plan都开不起来，不过这种恶劣的项目环境恐怕就不是软件工程所能解决的了。
家园 存质疑的还是这个us 在scrum里面就是backlog item，就一句话，比xp的us简单的多得多。 细节全靠你问我答。
用mock是个好办法，这也是我们以往在传统过程里面就比较注重的需求沟通方法。但是对于一些po，他们会感觉这个工作量太重了，不乐于去做。
另外一个是验收条款，这个怎么写，粒度如何控制，是个问题。每次的planning game之前都是有意愿push po去写得，但是往往开到后面已经完全精疲力尽，不知所云了。这方面希望听听你的意见。
agile能否做好大的内容就在2个方面，一个是开发人员内部能否沟通顺畅，人尽其能。另外一个就是这个需求问题，如何做到和客户代理的高效沟通。
我觉得你可以再充实一下，现在内容还不够，再加点。
家园 北风客兄能否展开谈谈XP,正好可以和SCRUM对比来看. 花您.
家园 backlog item只是story的标题而已 答疑：
具体的story内容要写清楚，在poker-plan会上一问一答是正常的，但互相了解清楚以及story内容调整完毕了以后要写下来的。
我举个例子：
PO写下一个STORY
ID 1234
Title：替换下拉菜单按钮颜色
Description: 把所有页面上的下拉菜单按钮都换成浅咖啡色，而不是现在windows默认的灰色。
Acceptance tests:下拉菜单按钮颜色换成浅咖啡
这样的story就很像PO写出来的，他们首先认为并不复杂，其次他们认为已经讲清楚了。
于是开始poker-plan了，TEAM一上来至少会问两个个问题：
1，到底有多少页面？PO回答根据现在的设计有55个页面，每个页面都有2到3个下拉框。
2，浅咖啡具体是什么颜色？PO立刻拿出一个颜色样板来，TEAM用工具读出后告诉他这是＃996600，但PO说我现在也不确定这个颜色配上去是否合适，具体作出来看，不好看再调整一下。TEAM说不接受这种模棱两可的“调整”，万一将来调整成了每个下拉框颜色都不一样，工作量完全不同。所以“调整”一词不接受写入STORY。将来如果PO需求“调整”，将以另一个STORY的形式出现。
于是STORY的description更改为：
替换现有55个页面的下拉框的颜色，每个页面下拉框2－3个，颜色替换成＃996600。
然后开始出牌了，假设TEAM有三个网页程序员，出牌后点数分别是：
A：1，B：3，C：5
差距很大，开始讨论
A说，这只是html更换一小段而已，半天足够了。
C说，这种下拉框还颜色html本身不支持，需要另外写JS的，
B说，同意C的，需要另外写JS，不过应该有现成的JS可以找到。
第二次出牌：
A：5，B：3，C：5
差距缩小，A和C表示他们不确定哪里能找到现成的JS，打算自己写，所以出5，B表示他有把握找到，所以出3。
没有必要再出了，平均点数为4.3。SM宣布最终点数为4.3。
有些SM不接受这种带小数的，直接采用多数票，SM宣布最终点数为5，也可以，这不是很关键。
这次poker-plan起到了好几个作用，
第一， PO了解了这个story的工作量，比他预想的大。
第二， A成员的经验值增加了
第三， 由于PO事先没有画MOCK，自己也不确定将来是否要调整，可能导致做出来还要另外加调整的story（额外支出），相比这种可能的额外支出，PO下次提类似要求前可能会先MOCK一下，尽量确保最终需要的细节（比如颜色）。于是PO的经验值也涨了。
第四， SM记录下了ABC的出点，将来工作分配，倾向于分给B。
我认为，这就是一次成功的Poker-plan。
PO将被“逼”着完善自己的细节设计，否则poker-plan会上会很难堪。
高效的沟通取决于沟通前的功课是否做好了，如果按照上面那个例子的方式去开Poker-plan，就会逼迫PO去做会前功课。
通宝推：我爱我家fh,
本帖一共被 3 帖 引用 (帖内工具实现)家园 嗯，我们过程确实有问题 我们的estimation是在 planning game之前开的，那个时候大部分人对任务的工作量不会有清晰的认识。
另外pg里面虽然有不断问答的过程，但是没有逼迫po把验收标准写下来。现在我们的要求是开发人员来写test plan和验收标准，非常ft的做法。完全是偷换概念。
我觉得这个地方是scrum的一个弱点。他并没有清晰的定义如何做这个，backlog就一句话。各个团队实施的时候自我选择如何去解决需求的沟通问题。所以往往导致po和manager都觉得按过程，该做的他们都做了。现在是开发人员的问题了。
agile过程比较头痛的一点，就是如果角色定义不清晰，有些关键问题上，往往问题双方都认为自己是ok的。争论的地方很多，传统瀑布这方面就简单多了。按我理解，agile的出发点是考虑高效的团队必须彼此互相信任，所以这个角色定义可以在此基础上沟通解决。但是中国人的本质就不match这一套。
家园 scrum don't define anything. you need to develop your own scrum practice for your team.
