2012-11-05 18:00:57 cheny_com 阅读数 9768

问题

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

来自提问帖 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


2014-01-02 13:25:21 u013357325 阅读数 4833

计划扑克介绍

所谓“计划扑克”(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 - 观点


2019-02-18 21:15:54 hdfyhf 阅读数 54
               

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

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

第一种是领导指派,领导说这是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的参与解决了做什么的问题,依靠师傅的带动解决了怎么做的问题。

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

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

 

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

 

           

再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

2014-09-24 17:56:00 weixin_30586085 阅读数 7

原文地址:http://www.uml.org.cn/SoftWareProcess/201108264.asp

敏捷扑克是什么?

其实应该叫“估算扑克”更准确一些,本质上是扑克牌,基于Delphi估算原理,可以快速估算出需要的数字。

关于扑克牌上的数字

估算扑克牌上的数字,有的牌是自然数排列,有些是斐波纳契数,有些则是不连续自然数。具体选用哪种扑克,要根据被估算的内容的跨度大小而定,如果估算值跨度在10倍以内,那么采用顺序自然数比较好,如果数值跨度较大,达到10倍以上,那么采用斐波纳契数比较好。一般而言,估算软件开发工时的话,自然数可能更好一些,毕竟数值都不大,跨度也不会很夸张。

扑克估算的意义与价值

第一点,自然是要获得一个相对较为准确的数字。

和其他估算方法比,使用扑克牌的方法,能够带来一个额外的好处:促进团队成员间的交流,让大家共享、了解更多的信息。扑克牌估算中,有一条规则是:当估算值差距大于可接受范围内的时候,估算数值大的人和估算数值小的人,要各自陈述自己的意见,陈明是什么原因/根据促使自己做了相应的估算。通过这种方法,可以让所有人都有机会发言,分享自己所了解到的知识,而其他人则在这个过程中了解到了很多其他人的知识,这些知识在接下来的开发工作中,都是很有用的。

会不会有人从来不发言呢?

答案是,不会的,不可能有人每次都能够估算出平均值,因此而避免发言。如果这有这么一个人的话,哈哈,那千万不要放跑这个人,也别打牌了,全由他一个人估算就好了,又快又准,哈哈~~(发白日梦中……)

在线免费申请敏捷扑克

点击此处,申请免费的敏捷扑克

如何使用敏捷扑克?

项目组成员

Scrum Master:Lily,后排左侧,QA出身,工作细心踏实。

Product Owner:勇哥,后排右侧,资深ITer,做软件无数。

成员共有四名:前排,从左至右:陈师傅,开发组的老大哥;小洁,新人,表现相当出色;阿典,开发组里的帅哥;Pan,真正的高手。

分牌

每名参与估算的成员分得相同花色的一组牌,两张Joker不参与估算

敏捷扑克和普通游戏扑克一样,也有54张牌,也拥有4种花色(每种各13张)和两张Joker。敏捷扑克的每种花色均是一组13张牌组成的估算扑克牌,牌正面上印刷有供估算用的数字与符号,数字分别是1/2,1~10和20,符号为“!”,代表一些未知情况,如无法提供准确估算值等。

一副估算扑克可供四人使用,如果参与估算的人员多于4人,可以使用多副扑克。关于参与估算的人数方面,一般我们推荐4到8人参与估算;人数太少,会使估算结果偏差很大,人数太多,会拉长估算时间,降低估算效率。

讲解Backlog

产品负责人勇哥从Backlog中选择一个条目,为大家详细讲解该条目

团队成员针对该条目进行讨论并提出问题,勇哥逐一解答大家的问题;阿典思路敏捷,总能想到很多大家意想不到的东西来。

这个步骤是团队和产品负责人之间的交互的环节,帮助团队和产品负责人共同加深对条目的理解。同时产品负责人也会根据大家的反馈,及时修改条目,完善条目。

在讲解条目过程中,千万不要制定该条目的负责人或明显的倾向于某些人来做这个条目,这样会大大降低不负责该条目的团队成员的积极性,甚至会扰乱估算的秩序与结果。

估算

当团队成员确认已经对该条目完全了解、无任何重大问题后,大家开始对该条目进行估算,同时选出代表自己估算值的纸牌,但不可立即亮牌。在估算过程中,为避免干扰估算结果,团队成员之间不可以互相商讨;

估算时,我们经常会估算相对值,而不是绝对值,如一个功能的开发难度或者代码规模,估算单位经常使用点,而不是绝对的时间或者数量,这时我们需要选择一个估算的标准。最简单的方法就是我们选择一个规模中等,大家都比较容易理解的条目,将其设定为一个标准值,比如5,然后再将其他条目和他进行比较,得出其他条目的相对点数。每次估算时,最好使用相同的标准条目,这样对于整个项目的统计有很大帮助。使用相对值进行估算,可以有效的监控团队的生产能力。

选择牌时,牌中央的数字和符号代表了你的估算值,受到纸牌数量的限制,牌面数字不可能包含了全部的可能性,遇到特殊的数字时,我们可以采取组合牌的形式,比如您的估算值为3.5,那么我们可以使用一张3,再加上一张1/2来表示3.5。

+=3.5

当所有成员选牌完毕,大家可以同时亮牌

大家估算的结果是:陈师傅,7;小洁,9;阿典和Pan,3。

同时亮牌的好处是,不会有人跟风出牌,每个人的估算都有其独立思考,这也是扑克估算的精华所在。

争议与讨论

对比每张牌估算值之间的大小,若估算值差距明显,代表大家对该条目的价值没有获得共识,团队需要对该条目价值评估结果进行讨论;

VS

第一轮出牌的结果分别是3,3,7,9;这四个数字差别很大了,两个个偏小,两个偏大,4个数字的平均值是5.5。这时我们需要让估算值是3的阿典说明为什么他认为只有3点,为何会如此简单;之后我们需要选择9的小洁说明为何她认为数值会比较大;选择7的陈师傅最接近平均值,可以选择发言或者不发言均可。

之后大家可以针对每人的发言进行简单的讨论,讨论过程中,随时可以向产品负责人提问,产品负责人需要回答相应的问题,同时向团队成员的估算发出质疑。在讨论过程中,Scrum Master要维护活动秩序,不要让大家讨论跑题了,也不要深入研究代码编写细节,这些是实际开发是再去解决的问题;还有一点很重要,那就是鼓励所有人都发言,千万不要让老手们或强势的人控制了局势。

共识

重复步骤3、4、5,对该条目重新进行估算,直到团队对于该条目的评估数值达成一致。

一般情况下,最多3轮就可以得出一个比较统一的意见。

第二轮,大家出牌的结果是6,7,5,5,虽然有人很不情愿,但是毕竟大家达到了一个不错的共识:估算结果是6~~

如果3轮之后依然没有得到一个统一的意见,比如第四轮出牌结果依然是2,5,5,8;那么Scrum Muster应当立即中断该条目的估算,取平均值或其他大家比较能接受的值作为估算结果。没有任何一种估算是高可靠度的,扑克也不例外,扑克估算的目的就是为了能够在一个尽可能短的时间内,让团队成员更加多的了解需要做的工作,同时顺带得到一个可接受的估算结果。

转载于:https://www.cnblogs.com/AloneSword/p/3991263.html

2011-10-17 06:30:15 zhoujg 阅读数 697

    估计和规划在软件开发中是必不可少的活动,那敏捷方式下我们如何做呢?以下是今年5月份内部做的一个培训PPT,希望对大家有所帮助。

 

敏捷个人俱乐部QQ群:40961321  加入敏捷个人俱乐部QQ群说明

敏捷个人线上线下活动PPT及照片做成的视频共享

推荐:你可能需要的在线电子书   

我的微博:http://weibo.com/openexpressapp

敏捷个人sina围裙:http://q.t.sina.com.cn/135484  


没有更多推荐了,返回首页