还有没有别的做法?
调查:
1,所在团队实际用了哪种做法?
2,你倾向于采用哪种做法?
On 10月2日, 上午9时12分, 姜志辉 <ibags...@gmail.com> wrote:
> h1,克强。
> 我们团队第二种情况使用的情况可能居多一些。不过有一些出入:
> 1、受Joel的影响,我们采用的基本单位为人.时,不是人.天,我们基本估算团队的有效工作时间为5小时/每天
> 2、除了资源利用率,会把在这个阶段的一些风险考虑进去,我们叫缓冲时间。比如十一的假期等等。这个你可能考虑到Velocity里了,但我还是把他单独提出来,因为不同的时间段缓冲时间是不一样的。
> 3、一般我们会在一开始做两个小而价值比较高的user story试试看,然后重新估算
> 基本上可以看出来,我们的估算受Joel的影响比较大。
>
> 2009/10/2 克强 <zhangkeqi...@gmail.com>
User Story是无单位的.
On 10月5日, 下午5时09分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/5 Daniel Teng <tengzhe...@gmail.com>
>
>
>
> > User Story是无单位的.
>
> 哈哈,犯了和我一样的错误嘛~ 无单位的是story point,而不是user story。
>
> > On 10月5日, 上午6时33分, 张克强 <zhangkeqi...@gmail.com> wrote:
> > > unitless作何解?
> > > 是 "无单位"?
>
> 是的。user story用于评估user
> story的相对大小(bigness),它并无一个可用于度量的单位值。时间或是长度单位,例如"小时"和"米",乃是全世界同一的度量。
>
> 一定程度上可以说story
> point最终会达到具有一定的单位效用。当某产品开发大团队(包括若干scrum团队)保持团队稳定,以及开发足够长时间后达到velocity稳定时,可以-借由建立一定程度上story
> point向"成本"、"时间"等度量的映射,使其成为"虚单位"。
>
> 例如,平均下来大团队(5个人/scrum团队 *
> 5个scrum团队)每个sprint(4周)能完成50个point,那么可以将一个point等同为一个时间范围,1 point = 40~70h
> (假设scrum团队的capacity为可用时间的80%到50%之间,5*5*140/50 和5*5*80/50)。
>
> 同样,也可以将point和费用、收入联系在一起。假设上述25人大团队的每月总费用是12.5万元。那么可以认为一个point的成本是2500元,需要的时-候,可以通过计算某个user
> story的可能性收入,并与其成本做比较进行决策。
>
> 但问题在于,对于不同的组织或是产品大团队,其成本因素以及开发效率都不同,这也造成其每个point的相对应时间、成本虚单位不同。而且形成稳定的point-虚单位,需要维持point的相对大小一致很长时间,一年两年甚至更长时间。
--
-----------------
张克强
blog: http://hi.baidu.com/hespr
-----------------
On 10月5日, 下午5时09分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/5 Daniel Teng <tengzhe...@gmail.com>
>
>
>
HI,Xu Yi:
Thanks
我刚刚查阅了一下资料。story point确实是无单位的。这里找到了一个摘录:
"Next we take the stories that the customer selected and break them
down into tasks.A task is much smaller than a story.It is a unit of
work on the order of four to 10 man-hours is size."
他只说了大小约是4到10人时,确并没有指定单位是多少。我又查阅了一些相关资料,都没有指明单位,只是说大约多少人时
而Joel的任务划分是人.时为单位的,但没有说是故事点,只说是任务。
提议不再讨论story point单位的问题, 或者开新贴。
把讨论集中在sprint plan的估算实践上,就做过的或是见过的实际做法上。
On 10月6日, 上午10时19分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
Joel所说的Task( a unit of work....)在不同的user story里所需的人时是不是一样的?
On 10月7日, 上午2时39分, 姜志辉 <ibags...@gmail.com> wrote:
> 是的,这里用EXCEL的好处有三点:
> 1、EXCEL可以直接计算总人时,一旦有变动,会在实际栏里记录,这样会有一个比较,而且计算是自动的。每次迭代后,估算的误差一目了然,如下:
> 故事 任务 估算值 实际值 误差 ...
> A A1 2 4 2
> A2 3 2 -1
> .. ...
> 5 6 1
> 2、通过EXCEL的图表功能直接产生燃烧图(我自己对应燃烧图产生的图,不纯)
> 3、通过EXCEL的宏功能直接产生backlog(又是我自己的对应backlog产生的冲刺任务,不纯),然后打印出来,贴到白板上
>
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
这里面 “实现功能的IMD” 的理解有点小弯弯的,我试谈谈我的理解:
1,如果某个sprint计划时 选择了50IMD的功能,sprint结束时正好做完计划所选功能,那么实现功能的IMD就是50。
2,如果某个sprint计划时 选择了50IMD的功能,sprint结束时没有做完,那么考察没有做完的功能还要多少个IMD,假设是5,那么实现
功能的IMD就是50-5 = 45。
3,如果某个sprint计划时 选择了50IMD的功能,sprint结束时做完了,并从backlog中又挑了一些功能做完了,考察这些功能要多少
IMD,假设是5,那么实现功能的IMD就是50+5 = 55。
实现功能的IMD的计算与实际投入多少人天是无关的。
请Andy指正。
我的问题:实践中 功能分解到任务的大小一般是什么样的数量级?1~3 IMD or 4~10人时? 前面姜志辉show的例子是2~6人时。
--
-----------------------------
blog:http://hi.baidu.com/hespr 高效过程研究
On 10月6日, 下午5时11分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/6 张克强 <zhangkeqi...@gmail.com>
>
On 10月10日, 下午10时57分, Xu Yi <kaverj...@gmail.com> wrote:
> 2009/10/10 张克强 <zhangkeqi...@gmail.com>
team过去的velocity是如何计算的? 考虑投入工作量吗? 是不是 sprint完成的story point数 除于 sprint投入的
工作量?
或者不考虑投入工作量,直接以一个sprint能完成多少个story point来表达?
(9+12+5+16+10)/5=10.4这么算误差太大了,应该是每次迭代之后,用完成的任务点数处以实际投入的人日数。
每次迭代能投入的人日数受很多因素影响,你那种算法得不出什么有意义的结果!
你真的喜欢你的"velocity"?
看不出你所说的算法在何处减小了误差。
当然还有个前提就是,每次做计划时对story point的评估要按照一致的标准,
其中关键就是point值等于1的那些原子story不要有太大误差,
然后其他story以原子story为参照,比如point值为2的必须是原子story工作量的2倍,以此类推。
这不是很明显的问题吗?
你的velocity的定义是什么,是每个sprint可以完成的工作量,对吧?
可是不同user story的工作量有数倍的差距,你算出每个sprint的平均story个数跟工作量没有任何换算关系,算它干什么用呢?
哦,“sprint的平均story个数” 是个误会,我道歉!
你觉得我说的前一个问题是否存在呢?
在我所见到的实践中,“猪”们(scrum中意思,绝无其它意思)的承诺都基于历史数据估算,就算是第一个sprint的估算,也参考了非敏捷生命周期
的数据。承诺估算虽然会调整些,但幅度都在25%以内,多数情况下幅度小于5%。
历史数据估算在sprint plan时看起来是不可少的。(有没有真的不做的?)
而承诺估算很难单独应用,我所见的“猪”们没有单独这样估算过。
我的看法:把历史数据估算的结果(包括微调)作为承诺来达成,不失为一种可行的做法,尤其适合引入scrum不久的团队和有新人的团队。
--
-----------------------------
blog:http://hi.baidu.com/hespr 高效过程研究
如果承诺估算中在sprint刚开始时把story分成2~8人时的任务,这样的颗粒度我没有在scrum中经历过,我在瀑布生命周期的阶段估算中经历
过。而在瀑布生命周期中的回忆是痛苦的回忆。
请教经历过的朋友,在scrum sprint plan时开展2~8人时颗粒度的承诺估算有什么注意点,有什么有效实践?
阿捷:那具体怎么做呢?大家一起做计划,岂不是很乱?
敏捷圣贤:首先,你们要先定下来Sprint的目标,即作为一个团队,你们要完成什么,然后再决定完成多少。
阿捷:我们当前没有任何历史参考数据,怎么知道完成多少呢?
敏捷圣贤:事先计算出在一个Sprint内,团队的可能工作时间。譬如,在未来三周内,一个5人小组,每人每周工作40小时,那么总的工作时间=5×40×3=600小时。
阿捷:理想情况是这样的,但肯定会有人休假的。
敏捷圣贤:对,所以你要将总的工作时间扣除任何预期的非工作时间。譬如,有一个人要休一个礼拜的年假,还有人要看牙,需要占用3天,这样算起来是600-5x8-3x8=536小时。
阿捷:还有,即使每人每天工作8小时,但也不是会真的有8小时工作在项目上,还要参加各种Tea Talk、培训、Team Building等活动。
敏捷圣贤:如果每天8小时,你们大概会有几小时工作在项目上?
阿捷:平均差不多6小时吧。
敏捷圣贤:你得把每天花在参加会议、谈话、处理邮件、上网等时间都除去。
阿捷:那估计5小时。
敏捷圣贤:我们把它用百分比表示,5/8,那么就是60%左右,然后用这个“负荷指标”(Load Factor)乘以总的工作时间小时数,你就得到了536×小时。
阿捷:嗯,这种估算很实际。
敏捷圣贤:然后从产品Backlog中,按照优先级从高到低,选择出你们认为能在322小时内完成的条目,作为你们当前Sprint的Backlog。注意:选择的Sprint Backlog Item一定要强内聚、松耦合,这样你们才能不受或者少受外界的干扰,目标明确。
阿捷:那个“负荷指标” 60%应该是变动吧?我们刚做一个项目,跟项目做了一段时间相比,肯定是不一样的。再譬如我有新员工加入时,他的效率肯定是要比老员工低的。
敏捷圣贤:对。你已经很好地理解了负荷指标,你可以利用它把Sprint计划得很准确。当你遇到低的“负荷指标”时,要试着找出根本原因,这会使你门的Sprint更有效率。
阿捷:下一步是不是该做任务细化?进行估算?
敏捷圣贤:不完全对,任务细化之外,还有一个非常重要的部分:对于每个细化后的任务,都需要一个非常明确“完成”(Done)的定义。这一点非常重要,必须保证每一个人的理解是正确的、一致的。
阿捷:嗯,否则每个人的估算就会千差万别。
敏捷圣贤:对!估算时,可以用“计划扑克牌”来估算完成时间。你知道怎么用计划扑克牌吗?
阿捷:不知道,我想我可以去查一下。
敏捷圣贤:嗯,你们应该尝试一下这个东西。
阿捷:还有什么值得注意的?
敏捷圣贤:做Sprint任务细化时,一个最佳实践就是把每个任务控制在2~16 小时之间。任务太细,会涉及更多的微观管理,太粗,估算就会不准确。
阿捷:OK!在这一点上,Scrum跟其他项目规划方法是一样的。
敏捷圣贤:下一步,就是让大家自己认领任务,而不是指派!这一点非常关键,一定要记住啊?
阿捷:为什么要认领?指派会更有效率,而且还能根据每个人的特长,让每个人做他擅长的事情。
敏捷圣贤:首先,每个人认领任务后,实际上就是对整个团队有了一个承诺,更能保证按计划完成。其次,让每个人选择自己愿意做的事情,这样才会更有主动性,毕竟“做自己有兴趣的事情,才会真的做好”。这样,不仅满足了个人发展的需要,还可以达到快速的知识共享、团队技能的整体提高。
2009/11/1 Xu Yi <kave...@gmail.com>:
> 最近在看一本挺搞的书,不晓得很多人的做法是否来自这里。。。
>
> 新浪文化读书 > 商场小说 > 敏捷无敌 > 第5章 成长的烦恼(5)
> - http://vip.book.sina.com.cn/book/chapter_98731_65356.html
>
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
我认为所谓专业人士,其一大特征就是能分辨小说与专业著作的区别。比如建筑师下班时看看小说没啥问题,不过要是他从高第密码里面学建筑技术,不知道有几位敢买他设计的房子?
答案是,这是个伪问题
会被小说影响的“专业人士”他就不是专业人士
2009/11/1 Xu Yi <kave...@gmail.com>:
--
这个问题的实质是“一本小说能对其主题所指的专业产生什么样的影响”
答案是,这是个伪问题
会被小说影响的“专业人士”他就不是专业人士
我相信重要的還是獨立思考的能力去分辦是非。
On Nov 1, 5:09 pm, Jeff Xiong <gigix1...@gmail.com> wrote:
> 这个问题的实质是"一本小说能对其主题所指的专业产生什么样的影响"
>
> 答案是,这是个伪问题
>
> 会被小说影响的"专业人士"他就不是专业人士
>
> 2009/11/1 Xu Yi <kaverj...@gmail.com>:
>
>
>
> > 2009/11/1 Jeff Xiong <gigix1...@gmail.com>
http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884270610
http://en.wikipedia.org/wiki/The_Goal_%28novel%29