testing - Scrum，但没有测试或文档

Question

当你加入一个说他们使用 Scrum，但只将其用作时间管理工具而不是整个过程的团队时，你会怎么做？如何恢复回测和文档？

我正在考虑从添加专门用于测试和记录的用户故事开始。也许其他人对此有更多的经验，然后我对此进行了处理，因为我相信这并不少见。

Answer 1

Scrum 的关键在于，在将任务归类为已完成之前，可将其识别为“已完成”。贵公司如何在不审查文档和测试的情况下评估某事是否已完成？

也许他们有一种不寻常但有效的方式来做这件事。或者他们可能错过了“完成任务”的意义。我建议您首先询问他们如何衡量以及是否可以改进。然后建议将文档和测试作为改进流程的方法。

Answer 2

请注意，测试和文档实际上都不是 Scrum 的一部分。Scrum 是一种纯粹的项目管理方法 - 所需的工程实践，就像你提到的那样，应该在项目期间“出现”。更具体地说，它们应该在你在每个 sprint 结束时进行的心跳回顾中被识别出来。你在做那些吗？你能在那里提出你的担忧吗？它们实际上是团队最大的担忧吗？

Answer 3

问题是他们没有任何文档和测试，还是他们没有实施整个 Scrum 方法？在我看来，这是两个非常不同的问题。

我更喜欢一个花费时间和精力来寻找和适应与其开发风格相匹配的开发过程的组织，而不是从高处强制执行一个真正的过程。因此，如果他们使用他们称为 Scrum 但不符合所有“官方”准则的流程，我根本不会担心。试着确定为什么这个过程是这样的。很有可能，如果他们花时间进行定制，团队就会接受你的想法，特别是如果你花时间确定事情为什么会这样。如果您只是简单地将其视为“这不是 Scrum，因此是不正确的”，您可能不会取得太大进展，但通过务实地看待好处，您可能会做出一些实质性的改进。

或者，如果他们没有进行测试并且没有任何文档，我会认为这是一个相当糟糕的迹象。通过文档，我在这里采取了极简主义的观点——功能列表、错误跟踪等——我会非常担心这些项目的缺失，而不是抽象列表中更高层的项目的缺失。在没有管理层支持的情况下，我建议您以身作则。自己设置一个简单的错误跟踪系统（有几个 - 在紧要关头，中央位置的简单文本列表也可以工作）。在其他人测试之前不要宣布您的功能完成。这可以简单到走到另一个开发人员面前，让他们在你面前尝试一下。如果有人声称某项功能已完成，请花几分钟时间熟悉它。如果您发现错误，请礼貌地向负责的开发人员提及。慢慢建立一个环境，让团队可以看到运行测试和跟踪功能和错误的好处。

大多数团队以这种方式运作只是因为错误地认为他们没有时间“做正确的事”，或者他们稍后会去做。当一个或两个开发人员作为副项目完成的简单概念验证转变为全面的开发工作时，通常会发生这种情况。通过展示它实际上可以节省时间和精力，并降低团队其他成员的初始成本，您经常会发现它作为流程的一部分变得根深蒂固，而实际上并未得到正式认可或接受。

如果您有管理层的支持，这将变得更加容易，但请始终小心确保团队能够接受更改。这可能意味着它需要的时间比您想要的要长，但是就这样吧，如果没有团队的支持，任何强制性流程都会在压力的第一个迹象出现时失败，这是您最需要流程的时候。

*免责声明 - 在我的上一个项目中，我带头调整 SCRUM 流程以适应我们的环境。“官方”流程对​​我们的客户来说根本站不住脚，但它仍然是我们定制流程的宝贵指南。

Answer 4

“添加专门用于测试和记录的用户故事”

虽然元用户故事在某些圈子中可能有意义，但它很少能奏效。软件人员很少能很好地处理元用户故事，他们要么不知道他们可以通过编写故事来改变自己的流程，要么——更典型地——他们将元用户故事设计得死去活来。

当你采访用户时，感觉就像他们在编造用户故事。当然，当您聆听他们并尝试捕捉它时，您正在编造它。

当 IT 组织试图编造自己的关于 IT 应该如何工作的用户故事时，这个过程就会分崩离析。直到组织手动完成了很多次（例如测试），他们才真正有资格编写用户故事。然后，在他们完成之后，他们就不需要软件开发过程，他们只会一次一点地自动化重要的部分。

我认为改变必须来自一个不太正式的方向。实际上，不愿将未经测试的事情称为“完成”是一个很好的起点。

除非被迫，否则 IT 不会做任何事情。因此，与用户会面并找出他们不需要测试的原因。指导他们要求测试。告诉他们后果和要使用的词语。

组织中的很多问题都可能导致糟糕的流程。重要的是要知道哪里出了问题，并提出改变的需求。最好的办法是让你的老板抱怨你没有修复它，而不是你建议修复它可能会很好。

[当你的老板要求你修复流程时感觉不对，但这是改变发生的唯一方式。]