暗黑敏捷——Dark Scrum(下)

Test Ninja 软件质量报道 2019-06-11

(来自“真北敏捷”微信群)


【编者注:最近讨论有几篇文章在讨论“伪敏捷”,所以本公众号特翻译Ron Jeffries在2016年写的一篇文章Dark Scrum(暗黑Scrum),以警醒“权力持有者”。从下篇解决方案——将暗黑scrum转换成真正的scrum,需要做好5件事:验收测试、增量设计、重构、程序员测试/TDD、持续集成,说明基础性实践很重要,其中测试(单元测试、集成测试、验收测试)也非常重要。差之毫厘、谬之千里,国内敏捷践行者需要经常反思


接上篇:暗黑敏捷——Dark Scrum(上)


增量的力量

在每个Sprint结束时,Scrum要求我们提供经过测试、集成的、可正常运行的、可交付的软件产品增量(Increment)。我们很快就会谈到如何做到这一点。现在,让我们假设我们可以做到这一点:我们有能力每两周提供一次可正常运行的产品增量。

如果领导们能够看到真正的结果,那么大部分的恐惧都会自行消失。然而,领导们仍然存在一些恐惧,因为真正的结果还是落后于他们的希望和梦想。每个人都希望有一辆跑车,但有时你只能骑自行车。也许你想要一匹小马,但你只会得到一只狗,甚至不是一只猫,即使这样,一个人至少要得到尊重。(我跑题了。)

尽管如此,团队能够交付经过测试、集成的、包含最重要的功能特性这样稳定的产品增量时,我们可以改变对话:

 

  • 领导:你做得不够:你必须做得更多。


  • 开发人员:我们正在尽我们所能,我们将继续努力改进。同时,所有这些工作正常、可以使用。使用我们的实际交付率来预测开发速度有多快可能是明智之举。最好让我们首先处理最重要的待办项(backlog items)。最好将每一项整理成足够精益(Lean)。

 

虽然这不能神奇地立即起作用,但它会有帮助,而且我们的产品增量越真实,它就越能影响人们看待现实并将管理建立在现实基础之上。和我们经常想到的相反,领导们并不愚蠢。他们用自己的信息尽力而为。如果我们能够以“可工作的软件”这样的形式向他们提供更好的信息,他们就会开始使用这些信息。有了这些信息,他们将诉诸于减少压力、减少滥用。

 同样,这不是魔术,也不会在一夜之间发生。但是,我已经看到它一次又一次地发生。除了地球上最不正常的组织 - 实际上只有少数读者在那里工作 - 如果我们坚持下去,它将起作用。

 

有一个问题

总有一个问题,这个问题就是:为了改变对话,为了减少压力和滥用,增量的确能正常运行。它必须经过测试、集成,做好发布前的准备工作,包含我们承诺要完成的所有待办项。

这并不容易。更糟糕的是,我们没有在计算机科学中学到如何做到这一点;我们没有在软件工程中学习如何做到这一点;我们无法在IT技术学院学习如何做到这一点,我们也不会在《你最喜爱的语言傻瓜书》中找到它。有一些特殊的实践可以让团队逐步构建软件,保持良好的测试、精心设计、专注于功能,随时可以使用

如果我们要将“暗黑Scrum”改为“Scrum”,那么我们需要学习这些实践。幸运的是,掌握它们并不难,像所有编程一样,如果想要熟练掌握,只有不断练习和努力工作。在本系列的后面部分,我们将更详细地介绍它们,但让我在这里简要介绍一下它们。

 

验收测试

在Sprint结束时,争议是关于团队是否构建了PO“想要”的内容,这是很常见的。这些争议是一种浪费,往往会造成PO和开发人员之间的隔阂。我们希望他们紧密合作,而不是互相争斗。

 一个非常强大的实践是PO和开发人员就每个故事的具体可执行的验收测试达成一致。将这些视为“例子”可能很有成效。

 

  • 团队:好的,我们希望系统能够显示拖欠30天的所有企业帐户以及欠款总额。这是一个帐户表,这张表像这样显示已识别帐户的情况,含欠款总额。

  • PO:不,那不太对劲。我们不想显示30天的数据,只有超过30天以上的账户。

  • 团队:好的,那样呢?

  • PO:对!就这样实现!

 

每个小例子都成为有问题的故事或待办项的验收测试。按照惯例,如果测试没有运行,团队就还没有完成那个故事。相反,如果测试确实运行,意味着PO和团队同意我们的工作已达到了要求。

 当然,PO可能不喜欢她所看到的东西。但现在对话已经改变了。如果她说“那不是我想要的”,现在就明显不合理。当我们同意时,这就是她想要的。她学到了一些东西,现在想要一些不同的东西,这很好,这是PO的工作,找到最佳产品。通过具体的验收测试来帮助我们了解所要求的内容,帮助我们了解我们何时完成它,并帮助我们了解何时我们正在完善理解并要求改变某些内容。

 作为一个重要的亮点,当我们自动化这些示例时(验收标准再进一步,即需求实例化、需求可执行),我们可以运行所有这些示例,并确定地表明该产品仍在按照我们同意应该做的事情进行。

 

增量设计

在Scrum项目中,在每个Sprint之后,假定我们能提供经过测试、可工作的、可交付的产品增量。显然,我们不能在一开始时就能弄清楚整个设计,我们只是大概了解产品会是什么样子。同样显而易见的是,在最后结束时我们需要一个好的设计。因此,我们的软件设计必须逐步创建、不断完善。

 没关系:当产品很小而且不完整时,它不需要太多的设计。随着它的开发往前推进,它需要更大规模、更好、更强的设计。我们在产品演化(grow)过程中恰当地(just)演化设计。

恰当地(just)”——软件开发中最危险的词。在我们前进的过程中建立设计很困难。它需要设计技巧、测试技巧和重构技能。我们将在下面和本系列的其他文章中探讨这些内容。随着时间的推移,我们将为您指出一些有关该主题的资源。

 但基本事实仍然存在:如果我们要在每个Sprint上提供产品增量,我们必须找到一种方法来逐步实现足够好的设计。

 

重构

我们今天所知道的增量设计的最佳方式称为“重构”。重构是改进现有代码设计的过程,但不破坏它!

 重构不是重写。当然,如果我们有一个设计不好的程序,我们可以使用更好的设计重写一个新程序。也许我应该在这里说“只写(just write)”,因为那种技巧很少奏效。但原则上我们可以。然而,这需要很多时间,但在Scrum中我们没有太多时间:当前的Sprint结束时,我们需要更好的设计。

 重构是一个通常以非常小的步骤转换代码的过程,使其更好。现代IDE有助于做到这一点:大多数IDE提供了许多自动重构的功能。他们可以提取常用的代码,并将其转换为方法或函数。他们可以将代码从一个类移动到另一个类,也可以重命名或更改方法的签名。

 使用重构,我们可以逐步改进设计,朝着好的方向改进。我们必须建立这种技能。

 增量设计改进是必要的,重构是设计改进的方法

 

程序员测试

除验收测试外,我们还需要程序员测试(指单元测试)。我们构建的每个功能都由众多编程步骤组成。在这些步骤的每一步,我们都可能犯错误。让程序员测试来避免这些错误。一种非常好的程序员测试形式是测试驱动开发(TDD),是这样的: 

  1. 想想在构建功能的过程中的一些小的步骤。编写在该步骤完成时须执行的测试。运行它:确保它现在不能正常工作。

  2. 构建代码以完成这一步骤。运行测试:确保它现在正常工作。

  3. 检查代码以查看它是否足够清晰。如果没有,重构它。再次运行测试以确保一切仍然有效。

  4. 重复此操作直到该功能完成。 

(TDD示意图,来自网络)

这不是我们做事的唯一方式,但它是目前所知道的最好的方式之一。无论如何,由很多小测试支持更大尺度的验收测试是非常有帮助的(Google也有类似的说法:大尺度测试、中..测试、小..测试),因为小测试能告诉我们哪一点错了,而验收测试只是尖叫“崩溃了!”

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

 

持续集成

Scrum需要一个运行的、经过全面测试的可用增量,其中包含以前各个迭代所有待办项的价值:一个完整的、运行的、经过测试的、可操作的程序。

 显然,这要求所有团队的工作必须在Sprint结束时完成集成、测试和整个系统运行正常。延迟集成会带来一些问题,例如需要大量调试。我们等待的时间越长,情况就越糟糕。相反,如果每完成小的变更就进行集成,那就变得容易多了。

 运行系统测试套件的自动构建过程最终成为Scrum团队开发过程的重要组成部分。对大多数团队来说,构建的频率越高,事情就越好。 “持续地”构建似乎最好,这就是为什么这种做法被称为持续集成。

 

幸存的暗黑Scrum

  •  许多Scrum实施过程中都有一个常见的、可能不可避免的Dark Scrum阶段;

  • 暗黑Scrum情况遵循一个共同的模式;

  • 开发团队可以为自己创造更好的环境,并且可以将Dark Scrum转化向真正的Scrum,一个更好的状态。

 

如果您想提供意见,我的电子邮件将是开放的: ronjeffries at acm.org。

  • 在我看来,“暗黑Scrum”是描述Scrum滥用形式的好词。如果您同意,请开始采用该术语。如果你对此也非常倾心,我会很高兴为“敏捷”和Scrum历史上的一个重要话题命名。

  • 在本文中,我使用术语“领导们(powerholders)”表示所有在开发人员之上拥有并施加权力的人,特别是在暗黑Scrum中。这些人没有问题,然而,在暗黑Scrum中,无论是开发经理、团队负责人、PO还是ScrumMaster,使用权力往往都是错误的。在真正的Scrum中所有这些人都有正当合理的位置。在暗黑Scrum中,他们还没有找到自己合适的位置。

  • 截至2016年9月,共有388,000名认证ScrumMaster,82,000名认证Scrum PO,表明近80%的团队没有经过培训的PO。这些数字还表明,在这些ScrumMaster下面可能有多达一两百万程序员。世界上有一千到一千五百万的专业程序员。在他们安全之前,我们还有很长的路要走。

  • 没有双关语。

  • 例如,请参阅文章:The most dangerous word in software development.

(喜欢看英文原文的,点“查看原文”)


(现在当当、京东6.18特惠)

    阅读原文
    已同步到看一看

    发送中

    本站仅按申请收录文章,版权归原作者所有
    如若侵权,请联系本站删除
    觉得不错,分享给更多人看到