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

纲要性需求只能给出概略的人数和周期。

但是说清楚这是概略的，因为甲方没有提供详细的需求，所以无法提供准确的人数周期，这个甲方应该理解。

如果你打算采用SCRUM管理，必须要求甲方派能负责的PO过来。

同时告诉对方几个好处：

1，开工后接受任何改动（对方会很高兴的），

2，随时可以要求交货(而且提前交货可以少收他们的钱）。

3，随时可以看到可用版本。

如果对方完全不懂SCRUM，最好上门给对方讲解一下，这是对双方都好的方式。

我的经验是如果用中文讲，花一小时吃个午饭基本上可以讲清楚了。

如果是英文，大概要吃三次午饭。

• 先看

按消费点数计算？

如果碰到的客户没有这么高的素质就麻烦了。

这样的合同以前也有的，多少人给你干多少时间，反正甲方有PO现场驻扎。

有水平的SM可以缓解PO的素质问题。

经历几个po是技术出生的，头很痛，明明脱离开发一线很多年了，就算做开发时技术也不咋样。最怕这种站在技术人员角度的上人来谈需求了，有时候很难建立信任关系，他往往会主动帮你评估需求和技术实现。随口一句话，老子又不是没做过，就够玩得了。

在scrum里面就是backlog item，就一句话，比xp的us简单的多得多。 细节全靠你问我答。

用mock是个好办法，这也是我们以往在传统过程里面就比较注重的需求沟通方法。但是对于一些po，他们会感觉这个工作量太重了，不乐于去做。

另外一个是验收条款，这个怎么写，粒度如何控制，是个问题。每次的planning game之前都是有意愿push po去写得，但是往往开到后面已经完全精疲力尽，不知所云了。这方面希望听听你的意见。

agile能否做好大的内容就在2个方面，一个是开发人员内部能否沟通顺畅，人尽其能。另外一个就是这个需求问题，如何做到和客户代理的高效沟通。

我觉得你可以再充实一下，现在内容还不够，再加点。

至少在业务上要比你明白。如果你觉得他素质达不到要求，反过来就说明你素质不够，至少沟通能力不够，呵呵。当然了，个别情况也可能你确实比他更明白，这个时候就要要求他可以承担起责任，拍板还是要他做得。客户么，总是可以引导的。

我觉得po做的好不好，关键在于他的责任心，以及是否能和团队建立信任关系。彼此如果缺乏信任，沟通成本就会大幅度上升。 以我们某个PO为列，从来不跟我们做交流，也不参加我们的任何晨会和一些内部沟通会议，做出来的东西他看不上，也基本不检查。一星期都说不上2句号，能建立信任关系才怪。

如果说是业务水平，我不认为PO应该比开发的人高。PO应该是市场导向上的水平比开发的人高，也就是说，按PO说的需求做更容易赚到钱——所以资方才会放心让他来提需求。

说到业务水平，PO应该相信开发人员水平高，如果不信，Poker-plan会上对答几次就自己知道斤两了。

你们的PO不来交流？poker-plan会来不来？他不来，他的story就没有被估过点数，也就不会有人开始干，他不着急？

信任问题么，PO一开始肯定是信任开发组的，否则一开始就不会有这个项目。我们去店里买东西，一开始就是信任这家店不会骗我，我才进去付钱的，一个道理。

如果合作后出现不信任，那是合作中的问题，不是一定是PO造成的。

怎么和搞文史的一样，转弯抹角的东西太多了，再看1000字，还没到正题，想给你100个砖头

中国有句俗话：隔行如隔山。所谓用户需求的变化，我认为不是真正的变化，而是软件人员对真正客户需求的捕捉过程，以想当然的态度看待问题，对另一个领域貌似微不足道的关键部分的忽略。

当然，如果真碰到客户希望软件人员帮他们开发银弹的项目，我觉得这种项目绝对不会成功

答疑：

具体的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（四）
• 刚才给风北客的例子你觉得如何？

管理学，政治学，经济学，相通的内容很多。

在SCRUM里有很多融合。很多同学可能根本没接触过Agile或者SCRUM，得从本源推导。在我看来这是个很革命性的管理方式。写出一本书来也很正常。

感觉不到多少优越性，最终还是聚焦到po上，需求的问题还是回避不了，所以你说哪么多和需求相关东西，我感觉有点多余，不好意思，要不你再给咱们加点料

项目的成功应该是和客户一起成功，而不是仅仅自己的项目成功，这是我的观点

链接