主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

答疑：

具体的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去做会前功课。

• 【原创】闲聊敏捷开发——SCRUM（五）
• 【原创】闲聊敏捷开发——SCRUM（四）
• 刚才给风北客的例子你觉得如何？