在我们的商店，我们努力做到敏捷。我想说我们正在取得长足进步。就是说，我们中的一些人发现了一种模式，我们已经开始将其称为“故障驱动开发”。
基本上，可以将失败驱动开发描述为一个敏捷的发布/迭代周期，其中的错误/功能不是由具有接受标准的任务和故事来指导，而是由缺陷跟踪软件中输入的缺陷来指导。
我们的团队有一个出色的项目经理，他努力从客户那里获得验收标准，但这并不总是可能的。从我的开发主席那里，这是由于客户要么不完全知道他们想要什么，要么是（这是踢球者）客户总公司的两个不同“营地”与故事的实现方式冲突。营A将松散决定了功能X的作品像这样，那么营B就失败，这是由于不喜欢运行的是。因此，术语“ FDD”。该过程是由“故障”驱动的。
这引出我的问题：是否还有其他人遇到过这种情况？
当然，我们已经尽力让A和B营地达成一致，但每个人都知道并非总是如此。
谢谢
Answers:
在企业界，相互矛盾的要求并不罕见。这通常是业务流程自动化项目“失败”的原因。它可以很简单，例如“政策和程序手册说要做X”，而实际工作的人则做Y。将软件做成Y意味着要付费的人会坚持认为软件存在缺陷。透视。将软件制作为X意味着实际完成工作的人员无法完成工作。
通常，大多数开发公司会选择经理说什么，而不是工人说什么，因为这就是账单的支付方式。在理想情况下，书面政策与实际政策之间不会存在阻抗失配的情况。在现实世界中，许多办公室工作都是非正式地划分且没有文件记录的。
营地A会错误地指示Feature X像这样工作，然后营地B将由于功能失效而失败。
CampA和CampB之间的不匹配是一个政治问题，而不是软件问题。解决问题将涉及与人交谈并获得一名明确的获胜者。
使用迭代开发的主要原因之一是因为您有一个客户群，但对该客户群的需求并不了解。
这不是失败。直到他们掌握了一些东西，许多客户才完全不知道自己到底需要什么。这就是为什么他们第一次看到客户认为系统在安装和完成完所有功能后就不会出现故障的原因。让他们及早和经常看到它。
换句话说，如果那是唯一的问题，那么除非您陷入无休止的重试的境地，否则不必恐慌。
客户主体之间的分歧是产品经理的问题，不应泄漏给您。您应该看到的最多是积压/任务/所有内容。当然，PM经常会在开发范围内发泄，因为那是他们唯一可以做的地方，但它不会影响您。
如何管理很大程度上取决于A营和B营。
如果营地A和营地B代表两个更高的级别，则请一个实际使用该系统的人来告诉您您需要什么。有时您会在管理领域中获得稀少的空气，从而与现实脱节。经常动手的人经常会突破理想主义，指出真正需要什么。
另一方面，如果A和B是用户组，则使用相反的方法，即让某人从管理层那里制定法律。
在所有情况下，完美都是足够好的敌人。
您描述的是敏捷的典型错误实现。你不拥抱变化，你是变化的奴隶。
您有产品负责人吗？您可以根据需要与他们交谈吗？您是否正在与用户进行冲刺审查？用户是否在冲刺计划中（通过产品所有者）参与了流程？您的主要团队中有测试人员吗？
我强烈建议您雇用一名敏捷教练和/或派遣团队参加培训。
另一个解决方案是停止执行敏捷。
这里的问题似乎不是“我一看到就会知道”。线框可以（最大程度上）解决该特定问题。
在我看来，这里的问题是您客户内部的两个相互竞争的派系。理想情况下，A营和B营将提出一些可以传达给您的协商一致的愿景。
也许当您再次重做A为B的要求时，您可能会通过解释内斗给他们带来多少费用而被迫上桌。
详细记录您的时间花费将对您有所帮助。（我的工作写了一个轻量级的时间跟踪应用程序：易于使用，易于报告，并且以15分钟为一个块报告时间。这很容易说“我在功能X上花了n个小时”。）
这确实意味着，无论您做什么，都有使客户烦恼或看上去很糟糕的风险，因为您为B所做的事情可能会使A烦恼（反之亦然）。
希望您能在客户身上找到一个冠军，可以为您处理内斗。
如我所见，该问题只能在客户的一个地方有效地解决，这将是困难的。
您提到的是您正在为敏捷而努力，所以我将从scrum的角度出发，这是我最了解的敏捷过程。
根据scrum的说法，您有一个特定的角色，产品负责人，负责对用户故事/错误/发行版等进行优先级排序。理想情况下，这应该是一个人。如果在同一软件上有许多有不同意见的相关方，则产品所有者有责任使产品满足所有相关方的责任。
在我看来，您的项目经理扮演着这个角色。但是由于他被称为项目经理，而不是产品所有者，因此我被认为他也承担着其他任务（传统的，非敏捷的，管理任务？），并且没有足够的时间从事产品负责人的角色。
因此，我认为您需要一个负责协调客户不同团队之间需求的人员，以确保交付给开发人员的需求/用户故事已经被客户两个团队验证。担当这个角色很容易成为一项全职工作，尤其是对于您拥有的客户而言。
真正理想的是将这种责任转移给客户，让您的一位客户员工担任产品负责人。只要客户没有这个角色，客户就不会致力于解决他们自己的内部分歧，他们将由您来解决，而您很可能无法解决。这就是为什么我相信唯一有效的解决方案是赋予客户这一责任。
但是考虑到您已经开始进行协作，我相信您将很难实施该更改。