doc:feature parity

Pattern-Legacy-Displacement/divert-the-flow.md

@@ -28,7 +28,7 @@
 
 ### 用户需求
 
-显然，我们需要了解最终用户是如何使用我们计划"转移"的功能的。对于"关键汇总"功能，我们通常会为每份报告或指标分配大量不同的用户。这是一个典型的例子，说明[功能奇偶性](https://martinfowler.com/articles/patterns-legacy-displacement/feature-parity.html)可能导致重建一套"臃肿"的报告，而这些报告实际上并不能满足当前用户的需求。简化的小型报告和仪表盘可能是更好的解决方案。
+显然，我们需要了解最终用户是如何使用我们计划"转移"的功能的。对于"关键汇总"功能，我们通常会为每份报告或指标分配大量不同的用户。这是一个典型的例子，说明[功能对等](feature-parity.md)可能导致重建一套"臃肿"的报告，而这些报告实际上并不能满足当前用户的需求。简化的小型报告和仪表盘可能是更好的解决方案。
 
 并行运行可能是必要的，以确保在初始实施过程中关键数字相匹配，从而让企业确信一切都能按预期运行。
 

Pattern-Legacy-Displacement/feature-parity.md

@@ -0,0 +1,66 @@
+# 功能对等
+
+*使用新的技术堆栈复制旧系统的现有功能。*
+
+在许多情况下，当我们与 IT 管理人员交谈时，我们会听到他们是如何拥有一套老化的应用程序，这些应用程序使用的是即将报废甚至已经报废的技术。这些系统往往托管在昂贵的数据中心，由第三方管理，合同缺乏灵活性。这些应用程序对企业的成功运营至关重要，同时也是业务和运营风险的最大来源之一。
+
+他们都非常清楚，现在有机会进行改进、优化流程并解锁新的机遇。然而，要完全做到这一点，将具有破坏性，并带来许多依赖性。例如，现有"BAU"工作的承诺、其他变革计划，尤其是最终用户所在部门的现有计划和预算。
+
+在这种情况下，一种方法是通过"简单"地更换技术，同时保持其他一切"原样"，尽量减少更换对更广泛组织的影响。这种方法通常被尝试过的人称为"功能对等"（Feature Parity）或 "功能对等陷阱"（Feature Parity trap）。
+
+虽然**功能对等**听起来似乎很有道理，但我们已经深刻认识到，人们大大低估了所需付出的努力，从而错误地判断了这一方法和其他替代方法之间的选择。例如，即使只是定义"原样"范围也会耗费大量精力，尤其是对于已成为业务核心的遗留系统而言。
+
+随着时间的推移，大多数遗留系统都变得"臃肿"，许多功能都被用户闲置（根据 Standish Group 2014 年的一份报告，闲置率高达 50%），因为新功能不断增加，而旧功能却没有被移除。过去的错误和限制的解决方法已成为当前业务流程的 "必备"要求，用户的工作方式与其他任何东西一样，都是由遗留系统的限制所决定的。重新构建这些功能不仅是一种浪费，而且也错失了构建当前实际需要的功能的机会。这些系统往往是 10 年或 20 年前在前几代技术的限制下定义的，"原封不动"地复制它们很少有意义。
+
+如果功能对等是一个真正的要求，那么这种模式就描述了如何才能做好。这不是一条简单的道路，也不能掉以轻心。
+
+## 如何工作
+
+功能对等是一个简单的概念。用更合适的技术栈构建一个新系统，其功能和行为与现有系统完全相同。每当有人问到新系统应该做什么时，我们的回答都是"做现有系统做的事情"。**我们需要充分了解现有系统的功能，并能够验证新系统是否也能做到这一点，这样才能知道我们的系统是否具有同等功能。**
+
+### 范围是什么--旧系统做什么？
+
+功能对等的第一部分是创建当前系统功能的规范。可能需要将以下内容结合起来：
+
+#### 系统调查
+
+##### 用户操作
+
+用户角色是什么，他们能看到系统中的哪些功能（菜单项），能执行哪些操作。每个菜单项/操作--涉及哪些屏幕、哪些数据项、验证逻辑。用户执行操作后有哪些可观察到的结果？
+
+##### 批处理
+
+系统中定义了哪些批处理任务？何时触发，执行哪些处理，有哪些可观察到的结果？
+
+##### 接口和集成
+
+系统都集成了什么？
+
+- 本系统向客户提供哪些接口，这些接口有哪些规约（API、CFR、行为预期/副作用）
+- 该系统使用哪些接口，这些接口的规约是什么？
+- 注意通过数据库集成的系统或系统的一部分（见报表/数据和考古学（Archeology））
+
+##### 核心算法
+
+需要复制已知的业务规则和计算 —— 由用户操作和批处理触发。
+
+##### 报表/数据
+
+系统以何种格式、根据哪些数据、何时以及多频繁地创建哪些报表？
+
+数据库中的数据是如何变化的？是否有触发器更改数据，是什么触发了触发器，触发器触发了哪些程序？这个兔子洞有多深？
+
+还有哪些系统可以访问或集成使用这些数据？它们以何种方式更改数据，这些更改有哪些可观察到的行为？
+
+#### 考古
+
+要完全理解一个系统的功能，往往需要考古。通过"考古过程"，你可以了解到，改变屏幕 A 上的数据字段 Y 会导致批处理作业 N 运行后报表 C 上出现值 Z。进行这种考古可能需要投入大量的时间，并需要那些对遗留系统最有经验的人投入大量的脑力。
+
+#### 仪表化 - 基于数据，使用什么？
+
+值得花些时间分析现有报告，如访问或其他系统日志，以了解当前系统的使用情况。如果没有这些报告，那么在现有系统的仪器化方面进行一些投资可能会带来很好的回报，因为它可以让你避免基于数据的不必要的工作。
+
+#### 功能价值--我们能否放弃低价值的功能？
+
+虽然我们在采用这种模式时尽量避免给业务带来负担，但与用户交流以了解哪些功能价值较低或未被使用，对管理范围很有帮助。不过，这将重新带来我们试图避免的组织影响/变化。
+