开发人员可以期望多少有关用户故事的细节？

我所体验到的敏捷开发的最大缺点是，不参与开发的人们专注于这样的口头禅：用户故事（3-10个理想人日）不应包含超过1-3个句子，例如：

作为客户，我可以使用自由文本搜索，以便找到所需的产品。

给出这句话，项目经理希望我作为开发人员致力于估算并开发故事。他们认为敏捷开发意味着他们必须提供给开发人员的此类语句。

我不会责怪他们，因为关于敏捷开发的著名文献给人以这样的印象，即它实际上是可行的。在“ Planning XP”中，每个故事我都用自然语言阅读了大约2页，但这就是事实。因为“工作软件”比“综合文档”更受青睐，所以似乎通常避免使用此主题。

当然，现实是，如果开发人员有机会这样做，则与客户的访谈会提出一长串客户对故事的要求清单：

• 我们需要布尔运算符，例如AND和OR。
• 我们需要所有的模糊搜索。
• 我们需要按单词和短语进行搜索。
• 我们不想找到符合标准X，Y和Z的产品。
• 我们要对结果进行排序。哦，顺便说一句，用户可以在带有选项a，b和c的组合框中选择排序标准。

所以您看到我不是在谈论技术细节，软件设计甚至实施细节。这是纯粹的要求。我们交谈的时间越长，客户就越能意识到他们想要的东西很多。

但是，我经常发现自己处于这种情况，即没有提供此类信息或以次充好方式。我既不可能进行面试，也没有可能进行面试的人为我提供面试的结果。

有时，经理甚至会提出“我们希望进行Lucene搜索”之类的技术细节，但他们不想考虑是否只想查找产品名称或产品描述。有时我认为他们只是懒惰;）

对我来说，这是我工作的项目中的头号问题（电子商务Web应用程序，每个项目500-2000人日）。我已经足够频繁地解决了这个问题，并且经理们意识到大多数开发人员对此情况都有疑问。但是他们认为开发人员实在是太“完美主义者”了。他们似乎对开发人员“总是希望指定所有内容”感到恼火。

由于缺乏公认的数字，因此很难争论。每个人都知道迭代应该持续多长时间。但是没有人能说出估计和发展一个故事需要多少需求。

你有参考吗？

您缺少一点敏捷性。在您所说的用户故事中，我至少看到了六个：一个简单的搜索，一个针对每个要点。一定要制定足够的计划，以免陷入困境，而陷入困境将使自己陷入困境，但总的想法是，您提供提供某些价值所需的最低限度的知识，并以足够快的速度获得快速的反馈。

当您按这样的方式划分一个故事时，它不仅使估算更容易，而且还使产品所有者可以以更细粒度的方式确定优先级。当然，他们喜欢对搜索结果进行排序的功能，但也许它不像积压工作中与搜索完全无关的另一个项目那么重要。

另外，关于程序员需要指定的所有内容的想法，请尝试从客户的角度来看待它。很多时候，这就像您要去买车，而推销员则问您想要挡风玻璃刮水器旋钮的颜色是什么。从客户的角度来看，我们可能发现重要的许多细节是完全不相关的。我曾在要求被过度指定的地方工作，请相信我，这不是很有趣。您抱怨的那种自由度，很多程序员都希望拥有。

听起来像第一个问题是，您不应该将时间估算应用于用户故事。您应该讲一个故事并应用“故事点”，这是对从1到INFINITY的复杂度的一般估计。故事点通常运行像1,2,3,5,8,13,20 ...（每个组织都有自己的规则。）它们通常适用于：

1-您可以在睡眠中做到这一点，几乎不值得实施。2-您了解这一点，并且可以快速完成它，而没有超限的风险。3-您了解这一点，但可能会有一两个惊喜。5-这将进行一些研究，并且风险很小。8-这是一项艰巨的任务，需要大量研究，并且可能不适合进行冲刺。13-这是巨大的，绝对不适合短跑。存在巨大的风险。等等

通常，任何8以上的用户故事都需要细分为较小的故事。

如果没有足够的信息来执行此操作，则绝对应该将其退回给项目经理，并说您需要更多信息。

确实，只有在您将故事接受到冲刺中之后，您才应该估计时间，但是即使如此，对此的强调也很少。这样的想法是，一旦您的团队习惯了指点过程，就可以在故事点中衡量每个冲刺的粗略输出，并以此方式进行规划。您不希望在比冲刺短的时间内进行计划。这里的想法是，如果您正确地分解任务以使多个故事适合一个冲刺，并且处于1-5个故事点的范围内，则意味着它们定义得足够好。

同样，听起来您公司的PM也不了解什么是“故事”。“用户故事”的关键部分是退出标准。退出标准是一两个简短的句子，明确描述了如何显示该存储已完成。理想情况下，您的质量检查人员应该说的是“是的，我们可以对此进行测试”。重要的一点是，当软件满足“退出标准”时，PM必须了解用户故事已完成。“但是我们不想要那个”并没有削减它。如果他们不希望交付什么，但符合退出标准，则他们必须输入新的故事。

这里肯定有一个“培训PM”的元素。他们必须了解，模糊的故事会导致故事内容过多，并且如果他们将故事定义得模棱两可才能获得想要的内容，那么他​​们就必须重新做一遍。

显然，如果利益相关者没有收集到足够的信息，那么您就必须这样做；如果必须，那么这还需要做很多工作，不是吗？在敏捷时代之前很久，我通过提供非常大的估算值而获得成功，并明确表示估算值太大，以至于由于缺乏信息而导致风险。我必须假设所有问题的最坏情况，并根据最坏情况进行估算。我发现，经理们看到它们会导致估计下降时，更愿意提供更多细节。

这不是游戏系统...这是完全有效的。如果您不知道它是“ A”还是“ B”，则可以根据估算值来估算出最大的资产。

根据我的经验，我正在处理的许多更改或项目都涉及到此问题。Custom X想要一些东西，他们对想要的东西有一个想法，但是它们只给您带来少量的电子邮件需求。这主要是因为客户并不“完全”知道他们想要什么。这就是为什么我们大多数客户服务部门的工作是充实那些客户需求并过滤所需的信息，同时还能预测客户真正想要的或他们真正需要的东西。

假设某个客户（对我而言）希望我们的Web应用程序中的一部分向其返回所有电话号码的列表。他们从不指定是指物理上的，逻辑上的，分配给某个人或某个位置的等等。他们只是想要所有电话号码。作为开发人员，我可以坐在那里思考很多问题，就像您遇到的一样，我需要向客户提出一些问题。但是，正如您所说，这是不可能的。这就是为什么拥有一个了解产品和客户的宝贵客户服务部门非常宝贵的原因。

当这种电话打给我们的客户代表时，他们就可以与客户进行详细说明，知道他们需要什么才能让他们回答正确的问题。他们也有远见，知道客户过去曾要求什么，并且他们对我们开发的系统了解得足够多，他们甚至可以在不询问客户的情况下对某事说是或否。

当然，在很多情况下，客户端仍然需要您和客户端服务都错过的其他东西，但这总是会发生的。您的目标以及客户服务的目标应该是最大程度地缩短开发某些东西与从客户那里获得需要进行更改的东西之间的延迟时间。而这仅取决于与客户服务的沟通和培训。

也许对您而言，这并不像我现在所处的位置那样可行，但是与客户代表保持良好的沟通和信任关系几乎总是会在一定程度上帮助您，并且会减少您的沮丧感并提高客户的满意度。另外，您可以更轻松地为项目提供一个时间范围，而不是耸耸肩说“我不知道项目的全部范围，所以我不知道要花多长时间”。我们在这里遇到了同样的问题，更好的沟通和培训可以帮助我们制定合理的期限并始终如一地达成目标。

顾客

我要搜寻产品

产品经理 我已经分析了客户的故事，并提出了以下要求。每个需求都被记录为单独的用户故事。

• 搜索产品
• 排序结果
• 过滤搜索结果

开发人员 我从产品经理那里收到了用户案例。我已经分析了每个用户故事，并提出了每个用户故事的任务列表。

• 搜索产品
  1. 任务1：数据库更改
  2. 任务2：服务器端更改
  3. 任务3：前端更改

客户，产品经理和开发人员都是此过程的利益相关者。他们都需要在工作开始之前为分析过程做出贡献。请注意，这是非常简化的示例。

我们的用户案例按以下顺序进行分析和完善（当然会有一些变化）：

服务台->产品负责人->产品经理->部门主管（高级开发人员，质量保证主管等）->开发人员

一旦所有相关的利益相关者都对分析过程做出了贡献，我们就可以估算出传递故事所需的时间。我们遵循的估算过程基于各个开发人员的速度和专业知识。

我并不是说这是正确的做事方式，但在我们组织内部确实运作良好。