坏消息：敏捷与ERP，第4部分

到目前为止的故事…

• 第1部分：敏捷和ERP介绍
• 第2部分：好消息：敏捷可以与ERP合作！
• 第3部分：文化：敏捷与ERP文化如何冲突

在这个小型系列文章中，我将讨论ERP系统上的敏捷开发。 如果您正在执行此操作，并且刚刚在Google搜索了“ Agile and ERP”，那么您很有可能找到该博客，因为……坏消息……在ERP环境中进行敏捷的经验不足。

当然有人这样做了，当然有人在博客和期刊上写了关于它的内容，但是我说：“有些”。 有些意味着“不多”。 在ERP环境中进行敏捷的问题之一是缺乏知识和经验。 人们已经做到了这一点，但我本人已经“完成”了几次，但是……没有像在Java Banking或其他领域中那样敏捷地在ERP中完成敏捷。 他们中几乎没有人写下自己的经验。 很少有好故事要讲。

部分地归结为一个问题：“您对敏捷的含义是什么？”。 如果将“敏捷”定义为可在ERP设置中使用的“敏捷”实践，则可以肯定的是，您可以在ERP中执行敏捷。 另一方面，当您找到现有的示例时，会发现许多实践缺少，特别是技术实践。

您几乎会发现有关ERP中Agile的所有报告都是关于过程的，这与我之前的帖子很相似。 用测试驱动开发，验收测试驱动开发，简单设计，紧急设计和重构来进行ERP几乎是闻所未闻的。

当然，那里有一些博客对此进行了一些讨论，但没有太多。 我向招聘人员进行了简报，以寻找具有（A）TDD和ERP经验的人员。 几周后，他回来了。他说：“这就像在寻找独角兽，这些人不存在。”

部分原因是因为ERP系统是按一切承诺出售的。 他们的设计可以追溯到几十年前，因此它们是整体的，其周围的文化比当前的思想落后20或30年。

我最近在这个问题上的表现是最好的，但这是个坏消息：有了ERP系统，一旦您离开敏捷流程实践并开始关注敏捷技术实践，事情就会变得非常困难。

文化问题（包括特定于 IT和ERP的问题）无济于事，但技术是主要障碍。 让我们从测试开始...

确实存在一些测试框架（例如ABAP单元和X ++单元），但是它们受到限制，并且与其他语言一样，只有一小部分开发人员使用它们，只有少数开发者可以正确使用它们。

问题之一是一个古老的问题：模拟和存根。 但是在ERP系统中，“模拟”和“存根”问题要严重得多，因为已经提供了太多的系统，您需要做更多的模拟工作，该系统无处不在，只有更多的系统可以进行模拟和存根。

由于ABAP实际上是Cobol，您可以忘记反射，注释和多态替换。 哎呀，我不认为它甚至不支持宏！

部分原因是由于ERP系统的体系结构。 该体系结构已有数十年的历史了，它绝对不是面向对象的，比在Java中更适合于在嵌入式C中工作。

另一个问题是由于很多系统未使用文本编程。 还记得我说过某些编程是基于表的吗？ 还有一些是尖尖的？ 这些东西极难测试，因为它存在于另一个范式中。 在某些情况下，即使“配置”作为代码（如片段）存在，系统也将其视为数据并且无法提取。

在一种情况下，我们导出“代码”只是发现它没有用ASCII编码。 而且，如果已导出，则可能无法再次导入。

这些系统的设计人员实际上期望通过配置系统的人员来更改，修改，修改，修改其生产代码。 让我重复一遍：供应商的生产代码可能会在配置工作中进行更改。 想象一下，当您想在Microsoft Word VBA中编写宏时，可以访问底层的Microsoft Word代码。

这些系统与John Vlassides主张的完全相反：

“好的代码的标志是通过添加而不是修改来对其进行更改”， The C ++ Report John Vlassides

通过添加代码来更改代码是ERP世界中的一个新想法，对于那些“配置”代码和构建产品的人来说都是如此。

但是，与进行自动验收测试驱动开发（ATDD）的问题相比，自动化单元测试TDD的问题显得微不足道。

由于ERP系统是整体，因此很难（即使不是不可能）找到添加ATDD样式测试的方法。 这些系统不仅早于微服务，还早于组件，COM，CORBA，DLL，共享库甚至静态库。

我已经看到自动化测试工具可以在最高级别（UI级别）上工作。 我听说Quick Test Pro可以在Windows界面上的UI上运行，并且我已经看到Selenium在Microsoft前端上运行，甚至还看到Selenium执行“ Given-When-Then”测试，但是…

这一切都在UI级别上。

似乎不可能在最低级别和最高级别之间的任何地方进行测试。

幸运的是，ERP系统公开了一些您可以连接的服务或接口，例如，Rocket U-2让.NET代码可以就地连接到它。 但是，此类接口并不总是存在的，或者如果没有记录，则可能会发生更改。 因此，大多数更高级别的测试都需要在UI级别上进行。

由于其处于UI级别，因此测试缓慢，脆弱，缓慢，难以预先创建且缓慢； 整个系统需要运行才能运行，因此，如果发现某些东西，可以在其中钓鱼。

由于正在为整个系统加电进行测试，因此您需要测试数据，这是一个问题。 如果很幸运，您可能可以访问关系数据库并插入自己的数据；如果不幸运，您将无法访问该数据库，或者会发现该数据库是旧的专有层次数据库，则需要加载大量数据。

我有提到它的速度慢吗？

不仅仅是ATDD测试缓慢，构建速度也很慢。 小时而不是分钟。

构建可能并不像您所知道的那样，我曾经不得不向SAP团队解释源代码控制。 因为所有配置都被视为“数据”，所以源代码控制的概念可能很奇怪–您依赖供应商实际支持源代码控制，而SAP在某一点上却没有。

有时实际上不保存“配置”并将其加载到系统的另一个实例中。 您可能需要构建该管道。

请记住，这些想法对于“配置”系统的人们可能是完全陌生的。 这些人是人力资源或供应链专家，他们碰巧学了一些ERP，并发现它很赚钱。 他们不了解许多软件工程概念，他们可能不想特别学习它们，而雇主也可能不想他们学习。

就像我之前说过的：这些系统是大型整体。

根本就没有软件开发人员创建的用于管理大型系统，对其进行模块化，对其进行控制，对其进行隔离，将它们的各个部分隔离以允许以不同的速率进行更改的许多工具和技术。 ERP系统不仅是垄断，而且是垄断，它们旨在形成组织的中枢神经系统并运行组织，它们是一件事。

那就是他们的本性，他们的文化，他们的技术，甚至他们的存在理由。

这看起来似乎很强大，但请考虑一下……高级经理购买这些系统是为了对大型组织提供洞察力和控制力。 他们希望大型组织充当单个实体，他们不想重复，他们不想变异，他们想要一个整体，这就是ERP销售人员向他们出售的东西。

因此，尽管您可以在ERP实施中引入一些敏捷性，但敏捷方法与绝对不敏捷的目标之间存在着非常深层次的冲突。

翻译自: https://www.javacodegeeks.com/2016/09/bad-news-agile-erp-part-4.html