9

我参与了几个项目,这些项目基本上涉及用“新”系统替换“旧”系统。一贯的模式是,构建“新”系统的团队中几乎没有人对“旧”系统有任何真正的了解。每当我对此提出质疑时,都会有人告诉我这是有目的的……通过不了解“旧”系统,团队能够以不同的方式思考,而不受那里的工作方式的限制。所以发生的情况是,团队中通常只有 1 或 2 个人对“旧”系统有所了解,每当出现有关“旧”系统如何做某事的问题时,都会向他们咨询。

但似乎总是发生的情况是,在“新”系统交付后,用户总是会提出“我们如何在新系统中执行 X(在旧系统中很容易)”形式的问题?对于开发人员来说,这往往是他们第一次听说 X。所以他们必须去研究 X 是什么,而他们给用户的答案往往是“你不能”或“你可以,但它是真的很尴尬”。

这对我来说似乎不对……在我看来,让“新”系统的每个开发人员都非常了解“旧”系统会收获很多,而且这不一定会扼杀他们的创造力,如果他们有不错的设计和开发技能。

关于哪种方法最好的任何想法?

4

3 回答 3

8

您需要更好的业务分析师。他们应该审查旧系统,并准确(和完整地)定义新系统需要做什么。他们应该为您提供完整的要求列表,以便考虑所有需要发生的事情。

编写需求的人需要更彻底。如果这不可能,那么您可能需要参与并学习“旧系统”。

然而,总会有一些事情错过——这只是人性。您显然应该尝试使“新系统”尽可能灵活,以便在用户意识到他们已被遗忘时可以添加需要的功能。

我理解你的痛苦。

于 2009-11-23T12:46:33.607 回答
3

用新系统替换旧系统通常意味着功能相同(即至少能够完成旧系统能够完成的工作)

因此,虽然对旧系统的深入了解不是强制性的,但了解接口并构建一组功能测试套件对于有效地开发新系统很有用。
该套件将用于验证新开发的结果,请记住结果绝不能是 100%(否则,您将成功重现第一个系统的错误!)

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

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

如果我们谈论的是一段很长的时间,那还涉及一个架构师能够管理旧系统的演变(它不能停滞不前,在新系统取代它之前等待几个月或几年),保持这些演变不变方向比你的新实现。

于 2009-11-23T12:45:39.677 回答
2

这听起来像是新系统的规范不完整,因为有人(项目经理、项目发起人)没有确保记录并检查旧系统的功能以查看客户实际使用的内容。

如果这样做了,那么没有人知道旧系统就无关紧要了,因为规范是您正在开发的东西。

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

于 2009-11-23T12:49:16.840 回答