如何将敏捷应用于涉及复杂处理的应用程序？

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序，在该应用程序中，用户非常了解幕后情况。（这很好，因为所编写的大多数代码可能都属于此类。）

对于这种类型的应用程序，用户故事（需求）和开发任务之间的关系通常很简单：只需将用户故事分成几个任务即可。

但是还有另一种类型的应用程序，其中大多数代码必须处理用户不直接可见的复杂处理。例如：

• 编译器
• 自动驾驶汽车图像分析系统
• 流体模拟系统

在这里，将任务和用户案例联系起来确实非常困难。是否有克服这一问题的技术，或者仅仅是我们必须接受并充分利用的技术？

事实证明这比我计划的要长（它开始只是评论），但是我希望增加的长度/详细信息对您有所帮助，您会发现它们是合理的。

敏捷并非特定于CRUD应用程序

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序，在该应用程序中，用户非常了解幕后情况。（这很好，因为所编写的大多数代码可能都属于此类。）

我认为这是因为创建此类易于遵循的示例更加容易，而不是因为该方法针对的是此类系统。如果您创建了一个不太容易理解的示例，则当您认为要向读者教授敏捷概念时，您可能会冒着使读者陷入尝试理解该示例的风险。

用户故事！=要求

对于这种类型的应用程序，用户故事（需求）和开发任务之间的关系通常很简单：只需将用户故事分成几个任务即可。

用户故事是不一样的要求。的确，根据需求的“高级”程度可能会有一些重叠，但通常并不相同。我得到的印象是，您遇到了很多我的前任经理都陷入的同样的陷阱：仅将用户故事视为“要求”的同义词来思考，这类似于SVN用户尝试过渡到Git时，但是根据SVN进行思考。（由于糟糕的起步假设，他们随后遇到了问题。）

恕我直言，需求和用户案例之间的主要区别在于需求详细指定了某些系统组件应如何运行；它们是包括输入，输出，假设/前提条件，可能引发的异常等的规范。它们专注于系统的工作。

OTOH，用户故事集中在最终用户的预期结果上，而没有尝试为系统组件创建详细的行为规范。他们专注于预期的用户体验。

我曾经做过的事情（这是我的团队采用的一种做法）是将用户故事分解为任务。您的任务可以像您希望/需要的那样具体或模糊，但是它们的目的是作为使故事达到完成状态的实际工作的进度指示器。

例

我大概回想起几年前在美国工作过的情况，在该情况下，用户需要自行分配测试用例，以便团队中的每个人都知道他们正在研究哪个TC，以避免重复工作。UI是一个内部Web应用程序。用户只看到一个按钮，但是故事被分为几个任务，其中包括一些技术实现细节等。

用户可见度

但是还有另一种类型的应用程序，其中大多数代码必须处理用户不直接可见的复杂处理。

是否可以通过某种方式使其对用户可见？

考虑一个GPS。当您错过转弯时，您将不会看到实际的路线重新计算过程，但是用户确实会收到一些有用的反馈（例如“重新计算...”）。

编译器可能会显示警告或错误，或者在GUI中包含新的设置/选项，以使用户看到已添加的新内容。我认为编译器的用户将是程序员，对吗？他们不会看到对新标准的支持吗？

虽然支持新标准可能是在功能级别，并且需要分解为用户故事，但是您是否确保至少在某些情况下在使用功能时不尝试使用故事？ ？

汽车中的图像分析可以用一种措辞来表达，即让用户知道减少了撞车事故的可能性。例如：

作为自动驾驶汽车上的乘客，我需要使车辆因撞到无法识别的物体而导致事故的可能性尽可能接近零，以便我可以更安全地行驶。

美国在较高级别上捕获了通常需要结合功能和非功能要求（包括安全性，安全性等）指定的事项。

但是，对系统的要求可能更多。例如：

abc组件的功能A必须在图像比较算法中降低公差阈值，以更好地检测缓慢移动的对象。

对我来说，这很容易成为我上面提到的用户故事中的一项任务，标题为：降低功能的容忍度A.abc，然后在其中包含其他相关细节。

对于流体模拟系统，您甚至可以使用进度条，如果有必要，它会提供有关系统正在执行的后台任务的反馈。（尽管您可能想避免成为垃圾邮件，但总有一种方法可以通知用户某些内容。）

对于所提到的特定领域，我还不够了解，无法提供更好和/或更现实的示例，但是如果这里有个收获，那就是您可以使用不同的方式向用户提供有关不可见内容的反馈信息系统可能正在做，即可能有办法使不可见的事物更加可见。（即使归结为编写一组发行说明，这些发行说明记录了由于您的努力等原因导致系统性能现在提高了多少）。

故事与任务之间的关系

在这里，将任务和用户案例联系起来确实非常困难。

我们的做法是保持用户的故事集中在哪些请求是，为什么有人做，并且是有什么事情需要真正考虑美国的“完成”。该怎么总是被排除在美国和留给开发人员（一个或多个）。

开发人员可以将在美国描述的问题分解为他们可以处理的一组任务。

我的意思是说，大多数情况下，他们都进行了后端服务器端编程，这对于最终用户来说可能是“隐形的”。

根据我需要执行的操作，有时我会使用AJAX来显示一个简单的“正在加载...”动画/ gif，以便用户知道他们需要稍等片刻才能完成其他操作，而不会得到错误的印象。有时就是这么简单。为此的任务将是适当的。

不同的范式，实践和经验

是否有克服这一问题的技术，或者仅仅是我们必须接受并充分利用的技术？

除了接受范式转换，实践和积累的经验外，也许还不多说。我经常看到人们试图在整个过程中采取捷径。我建议您不要这样做，尤其是在您入门时。随着您获得更多的经验，您可以允许一些灵活性，但要避免损害自己。

考虑到您之前的措辞，您仍在考虑将故事视为“重命名的需求”，我认为这是错误的假设。我认为这是关于敏捷方法和非敏捷方法之间的根本差异的更深层问题的征兆。

其次，我认为您应该接受敏捷性相对于瀑布式的范式转变，这意味着尽管流程具有相似的目标，但实现方式却截然不同。（如果有帮助，请考虑SVN vs Git。）

尝试提高您对需求和用户案例之间的概念差异的当前理解，并接受它们不是一回事。

向冲刺学习-回顾

我不足以强调的是，每次冲刺结束时Scrum Master和Developers之间的回顾。在那儿，他们以诚实/透明的方式讨论“做得好”或“做得不好”的事情，接下来的冲刺将实施哪些可行的更改以解决“做得不好”的要点。

这使我们能够适应甚至借鉴彼此的经验，而在我们不了解之前，以我们团队速度的总体一致性来衡量，我们已经取得了显着进步。

在这些情况下，可以肯定采用敏捷原则。怎么样？

• 编译器可以在以后的单独用户故事中添加新的语言功能
• 图像分析系统可以添加新功能，作为不同的图像分类
• 流体模拟系统可以在模拟中考虑不同的模型方面

您不必一口气吃掉整个大象。敏捷只要求您证明您在下一份大象之前就已经清洁了盘子。

我发现严格遵守用户故事的人们要么只是愚蠢地提出了一些牵强附会的方法，这些方法以后端技术变更影响用户（当然，这对于用户来说是天真的，这对用户而言并不为人所知）用户，而您正在谈论的是数据分析管道中的复杂变更或类似的变更），否则，他们将完全为“我们如何组织这项工作！

我认为显而易见的解决方案是更加务实。如果这项工作本质上是非常技术性的，并且对用户没有特别明显的影响，请不要因为试图解释它的工作而昏昏欲睡。只需选择一种显而易见的简单方法即可使用户受益，然后围绕开发人员完成工作所需的细节定位故事。当PO绝对必要时坚持不提供故事中的技术信息时，我会感到非常沮丧。对于那个工件（故事）的真实情况，这不是一个非常全面的看法。就像他们认为它只是为他们而存在一样，在大多数情况下，它对工程师也很重要。

对于这些技术任务中的大多数，在影响用户方面是否有一些悬而未决的成果，无论这是否正在提高效率，因此未来的交付将更快，性能，可靠性等得到提高。它们并不是人们在想到“用户故事”时通常会想到的东西，但是如果企业想了解您为什么承担技术债务或类似的事情，那么这些解释通常是最简单的。

tl; dr不要仅仅因为它们太大而无法适应，所以不要让乱序使您的生活更加困难。适应性毕竟是敏捷的核心概念。严格遵守Scrum或敏捷通常会面子苍白或实用主义和实用性（实际上最有效的方法）。

我认为问题在于给用户故事一个他们没有的含义。Scrum使用术语PBI或Product Backlog Item，我认为这是更好的选择。所涉方案会经常跟随用户故事的格式，例如，你可能有一个PBI像“订户应该能够查看他们的订阅范围”，但你也可以很容易地有PBI像“创建一个存储过程来获得用户的详细信息”。

用户故事是一种工具。它们帮助您根据自己的习惯来形成功能描述和要求。但是，就像当您需要悬挂图片时用扳手没用一样，有时您可能不需要用户故事。

就是说，许多团队实际上只是在“用户”部分进行松散的比赛。他们可能有“用户故事”，例如“作为开发人员，我需要能够调用存储过程以获取订户详细信息”，本质上就是“开发人员故事”。这是一个同样有效的选择，但就我个人而言，我想说的是，只要您能描述需要完成的工作并提出一套接受标准，那么是否有实际的用户故事就无关紧要。

这些类型的应用程序正是具有不同专业知识的应用程序，并将进一步发展。由于不同的教育，不同的业余爱好项目以及不同的过去工作经验，团队成员将具有不同的技能。此外，如果有人开发特定代码，则可以期望开发人员是最了解该代码的人。因此，将涉及同一段代码的更多开发任务分配给同一开发人员可能是有意义的。

在最流行的敏捷流程Scrum中，有计划的扑克，其中为每个任务分配了一个难度级别。难度级别不取决于根据流程执行任务的人员。然后在冲刺期间，人们被认为是同质的，因此希望每个人都能选择并执行每个任务。在像项目这样的简单CRUD中，此假设成立。但是在非常复杂和困难的项目中，肯定没有。

对于这类项目，我不会使用敏捷过程。最好的选择是避免任何正式流程，而要使用良好的项目管理。在决定谁实现特定功能时，请考虑谁具有此功能所需的最佳技能以及对现有代码的最佳了解。不需要任何处理。您可能希望为所有功能编写好的设计文档并保持最新。请注意，我不是在这里推广类似瀑布的模型：设计文档不会在项目开始时就全部编写；您将根据需要的新功能编写新的设计文档。