五千年(敝帚自珍)

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

共:💬141 🌺325
分页树展主题 · 全看首页 上页
/ 10
下页 末页
    • 家园 【原创】闲聊敏捷开发——SCRUM(二)

      总结上一篇,简单概括就是说,需求变更是不可避免的,可以认为是常态,SCRUM作为解决需求变更的机制应运而生。

      我的理解,最最能够概括SCRUM机制的话只有一句:

      SCRUM就是打算以市场经济体制来对应需求与供给。

      每当我说出这句话,总有人会说“老白,你也太扯了吧,有关系么?”。

      有的,我讲完以后也许你会发现哲学层面上,两者高度统一。

      客户在SCRUM项目中的角色,不是发布指令的上帝,而是购买者。上帝说要有光,于是就有了光?不对,上帝要有光,先得问问搞个光花费多少,然后上帝想想还有没有必要有光,然后再决定要不要买。在SCRUM中,这样的上帝被叫做product owner,简称PO。可能不止一个人,但是他们的声音必须是一致的,如果不一致,回去讨论完了再出来。

      在SCRUM中,PO只是购买者,市场供给者就是TEAM。PO花费的钱是未来一定时间内TEAM成员们的工作总时间,PO的需求叫做story。

      如果TEAM的人数不变,TEAM未来一定时间内的工作总时间就是不变的。把这个总时间以point来计算,发到PO手里,然后让PO用这些Point来购买他们的需求。所有的需求加在一起成为客户最后的产品。

      客户=PO,

      开发组=TEAM,

      开发组未来一定时间内的总工作时间=PO可以花的‘钱’=Point

      客户的需求=story。

      PO拿着point来向TEAM购买他们的story。

      既然是购买,那么总得有价格吧,每个story都有自己的价格,价格单位就是point。

      此外还得有个规则的维护者,叫做SCRUM MASTER

      先约定好一个point和时间的换算率,比如一个人工作1周为10个点数。那么如果TEAM里面有10个人,那么一周的总点数就是100点。我先不提其他什么factor,不重要,先就这样算。

      演出开始了。

      既然讲需求变更,那么第一个就是需求(story)能变更么?

      能啊,如果这个story还没有开始做,就可以变更,不过如果story变更了,那么价格也变更了。(塑料的把手2块钱,镀铜的10块钱。我比较喜欢用装修的例子,容易换位思考,大家其实都当过客户)

      如果这个story已经做过了,那么任何变更就是另一个story,随便你什么名字,polish, improvement, jump……,随便,都是另一个story了,另外花钱买。

      较真党问如果正在做怎么办?我后面会详细说。

      先要说一下价格怎么来?既然是市场经济体制,价格当然是市场定咯,注意,客户听到这里要光火了,TEAM自己决定?他开个天价我怎么办?等等,你怕不怕买到天价的面包?不怕,为什么?因为市场是有竞争的,不买你的可以买他的。那么我们这里的市场是TEAM和谁竞争呢?有些同学可能想到了Multi-TEAM,这个我先不说。由简入繁,只有一个TEAM的情况下,怎么处理呢?

      SCRUM是这样解决的,开一个会,叫做Poker-plan meeting,用来给PO的story进行估价。在这个会上,PO先解释自己的story,比如这个story叫做‘卧室的房门’,需求是门上用镀铜的把手,油漆用清水的,贴面用胡桃木的,门正中央有个镀铜的福字……

      如果TEAM觉得PO讲的还是不清楚,当场提问,比如,这个‘福’字要多大?镀铜的把手在什么位置,门朝里面开还是朝外面开?门套是不是一起做?……

      PO(们)讨论了一下,回答完了TEAM的问题,然后TEAM可以估价了。

      怎么估呢?每个TEAM成员自己手里拿一付扑克牌,从牌里抽出代表自己的价码的那张,说1,2,3一起摊牌。由于事先不商量,价码有高有低,通常差异很大,TEAM成员各自阐述一下理由,然后再出一次牌,如果还是差异很大,那么再商量出一次,一般不超过三次。第三次如果差异还是很大,那么SCRUM MASTER(以后我简称SM,想歪的去面壁)宣布价格为平均数,此时SM把各自谁出了什么价记录下来,将来有用的。

      这个流程基本已经过滤掉‘天价’的可能性了。在我实际项目运用中也确实如此。

      大概分析一下天价牌可能出现的几个情况:

      1, 故意哄抬物价,由于TEAM成员此时出牌并不知道这个story将来会谁做,他故意出天价牌,看不到直接好处,由于他的天价牌,倒是需要他做出技术上的解释的。所以这种情况可能性很小。

      2, 个别成员经验不足,那么第一次摊牌之后,大家商量一下,解释完了,第二次摊牌的时候这张天价牌也自然消失了,与此同时,在解释商量的过程中,这个经验不足的成员也因此学习提高了一下(这是个SCRUM的副好处)。

      3, 大多数成员经验不足,只有极个别精英成员意识到这个story不像看上去那么简单,那么这个精英会和大家解释大家没有看到的陷阱。如果能说服大家,下一轮摊牌,大家会提高点数的。如果说服不了,那么也无所谓,精英保留自己的高价牌。SM会记录下各自的出价的。

      但无论大家有没有达成共识,三轮以后,报给PO的价码只有一个。PO把刚才说过的细节写下来,然后TEAM的价格也填上去,SM作证。这个story就有点像是一个合同了(合同的交货日期不用现在定,后面再说)。

      由于是‘市场经济体制’,这个决定story价格的会议非常重要,需求在这里由价格来反映。一定要好好开,需求问题都得问清楚,写下来。之后反悔就有字据了。我的经验表明,之后绝大多数问题追根溯源都能发现是这个poker-plan 没有开好。

      总结这个poker-plan会议的要点。

      1, PO充分表达story的细节

      2, TEAM充分了解story的细节(觉得不清楚的要问清楚)

      3, 出价过程要被记录下来

      4, 价格一旦被敲定,story内容不再修改。

      5, 如果story内容要修改,这个会重开,重新估价。

      6, 如果因为其他story牵扯到这个story的价格必须出现跟进变化,这个story可以重新开会估价。

      开过poker-plan会后,相当于客户去市场上逛了一圈,了解了一下他需求的东西的价格,至于买不买,先买什么后买什么,还没有定。之后就要讲到优先级和sprint了。

      下一篇

      元宝推荐:铁手,

      本帖一共被 2 帖 引用 (帖内工具实现)
      • 家园 我觉得让多个TEAM成员来开价不太可能

        现在通常的做法都是一个功能模块只由一个程序员负责开发,那么关于这个功能模块的需求变更就只能由这个程序员出价了,其他成员都不熟悉这个功能,包括这个功能的业务领域知识和实现的技术细节都不了解,怎么出价啊。而那个负责程序员的出价显然多半是偏高的,PO一般也就无法接受了。

        • 家园 agile里的做法相反

          要避免一个功能模块只由一个程序员来开发。

          1.为了规避风险,提高truck number

          2.避免程序员形成各自为战的工作方式,强调要团队作业

          3.基于代码共同所有的原则,就算是你开发的,别人也有权利修改和维护,所以一般团队成员都兴趣也有义务去了解别人的工作。老实说这点我刚开始挺不适应,自己写好的东西,有时会突然就被别人改了,特别是被改错的时候,砍人的心都有,呵呵。后来发现这逼迫自己多去了解别人的工作,直接改善了交流。这点我发现是国内程序员特别不能适应的地方。

          agile的团队会极力回避传统开发方式在程序员之间建构的责任壁垒,建立互相信任的关系。 只要信任关系建立了,你的这些种种疑虑都可以打散。在一个崇善的环境,人人都回争着表现自己好的一面,这是agile很有意思的地方。以前在国外的时候,不同团队的老外可以放下手上的工作,化一整天时间帮你解决问题,越是牛人,化在帮助别人的时间越多,这和国内那种注重个人成绩的气氛完全相反。当然,下一次别人有问题的时候,你也就没有借口拒绝帮助,所以长期来看,还是挺好的。

        • 家园 很好的问题,很多人问这个

          开始poker-plan前很多人有这个疑虑。

          但仔细想想,恰恰因为个别程序员了解这个模块,所以他开价应该比较低,其他人开的价是假设他们来接手的价码,自然稍高,那么平均价理论上高于那个‘个别程序员’,所以,这个个别程序员选择这个story就比较划算。

          但是,如果这个个别程序员胁着‘别人不了解’而故意高开,那么就会‘暴露’。客观上,更加公平的找到了价格。

          PO了解到这个层面,就OK了。

      • 家园 这个poker-plan是否可以这样理解

        客户邀请几家供应商来共同开会。会上大家充分讨论后,各家私下讨论报价,再共同开标?那么这个SM的属于哪方的?屁股坐在哪方都很难不偏不倚吧?希望老兄能解释一下哦!

        • 家园 理解的不错

          这个SM的屁股问题我在(四)里已经开始提到,下一篇还要讲SM,鉴于PO出去强势地位,屁股表面看是偏向TEAM的。

          但是,由于他是执法者,而不是立法者,他的屁股其实是坐在规则之上。只是破坏规则的大多数情况是PO,所以这个SM的屁股表面上偏向了TEAM而已。

      • 家园 没看完,先说一句

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

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

      • 家园 送花,感觉精彩的马上就来了

        恭喜:你意外获得【通宝】一枚

        鲜花已经成功送出。

        此次送花为【有效送花赞扬,涨乐善、声望

        我们在这个帖子里面玩儿个角色扮演怎么样?预设一个项目,然后各自扮演客户,SM,想想都好玩,老白你是楼主,还有代码老哥,软件工程这个坑你们带头刨出来的,组织一下吧,呵呵,越想越兴奋了。

        ps:老几位慢慢儿想着,小羊先去面壁。。。

      • 家园 提点意见

        感觉说到目前为止,你描述的scrum和其他agile开发,比如xp没什么区别,呵呵。

        • 家园 有的,多了一个SM

          后面的过程也是有区别的,耐心点。

          另外,敏捷原则下各种方式并没有本质的区别。

          • 家园 还是有一定差别的

            现场客户,时间盒子,技术人员负责工作量评估,客户负责任务选择。强调尽可能多的减少管理人员和管理成本,让合适的人干合适的事,这些就算是基本原则了,大家都插不多。

            但是不同过程在具体应用中有比较大的差别。scrum向传统的重型过程妥协的比较多一些,所以比xp更容易接受和实施。 比如scrum中的测试理论上还是可以安排传统的方式去实施的,这点是xp在很多公司很难被接受的地方。基本上scrum和cmm模型里面的2-4都可以吻合的比较好。xp就相对困难了。

            另外scrum的需求方面和xp差别比较大,backlog就是一句话, xp至少userstory 背面还要写确认测试。怎么去run这个部分,就是各人自己理解了。po不负责任的时候,这句话就搞死人了,之前就是这样的。当然如果po不负责任,xp也一样完蛋,不过xp里面要求po负责写确认测试,这样至少会逼迫po认真思考他要想要做什么。相对来说scrum这部分随意性更大一些。

            楼住能否加快进度?你们要兴趣弄个qq群,我们可以进一步讨论。

            • 家园 基本原则差不多

              你总结的蛮好,我感觉SCRUM对于PO要求更低一点,更加适合对开发完全不懂的人来做PO。这也就是要安排SM的原因之一。

              我QQ不常用。MSN是[email protected]

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

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

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


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

Copyright © cchere 西西河