Scrum Master需要保持警惕的几件事

引言


大千世界里,越是简单的事物,越难以掌握和自如运用。西红柿炒鸡蛋很好做,但把西红柿炒鸡蛋做得色、香、味俱全,却并不容易。Scrum亦是如此。Scrum是一种相当简单的敏捷框架,以其简单易上手而广为流行。但要真正运用好Scrum,构建强大而有效的Scrum团队,却并非易事。

在团队导入Scrum的初期阶段,很多团队在经过简单的尝试之后,往往会出现各种阻力,或因团队成员的反感,或因领导的过多干预,或因项目巨大的压力。凡此种种,往往会导致对Scrum进行更改,或者出现明里暗里的抵制,故意制造出跑偏、走样、延误等种种问题。作为Scrum Master——团队的敏捷教练——有责任保证团队严格遵循Scrum和敏捷的各种原则,及时纠正团队出现的问题。

其中,有些事情特别值得警惕。我们今天就来看一看都有哪些需要Scrum Master时刻警惕的事情。

Scrum Master需要保持警惕的几件事


在Scrum的推行过程中,Scrum Master是团队的保护者,也是团队严格、认真遵循Scrum流程、实践和原则进行开发的教练。

Scrum Master 要时刻警惕团队中出现的一些非敏捷的苗头并及时纠正。

范围蔓延

范围蔓延”是PMBOK中的术语,说的是在项目进行过程中,项目的范围因种种原因而不断发生变化,通常是慢慢增大。在Scrum敏捷开发中,导致范围发生变化的各种内外部条件并不会完全被消除,因而也很有可能出现项目范围发生变化的情况。其实,敏捷原则第2条【1】就讲到,

欣然面对需求变化,即使在开发后期也一样。

所以敏捷开发并不惧怕项目需求变化。但静悄悄的、毫无知觉的项目范围增加,尤其是在Sprint进行中的需求增加,还是要警惕的。

当团队在一个“时间盒”式的Sprint中尽可能快地进行开发时,我们希望能够以流畅、持续的步伐,识别新需求、详细分析描述、实现、测试并予以交付。这看起来很容易,但做起来却很难。

大家都知道范围蔓延是怎么回事,但真的在迭代期间出现时,仍然会感到特别诡异。一旦团队做出了自己的迭代承诺,并把需要处理的Sprint Backlog分解成了任务,我们通常不会在允许新的工作再加进本次迭代中。但是,如果在迭代期间出现了新的、特别是优先级更高的需求,这就有可能会导致迭代时间增长。

所以,Scrum要特别坚持敏捷原则。在迭代期间,允许团队信守承诺,完成已经承诺的任务直到本次迭代结束,在下一次迭代中,和Product Owner一起,重新梳理Product Backlog,将优先级最高的需求放到最优先地位,确保下次迭代优先完成并交付最优先、对客户最有价值的需求

遗留的用户故事

有时候,在一个迭代结束时,某个用户故事只完成了一部分,这样的用户故事被称为“遗留故事”。这是前次迭代没有完成的工作,通常会被自动添加到下一个迭代中,继续开发。但千万别这么做

敏捷宣言的12条原则中,第一条就是,

我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

对客户来说,在上一次迭代进行中,Product Backlog中的最有价值需求可能会发生变化。在上一次迭代中被认为是最有价值、优先级高的需求,随着外部环境的变化,可能会出现变化而降低了价值和优先级。如果我们自动将这些未完成的工作放入下一次迭代,有可能我们所做的工作并不是最有价值、优先级高的需求。

Scrum中,Product Owner的责任之一是维护Product Backlog,确保Product Backlog中的用户故事,都是经过了严格、认真的评估,是已经按照对客户的价值高低而拍好了顺序和优先级的。

所以,对于前次迭代没有完成的故事,Scrum Master要鼓励团队对未完成的用户故事进行分析,从中找出没有完成的原因,并在回顾会议中进行分析,拟定改进措施。同时,要从中学会如何在单次迭代中完整地完成用户故事,而不是只完成一部分

Scrum Master要确保这些用户故事被重新放入Product Backlog,和Product Owner一道,对这些用户故事重新进行价值评估并排序。这样,下一次迭代规划时,团队拿到的就是一份完整的、经过了价值评估的、排好了顺序和优先级的Product Backlog。因而,下次迭代选中的工作,也都是对用户最有价值的需求。

当用户故事只是部分完成了但其优先级仍然是最高的,可以基于剩余的工作,对用户故事重新估算。基于团队的“速度”来决定团队在单次迭代中到底能完成多少工作,而不是只完成一部分。

迭代期间出现变化

通常情况下,迭代期间出现的变化与“范围蔓延”类似,因而处理措施也基本相同。Scrum Master务必要竭尽所能地与Product Owner 就迭代期间如何完成用户故事达成一致,确保团队不受外界干扰

项目进行期间,务必要避免出现大规模、批量的需求变更。出现这样的变更,肯定会影响整个迭代进程。那最好的处理措施可能就是,立刻停止当前的迭代,重新审视、梳理Product Backlog。该增加新故事就增加,该删除无效故事的就删除。等整个Product Backlog重新梳理完成后,重新开始迭代开发。

Scrum Master一定要确保,团队当前手头的工作,对客户来说,是最有价值、优先级最高的

软件缺陷

发现软件缺陷(Defect、Bug)是不可避免的。

当在在线系统中发现缺陷时,要立刻停掉手头的工作,优先修复软件缺陷。直到发现的缺陷修复了之后,再继续之前的工作,或者开始新的工作。

当修复了缺陷之后,还有做两件事情:

其一,进行一次根本原因分析,以确定这些缺陷是如何从最初的工作中遗漏出来的。这种缺陷在PMI-ACP中被称之为遗漏缺陷,又称逃逸缺陷

其二,对当初的工作疏忽或不足进行改进,以弥补工作中的漏洞,避免同样或类似的缺陷再次出现。

敏捷团队并不以延长工作时间而获得更多产出,我们时刻聚焦于软件质量,以减少不必要的重复、返工的数量而提高生产率。但发现软件缺陷时,我们要立刻修复缺陷。如果某个用户故事还有很多已知的缺陷没有修复,那最好不要把这样的用户故事算作完成。如果团队低估了完成工作所需要的时间,Scrum Master要确保在迭代回顾的时候,团队对此进行讨论,并切实采取措施避免同样或类似的事情再次发生

迭代气味

同很多事物一样,但出现不期望的事情时,一定有很多这样或那样的征兆。我称这些异样的征兆为迭代气味,或者更直观地,迭代臭味。这些现象可以通过观察团队的每日站会(我称之为每天碰头会)而清晰地识别出来。

  • 团队成员缺席会议。每日站会是团队的会议,每个人都应该出席。
  • 重复任务。当每日站会上,问那三个经典问题时,如果某个人每天的答案都是一样的话,那一定有问题,Scrum Master需要对此做一番调查。如果一名团队成员在某个任务上被block了,这个团队成员应该尽快寻求帮助。其他团队成员应该尽快帮助他解决问题。敏捷开发中,团队是一体的,是一损俱损、一荣俱荣的。
  • 没有提出问题。如果每日站会上,团队没有提出什么障碍、问题,这时Scrum Master也要特别注意,尤其是当团队的燃尽图显示毫无进展时。
  • 每次提出的问题都一样。与上述类似,如果一天又一天,团队提出的问题都一样时,Scrum Master就需要特别留心了。
  • 领导安排任务。敏捷团队是自组织的团队。千万不要让领导或项目经理为团队成员安排任务,哪怕只有一次。
  • 领导管理团队。与上面类似,团队需要领导来管理时,Scrum Master就一定要出面干预了。敏捷团队应该管理他们自己。
  • 工作角色过于明确、行动起来不像个团队。如果某个团队成员提出了一个问题,而其他成员觉得这不是自己或者团队的问题。Scrum Master这时候要进行干预。敏捷团队是一个完整的集体,集体、共同为完成交付目标而责任均担

总结


我们已经讨论了敏捷团队经常出现的几种现象,Scrum Master需要对这些现象格外留心,如果真的出现,要及时采取措施。

  • 范围蔓延
  • 遗留故事
  • 迭代期间的项目变化
  • 软件缺陷
  • 迭代臭味

参考文献


【1】《敏捷宣言》,http://www.agilemanifesto.org/iso/zhchs/manifesto.html