平安险与敏捷不兼容吗？

Question

我目前在一个基于敏捷+ SCRUM的项目中工作。我在一个较低层次的模块工作。这就引出了一个特殊的问题。我所做的工作不能与用户故事直接关联很多次。由于我无法将用户故事直接与我的工作联系起来，所以我经常面临需求不明确的问题。此外，我倾向于“错过”一些事情，只有在冲刺后期我才明白。我的图层工作不能直接测试。

类似地，我们的GUI团队由于遗漏了次要的隐式需求而产生了许多bug。例如，文本字段的宽度小于预期，等等。

我以前曾在另一个项目中使用FPA，我认为这是一个很好的方法，可以将需求分解为微小的原子细节，澄清次要点，然后使用这些点作为核对表构建您的软件。我真的觉得这将有利于我们的项目，特别是我的层。我建议在我的团队会议上，bit，它被拒绝了，因为所涉及的文件。“智者”的基本原理是: FPA是文档--很重，而敏捷则对大量文档皱眉。我认为敏捷就是生产好的产品，如果一个敏捷过程不能被塑造成添加一个减少缺陷并产生好代码的过程，那么它就是不“敏捷”的。最后，团队否决了这个提案，声称它不是“敏捷”。然而，我怀疑原因更可能是懒惰。

FPA是否真的与敏捷不兼容，因为涉及到大量的文档？那么敏捷宣言的崇高目标呢？它只是“工作代码”还是“良好工作代码”？

Answer 1

这是一个典型的误导SCRUM实现的例子。你(和你的团队)需要遵循这一点，从崩溃的角度回到需要做出的改变(记住: SCRUM是一个适应性的过程，评审会议的后半部分应该用来研究如何在下一次冲刺中更好地工作(S)！)

故障点显然是GUI团队提出的所有错误。还有一个问题是，您的代码不能直接进行测试。这两种观点都表明故事的定义不够充分。这个级别的细节(文本字段的长度等)不需要预先完成，它可以在sprint期间发生，但是它需要团队成员和产品所有者之间的密切交互(您确实有产品所有者，对吗？)如果发生了这种交互，则不需要额外的文档。在交互中没有发生，那么您就有问题了，scrum大师需要介入进来。

另外，如果您的工作不能与用户故事相关联，那么产品所有者就没有正确地完成他们的工作。

我已经使用SCRUM很多年了，我是一个认证的SCRUM大师。我可以从经验中告诉你，如果你遵循基本原则，它就会工作得很好。但你必须遵循所有这些原则，而不仅仅是那些适合你的(在这种背景下，你意味着整个scrum团队，包括产品所有者)。

你不需要平安险，只需修复你的SCRUM过程。