用户故事水平太高且太概念化，管理层希望开发人员填补空白

我受雇于一家非常有才华的公司，真正的目的是从事XP。沟通很好，管理人员也可以进行富有建设性的讨论，但是由于时间紧迫，某些事情被认为是RUP，无法讨论。

目前，我对实施故事时需要进行的大量更改感到有些困惑。我相信其中许多发现（当然，这需要花费时间和精力）是故事编写者（客户，最终用户和产品所有者）的责任，而不是开发人员的责任。简而言之，用户故事太概念化，只是传达了基本意图，但缺乏足够的细节（特别是前提条件和后置条件，与其他故事的相关性，依赖关系等）。由于XP开发人员同时是设计师和分析师，因此开发人员可以自行决定填补空白。问题在于许多空白是在发现错误的假设进入评估时间和代码之后才发现的，因为注意到比最初预期的情况更加复杂。即使到那时，找到合适的东西来填补也要花费时间，在不同程度上，这被认为是与初始估计的偏差。

我正在寻找一种建设性的方式来将这些含义传达给管理层，而这种方式不会使我成为试图不必要地使事情变得复杂的人。我是新手，但我尚未建立起很高的信誉。

我们欢迎您的见识。

密切相关并且以某种方式给出了答案：开发人员可以期望多少有关用户故事的细节？

诀窍不是避免出现空白。诀窍是在开发过程中尽早填补这些空白。

您是正确的，如果开发人员做出假设，那么他们肯定会是错误的，这将花费时间在以后重新开发软件。但是，同样地，如果期望商务人员在不知道自己真正想要什么的情况下进行完整的前期设计，那么同样的事情将会发生。

在客户通常不真正知道的时候，弄清楚客户想要什么是开发人员工作的很大一部分。

首先，提出问题。如果您得到的答案似乎不令人满意，请创建一个原型。向客户展示他们的要求，并让他们告诉您这不是他们真正想要的。从一个纸质原型开始，然后转到没有任何代码的基于HTML的原型。然后进行最少的开发，以生产出几乎可以正常工作的产品并向他们展示。尽可能将棘手的部分留在过程中。

这本身听起来很耗时，但是与重新开发假定完成的产品相比，事实并非如此。

此外，请使故事尽可能小。企业始终想要的是史诗般的东西，可以分解为许多可交付成果。这样会更好，因为当他们看着最终发行版的候选人并大喊“哦，不，那不是我们想要的东西”时，您的发展不会太多。

即使到那时，找到合适的东西来填补也要花费时间，在不同程度上，这被认为是与初始估计的偏差。

这对我来说听起来不是很“ XP”。

我绝不是XP专家，但是AFAIK XP的想法是，只要您从过程中获得反馈，就不断调整您的规格和估计。并且该过程是“稍微分析-稍微设计-稍微编码-稍微测试-然后尽早获得用户反馈以纠正错误的假设。例如，您还可以尝试更早地获得用户反馈。在设计了软件的某些部分（例如UI）之后，在纸上或白板上与用户或客户进行讨论。我不认为“ XP方式”会因为具有“用户故事”。

这是一篇很好的文章，介绍了如何通过使用规范更早地获得反馈。我认为这种思维与“方法论”无关，那里提出的论点将帮助您与管理层进行辩论。

总结一下，您处于以下情况：

1. 你是新来的。
2. 该项目（我想您正在谈论一个正在运行的项目）具有紧迫的时间限制。
3. 开发人员应自行决定填写空白。
4. 您所在的公司打算练习XP。但是，似乎没有以适合XP方法的方式应用用户案例。另一方面，“ 开发人员应自行决定填写空白 ”。

考虑第4点：我的观点是，敏捷实践应适应公司/团队的需求和文化（而不是相反）。确定公司坚持XP方法论的地方以及偏离的地方。这是针对您的问题采取建设性方法的基础。

由于1和2，您目前无法很好地质疑公司是否以合理的方式应用XP。与管理层进行讨论很可能使您成为“ 使事情变得复杂 ”的人。但是，您可以开始与其他开发人员讨论您的担忧。也许您会发现一些开发人员以您的方式思考。也许会有一位高级开发人员将您的疑虑传达给管理层。但是不要期望事情会很快改变，尤其是在当前项目中不会如此。但是，该项目将为您提供一个收集更多数据的好机会，这为建设性方法增加了更多实质。

现在到第3点：我认为，好的用户故事是由客户/最终用户/产品所有者和开发人员共同编写的。展现一些主动性：寻找机会直接询问用户故事的作者。如果无法做到这一点，请问一些高级开发人员或管理人员如何处理未解决的问题，这些问题必须由用户故事的作者回答。也许您至少可以有一些书面信件。由于您需要自行决定填写空白，因此您的选择应该是积极吸引客户/最终用户/产品所有者。

在某些时候，您已经对公司如何应用XP（或一般的敏捷实践）进行了充分的思考和观察。也许已经过去了一段时间，您不再被视为新角。也许您与客户的积极参与已显示出一些积极的影响。也许下一个项目已经开始。也许您也已经从其他开发者那里得到了一些备份。也许您发现它的工作方式还不错。关键是，您将根据公司内部的实际经验和数据，有足够的想法将您的疑虑传达给管理层。

坦白地说，用户故事不应包含很多细节。“我希望软件做X，满足Ÿ业务需求” 应该是足够的。毕竟，您不希望业务人员决定如何执行此操作-您是其中的软件和最佳实践的专家。

也就是说，开发人员还需要问：“您希望它如何工作？”，“当它与功能Z交互时会发生什么？”。开发人员不提出要求，而是制定实施方案。

听起来，实施和评估之间似乎还有太多差距。利益相关者应该每隔几天就以半完成的代码查看原型。这样一来，您就可以在杂草丛生之前获得反馈。

如果要求您估计一个看起来不完整的故事，请告知您有关该故事的问题，并且在回答这些问题之前无法给出正确的估计。

然后，提出您的问题，并确保答案成为故事的一部分。

如果即使没有（全部）回答您的问题也被迫做出估算，则可以选择拒绝给出估算，或者明确表示您对估算中的其余空白假设最坏的结果（即可能会使您的估计值更高）。

您所做的不是敏捷的开发方式。相反，您的工作质量较低。敏捷的开发方式没有指定需求是错误的。

相反，他们需要最初指定尽可能多的内容，如果需要，可以在以后进行更改。然后，您将您的工作分解为多个部分并进行迭代实现。每次迭代之后，您都会完成一些操作。

与瀑布式开发的不同之处在于瀑布式开发，所有内容均按初始要求实施，并在最后进行更改。

听起来好像开发人员已从创建用户故事中完全删除了。您是否希望能够像详细的规范一样阅读它们并在第一时间构建它？如果可以做到，则不需要XP或任何其他敏捷方法。

如果故事太含糊，应该有人问。验收测试在哪里进行？

用户故事必将发生变化。您需要处理它。

尽管开发人员可以编写故事/详细要求，但我还没有看到很多擅长该故事的人。我们擅长指出问题，建议更好的流程，但作为已经写得很好的案例的输入。

曾经在新产品和现有产品上工作过，并且都遇到过这样的情况，即要求只有5行，我们应该填补空白并做出“理解”或更详尽的文档。

项目进展得好得多，然后我们有了自己的专业服务人员来帮助解决这个问题（或者在一个案例中，由于没有其他人，一位副总裁也加入进来）。无论哪种方式，都浪费了开发时间（除非没有反馈，并且截止日期没有改变）。因此，我的建议是：索取更多详细信息，提供更多信息，要求您对假设和文档进行时限反馈，并指出，如果您在x日期之前未获得此信息，则存在返工和延误的风险。

不管开发方法论如何，如果您用来定义需求的任何事情使开发人员做出假设，则都需要将其放回业务方面。我通常会对自己想要的答案有个好主意，所以我会像下面这样退缩：

XYZ对我不清楚。意思是ABC吗？还是我错过了什么？（假设XYZ是要求，假设ABC是我想作为开发人员进行的假设）

在做出错误的假设之前，清除问题所需的时间要比重做少得多。在未确认自己的猜测正确的情况下对需求进行猜测的开发人员往往是糟糕的开发人员，并且使他们的公司付出了很多钱。如果一个坏经理不会让你退缩，那么请向他解释在时间和金钱上要付出多少代价是错误的。如果他仍然坚持，那么请按他说的做，当UAT无法通过时，下次您想退回某些款项时，请提醒他这是他不让您这样做的代价。如果他仍然不听话，那就找一个更好的老板。

退缩的另一个价值是，企业将逐渐了解您的需求并提供更好的要求。

作为开发人员，

我需要充分了解用户故事的细节，

这样我就可以放心地估计和实施它。

换句话说，您必须提出问题，直到您了解故事的细节。这是在迭代计划中完成的，并且充当决策点：如果无法估计，就无法构建。