主题:【原创】闲聊敏捷开发——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去做会前功课。
本帖一共被 3 帖 引用 (帖内工具实现)
- 相关回复 上下关系8
压缩 2 层
🙂如果最后什么都拿不出来,倒霉的只有我们 颓废客 字122 2009-06-14 01:09:46
🙂存质疑的还是这个us 2 风北客 字570 2009-06-10 09:18:37
🙂北风客兄能否展开谈谈XP,正好可以和SCRUM对比来看. james 字5 2009-06-19 11:57:25
🙂backlog item只是story的标题而已
🙂嗯,我们过程确实有问题 2 风北客 字719 2009-06-11 20:36:55
🙂scrum don't define anything. tubie 字58 2009-06-11 22:22:53
🙂你提到的其实是SCRUM的自学问题 哈酷 字43 2009-06-12 03:27:30
🙂角色问题非常重要 1 哈酷 字161 2009-06-11 22:17:30