敏捷开发扑克牌_敏捷扑克牌 - CSDN
  • 用于敏捷开发的Scrum开发团队估计故事(Story)的故事点(Story Point)。 计划扑克玩法 参加游戏的开发人每人各拿一叠扑克牌,牌上有不同的数字。客户或者产品责任人为大家挑选 1 个 Story(Backlog),并简单...

    计划扑克介绍

    所谓“计划扑克”(Planning Poker)是一种标有一系列数字的扑克牌。用于敏捷开发的Scrum开发团队估计故事(Story)的故事点(Story Point)。

    计划扑克玩法

      1. 参加游戏的开发人每人各拿一叠扑克牌,牌上有不同的数字。
      2. 客户或者产品责任人为大家挑选 1 个 Story(Backlog),并简单解释其功能,以供大家讨论。
      3. 每个游戏参加者按自己的理解来估计完成这个 Story 所需的时间,从自己手中的牌里选 1 张合适数字的牌,并发展示给大家。
      4. 游戏参加者各自解释选择这个数字的原因,尤其是数字最大和最小的人。
      5. 根据每个游戏参加者的解释,重新估计时间并再次出牌,直到大家的估计值比较平均为止。

    得意 在这个游戏中需要注意的是:首先,这不像普通的扑克游戏,不是轮流出牌,而是大家考虑好之后同时出牌,这样就可以避免后出牌的人被先出牌的人干扰;其次,要告诉团队成员,他们需要估计所有的 Story,而不仅仅是他们自己将要做的那些部分,比如测试人员不能只估计测试工作所需要的时间。

    Unlimax的计划扑克  购买

    (消息) 一副扑克有4种花色,可供4人同时使用,如果团队大于4人,可使用多付扑克组合使用。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 每种花色有13张牌。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 0表示认为所选Story非常简单,根本不需要精力就能完成;

         ?表示根据已知情况,无法评估Story需要多少故事点;

         咖啡杯用于提示团队成员该休息了,实在太累了(吐舌)

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 大小王分别用中英文,告诉团队如何使用计划扑克估算故事点。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) Unlimax的计划估算扑克可通过淘宝网店在线 购买

    敏捷计划估算扑克 - Tennille - 观点


    展开全文
  • 转载自: ... ...(之一,之二,之三,之四,之五,之六,之七,之八,此系列之九及之后文章请见栏目总目录。...第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如
    
    

    转载自: http://blog.csdn.net/cheny_com/article/details/6587277



    本文是“松结对编程”系列的第三篇。(之一之二之三之四之五之六之七之八,此系列之九及之后文章请见栏目总目录。)

    估算是经久不衰的管理话题,大致分为两种流派。

    第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是交给领导审批;领导审批其实就是砍一半的过程,还好大家之前就已经加了一倍,所以不怕。

    第二种是自我管理派(偏敏捷),就是由具体开发的人员自己说开发工作量,领导和他人不干预。尽管“自组织”了,但是领导深以为这种方法留下了偷懒的种子,而队员也觉得某人的估算很不靠谱(太长或太短),到底怎么办呢?

    共同估算吧。

    --------------------------------------------

    基本概念

    假设现在是一个计划会上,PO(产品经理,策划组长,项目经理,某销售……)刚刚讲完需求,下一步不是交给某人做估算,而是交给某个潜在的组(师傅+1~3徒弟)。

    由师傅带头打牌,对,在计划会上玩扑克:

    1. 大家各自思考可能要花多久时间完成任务,扣一张牌出来;

    2. 师傅喊开牌,大家亮牌,比较大小;

    3. 一般最小和最大的两个人PK,说出自己的观点,大家一起讨论;

    4. 差异无非来自于两个方面:做什么,怎么做;PO参与讨论回答做什么的问题,师傅和徒弟们讨论解决怎么做的问题;

    5. 讨论过后再来几轮,直到大家觉得结果差不多了。

    扑克牌估算的匿名性和开放性保证了大家不会人云亦云,也不会因为缺少沟通而难以达成一致。

    笔者的经验是一局扑克牌估算大约持续1~5分钟,还是很快的。偶然有黄庄的,一般都是因为PO那里回答不了做成什么样子,某某附加功能是否也要做……等等问题时。

    几个问题

    1. 为什么分给组而不是个人?

    不分个人就打牌使得每个人都不得不思考,因为怕出错了牌又说不出所以然。这样即使日后他不做这个功能,也对这个功能很了解。

    2. 为什么不让最后领任务的人自己估算?

    因为他很可能因为不知道某代码可用、不知道某软件不行、不懂template(我们因此扔过1个人月代码)……而选择了错误的实现方法。

    3. 为什么不让师傅估算大家采纳,他不是最厉害吗?

    师傅的想法常常是徒弟们理解不了的——比如为什么不留在女儿国而偏偏去西天取经之类的,呵呵——共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

    4. PO怎么还参加?不是不让别人干预吗?

    很多问题比如在游戏中“显示武林排行榜”,具体工作量可能不在于怎么做而在于做什么:凭什么排名?排多少名?实时排名还是每周排名?怎么显示排名?……因此PO不能写出一堆文档,然后以不便干预估算为名不参加敏捷计划会议。

    PO可以挑战估算,比如:“这真的要这么久吗?我记得上次……”但要有理有据。其实实践中更容易看到的是,团队往往过于激进乐观,PO反而要让他们意识到完整的需求和要求,做出更现实的估算。估算不准确,PO也有责。

    5. 一直无法达成一致怎么办?

    其实估算不是为了最后那个数字,而是弄清楚做什么和怎么做的问题,如果这两件事情清楚了,但结果却是偏偏有人说4天有人说6天,随便取个数就可以了(事实是应该按墨菲定理取6天)。有师傅在,一般很少会就实现方法争执不下;有PO在,一般很少会就要实现什么争执不下。

    不排除有特殊情况比如PO发现自己也没想过排行榜凭什么排行,那么就应该搁置此用户故事;又比如大家觉得如果数据库给力可能实时排名也行但又拿不准,可以暂时搁置到开发的时候再说,但把故事上标注一下“若需要每周自动排名+1天”。如果经常黄庄,Scrum Master要分析总结避免。

    6. 四个人出牌不同,师傅先说还是徒弟先说?

    想起个脑筋急转弯:科学家 医生 士兵 护士 ……等等一群人在飞机上,飞机结冰快坠落了需要有人(可能不止一个)跳下去,问谁跳?答案是从体重最重的人开始跳,因为可以少跳几个。

    因此我们是出牌数字最小的先说,和师徒无关。因为他极有可能掌握最佳实现方法。如果后来发现不是如此,请参考下一条。

    7. 都有什么理由可陈述?

    按下面的顺序,越靠前的越接近真理,感觉自己接近真理的就一定要举手先说,马后炮招人嫌:

    经验事实:我以前做过……咱们有个类库……那个方法我试过不可行……

    蛛丝马迹:谁还记得上次……听说隔壁……与上回相比……你以前不是……

    逻辑推理:理论上说……我觉得……

    几个注意事项

    1. 小组内不要有强分工,否则大家会缺省认为肯定是某人的工作。

    2. 师傅不要太抢眼,要通过估算鼓励徒弟思考,同时也掌握徒弟的真实水平。

    3. 师傅不要太较真,编程规范、易用性、易维护性这些纪律不能放松,但如果徒弟想尝试一种不同但工作量也差不多的方法,可以适当鼓励。

    4. Scrum Master监控整个过程,防止太细/争执……等问题。

    5. PO必须参加。

    ----------------------------------------------------------

    共同估算依靠PO的参与解决了做什么的问题,依靠师傅的带动解决了怎么做的问题。

    共同估算是“跨职能团队”的基础活动之一,之后他们之所以能在每日立会上分享当前进展与困难,就是因为当初是他们一起思考这一任务的,因此对这一任务后来的实际情况非常关心。在发生问题的时候,大家也更可以互相帮助,而不是毫不所知。

    下一篇将会涉及日常工作/每日立会等迭代期内的工作。

     

    点击下载免费的敏捷开发教材:《火星人敏捷开发手册

    展开全文
  • 这是敏捷生态系统系列的第五篇(之一,之二,之三,之四,之五)。本文是2009年刚刚提出敏捷生态系统的时候参与一个MSN讨论组时的对话,当时的...“敏捷生态--Srcum敏捷开发”--msn群讨论 2009-08-25 13:52谷雨霖...

    这是敏捷生态系统系列的第五篇(之一之二之三之四之五)。

    本文是2009年刚刚提出敏捷生态系统的时候参与一个MSN讨论组时的对话,当时的想法与现在相比尚缺少系统性,但由于有问有答,也包含了本系列所没有包含的一些信息,仅供参考。

    删除了部分无关的对话。

    文章末尾有谷雨霖老师的博客地址,也在CSDN。

     

    “敏捷生态--Srcum敏捷开发”--msn群讨论
    2009-08-25 13:52
    谷雨霖 说:
    时间差不多了
    今天我们的主题是“敏捷生态”
    有幸请到的是我的老朋友,敏捷专家陈勇先生
    M群-项目管理 说:
    【系统提示】AlexQin将昵称更改为AlexQin-QC-深圳
    不胜人生一场醉-N/A-海南 说:
    鼓 掌
    dearChloe-PM-深圳 说:
    专家好
    Yong CHEN 说:
    大家好
    M群-项目管理 说:
    谷雨霖 说:
    陈勇先生在9.12的敏捷中国大会有专题发言
    他的介绍:
    TechExcel中国区咨询总监,具有13年软件研发、管理和咨询的从业经验,拥有多年敏捷开发、CMMI、度量与基准比对等多种软件过程管理咨询和培训经验。他结合企业中大规模团队的管理需求,成功导入并实施了面向100人左右大团队的最佳研发管理实践,融合了敏捷开发实践和CMMI体系。其以敏捷开发为主要内容提供过咨询/培训/专题演讲的企业包括Thomson CR / 广州从兴 / 金山软件 / 盛大网络等企业。他还在2007/2008年度中国过程改进大会及2009年中国软件技术大会上进行了《敏捷开发中的度量》、《从交付保证看敏捷开发的价值》等敏捷主题演讲。
    litao 说:
    陈老师好
    Yong CHEN 说:
    我是昨天刚来的,很高兴认识大家。
    现在就正式开始了
    谷雨霖 说:
    下面,我把时间交给陈老师。13:00听陈老师讲述
    susan-pm-湖北 说:
    鼓掌
    xiyeqing99@hotmail.com 说:
    (Y)
    谷雨霖 说:
    余下时间,提问交流
    xiyeqing99@hotmail.com改签名
    Yong CHEN 说:
    关于敏捷生态,是去年逐渐意识到的一个问题。
    M群-项目管理 说:
    【系统提示】AlexQin-QC-深圳将昵称更改为AlexQin(21)-QC-深圳
    Yong CHEN 说:
    在做CMMI咨询的时候,一直希望能把CMMI一点一点实施下去,而非一次到位。
    这样对企业的压力小,还能用已经取得的成就,去鼓舞和支持剩下的工作。
    但是一直没有成功,因为大家也知道,国内做CMMi都是阶段式的,直接一级
    完全没有做连续式的,也就是说重点做某些价值最高的过程域,以后再说其他的。
    但在国外,基本上则是一半一半。当然原因也很明显:政府给的补助,是针对阶段式的。
    所以后来逐渐转向敏捷以后,也是很想在新的领域引入连续式
    在一家南方的公司咨询的时候,我发现他们有诸多的限制,无法整体实现敏捷。
    对了备注一下:这里指的敏捷是Scrum,也就是偏管理的分支,重点内容是需求管理/项目计划/项目跟踪
    Yong CHEN 说:
    大家比较熟悉的TDD/结对编程/重构等属于关注技术的XP分支
    TonyAquarian_IT Consulting_北京 说:
    --- 系统提示: 您的联系人 aquarian - 庸人自扰已使用MSNShell 提供的加密对话功能,该功能需要双方都安装MSNShell(   http://z.xiaoi.com/r?msnshell-download-6zt818.hi5i.cn%2Fmsnshell) 以提升聊天信息的安全性,防止来自网络的偷窥行为 ---
    Yong CHEN 说:
    他们的限制主要在于:
    1. 团队内部有相当明确的分工,大家看到需求就知道是谁的
    2. 一直是项目经理说了算
    当然既然要敏捷,那么2是一定要破除的,一定要让大家自己估算自己的任务,这样才能实现承诺,进而激励工作效率
    但是1我当时就想将就一下,毕竟长期而言人们的专业分工已经很难破除了
    培训之后他们就用上Scrum了,过了2个多月,他们进行了两轮迭代,我满怀希望地前去做二次指导
    结果发现:他们开计划会议的时候,几乎同时只有1个人在做自己的估算,别人都在聊天,直到换任务(负责人也相应地换了)
    这里就出现了一个问题。我们互动一下,谁知道这种“自己估算自己的任务”的方式有什么不好的地方?
    M群-项目管理 说:
    【系统提示】aba21st@126.com将昵称更改为trriger-SQA-上海
    北京-QM-李晋James Li 说:
    没啥不好啊。
    susan-pm-湖北 说:
    缺少和其他成员之间的沟通?
    北京-QM-李晋James Li 说:
    自己估算,自己最熟悉自己能完成多少东西。
    谷雨霖 说:
    先听
    Yong CHEN 说:
    比项目经理或更高的领导直接指定时间,显然有其优越性。
    谷雨霖 说:
    不要打断
    liu.chsh@hotmail.com 说:
    “自己估算自己的任务”,成员往往多估计
    Yong CHEN 说:
    呵呵我就是想互动一下,大家插两句
    打断正常
    谷雨霖 说:
    ok;)
    依照过去打断很难收回的,哈哈
    Yong CHEN 说:
    1. 缺少沟通 2. 往往多估
    哈没事,我来控制。
    liu.chsh@hotmail.com 说:
    我认为还是互动比较好,老谷来控制
    Yong CHEN 说:
    为什么会多估呢……
    litao 说:
    也有可能为了冒进少估把
    liu.chsh@hotmail.com 说:
    没有共识,成员不能看到全面,有时也会少估计
    北京-QM-李晋James Li 说:
    能否delphi一下
    Yong CHEN 说:
    当然有很多原因:怕完不成;怕忙(偷懒)
    北京-QM-李晋James Li 说:
    说明一下估算的原因?
    Yong CHEN 说:
    恩,这样很多问题就冒出来了,我们可以看到:敏捷要求团队尽量弥合分工,尝试一起做估算。
    liu.chsh@hotmail.com 说:
    多估:主要是想骗PM
    少估:主要是不全面
    Yong CHEN 说:
    好的,剩下的问题:为何要估算?
    简单的原因是:需要一个数字,知道多少天多久
    dearChloe-PM-深圳 说:
    排计划呀
    xiyeqing99@hotmail.com 说:
    pm这么好糊弄啊
    Yong CHEN 说:
    复杂的原因可以分为两种:R问题和D问题
    liu.chsh@hotmail.com 说:
    虽然不好,但是他们还是想这么做
    北京-QM-李晋James Li 说:
    我们的主要问题是怎么估
    story point
    Yong CHEN 说:
    一个PM或高级领导是容易糊弄的,下面我们马上会发现有一些人是不能糊弄的:同行,队员,伙伴
    liu.chsh@hotmail.com 说:
    做WBS,评价自己多年的经验
    Yong CHEN 说:
    这是敏捷计划的精髓。Scrum计划尝试解决R问题和D问题
    liu.chsh@hotmail.com 说:
    在影响整体进度的情况下,参考一下 资深 成员
    Yong CHEN 说:
    所谓R问题就是:这个需求说的是什么?实现到何种程度?标准如何?0缺陷吗?等等
    这个是需求问题
    在Scrum计划会议的上半截,Product Owner要给大家统一讲解需求,有问题的人随时提问。
    剩下的事情是:谁会有问题?当然是任务的负责人。而我这个客户由于前面说的原因,提问的人就一个人
    自然也只有他彻底明白了任务的需求,而其他人事不关己,高高挂起。
    有时其他人也听到了一些有有疑惑的东西,但既然负责人都说明白了,我还要问什么呢……也就不问了,就埋下了隐患
    计划的第二个问题,是D问题(设计问题):这个需求用什么方法实现最好?有没有现成的代码可以复用?完全复用,还是需要改动一下,还是改动也没用因为留有后遗症?
    很可惜,D问题不是那么好解决的。
    比如如果我是一个高手,来了一个新手,我想知道他怎样实现“排行榜”功能,怎么办?
    当然我可以让他说说他打算干什么,可惜程序员都不擅长言谈:D
    Yong CHEN 说:
    计划会议上也难以让他把整个实现思路讲一遍
    这时候,就需要用别的方法了,那就是“CRC32”校验
    不知道大家了解CRC32校验不
    dearChloe-PM-深圳 说:
    不了解
    Yong CHEN 说:
    要想了解一个文件(或某短信息)是否是完整无损的,最简单的方法是把文件存两份(或发送两份),比较一下有无差别。
    (R)(L)China_Iverson(R)(L) 说:
    程序员都不擅长言谈?至少能说清楚吧
    Yong CHEN 说:
    但这样实在太费空间时间了,所以科学家们发明了一种方法:
    先说个简单的:就是把文件所有字节加起来(溢出超过256的不要了),把这个校验和放在末尾。
    收到文件后,重新计算一下文件的校验和,如果一样,“多半”表明没有错误。
    CRC32比校验和厉害一些,但原理相同。
    估算就是这个目的!
    03年我做项目经理的时候就是这样
    每天早上20分钟给大家讲讲需求和设计,然后挨个问一个问题:
    你今天听了需求和设计,打算写多少代码?
    他们就用手比划:2个屏幕,还是5个屏幕
    如果我感觉和我想的差不多,就过;如果差别很大,就问问屏幕里边有什么
    用这种方法,只要几秒钟,就能对上暗号,“多半”他没有听错想错,也不会做错。
    说的太多了,有没有说的不清楚的地方?
    chinamath(海茶)-Sr.SE-北京 说:
    这个方法好。
    dearChloe-PM-深圳 说:

    Yong CHEN 说:
    当年也是个编程高手,我说说曾经“杀代码”的经历,大家就知道估算的重要性了
    01年,110行杀到50,第一次杀,上瘾了
    还是01年,4000行杀到400行
    02年,4000行杀到50行(那个程序员干了一个月了,一个下午被杀到50行)
    04年,别人杀代码的记录:10万行杀到1.3万
    在4000杀50那次后,我在想:怎样让这个程序员干活之前,他的项目经理就知道他要做错事呢……(当时我是EPG的)
    所以在03年我又重新管理项目,实践出了上面那种方法。
    好了,R问题和D问题都解决了,剩下的是:刚才说过,任务都有一个负责人,别人怎么才能替他关心他的R和D问题呢?
    在那个客户那里,采取了两次步骤
    前几个迭代,小组长(手底下有3/4个人)和那个人一起打牌(计划扑克,不知道大家了解不?)
    我闪屏就是有问题啦,呵呵
    也就是让小组长和手下具体负责人一起计划
    后几个迭代:先把任务分配到小组(3/4个人)不指定具体负责人,先估算,再分配。
    这样大家不确定是否是自己的事情,不敢怠慢,都会用心得提问需求问题,用心地讨论实现方法
    讨论过程中很快发现,有些需求没有想到,有些方法是错误的
    比如有个程序员低估了任务,因为他说有个库拿过来就能用,另外一个程序员就告诉他:那个库很难用,自己试过,还不如重新写一个。等等。
    当然,大家用计划扑克的方法,如果大家数字相同,不会讨论直接通过,有人太多或者太少,才会讨论。
    这样大大节约了时间,又达到了目的。
    好了说了这么多,回到主题:敏捷生态
    通过刚才的例子,我们会发现敏捷这里就直接说Scrum把:是一个经过实践总结出来的方法
    他们当年也一定遇到过类似的问题,所以才说:尽量不分工,而是建立跨职能团队,“所有人干所有事”,才能取得良好的计划效果
    如果把跨职能团队去掉,仍然开计划会,仍然有PO,仍然让大家自己估算自己的任务,效果就很差了。
    这就如一个生态系统,各个部分是联动的,不能轻易去掉其中一个。
    哦对了解释一下另外一个问题:如果有3个人一起估算,这时候就会产生“同行压力”,没有人想证明自己是“笨蛋”,所以他们不会故意高估任务,因为自己的同事(技术背景/职位相同)在和自己一起估算
    dearChloe-PM-深圳 说:
    那怎么办呢?
    Yong CHEN 说:
    别人说2天能完,自己偏说4天,显然有问题。要知道这个工作还没有分配,未必是自己的工作。
    这种同行压力效果比领导压力好,因为领导不懂,很容易糊弄,呵呵。
    什么怎么办?如何对待生态系统?
    dearChloe-PM-深圳 说:
    我是说,因为同行压力,大家会不会都少估呢?
    Yong CHEN 说:
    了解了生态系统,就会知道:要上敏捷,尽量完整地接受敏捷,而不要卡在中间,效果不会很好的。
    谷雨霖 说:

    Yong CHEN 说:
    不会的,无论高估还是低估,都要给大家解释原因。
    dearChloe-PM-深圳 说:

    Yong CHEN 说:
    敏捷中计划扑克的玩法是这样的:
    (R)(L)China_Iverson(R)(L) 说:
    我觉得应该不会少估吧,因为有可能是自己会开发的
    Yong CHEN 说:
    1. 讲解需求和提问,直到没有问题
    2. 几个人一起扣着出牌
    3. 翻牌,最多的和最少的PK,除非他们差别很小
    4. 大家听他们两位PK(一般一位会“占理”一些),回到2
    5. 中间有任何对需求的分歧,PO解释(有时候PO也解释不清楚,这个需求显然还太模糊)
    在这个过程里边,人们显然不愿意故意高估或低估(PK中很难给大家一个满意的答案的)
    而寻求真是结果的愿望会占据上风。
    (R)(L)China_Iverson(R)(L) 说:
    估算的时候是是不公开的吗?
    就是说扣着牌的?
    Yong CHEN 说:
    对,先扣着出牌,然后一起亮牌
    susan-pm-湖北 说:
    是怕从众吗
    Yong CHEN 说:
    对啊
    xiyeqing99@hotmail.com 说:
    这方法好?
    (R)(L)China_Iverson(R)(L) 说:
    就像评委打分一样?
    xiyeqing99@hotmail.com 说:
    Yong CHEN大哥 怎么被你想到的啊
    Yong CHEN 说:
    这其实就是Delphi的变形,Delphi也是匿名的,但是太慢了。
    晕,不是我想到的
    谷雨霖 说:
    对 delphi增强版
    xiyeqing99@hotmail.com 说:
    哪位牛人想出来的啊
    这么好的主意
    Yong CHEN 说:
    http://z.xiaoi.com/r?www.planningpoker.com%2F
    xiyeqing99@hotmail.com 说:
    哈哈
    Yong CHEN 说:
    老外想到的
    敏捷生态是我想到的
    xiyeqing99@hotmail.com 说:
    老外确实有2把刷子啊
    你也有几把刷子 呵呵
    litao 说:
    不过还是有问题的,如果时间长了大家都可能在自己的基础上面高估的
    谷雨霖 说:
    继续说生态,没深入说这个理念
    Yong CHEN 说:
    对了我们公司要印刷敏捷扑克了,等15天就出来。谁要,给我发邮件,写个快递地址
    谷雨霖 说:
    怎么叫全生态
    Yong CHEN 说:
    cheny@cheny.com
    xiyeqing99@hotmail.com 说:
    我要
    Yong CHEN 说:
    写邮件
    (R)(L)China_Iverson(R)(L) 说:
    我也要
    Yong CHEN 说:
    好,全生态很复杂,但是局部生态是存在的。
    比如Scrum在国外其实比XP热很多,原因就是他的生态系统相对简单,比较容易建立起来。
    xiyeqing99@hotmail.com 说:
    恩 Scrum确实简单点
    Yong CHEN 说:
    我已经画好了Scrum生态图,回头发给大家。
    xiyeqing99@hotmail.com 说:
    上次买了本xp的书 看了一页就看不下去了
    Yong CHEN 说:
    如果大家用了Scrum,但感觉有件事情怎么也没做好,就看看与之相连接的生物是否有纰漏。
    xiyeqing99@hotmail.com 说:

    Yong CHEN 说:
    但XP的生态相对复杂,关键需要一些技术方法 。
    比如你想TDD和持续集成,就需要一些自动化测试工具的支持。
    如果老板说:太复杂了或太贵了别买了,你先用用别的条目吧……结果生态系统就被破坏了
    chinamath(海茶)-Sr.SE-北京 说:
    敏捷扑克太好了,请陈老师留个邮件地址。
    Yong CHEN 说:
    cheny@cheny.com
    chinamath(海茶)-Sr.SE-北京 说:
    OK,谢谢!
    liu.chsh@hotmail.com 说:
    怎么给你钱
    Yong CHEN 说:
    公司市场部给我钱,呵呵。免费的。
    参加敏捷大会的人手一个。
    liu.chsh@hotmail.com 说:
    但是我不在北京,不能参加,
    Yong CHEN 说:
    好了回到生态系统:由于Scrum只涉及需求管理/计划/跟踪(比CMMI对应内容少),所以存在整体部署的可能。如果要用Scrum,一定要用全!
    liu.chsh@hotmail.com 说:
    外地,你们帮忙邮寄吗
    Yong CHEN 说:
    没事,给我邮件说清楚地址收件人,快递过去。
    M群-项目管理 说:
    Yong CHEN 说:
    好了基本结束了,呵呵。
    谷雨霖 说:
    欢迎“打鬼子”加入;)
    S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:
    hi
    Yong CHEN 说:
    会上我会用3~4个例子更详细地解释敏捷生态系统,但这里太慢了就不多说了:D
    dearChloe-PM-深圳 说:
    哎,可惜
    Yong CHEN 说:
    回头大会或许有录像。
    刚才是其中一个例子。
    S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:
    //all
    Yong CHEN 说:
    打鬼子你好,呵呵
    S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:
    呵呵。
    我来晚了。
    谷雨霖 说:
    梅总也是很优秀的专家
    S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:
    大家都这么客气。。
    susan-pm-湖北 说:
    欢迎
    xiyeqing99@hotmail.com 说:
    (F)
    谷雨霖 说:
    陈老师,你今天讲了敏捷,非常打动我。让我第一次有了推行敏捷的冲动
    xiyeqing99@hotmail.com 说:
    哈哈
    陈老师的msn多少啊
    litao 说:
    陈老师,我还有问题,如何判断所有扣牌的人都高估呢?
    suzerain1983@hotmail.com 说:
    敏捷,英文是什么?
    AlexQin(21)-QC-深圳 说:
    Agile
    susan-pm-湖北 说:
    agile?
    xiyeqing99@hotmail.com 说:

    suzerain1983@hotmail.com 说:
    谢谢,忘了怎么拼了
    Yong CHEN 说:
    哈哈以前你没有推动敏捷的冲动啊,呵呵。
    AlexQin(21)-QC-深圳 说:
    呵呵
    chinamath(海茶)-Sr.SE-北京 说:
    实际一般怎么PK?能再讲点细节吗?
    Yong CHEN 说:
    哦,PO有权利挑战大家的结果,如果他感觉太高或者太低。
    谷雨霖 说:
    有冲动,但在全公司推行有阻力和顾虑
    Yong CHEN 说:
    所以可以防止整体高估或者低估。
    liu.chsh@hotmail.com 说:
    可以拿项目做示范
    Yong CHEN 说:
    PK举个例子:1 2 2 5,1和5PK
    1:这个很简单的啊,就调用个函数,上次小X已经编好后台了。大家:是嘛?汗~然后,二轮全部变成1
    也可能是:
    dearChloe-PM-深圳 说:
    我想问: 就凭需求,就可以做到那么细致的工作估算?
    Yong CHEN 说:
    1: 这个……后台了。5说:但我们不只在游戏里边做排行榜,还要在网站上做,两边同步。
    122问:要吗?
    PO:……应该要,网站不是你们做的吧?你们先看你们做要多久,我的记下来,得告诉网站部门也要干活……(写字)
    上面PK的例子是在盛大真实发生的情况,上次刚给他们做过咨询。
    susan-pm-湖北 说:
    老师,制定产品清单的过程是谁来做,也需要一个或多个迭代过程吗
    Yong CHEN 说:
    只凭借写出来的需求是不行的,因为写需求的人也不知道大家想知道什么,不知道什么。
    ddv731731-SSE-上海 说:
    是SDG,还是SDO
    liu.chsh@hotmail.com 说:
    开会讨论前,让所有成员都自己准备一下,注意一定要后分工,不要讨论前分配工作,不然他们就只管自己的估算了
    北京-QM-李晋James Li 说:
    今天公司网络不好。
    精彩的部分煤看到。
    没看到。
    Yong CHEN 说:
    所以一般需求可以写简单点,但讲解的时候多讲点(说话速度比打字快多啦),并且跟着大家的提问讲。
    北京-QM-李晋James Li 说:
    陈老师,放出msn吧。
    chinamath(海茶)-Sr.SE-北京 说:
    是不是还得有个记录?否则PK那么多,谁能全记住。
    Yong CHEN 说:
    当然,讲完后,根据大家的提问,把需求补充一下。
    liu: 对,讨论前要看的,特别是比较大的需求。
    SE: 对,有个会议秘书,打字高手(轮流的),记录一个草稿纸。
    北京-QM-李晋James Li 说:
    陈老师,重构在什么时候做。
    作为一个backlog吗?
    Yong CHEN 说:
    我本人的草稿纸现在264页,从去年7.15到现在。
    susan-pm-湖北 说:
    老师,制定产品清单的过程是谁来做,也需要一个或多个迭代过程吗
    Yong CHEN 说:
    用简单条目化的文字把PK中发现的问题记录下来,发送给大家。
    Li: 重构经常作为Backlog的一项做。
    Susan:是PO在做,他任何时候都可以碰Product Backlog,每个迭代需求都在变多。
    说说重构。重构是个很危险的工作,如果用敏捷,一定要有一个高级的设计人员,否则以后全重构了。
    北京-QM-李晋James Li 说:
    是啊。
    另外重构的point也很难估算。
    Yong CHEN 说:
    所以敏捷原则中有一个,就是要有优秀的设计。
    xiyeqing99@hotmail.com 说:
    重构是个很危险的工作?
    怎么会呢
    北京-QM-李晋James Li 说:
    还有Springt0与其他sprintx有啥区别
    Yong CHEN 说:
    恩,Point不好算,当然重构的任务多了,可以参考以前的。
    Xiyeqing:因为有些代码编的很烂,不好改动。
    北京-QM-李晋James Li 说:
    好像sprint0就是专门确定架构的。
    谷雨霖 说:
    重构必须要系统级的工程师才能碰,特别是对产品开发
    S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 说:
    msn抽风?
    Yong CHEN 说:
    Sprint0常常指那个做整体计划的Sprint
    xiyeqing99@hotmail.com 说:
    是呀 我就是看的重构这本书
    觉得越是烂的代码才越是要重构
    否则以后完全没法维护的
    等于要重新写一个
    所以我现在review他们代码的时候 写的烂的我都要他们改掉的
    Yong CHEN 说:
    其实很少有公司实行纯粹的迭代开发,那系统架构肯定崩溃。还是要有一系列的Sprint0(而不是1次!)来重新整理一下思路。
    北京-QM-李晋James Li 说:
    哦?这个思路挺好的。
    谷雨霖 说:
    时间差不多了,陈老师,你看延长到13:50?别太多打扰了
    Yong CHEN 说:
    012340123401234,这样规划,当然不一定是四次。
    恩,重构是必需的,但是“避免重构”也是必需的。高手写的代码,即使需求变化了,也不太需要改动太多。
    新手的能气死,只能重写。要在计划时就发现这一点,每天做代码评审,而非最后发现不好才重构。
    xiyeqing99@hotmail.com 说:

    Yong CHEN 说:
    好的,我这边还有个PPT晚上要交工,呵呵。
    xiyeqing99@hotmail.com 说:
    重构确实需要一次一小步的
    一旦都写完了 已经好久了 往往没人肯再花时间去重构了
    Yong CHEN 说:
    我们公司也在用Scrum,但是我们每半年左右就有一次Release,集中消除BUG,确定下一步方向,等等。
    是。
    xiyeqing99@hotmail.com 说:
    是。 是回答了哪个问题?
    Yong CHEN 说:
    Xiyeqing:我03年半天进行一次代码审查,中午就的看看大家的代码,免得晚上集成不了抓瞎。
    回答你的“往往没人肯……”
    xiyeqing99@hotmail.com 说:
    啊。。。半天就进行一次代码审查乐了啊
    那频率很高了哦
    呵呵 看来你是个很认真负责的pm啊
    Yong CHEN 说:
    总归有站起来走走的时间,就去看看别人的代码,非正式的。
    xiyeqing99@hotmail.com 说:
    怪不得混的这么好啊
    呵呵
    Yong CHEN 说:
    每人每天写100行左右C++,半天50行,2屏幕多点。5分钟看完。
    xiyeqing99@hotmail.com 说:
    他们知道你一直要看 肯定没人敢偷懒
    现在我就发现很多人喜欢偷懒
    不管了 他就不帮你做东西
    Yong CHEN 说:
    偷懒不好,到老了就后悔了。
    xiyeqing99@hotmail.com 说:
    呵呵
    其实他们不肯做工作 想学点别的
    Yong CHEN 说:
    好,基本结束。还有什么集中的问题没有?
    dearChloe-PM-深圳 说:
     学啥?
    xiyeqing99@hotmail.com 说:
    但是上班时间不可能一直让你看别的啊
    chinamath(海茶)-Sr.SE-北京 说:
    谢谢陈老师,今天讲的非常好!
    xiyeqing99@hotmail.com 说:
    他们自己看书
    谷雨霖 说:
    好了
    Yong CHEN 说:
    看代码别太认真,看全局不看细节。差代码全体换成*我也能看出是坏代码。
    xiyeqing99@hotmail.com 说:
    (F)
    谷雨霖 说:
    非常感谢陈老师的介绍,非常生动易懂。

    谷雨霖老师的地址:http://blog.csdn.net/cabinhome/

     

    点击下载免费的敏捷开发教材:《火星人敏捷开发手册

    转载于:https://www.cnblogs.com/dairongle97/archive/2011/08/17/2402009.html

    展开全文
  • 问题这是敏捷开发一千零一问系列的第二十七篇。(在这里提问,之一,之二,之三,问题总目录)来自提问帖 15楼 http://blog.csdn.net/cheny_com/article/details/7564388原问题摘录如下:开发组中可能同时进行几个...

    问题

    这是敏捷开发一千零一问系列的第二十七篇。(在这里提问之一之二之三问题总目录

    来自提问帖 15楼 http://blog.csdn.net/cheny_com/article/details/7564388

    原问题摘录如下:

    开发组中可能同时进行几个专项开发,那么就有人参与这个专项,不参与另一个专项。
    那么扑克估算的时候,针对某一专项的任务,要怎样做,是否是开发组所有人员都参加评估,还是这个专项相关的人员才参与?

    可能一个专项就一两个人来做,专门估算,跟单独拍脑袋差别不大;
    如果大家一起估算,存在效率很低的问题;

    分析

    估算的目的是什么?

    在估算之前,一个非常重要的一定要问自己的问题是:估算的原因或目的是什么?

    估算有很多原因,但实际上有些不太经得住推敲,或者说若遇到有人喜欢杠头,则很难反驳。比如:

    1. 为了知道多少行代码可以完成(如果用代码行估计)。

    杠头:无论知道是1000行还是不知道,做完了一数都是1000行,为什么要提前估计呢?(这个是我8年前被问到的一个问题

    2. 为了知道多久才能完成,以便做计划。

    杠头:我们计划都是反推的,领导说多久,我们就做多久,估算有什么价值?

    ……

    那么有哪些估算是无缺缺少或极具价值的呢?大致有两种。

    1. 在报价/合同发生之前的估算

    若能在此之间完成估算,就能把握商务的主动。即使“被迫签订合同”,做到“心里有数”还是要好很多。

    这个属于早期造价估算,以后再详述,但可以参考http://blog.csdn.net/cheny_com/article/details/7672333

    2. 能改善结果的估算

    如果之前以为要1000行——而且直接做也真的要1000行,结果估算完了发现只要100行,就很值得估算。

    如果之前以为要100天——而且直接做也真的要100天,结果估算完了发现只要10天,也很值得估算。

    这个是扑克牌估算的最佳应用场景。

    预备活动

    原理

    估算能改善估算结果的原理是:通过沟通共享信息,从而降低浪费。

    一般而言浪费活动有两种:

    1. 需求理解错误造成的浪费

    在估算中,通过不同的人、不同侧面的问题,来抽丝剥茧发现需求的真相,可以有效避免这种浪费。

    测试人员和开发人员共同估算,是一种弄清楚需求的常见方法。尤其是开发人员,由于经常深入内核,所以常常听到一点点需求,就想当然地理解为自己曾经想过的一个类似需求,然后急于思考实现方法。

    2. 实现方法错误/重复造成的浪费

    一种是重复代码,重新发明轮子……;

    一种是错误实现,比如曾经有人由于不擅长使用“模板”(就是泛型),而把1个函数写成65个;

    一种是蛮干,比如曾经有人为了图省事使用硬编码来实现码流打包拆包,结果码流在接下来的日子里不断变化,结果骑虎难下,2个月的工作因为质量低下而被扔掉,2周就重新设计编码结束了。

    ……

    水平不同、负责不同部分的程序员充分沟通、共同估算可以避免这些情况。尤其是高手、老手,可以提醒新手避免犯错。

    浪费与反浪费

    必须意识到一点,尽管估算可以防止浪费,估算本身也要花费时间,因此要思考估算的效率。

    提高效率的方法包括:

    1. 若无必要,不牵涉太多人员进行估算

    139团队是一种方法,就是如果我们有13个人,那么尝试分为3组,每组有4个人,这四个人是基本估算单元。他们应该负责相似的功能,平时也坐在一起,因此沟通起来比较顺畅。

    2. 尝试使用较大的颗粒度

    常常听说有敏捷开发实践者把任务且分到2小时左右的,甚至有0.5小时的。这里不直接说应不应该切分,而是提醒一下:4个人吵吵15分钟,就是1小时。我们可以花费1小时,但一定要知道获得了什么,如果真的值得,就去做;如果不值得,就换大一点的颗粒度。

    3. 尝试更快速的估算方法

    扑克牌估算就是一种很快速的方法了,因为如果出牌数字相同,基本上就不讨论了(如果第一次就相同,推荐让一个人说一下,其他人没有太大的不同意见就过)。

    方案

    分析清楚了,方案就比较好写了。

    方案1最容易实现但效果也最不好,后面的则效果好但实施起来更费劲。

    方案1

    在完全一穷二白从来没有估算过的团队,如果他们本来业务也是各自负责一块,建议先以“技术相同”为条件拉几个人在一起估算;如果这几个人平时就坐在一起更好,可以在平时补充一些会上讲不到的地方。

    在公开课课堂训练这种彻底“强分工”的环境下,我发现只要技术说的通,两家公司的人都可以在一起估算的,何况一个团队的小组内部。但前提是产品经理要能说明需求。

    不过初期一定会发现估算很花时间,因为初次估算的时候很多背景知识都不知道,甚至那位直接负责此事的人也说不清楚,所以沟通的成本比较高。如果大家月月都花上一天讨论,很快就可以避免对基本背景知识的交流了。

    刚开始的两三个月,不用太强求有何效果,大家互相理解了背景,就是个效果。

    方案2

    一点点建立有固定组织结构的小组,然后把估算组与小组绑定。

    139团队是一种,其实即使简单任命一个小组长然后带领其他3~4个人开发某种东西,就可以称之为一个固定的小组了。

    固定的小组应该开发相对接近的功能(技术是否相同反而次要),即使技术不同也可以从不同的角度提出自己的看法。有很多人认为,如果我不懂某个技术,就说不出来那部分的开发要多久,这个其实不对。如果我距离那个人不到5米远,我们在开发同一个模块的不同部分而已,他用的技术也不涉及广义相对论之类的很费解的内容,人们就没有理由对某个技术“说不什么意见出来”,尤其是小组的组长。

    在01年的团队中,我们的25人的部门经理基本上参加过每个小组的开发,包括类似机顶盒这样的和PC完全不同的开发平台。当时机顶盒小组发现代码里边有一些难以处理的缺陷,他就过去“顺便帮忙”,结果是发现整个代码过于混乱,于是用了两周他就重构了整个机顶盒里边的代码结构,在C环境下实现了接近C++的面向对象结构。当然要做到这一点需要相当天才的人。但如果只在3~4个人的范围内,这件事情就不那么复杂,人才也不需要太好。

    方案3

    建立L型代码结构。L型代码结构具体情况请参考松结对编程系列中的相应文章(大约第9篇左右开始,当前有三篇)。

    我现在和程序员也“分工”,估算虽然不做(现在只有两个人,沟通太多了所以前面提到的估算的第二个目的早实现了),但给他布置任务的时候,会讨论每个方法的实现方法。主要的讨论内容,是告诉他两样东西:

    1. 整个业务过程类似我编写过的哪个部分,可以作为整体过程的参考(一般集中于View/Controller两个层面)。

    2. 可能用到哪个底层类和函数(集中于Model,我们的Model库占总代码量的67%,多数是我在编写我的上层应用时顺便写的,他也做过维护)。

    第二部门有时候我不会主动交流,因为看过1之后基本上就能看出来,有疑问时再交流。

    L型代码给估算带来了几个变化:

    1. L型代码的高层调用过程非常容易理解,因此关于“如何实现”的讨论比较简单,不用涉及太深的底层实现。

    2. 很容易找到相似业务的模块做参考。

    我们平均一个Controller大约有5~10个函数(比如“用户”的增删改查等操作:UsersControler.Index/Details/Create/BatchCreate/Delete/Freeze/Edit),每个函数的代码量是4~5行,所以如果要学另外一种东西的增删改查全过程,看完这50行代码就能大概了解整个过程了。

    3. 由于底层库都用过,很容易找到使用样例(用IDE搜)。

    4. 每次讨论的时候,会发现需要扩展一些底层库尚未实现的功能,无论谁最终实现它们,讨论过程两个人都知道要多这个功能了,对未来充分复用很有帮助。

    不过,L型代码要彻底形成相对困难,对“顺便”产生底层库的人要求比较高。


    当然最后一个问题:“你们不但不打牌,还甚至不估算,这算敏捷吗?”

    怎么说呢,这么久以来,我们没有因为新人参加而发生重新发明轮子的事情,代码也没有因为新人来了而发生迅速增加或质量下降,人们知道代码中发生的几乎所有重大变化……目的达到了,过程就不重要了。




    本人正在参加CSDN博客之星评选,如果读完并喜欢这篇文章,欢迎投票:http://vote.blog.csdn.net/item/blogstar/cheny_com


    展开全文
  • 也就是少数人无法说服大家,或者说根本无人去听回答:计划扑克的结束条件”近似一致“是个很有趣的标准,其实要回答”什么时候停止打扑克“,就要先解决”为什么要打扑克“的问题。如果打扑克的目的已经达到,
  • 策划扑克是估算软件规模的一种敏捷方法。 该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度...
  • 估计和规划在软件开发中是必不可少的活动,那敏捷方式下我们如何做呢?以下是今年5月份内部做的一个培训PPT,希望对大家有所帮助。   敏捷...
  • 策划扑克是估算软件规模的一种敏捷方法。该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度等...
  • 敏捷扑克牌 不幸的是,出于我们应用程序的安全性考虑,我们通常不会在开发中“内置安全性”。 取而代之的是,我们等到最后一刻才采取安全措施,通常是建立一个警察型的安全部门,并在安全人员和开发人员之间产生对抗...
  • 敏捷扑克估算 许多敏捷和Scrum团队从基本实践入手,以使自组织团队能够更好地交付业务优先级。 实践包括承诺团队可以在冲刺中完成什么工作,举行日常站立会议以管理... [了解您的企业如何在敏捷开发中脱颖而出 。 | ...
  • 敏捷估算扑克

    2019-08-11 05:09:33
    其实应该叫“估算扑克”更准确一些,本质上是扑克牌,基于Delphi估算原理,可以快速估算出需要的数字。 关于扑克牌上的数字 估算扑克牌上的数字,有的牌是自然数排列,有些是斐波纳契数,有些则是不连续自然数。...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP… 为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum...
  • 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP... 什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 怎么理解呢?首先,我们要理解它不是一门...
  • 有效的估算是软件开发人员在工作中面临的最严峻挑战之一。无论团队规模如何,他们都需要在整个团队中定义,评估和分配工作。随着团队的扩大,围绕计划和评估工作养成良好的习惯变得越来越重要。缺乏计划和估计会降低...
  • 什么是敏捷开发

    2017-09-19 14:15:00
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,...
  • 敏捷估算方法 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在故事拆分之后需要对我们...
1 2 3 4 5 ... 20
收藏数 836
精华内容 334
关键字:

敏捷开发扑克牌