五千年(敝帚自珍)

主题:【原创】闲聊敏捷开发——SCRUM(一) -- 哈酷

共:💬141 🌺325
全看树展主题 · 分页首页 上页
/ 10
下页 末页
家园 一点不白痴,很实际的问题

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

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

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

同时告诉对方几个好处:

1,开工后接受任何改动(对方会很高兴的),

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

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

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

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

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


本帖一共被 1 帖 引用 (帖内工具实现)
家园 合同怎么签呢?

按消费点数计算?

家园 对PO的要求非常高啊...

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

家园 可以按人月算,或者人周

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

家园 下一篇讲SCRUM MASTER

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

家园 完全不懂开发的人做po应该更好

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

家园 存质疑的还是这个us

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

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

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

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

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

家园 做agile,你必须相信客户水平就是比你高

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

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

家园 这个水平不能一概而论

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

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

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

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

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

家园 搞技术的

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

家园 没看完,先说一句

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

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

家园 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 帖 引用 (帖内工具实现)
家园 不要以搞技术的眼光来看管理问题,我也不做技术很多年了

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

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

家园 具体的东西有点少

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

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

家园 刚才给风北客的例子你觉得如何?

链接

全看树展主题 · 分页首页 上页
/ 10
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河