Scrum_tp

放弃在每日站会上按成员逐个发言

很少有Scrum文献会说每日站会需要按团队成员逐个发言。然而大多数团队恰恰都是这样做的,但这可能不是最好的方式。

当每日站会是逐个团队成员进行的时候,团队成员会很容易丢掉所讨论的待办事项的上下文。例如,可能第一位团队成员正在处理前两个产品待办事项,第二位团队成员正在处理第二个和第五个产品待办事项,第三位团队成员也在处理其中这些待办事项中的一个,同时花费少量精力处理另一个无人的待办事项。
Read more

Scrum中文网敏捷实践

团队不需要在计划会上考虑到所有事情

几周前,我参加了一个很痛苦的迭代计划会。类似的会议你可能也参加过,团队竭尽所能试图分析出本次迭代所要完成的所有任务,并就每一个任务具体需要花费多少小时进行无休止的争论。

然而这种级别的细节讨论其实是不需要的。

迭代计划会的目的是从产品列表中挑选出本次迭代要完成的条目,并对如何完成有一个大致的想法,达到这个目的并不需要团队了解每一个任务,当然更不需要团队知道某个任务是需要花费4小时还是5小时。
Read more

Scrum_tupian

敏捷估算, 请忘掉人天

在介绍敏捷估算的方法之前,我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值,单位是人天或者人时。

比如:

David喝完一小杯热咖啡花费1.2个小时(工作量 1.2人时)

David喝完一大杯热咖啡花费2.4个小时(工作量 2.4人时)

由于人的能力是有差异的,所以David的工作量对于Tom来讲可能就不适用,Tom喝完一小杯热咖啡可能需要1.5小时。这样一来,工作量、参与人以及完成这些工作的时间周期就是强相关的,因为强相关会带来如下挑战:

1.  做计划时必须把人和周期关联到具体的任务上,会让计划很复杂。

2.   团队成员的分工发生变化时对计划的影响比较大,管理和维护计划成本高。(这是甘特图的价值所在 )

3.   由于第二条的原因,这种工作量的估算方式不利于团队协作。

Read more

Scrum_tupian

Scrum反模式之——汇报式每日站会

一些刚刚开始尝试使用Scrum的团队,很多时候你会听到他们说我们已经开始Scrum了,但是他们通常还会说我们对Scrum做了一些裁减,我们只挑选了一些适合我们的实践,比如Sprint,每日站会,以及Scrum看板。在旁观他们的每日站会的时候,你会发现,他们开站会也是围成一个圈来开的,并且也是站着的? 那会有什么问题吗?

仔细观察你会发现,他们开站会也会围成一个圈,但圈里面不是Scrum看板,而是Scrum Master。 你会发现有的Scrum Master 是非常积极主动的,他会挨个问大家三个问题:昨天做了什么?今天准备做什么?有没有什么障碍? 甚至有的Scrum Master会拿出一个小本子把一些问题记录下来,还承诺会后会把会议记录发给所有人,并抄送给相关干系人。Ethan Huang老师(中国仅有的几位认证Scrum培训师之一)称这样的Scrum Master 叫“二狗子”Scrum Master。

这样的Scrum Master很积极、执行力很强是没有问题的,问题在于这个会是团队自己的会,而不是Scrum Master的。 Scrum的团队是自组织的团队,在Sprint开始的时候团队共同承诺团队交付的目标,通过每天的站会,团队一起(商量着办)做当天的计划、回顾昨天任务完成的情况、发现团队遇到的问题和障碍,这三件事情应当是团队自己的责任。Scrum Master通过参加每日站会可以发现团队遇到了什么障碍,以便于协助团队移除障碍,但是,这个会的目的一定不是为了向Scrum Master汇报进度。

作为Scrum Master,我们在开每日站会的时候,难免会遇到这样的情况,大家不自觉的会围着你,或者用目光注视着你。遇到这些情况,你需要想办法避开,离团队稍微远一些,或者比如站在发言人的背后,让团队学会自己开会。

 

本文作者:
廖靖斌 Eric Liao, CSP,CSM,知名敏捷教练、顾问、培训师

TDD

实践测试驱动开发

作为一个有理想、有追求的程序员,你成天被各种名词包围着,你对其中一个叫做敏捷的东西特别感兴趣,因为它特别强调人的作用,这听着都让做程序员的你感到舒服。为了让自己早日敏捷起来,你从众多的敏捷实践中选择了一个叫做测试驱动开发(Test Driven Development,TDD)的作为你的起始点。 Read more