主题：【原创】闲聊敏捷开发——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的依赖关系

下一篇

• 【原创】闲聊敏捷开发——SCRUM（二）
• 【原创】闲聊敏捷开发——SCRUM（四）