如何处理“失败驱动的开发”？

Question

在我们的店里，我们努力做到敏捷。我想说我们正在取得很大的进步。尽管如此，我们中的一些人已经发现了一种模式，我们已经开始称之为“失败驱动的开发”。

失败驱动的开发基本上可以被描述为一个敏捷的发布/迭代周期，在这个周期中，错误/特性不是由带有接受标准的任务和故事指导的，而是由缺陷跟踪软件中输入的缺陷所引导的。

我们的团队有一个伟大的项目经理，他努力从客户那里获得验收标准(S)，但这并不总是可能的。从我的开发讲座来看，这是因为客户要么不知道他们到底想要什么，要么(这就是问题所在)客户的主办公室里的两个不同的“阵营”与如何实现一个故事相冲突。A营会松散地规定X功能是这样工作的，然后B营就会失败，因为它不能像那样发挥作用。因此，“捍卫民主阵线”一词。这一过程是由“失败”驱动的。

这就引出了我的问题:是否还有其他人遇到过这种情况，如果是的话，有什么建议可以解决吗？

当然，我们试图让A营和B营事先达成一致，但每个人都知道情况并非总是如此。

谢谢

Answer 1

在企业界，严重冲突的要求并不少见。这经常是业务流程自动化项目“失败”的原因。就像“政策和程序手册说要做X”一样简单，而实际工作的人则做Y。让软件做Y意味着支付软件的人从他们的角度来看软件是有缺陷的。让软件做X意味着实际完成工作的人不能完成工作。

通常，大多数开发公司会选择经理说什么，而不是工人说什么，因为这就是支付账单的方式。在理想世界中，书面政策和实际政策之间没有阻抗错配；在现实世界中，许多办公室工作是非正式划分和无文件记录的。

夏令营将愚蠢地规定，功能X像这样工作，然后营地B将失败，因为没有那样的功能。

CampA和CampB之间的不匹配是一个政治问题，而不是软件问题。解决这个问题需要与人交谈，并获得一个明确的胜利者。

Answer 2

使用迭代开发的主要原因之一是，您有一个客户团队，它不太清楚它想要什么。

这不是失败。许多客户只是不知道他们到底需要什么，直到他们得到了他们手中的东西。这就是为什么他们第一次看到系统不应该是在所有的适合和完成已经完成。让他们看到它的早期和经常。

换句话说，如果这是唯一的问题，没有必要惊慌失措，除非你在一种情况下，你只是有无休止的重试。

客户群体之间的分歧问题是产品经理的问题，不应该泄露给您。你最应该看到的是积压/任务/任何东西。当然，PM经常会在开发范围内发泄，因为这是他们唯一能做到的地方，但它不应该影响到您。

如何管理将在很大程度上取决于谁是A营和B营。

如果A营和B营代表两个更高的级别，那就找一个真正使用系统来告诉你需要什么的人。有时，你在管理土地上得到稀薄的空气，导致你与现实脱节。一个人的手，往往可以突破理想主义，指出什么是真正的需要。

另一方面，如果A和B是用户组，则使用相反的策略，让管理人员制定法律。

在任何情况下，完美都是足够好的敌人。

Answer 3

您所描述的是敏捷典型的错误实现。你不拥抱改变，你是它的奴隶。

你有产品负责人吗？你能在需要的时候和他们谈谈吗？你在和用户一起进行sprint评审吗？用户是否(通过产品所有者)参与了sprint计划？你们的主要团队里有测试人员吗？

我强烈建议你聘请一名敏捷教练和/或派遣你的团队参加培训。

另一个解决方案是停止执行敏捷。