实施大型系统变更[关闭]

Question

如果您熟悉“建造一个然后扔掉”这句话，那么我们似乎已经做到了；我们已经达到了在线应用程序版本 1 的限制。是时候通过以下方式清理事情了：

• 重新组织代码和 UI
• 统一 UI 流程
• 添加更多功能
• 为未来而建设
• 修改我们的数据库结构来处理上述所有问题

实现这一转变的最佳方式是什么？

我们希望避免将所有用户扔到一个新系统（一旦完成）......他们会惊慌失措，而我们无法处理呼叫负载。我们的用户涵盖各个领域，从技术熟练、用于编写软件的类型到不知道 HTML 是什么的用户。

在我们确保这个新设计足以解决版本 1 的足够问题后，我们是否应该开始对系统进行新的“安装”并逐渐将用户转移到该系统？

我们是否应该（以某种方式）逐步改变系统的每个模块和阶段？这可能很困难，因为数据库布局会发生变化，导致必须调整“核心代码”和几个周围模块的代码。

拥有一组值得信赖、耐心的“测试版测试者”客户使用尖端版本的应用程序是否很常见？（这里的目标是获得反馈并测试新系统上的错误）

还有其他建议吗？第一手经验？

Answer 1

恐怕答案是视情况而定。这取决于应用程序的类型和您拥有的用户的类型。在不知道系统是什么以及版本变化范围的情况下，很难给出答案。

也就是说，有一些经验法则。

首先，避免大爆炸发射。任何系统的启动都会出现问题。这个行业充满了人们认为轰轰烈烈的发布是个好主意的项目，只是因为初期的问题导致发布失败。 库伊尔 是最近一次备受瞩目的大爆炸发射的因果关系。

为了使初期问题易于管理，您需要首先与少量用户合作，然后慢慢增加用户数量。

其次，你绝对必须积极做的事情是 把用户放在第一位. 。用户应该做尽可能少的工作来使用系统的 V2。理想的工作量为零。

这意味着如果您选择缓慢地将用户从一个系统迁移到另一个系统， 你 负责确保迁移所有数据和设置。例如，不要做任何愚蠢的事情，比如告诉用户必须对 2008 年 9 月 12 日之前的所有记录使用 V1，对之后的所有记录使用 V2。

发布 V2 的目的应该是让用户的生活更轻松，而不是让用户的生活变得不必要的困难。

第三，有一个测试版程序。这甚至适用于 Intranet 应用程序。开发应用程序很像牛顿-拉夫森求多项式根的方法。你猜测用户想要什么，将其交付给用户，用户提供反馈，缓慢但肯定的每次迭代都会让你更接近问题的解决方案。

测试版程序将帮助您更快地找到根源，而不是仅仅将新版本强加给人们，而没有时间让他们对更改发表评论。Beta 版有助于让您的用户更早加入并让他们感觉自己融入了流程；其重要性我怎么强调都不为过。

Answer 2

我们刚刚为我们的用户安装了一个全新的 CRM 系统，让我告诉你，这样做是一个糟糕的想法：这对我的团队和我们的客户来说都是极其痛苦的。

我会想尽一切办法逐步发布版本，即使这意味着需要做更多的工作。您会很感激，因为您不必付出巨大的努力来移动所有东西，并且您的客户会欣赏能够一次向您介绍该产品的能力。

希望有帮助！

Answer 3

我同意 埃斯特班 逐步发布是最好的。就像改造房子一样：最初，结束这件事似乎是个好主意。但这意味着你必须提前计划好一切，雇佣一群承包商然后搬出去。然后计划发生变化或者承包商消失，您希望节省的所有时间都消失了。同时，渐进式的改变让每个人都有机会在步骤之间停下来思考。有时，当早期的更改比您计划的效果更好时，您可以避免以后的更改。

我工作的系统存在巨大的扩展问题。我们列出了我们认为需要的所有更改，并根据可能的影响对它们进行了优先级排序。然后我们开始一次只做一项改变。大约完成列表的一半时，我们发现我们已经解决了扩展问题。我仍然保留着这份清单，但我可能永远不需要完成它。我可以自由地添加功能并解决其他问题。

当然，有时候最好硬着头皮把整个事情拆掉。但这种情况比人们想象的要少得多。对于关键的操作系统来说，“拆除”的决定可能是致命的。看看那些大家都同意必须带入现代计算时代的大型政府项目，但又不能这样做，因为一些重要的服务将会丢失。如果哲学是渐进式的改变，也许它们会一次一点地现代化。

Answer 4

这听起来像 增量重构 应该是您选择的敏捷流行语。

我从未在 Web 应用程序上做过这件事，但我已经经历了一些相当激进的客户端应用程序更改，这些更改是逐步完成的。如果您预先投入一点时间来确保以相当合理的方式对工作进行排序，那么它可以很好地发挥作用。如果您还没有良好的重构辅助工具，那么进行少量投资将会非常有帮助。我个人可以推荐 jetBrains 锐磨机 如果您使用 .NET，并且如果您基于 Java，我相信 IntelliJ IDEA 包含类似的功能。