《Scrum精髓:敏捷转型指南》—冲刺

举报
清华大学出版社 发表于 2019/10/13 14:44:23 2019/10/13
【摘要】 本节书摘来自清华大学出版社《Scrum精髓:敏捷转型指南》一书中第二章,作者是 Kenneth Rubin,姜信宝 米全喜 左洪斌 译 , 徐 毅 审校。

冲刺

Scrum中,工作在不超过一个月的迭代或循环中进行,这个迭代或循环称为冲刺(参见图2.7)。每个冲刺完成的工作应当创建一些对客户或用户来说具有明确价值的东西。

image.png

2.7  冲刺的特征

冲刺是有一定时间范围的,总是有固定的开始和结束日期,而且一般来说冲刺的持续期应当都是相等的。前一个冲刺结束后马上就会开始一个新冲刺。在一个冲刺中通常不允许改变范围内的目标或是更换人员,不过,有时业务需求使我们无法遵守这个规则。第4章将详细描述冲刺。

制定冲刺计划

产品列表体现的可能是多周或多个月的工作,是一个短期的冲刺根本无法完成的。为了确定下一个冲刺要构建的PBI最重要的子集,产品负责人、开发团队和ScrumMaster需要做冲刺规划(参见图2.8)。 

在做冲刺规划期间,产品负责人和开发团队要对当前冲刺准备实现的冲刺目标达成一致意见。针对这个目标,开发团队要对产品列表进行评审,确定在以可持续的节奏工作时根据实际情况在当前冲刺中能够完成的高优先级条目——可持续的节奏指的是开发团队能够轻松、长时间保持的工作节奏。

为了获得完成工作的信心,很多开发团队都会把每个需要完成的特性分解为一组任务。这组任务及其相关的PBI组成了第二个列表,称为“冲刺列表”(参见图2.9)。

image.png

2.8  冲刺规划

image.png

2.9  冲刺列表

接下来,开发团队给出完成每项任务所需工作量的估算值(通常以小时计)。把PBI分解为任务是一种设计形式,是适时(just-in-time)制定特性完成计划。

大多数Scrum团队在执行一个两周到一个月的冲刺时,都尽量在大约48小时内完成冲刺规划。一个一周的冲刺中,用于计划的时间应当不超过几个小时(或许还应当更短)。此时有几种方法可以使用。我最常用的方法是遵照一个简单的循环:选择一个PBI(尽可能选择由产品负责人定义的下一个最重要的条目),把条目分解成任务,确定把所选择的项目放到冲刺中是否合适(要和同一个冲刺中的其他条目结合起来考虑)。如果合适并且还有更多的能力完成工作,可以重复这个循环过程,直到团队没有能力再做更多的工作为止。

另外一个方法是由产品负责人和团队一次选择所有目标PBI。由开发团队自己独立分解任务,确认团队是否确实可以交付所有选定的PBI。第19章将更详细地介绍每一种方法。

冲刺执行

Scrum团队完成冲刺计划并就下一个冲刺的内容达成一致意见后,开发团队就要在ScrumMaster的指导下,执行为了完成特性而所需的所有任务级的工作(参见图2.10),此处所说的“完成”指的是非常有信心地认为对于产出高质量特性所需的所有工作都已完成了。

image.png

2.10  冲刺执行


当然,团队要执行哪些类型的任务,取决于工作特点。例如,我们是在构建软件吗,构建的是什么类型的软件?或者我们是在制造硬件吗?或者这是一个市场推广工作吗?

没有人告诉开发团队在完成一个冲刺列表的这段时间中以什么顺序、什么方式执行任务级的工作。相反,团队成员要定义自己的任务级工作,然后按照自认为最好的方式进行自组织并实现冲刺目标。要想进一步了解冲刺执行,请参见第20章。

每日例会

在冲刺期间的每一天,理想的做法是在每天同一时间,开发团队举行一定时间范围内(不超过15分钟)的每日例会(参见图2.11)。这个检视与调整活动有时也称为“每日站会”,因为大家站着开会可以使会议简明扼要。

image.png

2.11  每日例会

举行每日例会的一个常见做法是ScrumMaster负责确保会议更顺畅,每个团队成员都要轮流回答三个问题,让其他团队成员了解情况。

 

l  在上次每日例会之后我完成了什么?

l  在下次每日例会之前我计划做什么工作?

l  有什么障碍让我无法取得进展?

通过回答这些问题,每个人都能了解全局,知道发生了什么事情,实现冲刺目标的进展如何,对当天的工作,是否需要修改计划,有什么需要处理的问题。每日例会是必不可少的,能够帮助团队管理一个冲刺内快速、灵活的工作流。

每日例会不是用来解决问题的。相反,很多团队会选择把问题的讨论放到每日例会之后和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议,尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺列表条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性制定每日计划的活动,以帮助自组织团队更好地完成工作。

Scrum曾经使用过术语“猪”和“鸡”来区分在每日例会中哪些人应当参与,哪些人只要站在旁边看就行了,不过这两个术语现在已经不用了。这两个农场动物术语来自一个老笑话(这个笑话有几个不同的版本):“在早餐吃的火腿鸡蛋中,鸡是参与者,猪是全部投入了。”显然,Scrum使用这些术语是为了区分参与者(鸡)和为了实现冲刺目标而全力投入的人(猪)。在每日例会中,只有猪应当发言,如果有鸡参加例会的话,应当作为旁观者。

我发现一种很有用的做法,即把Scrum团队中的每个人都看成猪,不是猪的,就是鸡。当然,不是每个人都赞成我这个观点。例如,产品负责人不需要参加每日例会,所以有些人认为他是鸡(其中的逻辑是,如果不需要参与,又怎么可能“全力投入”呢?)。我认为这好像不对,因为很难想象作为Scrum团队的一员,对于冲刺的最后结果,产品负责人的投入怎么可能比开发团队更少呢?如果在Scrum团队中使用猪和鸡的隐喻,是行不通的。


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200