五千年(敝帚自珍)

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

共:💬141 🌺325
分页树展主题 · 全看首页 上页
/ 10
下页 末页
    • 家园 【原创】闲聊敏捷开发——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的依赖关系

      下一篇


      本帖一共被 2 帖 引用 (帖内工具实现)
      • 家园 关于排列优先级,是否可以用Pareto Voting

        Pareto Voting:基于二八原则。也就是说有10个Story,会有80%的人投票给其中的2个。那就把这2个给排成最高优先级。然后以此类推,排出所有优先级。

      • 家园 开发者将责任推给用户,而已。

        用户要是能清楚自己真正需要什么,能描述出来还要你们干什么?

      • 家园 现在我遇到的问题是PO根本不在乎POINT

        因为我现在这个项目是个内部客户项目,最大的领导已经下了死命令必须在年底完成,但并没有说具体要完成哪些需求。所以PO有恃无恐,知道最后的验收只能由他来决定是否通过,所以他只管不停地提出各种需求变更,至于开发团队能否完成不是他考虑的事,就算完不成,最后的板子也不会打在他的屁股上,所以连Poker-plan都开不起来,不过这种恶劣的项目环境恐怕就不是软件工程所能解决的了。

        • 家园 这种情况下,SM必须获得最大的领导的支持

          你这种恶劣的情况非常常见。

          内部项目的PO是什么?无非就是另一批更高级领导雇佣的人。其实内部项目更容易用,关键在于说服最高领导。

        • 家园 你这情况跟agile没一点关系了

          不过你能做的事是要让po明白现实,如果最后什么都拿不出来,大家一起倒霉。

          • 家园 如果最后什么都拿不出来,倒霉的只有我们

            说白了,这个项目对PO只是个锦上添花的东西,成功了最好,不成功也无所谓,但对我们就是只能成功,不能失败,我们的痛苦就在于此。

      • 家园 存质疑的还是这个us

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

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

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

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

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

        • 家园 北风客兄能否展开谈谈XP,正好可以和SCRUM对比来看.

          花您.

        • 家园 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 帖 引用 (帖内工具实现)
          • 家园 嗯,我们过程确实有问题

            我们的estimation是在 planning game之前开的,那个时候大部分人对任务的工作量不会有清晰的认识。

            另外pg里面虽然有不断问答的过程,但是没有逼迫po把验收标准写下来。现在我们的要求是开发人员来写test plan和验收标准,非常ft的做法。完全是偷换概念。

            我觉得这个地方是scrum的一个弱点。他并没有清晰的定义如何做这个,backlog就一句话。各个团队实施的时候自我选择如何去解决需求的沟通问题。所以往往导致po和manager都觉得按过程,该做的他们都做了。现在是开发人员的问题了。

            agile过程比较头痛的一点,就是如果角色定义不清晰,有些关键问题上,往往问题双方都认为自己是ok的。争论的地方很多,传统瀑布这方面就简单多了。按我理解,agile的出发点是考虑高效的团队必须彼此互相信任,所以这个角色定义可以在此基础上沟通解决。但是中国人的本质就不match这一套。

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


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

Copyright © cchere 西西河