谁应该学习“旧”系统？

Question

我参与了几个项目，主要涉及用“新”系统替换“旧”系统。不变的是，模式一直是建立“新”系统的团队中几乎没有人对“旧”系统有任何真正的了解。每当我对此提出质疑时，我都被告知这是有目的的......通过不了解“旧”系统，团队能够以不同的方式思考，而不受那里事情的限制。所以会发生的事情是团队中通常只有1或2个人对“旧”系统有所了解，每当有关“旧”系统如何做某事的问题时，他们都会被咨询。

但似乎总会发生的事情是，在“新”系统交付之后，新系统中的“我们如何做X（在旧系统中很容易）”这一形式的用户总会提出疑问？ “对于开发人员来说，这通常是他们第一次听说X.所以他们必须去研究X是什么，他们回馈给用户的答案往往是“你不能”或“你可以，但它是真的很尴尬“。

这对我来说似乎不对......在我看来，通过让“新”系统的每个开发人员都非常了解“旧”系统可以获得很多，并且这不一定会杀死他们创造力，如果他们有良好的设计和开发技能。

关于哪种方法最好的想法？

Answer 1

您需要更好的业务分析师。他们应该审查旧系统，并准确（完全）定义新系统需要做什么。他们应该为您提供完整的要求清单，以便考虑所有需要发生的事情。

无论谁在撰写要求，都需要更加彻底。如果那是不可能的，那么您可能需要参与并学习“旧系统”。

然而，总会有一些事情遗失 - 这只是人性。显然，您应该尽可能地使“新系统”变得灵活，以便在用户意识到它们被遗忘时添加需要的功能。

我理解你的痛苦。

Answer 2

用新系统替换旧系统通常意味着iso功能（即能够至少执行旧系统能够执行的操作）

因此，虽然对旧系统的深入了解并非强制要求，但了解接口并构建一组功能测试套件对于有效开发新系统非常有用。
该套件将用于验证新开发的结果，请记住结果必须永远不会是100％（否则，您将成功复制第一个系统的错误！）

另外，对于一个非常大的系统，您的新程序至少需要三个实现：

• 能够与旧系统对话的人
• 一个替换旧的
• 一个完全接管旧程序

如果我们谈论很长一段时间，那也涉及一位能够管理旧系统演变的建筑师（不能停滞不前，等待几个月或几年再取代旧系统），保持这些演变与新实施方向相同。

Answer 3

这听起来像新系统的规范是不完整的，因为有人（项目经理，项目发起人）没有确保记录旧系统的功能并检查客户实际使用的是什么。

如果这样做，那么没有人知道旧系统并不重要，因为规范是你正在开发的东西。

如果你没有规范，除了你将遇到的所有其他问题外，每个人都应该知道旧系统以避免这个问题。