我习惯于规划软件，其复杂性在于用户交互。我学到的敏捷软件工程原理非常适合这种情况。当大部分规划围绕用户的交互时，用户故事很容易写出来。
我现在正在研究一个系统，在该系统中，用户唯一的干预就是按下go按钮并在出现错误时读取错误。
该系统的所有其他工作都是数据处理和非常繁重的数据处理。我在这个处理工作流程中有大约5种不同的数据转换。
这些流程本质上是松散耦合的，因此它们应该很容易作为不同的流程进行规划，然后进入工作流程。即便如此，规划数据驱动流程的问题仍然存在，但规模较小。
我该如何规划这样的数据驱动流程？这类软件是否有任何已知的设计流程？
答案 0 :(得分：1)
同样的！
规划和迭代开发的敏捷原则可用于任何类型的项目。这仍然可以由用户驱动，但您可能必须扩展“用户”的概念。谁将最终使用您正在构建的软件？自己呢？技术团队？其他流程？ “真正的”用户？无论他们是谁，你都需要将它们包含在设计中，并让他们与你讨论规格。
首先确定用户想要的优先级。他们希望看到的“核心”功能集是什么，和/或新流程的最重要的架构定义功能是什么？计划它们的前几次迭代。 （在迭代0之后设置开发环境）。在这些结束时，您的系统将不会做它应该做的所有事情，但这将是一个开始。此外，关注端到端的故事。最好在早期生成输出，即使它不是所需的输出，然后重新进行重构以改进输出。
继续按照惯例编写用户故事，也许在每个故事的开头添加一个句子：“作为XXX，我想......为......” 。因此，每个故事都与该故事的原始请求者紧密相关。 （XXX可能是您自己，另一个系统或真实用户）。
尽早关注全面的验收测试。 （也许使用像JBehave或FITnesse这样的自动化框架（如果你使用Java，但我认为每种语言都有替代品。）对于数据驱动的项目，这些是最重要的：它们将充当文档您应该以这种方式构建您的接受测试：从“空”（或“给定”系统）开始，当您添加XX和YY以及ZZ作为数据时，结果应该是只要他们一直看到并得到用户的认可，就可以在你的验收测试中进行黑客攻击和削减。（不要对它们做任何假设，验证一切）< / p>
然后迭代后迭代，添加复杂的层，直到达到所需的规范集。
我参与了几个基于数据管理和处理的中型到大型项目（存储库，包括从不同来源合并，维护“黄金来源”，双时间数据库，为其他外部系统提供服务等）基本上，团队越敏捷，项目越成功。到目前为止。
答案 1 :(得分：0)
使用某种形式的验收测试（BDD现在受到很多关注）可以提供帮助。结果PDF肯定有不同的“功能”，你想要确保存在，不是吗？我建议尝试使用BDD验收测试来向最终用户转移验证（提供反馈）这些功能的责任。