当您加入一个表示他们使用Scrum的团队时，您会做什么，但仅将其用作时间管理工具而不是整个流程？ 如何恢复测试和文档？
我想开始专门为测试和记录添加用户故事。 也许其他人对此有更多的经验然后我这样做，因为我确信它并不罕见。
答案 0 :(得分：2)
scrum的关键是任务在被归类为完成之前可以被识别为“已完成”。如果没有审查文档和测试，您如何评估某些事情是否完成？
也许他们有一种不寻常但有效的方式。或许他们错过了“完成任务”的重点。我建议你先问问他们如何衡量，以及是否可以改进。然后建议文档和测试作为改进过程的方法。
答案 1 :(得分：2)
请注意，测试和文档实际上都不是Scrum的一部分。 Scrum是一种纯粹的项目管理方法 - 所需的工程实践，就像你提到的那样，应该在项目期间“出现”。最具体地说，它们应该在每次冲刺结束时进行的心跳回顾中被识别出来。你在做那些吗？你能否在那里提出你的担忧 - 他们实际上是团队最担心的问题吗？
答案 2 :(得分：1)
问题是他们没有任何文档和测试，或者他们没有实现整个Scrum方法？在我看来，这是两个非常不同的问题。
我更倾向于一个花费时间和精力来寻找和适应与其开发风格相匹配的开发过程的组织，而不是强制要求从一个真正的过程开始。因此，如果他们使用的是他们称之为Scrum的流程但我不会满足所有“官方”指南，我就不会感到担心。尝试确定流程的原因。如果他们花时间去定制它，那么团队可能会接受你的想法，特别是如果你花时间确定原因是什么。如果您只是将其视为“这不是Scrum而且不是正确的”，那么您可能不会取得很大进展，但通过务实实现这些好处，您可能会有一些实质性的改进。
或者，如果他们没有进行测试并且没有任何文档，我会认为这是一个相当糟糕的迹象。通过文档我在这里采取极简主义的观点 - 功能列表，错误跟踪等等 - 我会非常担心这些项目的缺失，而不关心抽象列表中更高的项目的缺失。在没有管理层支持的情况下，我建议你以身作则。自己设置一个简单的错误跟踪系统（有几个 - 在一个中心位置工作的简单文本列表）。在其他人测试之前，请勿声明您的功能完整。这可以像走到另一个开发人员并让他们在你面前尝试一样简单。如果有人声称功能已完成，请花几分钟时间熟悉一下。如果您发现了错误，请向负责任的开发人员礼貌地提及。慢慢建立一个团队可以看到运行测试和跟踪功能和错误的好处的环境。
大多数团队以这种方式运作只是因为他们错误地认为他们没有时间“做得对”，或者他们以后会接受它。当一个或两个开发人员作为一个副项目完成的简单概念验证变成一个全面的开发工作时，通常会发生这种情况。通过展示它实际上可以节省时间和精力，并降低团队其他成员的初始成本，您经常会发现它在过程中已经根深蒂固，而不是真正得到正式认可或接受。
如果您拥有管理支持，它将使其变得更加容易，但请务必小心确保团队能够接受这些变更。这可能意味着它需要比你想要的更长的时间，但是如果没有团队的支持，任何强制进程都会在第一次出现压力时失败，这就是你最需要这个过程的时候。
*免责声明 - 在我的上一个项目中，我率先采取行动来定制SCRUM流程以适应我们的环境。 “官方”流程对我们的客户来说根本站不住脚，但它仍然是定制流程的宝贵指南。
答案 3 :(得分：0)
“添加专门用于测试和记录的用户故事”
虽然元用户故事在某些圈子中可能有意义，但它很少有效。软件人员很少能够很好地处理元用户故事，他们要么不认为他们可以通过编写故事来改变自己的流程，或者 - 更典型的是 - 他们将元用户故事设计为死亡。
当您对用户进行面试时，感觉他们正在制作用户故事。当然，你正在聆听他们并尝试捕捉它时，你正在弥补它。
当一个IT组织试图编写自己的IT用户应该如何工作的故事时，这个过程就会崩溃。直到组织多次手动完成事情（例如测试），他们才真正有资格编写用户故事。然后，在他们完成之后，他们不需要软件开发过程，他们只需要一次一点地自动化重要的位。
我认为改变必须来自一个不太正式的方向。实际上，在调用尚未经过测试的“完成”的东西时，这是一个很好的起点。
除非被迫，否则IT不会做任何事情。因此，与用户会面并找出他们不需要测试的原因。指导他们要求测试。告诉他们后果和使用的词语。
组织中可能出现很多问题导致流程不畅。重要的是要知道什么是错的，并创造变革的需求。最好的办法是让你的老板抱怨你没有修理它，而不是你建议修复它可能会很好。
[当你的老板要求你修复这个过程时，它并没有感觉，但这是改变发生的唯一方式。]