文章

Scrum_tp

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

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

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

Agile stand-up meeting

让我们把这个讨论存档16分钟

很多团队努力缩短每日站会的时间。有些团队的站会甚至超过标准时间箱规定的15分钟,而这变成了一种常态。半个月前我教授scrum master认证课的时候,有些人提到了一个非常好的主意,在这里我想分享给大家。 Read more

编写文档真的是在浪费时间吗?

我最近留意到,在敏捷开发中存在着一个广为流传的谣言——“敏捷中没有文档”或者说“编写文档就是浪费时间”。特别是在从瀑布式向敏捷转型的过程中,我们感受到典型敏捷实践给我们带来的好处,例如:短周期的迭代、时间盒、每日站会、回顾会议等等。这也导致了我们希望放弃在应用敏捷之前的一些习惯:编写文档、给代码加注释等等。但是,我们完全不写文档和注释真的是对的吗? Read more

使每日站会的价值最大化

在最近过去的几年中,我在许多不同的每日站会中担任过参与者和协助者的角色。众所周知,每日站会的真正价值在于团队有能力不断地为当前的sprint周期的“承诺”而努力。每日站会并不是状态汇报,现在团队成员经常很容易陷入提供状态相关信息的这样一种模式。近期虽然我正在使用一种最老的每日站会的方法,但我认为一个成熟的团队可以从不同的程度来花费15分钟做这些事情,与此同时他也继续在进化使用敏捷/Scrum。
Read more

Scrum-ban

Scrum-ban是一个Scrum和Kanban的开发模型。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中,Scrum模型中规定时间的sprint显然就不能够满足项目的需求了,但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝,通过这两样法宝,能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。

为了能够清楚地展示工作的每个阶段,在同一个地方工作的团队通常会使用便签纸或者一块大的白板。而分布式团队通常会使用工具软件,如Assembla,ScrumWorks或者安装上GreenHopper的JIRA来帮助团队更好地了解各个用户故事、缺陷和任务所处的状态。

最简单的办法就是把任务或者用户故事划分成以下三类:
 候选
 进行中
 已完成

如果有需要的话,团队可能添加更多的状态,例如,“已定义”,“完成设计”,“完成测试”或者“已交付”等等。划分更细的状态能够帮助团队在遇到瓶颈又不能改变并行任务的最大限制的时候更有效地解决问题。同时,更具体的任务状态划分也能够使团队成员更专注在特定的工作环节上。

对于最大并行未完成工作的数量并没有一个通用的值,每个团队需要根据自身的情况来设定。如果这个值设得太小,有可能会导致很多团队成员有太多的时间在空闲状态;如果这个值设得太大,那么就有可能会在同一时间出现大量的未完成的工作,从而导致每个任务完成的时间大幅上升。这里给出的建议是,每个团队成员同一时间不能进行超过两个任务,另一方面在同一时间所有团队成员不能都有两个任务。

Scrum和Kanban最大的不同就是,Scrum把工作划分成固定长度的周期——sprint中,而Kanban则以持续工作的方式进行。从表示任务状态的表格来看,Scrum会在每个spirnt把表格清空,而Kanban则一直沿用同一个表格。从团队组成来看,Scrum强调的是跨职能团队,团队成员需要是多面手,而Kanban则更强调专职团队。

由于Scrum-ban是新的开发模型,因此并没有太多的参考资料。就目前来看,Kanban至少已经被Microsoft和Corbis采用了。

Sprint进度的测量

我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成以天为单位的任务。但是...

scrumcn1305615765
我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成刚好一天能够完成的任务。但是我见到不少团队在尝试过这么做以后,发现过程中遇到很多麻烦,因为有些任务需要不到一天,而有很多需要两天甚至以上,所以很难将所有任务都准确地拆分成正好一天能够完成。

有的团队把用户故事拆分成任务以后,花费大量的时间来计算每个任务所占的故事点数。而这个会在计划会议上完成,因此整个会议要持续4到6个小时。在下文中,我们把这种方法叫做“故事点数分配法”。

第三种方法是我最喜欢的一种,我觉得它是最有用的,因为这种方法不需要花费很多时间,这和Scrum中帮助团队避免花费太多时间在获得准确性的其他方面是一致的,例如,在Scrum中使用斐波那契数列或者2次方数列来进行用户故事的估计。

只要有机会,我都会推荐下面这种方法。这种方法的基本技巧就在于,持续地更新每个用户故事的估计所需剩余时间(ETC)。一般来说你可以在每日站会之后更新数据,如果你已经能够掌握时间盒的运用的话,你甚至可以在每日站会当中来更新。总而言之,这种方法的最基本思想就是让团队每天估计并且更新完成某个用户故事所需要的故事点数。

让我们来看看这个例子。假设我们的Sprint长度是两个星期。在计划会议之后,团队承诺完成A到G一共7个用户故事,放在下面的表格里面(图1)。
scrumcn1305615787
图1

 scrumcn1305615845
图2

在完成了星期一下午的工作以后,团队在星期二的早上聚集到一起举行每日站会,然后估计所有在进行中的用户故事所需要的剩余时间。从图2中可以看出,用户故事A和B正在进行中,于是团队根据当前的进展重新估计了这两个用户故事剩余的故事点数。做出估计的依据应该是整个用户故事所剩余的工作量,而不是被拆分的任务。下面是团队重新估计后得出的燃尽图(图3)。
scrumcn1305615878
图3

团队应该每天重新估计每个进行中的用户故事的剩余工作量。图4展示了从开始到完成的过程,图5则是Sprint结束时的燃尽图。

scrumcn1305615896
图4

 scrumcn1305615917
图5

我经常听到其中一个的争论是“但是ETC并不是百分之百准确的”。这是肯定的,没有任何的估计是百分之百准确的。但是,每天重新估计进行中的用户故事的剩余工作量比把故事点从Sprint开始分配到各个任务中,然后每天把剩余的故事点数加起来更加能够让你了解实际剩余的工作量。这是为什么呢?

我们可以用锥型不确定性理论来解释。在项目管理中,锥型不确定性描述了项目过程中不确定性数量了变化过程。在项目刚开始的时候,相对地我们对项目的了解较少,因此估计也会包含比较大的不确定性。随着我们完成了越来越多的开发工作和研究工作,我们对项目的了解也越来越多,不确定因素也会越来越少。(http://en.wikipedia.org/wiki/Cone_of_Uncertainty)

scrumcn1305615947

正如你所想到的那样,锥型不确定性理论对传统的项目管理模型有很强的依赖。尽管如此,它的原理同时也适用于敏捷的项目管理。

还记得“故事点数分配法”(把每个用户故事的点数分配的各个任务当中)吗?我们可以说我们已经有一个不错的误差了,姑且说是+/-25%(1.25/0.75)吧。当然这种方法不会让我们得到百分之百的准确度。当项目进行的时候,为了能够更好地计算剩余的工作量,团队会标记已经完成的任务,然后把在进行中的任务所占的故事点数相加。这么做的问题是,尽管我们现在能够掌握比我们第一次估计的时候更多的信息,但是由于我们没有对用户故事进行重新估计,于是我们的准确度就会卡在+/-25%这个槛上。

如果我们不在一开始就把故事点数分配到各个任务上会发生什么事呢?自然我们就不会把所有剩余的任务所占的故事点数加起来来获得剩余的工作量。我们只能够重新估计每个进行中的故事的剩余工作量。这样我们就可以保证我们重新估计的时候不会还带着+/-25%的误差,而且可以越来越接近锥型的右侧,也就是误差为0的地方,因为我们每次重新估计的时候就会比上一次更加了解项目掌握的信息也会更多。这样做会比单纯维护在计划会议上作出的估计要准确得多。

我推荐各个团队在下一个Sprint中尝试这种方法。如果使用得当的话,你将会很快地留意到持续估计剩余工作量的好处。

原文地址:http://www.scrumalliance.org/articles/356-measuring-sprint-progress

 

每日站会,自组织的量度

每日站会是指Scrum团队每天进行的15分钟左右的会议。其主要目的是给团队讨论每日的承诺和Sprint目标的进度的机会。Scrum Master Product Owner和所有团队成员都应该参加每日站会。每个团队成员在会议中都必须回答以下三个问题: Read more

每日Scrum: 不是只针对ScrumMasters的

我一向不认为每日scrum(或者每日站会)是“状态会议。” “状态会议”这个词语对我们大多数人来说都太贬义。对我来说,它让我回想起了这样一个画面,一群人围着桌子坐下,每个人向项目经理汇报更新情况,与此同时,每个人都假装很有兴趣地倾听着,但他们可能都在准备自己接下来要汇报的更新状况,或者在想这个会议将要持续多久。 Read more

每天的站会怎么开?

在那些最简单也最常谈起的敏捷实践中,每日站立会议(又称作每日例会)就是其一。 Jeff Martin在scrumdevelopment Yahoo!邮件组中问道:

我搜索过相关知识却一无所获,我想我一定是用错了词。谁能给我一个每日例会的范本?我们遇到些困难,导致有些团队成员想取消会议,或是一周只开两次会。

这个问题得到了很多回复。 Marcie Jones认为原因在于(缺乏)推动会议进行的技巧: Read more