暗黑Scrum(Dark Scrum)

极限编程创始人之一,敏捷宣言签署者Ron Jeffries提出了Dark Scrum这个叫法,并且写了一系列文章来介绍Scrum使用过程中的混乱与误区,本篇文章翻译自其博客,更多相关文章可以访问作者的博客。

让我们来谈谈“暗黑Scrum(Dark Scrum)”。至少在软件开发过程中,Scrum似乎经常给团队带来压力,常见的情况是:Scrum的交付速度远不如预期的那么稳定可靠,最终结果经常是每个人都承受痛苦,而且通常在这个过程中开发人员会承受更多痛苦。

我产生这些想法的背景是:

我最初的“敏捷”导师肯特·贝克(Kent Beck)有一次曾经提到,他发明极限编程(Extreme Programming)的主要目的之一是让程序员的生存环境变得更安全一些,然而事实证明,对于程序员而言,这个世界尚不安全,尤其是乱用Scrum可能会给程序员带来更多的不安全问题,Scrum发明人之一Ken Schwaber曾说这种情况让他很难过。

我非常肯定Scrum如果能执行好的话会成为一个非常好的框架,所有以下这些想法都非常好:

  1. 通过与业务部门建立紧密的关系以决定需要做什么,需要推迟做什么。
  2. 团队具备实现产品所需的全部技能。
  3. 每两周构建一次经过测试的有形的产品,并展示给相关干系人。
  4. 定期回顾工作情况并寻找持续改进的方法。

对于Scrum,我已经研究、使用并思考了很多年了,关于Scrum的一切都非常的好,虽然不能说完美,但是确实已经很不错了。

不幸的是,与所有好的想法一样,Scrum在理想的情况下是可以达到预期目的的,而现实经常是不如人意的,有时候甚至会非常糟糕,我把这种结果称为“暗黑Scrum(Dark Scrum)”.


暗黑Scrum: 一些典型的滥用场景

下面我们一起看看在暗黑Scrum中,事情是如何变得糟糕的,我们将观察一个正在经历Dark Scrum的团队,用这个团队的领导者的话来讲就是:”他们显然做错了“。

自组织是缓慢发生的

很显然,Scrum定义了新的角色和活动,要熟练掌握是需要一些时间的。更困难的是,它需要我们接受新的价值观,坚持新的原则。召集Scrum要求的这些会议,或者用Scrum中的角色来称呼我们自己很容易,但是真正执行起来并不容易。我们希望能通过让团队自组织来完成这项工作。

Scrum实践过程通常开始于少部分人接受了培训,并且这部分人认为自己已经知道需要怎么做了(即使他们实际还处于似懂非懂的状态下),然后就开始雷厉风行的开始了,这种情况下他们做错也就可以理解了,而且实际情况他们也经常会做错。

现代管理者相信他们的工作是决定团队应该做什么,然后团队照做就可以了。而Scrum则另辟蹊径,在Scrum中管理者只需要说明他们需要什么,然后退后一步,让团队通过自组织来完成剩下的工作。

然而人们一般无法一个开关就转换到新的工作模式,它需要时间来忘掉旧的习惯,并需要花时间来学习新的习惯。领导者也需要时间来建立起对团队的信任,团队也需要时间来学习如何获得信任。Scrum相关培训的作用之一便是帮助相关人员开启这一过程。

暗黑Scrum经常源自人们了解他们旧的工作方式,但是不了解新的Scrum的工作方式的情况下开始执行Scrum的各种活动。类似如下的情况:


每日站会 :太棒了,我们每天都能为团队提供帮助!

每天,团队都会聚到一起来组织当天的工作,我们叫这种实践为“Daily Scrum”, 它经常被强加给传统项目团队。这时候很可能屋子里只有一个叫Scrum Master的人知道为什么这么做以及应该怎么做。其余的程序员甚至是产品经理(Product Owner)可能完全不了解这么做的意义及方法。

而这时候管理者已经十分清楚他们的工作职责:掌握每个人正在做的工作,确保他们正在做对的事情,如果发现有人偏离则及时纠正他们。每天一次的强制性会议可以让他更方便的完成这项工作。

这样造成的结果:

团队无法围绕他们的任务目标并为事情找到一个好的解决方法,取而代之的是另外一个人把所有信息自行处理后告诉每个人应该如何做。由于事情不会每次都能像我们预期的那样进展顺利,因此这个过程常常伴随着责备和紧张。

“暗黑Scrum”每天都在给团队带来压迫感,这种情况下团队自组织将无从谈起。


我们也在频繁做计划(Planning)

每个冲刺(Sprint)PO都会和团队一起确定他们的需求,然后团队决定他们如何做来满足PO的需求并完成开发工作。然而,这只是理论。实际情况是团队根本没有一个来自业务方的PO, 即使有,也可能没有接受过如何成为产品负责人的培训。

管理者可能只是才接触Scrum,但是他们却有丰富的经验处理项目执行过程中的各种问题。因此,他们会每两周一次,告诉这些程序员应该做什么。这时候这些懒惰而顽强的程序员会进行抵制,这时候管理者通常会保持持续的压力,因为这就是他们的管理方式,由他们来告诉团队怎么做,并且团队最好按照他们说的来做。

当然,管理者通常并不了解如何编程,而程序员或多或少会有一些头绪,管理者无法知道当前的代码状态,而程序员通常是知道一些的。所以理论上程序员应该来决定在scrum中要做多少工作,但是在“暗黑Scrum”中,似乎管理者知道的更多,他们认为这是他们的工作之一:驱动团队。

结果永远不会改变。团队真诚而努力完成他们被要求完成的工作,即使他们知道这个工作是没有意义的。如果他们提出异议则只会因为懒惰,愚蠢,制造麻烦而受到谴责,即使他们尽力而为了也不够。

在冲刺结束后,并没有得到期望的结果,奇迹并没有发生。开发人员再次失败了,幸运的是,这样我们才有机会将问题解决:Sprint Review/冲刺评审会


哪些完成了?哪些没有?

每个Sprint的利益相关者都会查看团队取得的成果,并就如何前进提供指导。多么伟大的理论啊,但是当所在组织不是成熟的Scrum组织时,很少能在实践中实现。

在实践中,”暗黑Scrum”首先需要提醒所有人团队在冲刺内承诺要完成的事情,然后我们来看一下团队给我们带来的失败,这个过程对团队来说不是一个反馈的过程而会是一个带来无尽压力的煎熬的过程。

事实是什么呢?

组织对团队提出了远超过他们能完成的工作范围的工作,并且团队确实没有完成。团队进行了尝试,并尝试了所有可以想到的捷径,以完成所有这些不合理的要求。他们跳过测试,忽略设计,甚至在头脑一片混乱的时候继续工作。

最后,他们没有达到目标,他们的绩效不是很好。团队再次失败了。

幸好,“暗黑Scrum”还有管理者、PO、利益相关者在为此努力。他们会确保程序员认识到自己有多么糟糕,这肯定会激发大家下一次做得更好。为了解决这个问题,我们还举办了Sprint回顾会!


告诉他们如何改善…

在回顾会上,团队将回顾之前的冲刺的历史数据,他们观察到进展顺利和不顺利的症结。找出了下一次改进流程的方法。

在实践中,暗黑Scrum的领导者会帮助团队完成这项工作,他们会体现团队尽管我们对他们进行了密切而科学的管理,但是他们还是没有做到。他向这些开发人员明确指出,他们的失败(这确实是失败)肯定是由于懒惰和无能的结合所造成的。为了激励团队做得更好,他指出了不提高的后果,这几乎肯定会包括绩效与惩罚,这是他们最擅长的方法。

有时,团队会提出建议。现在让我为您罗列出来他们可能会说的一些话,以及管理者会如何回答他们:

开发人员  我们需要更多的测试来降低缺陷数量。
管理者    不,我们已经落后于进度了,你需要更聪明而小心地编码,避免产生BUG,我们需要的是功能,而不是测试!
开发人员  我们需要重构来改善现有代码架构的遗留问题。
管理者    为什么会出现糟糕的设计和遗留问题?尽快解决这些问题,就这个周末来完成这个事儿吧。
开发人员  需求不清楚并且没有得到澄清,然后我们开发的功能最后被拒绝了。
管理者    我们需要积极主动的人,您应该自行组织起来以解决这些问题。别总想坐在板凳上就能开发出我们想要的东西来。

你明白了吗,这一直是完成软件的现实过程,引入Scrum并不会改变这一点。多么令人沮丧啊。当然,Scrum实际上正在尝试改变这些情况,但是这需要组织真的从内部完成转变,事实是每个冲刺甚至每天都有太多的老式管理方法在使用着。


开发人员应该怎么办呢?

Scrum实践中发生的很多滥用行为确实与Scrum试图教给我们的背道而驰。真正的Scrum专家绝不会推荐这些东西。这些人并没有在做正确的事情。每个人都对此表示同意。尽管如此,”暗黑Scrum“的确会发生,而且发生的频率仍然很高。在我看来,在人们真正学习Scrum的原则和价值观之前,这种现象几乎是不可避免的。

看起来开发团队除了接受似乎毫无选择。幸运的是,事实并非如此,我们还是有很多有效的工作可做,虽然这并不容易,好消息是这些大部分是和编程相关的,而这正是我们擅长的。

我们从产品负责人或者利益干系人得到的压力往往是因为他们看不清我们在做什么,我们将要完成什么?如果我们能使进展清晰明了,我们就可以改变他们对待我们方式。

  1. 如果产品有很多已知的缺陷,我们的领导层会认为还有更多缺陷,他们会感到恐惧。

    这时他们会让我们承受更大的压力,并且由于恐惧通常表现为愤怒,因此他们会对我们感到愤怒,通常会非常非常生气。

  2. 如果我们在正式开发功能之前先进行设计或基础架构,那么业务功能就会耗费更长时间才能被看到。

    这使我们的领导者担心我们会延期甚至无法提供重要功能。

    这时候我们同样会遭受愤怒和指责。

  3. 如果由于缺乏设计和重构而使速度变慢,那么完成的功能就会减少。

    更少的功能会带来更多的恐惧,更多的愤怒,更多的压力。

当领导者看不到可以运行的软件时,他们就会对未来感到恐惧,这是正常的反应。但是事实表明,恐惧总是以无济于事的方式出现,并且通常是痛苦的。而开发人员可以选择阻止这种情况的发生,我知道的唯一方法是:交付 真实,可用的软件,让功能对管理者可见!

增量交付的力量

Scrum要求我们在每次Sprint结束时交付经过测试的,集成的,有效的,可工作的产品增量。我们将在接下来讨论如何做到这一点。现在,先让我们想象一下我们可以做到每两周交付一次有效的产品增量:

由于领导层可以看到真正的结果,因此大部分恐惧和压力会自行消除。当然,由于也可能存在实际结果落后于他们的希望和梦想的时候,因此压力仍然会存在。每个人都希望有一辆跑车,但有时您只会得到一辆自行车。

尽管如此,经过不断完善,经过测试,集成后,软件包含我们最重要的功能,我们可以更改上面的对话:
管理者: 您做的工作还不够,您必须做更多的事情。
开发人员: 我们会尽力而为,并且会不断努力进行改进。同时,所有这些完成的软件都是有效并且可以使用。使用我们的实际速率来预测我们的开发速度可能是明智的。但最好让我们首先处理最重要的待办事项。

这不仅会立即起到神奇的作用,并且很快会带来帮助,并且我们的产品增量越来越真实,它将对人们看待现实并基于其进行管理产生极大的影响。与我们通常的认识相反,我们的领导人并不愚蠢。他们善于利用自己所拥有的信息尽力而为。如果我们能够以工作软件的形式为他们提供更足够更准确的信息,他们将开始使用这些信息来完成决策过程。利用这些信息,他们将减少我们面临的压力。

同样,做到这些也不能靠魔术,并且这些情况也不会在一夜之间发生。但是,我已经看到它一次又一次地发生。除了在地球上功能最失调的组织中(只有少数读者实际在那里工作)以外,如果我们坚持下去的话,这种情况就会发生。

注意陷阱

很多事情都会存在陷阱,这里的陷阱是指为了改善我们与管理者之间的对话,减少我们面临的压力 和滥用情况,我们必须确保增量是经过测试、集成的,具备可以交付条件的,必须包括我们承诺要完成的待办列表内的条目。

要做的这点并不容易,我们没有在软件工程专业中学到如何做。我们也无法在IT技术学院学习到如何做到这一点,也无法在“您最喜欢的傻瓜语言”中找到它。有一些经过特殊设计的实践,使团队可以逐步构建软件,保持软件经过良好测试,精心设计,着眼于功能并随时可用。如果我们要将Dark Scrum引导到正常的Scrum中来,我们就需要学习这些做法。幸运的是,他们并不难掌握,尽管像所有编程一样,如果我们想精通它们,他们确实需要实践和努力。

在本系列的后面部分,我们将更详细地介绍它们,但在这里让我们简要地介绍其中一些:

1. Acceptance Testing

在Sprint的后期,关于团队是否完成了产品负责人“想要”的功能的争议是很常见的。而这些争执是一种浪费性,它往往使产品负责人和开发人员对立,而我们希望他们紧密合作,而不是互相争斗。一个非常有力的做法是让PO和开发人员就每个故事达成具体的可执行的验收测试,如果测试未成功通过则表示团队尚未完成该故事。

当然,即使是这样的情况下产品负责人也可能不会喜欢她所看到的。但是现在谈话方式已经改变了。她不再能轻松的说“那不是我想要的”。当验收测试通过时,这就是她想要的。她学到了一些东西,现在想要一些不同的东西。很好,PO的工作就是找到通往最佳产品的道路。基于验收测试推进工作,可以帮助我们了解所要开发的内容,帮助我们知道何时完成,并可以让我们进一步理解需求,并进行某些调整。

作为另一个重要的好处,当我们使这些测试用例自动化时,我们可以运行所有用例并确定看到产品在按照我们预期的方式进行开发。

2. Incremental Design

在Scrum项目中,我们应该在每个Sprint之后交付经过测试的,可运行的,可交付的产品增量。显然,我们一开始无法想清楚整个设计:我们只大致知道该产品将是什么,会使用哪些技术。然而,我们需要在最后完成一个好的设计,因此,我们的软件设计也需要一次次递增地实现。

当产品较小且不完整时,不需要太多设计。随着它规模的增长,它需要更大,更好,更健壮的设计,我们只需要随着产品功能的开发同步完善设计。然而在开发进行过程中同时改善设计是困难的。这需要设计技巧,测试技巧和重构技巧。我们将在下面以及本系列的其他文章中探讨这些内容。随着时间的流逝,我们将为您指出有关该主题的一些资源。

但是基本的问题仍然存在:如果我们要在每个Sprint中交付产品增量,我们必须找到一种方法来逐步完成并交付良好的设计。

3. Refactoring

我们今天知道的进行增量设计的最好方法称为“重构”。重构是改进现有代码设计的过程,而无需破坏代码逻辑!

重构不是重写。当然,如果我们有一个设计不良的程序,我们可以使用更好的设计编写一个新程序。也许我应该在这里说“随便写”,因为这种技巧很少起作用。虽然原则上我们可以。但是,这将花费很长时间,而在Scrum中,我们不会花费很长时间:在当前的Sprint结束之前,我们需要更好的设计。

重构是转换代码的过程,通常以非常小的步骤进行,以使其变得更好。现代的IDE可以帮助我们解决这些问题:大多数IDE提供了许多自动重构功能。他们可以提取常用的代码并将其转换为方法或函数。他们可以将代码从一类转移到另一类。他们可以重命名事物,或更改方法的签名。

充分利用重构,我们可以逐步改进设计。但是,有效词是“好”。我们确实必须建立这种技能。

增量设计过程进行持续的改进是必要的,重构正是我们的工作方式。

4. Programmer Testing

除了验收测试,我们还需要程序员测试。我们构建的每个功能都由许多编程步骤组成。在任何这些步骤中,我们都可能犯错。我们使用程序员测试来避免这些错误。程序员测试的一种非常好的形式是测试驱动开发,它如下所示:

  1. 思考下一步我们要实现的功能。编写一个应在该步骤完成后运行的测试。运行它:确保得到预期的失败。

     

  2. 编写代码以完成该步骤的业务。运行测试:确保测试正常通过。
  3. 检查代码以查看是否足够清晰整洁。如果不是,请对其进行重构。然后再次运行测试以确保一切正常。
  4. 重复以上过程直到功能完成。

这不是我们做事的唯一方法,但这是我们目前所知道的最好的方法之一。无论如何,拥有大量用来支持较大的验收测试的小测试非常有帮助,因为这些小测试可以告诉我们我们哪一点错了,而验收测试只能发现“测试失败了!”

这些测试还可以帮助我们进行更大范围的重构。一个完美的TDD程序员可以在TDD周期内完成所有的设计改进,但是我的经验是有时我不会马上注意到设计问题。发生这种情况时,在下一次使用该代码时,我可能需要进行一些额外的重构工作。就像我们开发功能时一样,我们的测试可以帮助我们确保设计变更没有破坏任何东西。

5. Continuous Integration

Scrum每个冲刺之后需要交付的是经过全面测试的可用增量,需要包含以前Sprint中完成的所有功能:完整,可运行,经过测试,可操作的程序。显然,这要求团队的所有工作必须在Sprint结束之前完成集成,测试和协同工作。推迟集成会发现很多问题,其中许多问题还需要大量调试工作。我们推迟的时间越长,情况就会越糟。相反,如果我们在进行少量工作更改后就进行集成,则会让问题的解决变得更加容易。

基于以上原因,一套自动化构建系统被证明是Scrum团队开发过程的重要组成部分。对于大多数团队来说,他们集成的频率越高,结果就越好。持续不断的进行集成似乎是最好的选择,这就是为什么将此实践称为“持续集成”的原因。

来源:敏捷工坊,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/128445

侵权联系 投诉举报
返回顶部