避免二次系统综合征的提示

最近我看到我们的开发团队在计划下一个版本的产品时越来越接近'second system syndrome'类型的想法。虽然我全部都是为了改进和消除过去的一些错误，但我不希望看到我们陷入无止境的重写和永不发射任何东西。避免二次系统综合征的提示

是否有一个很好的设计/开发方法，可以帮助构建更好的版本2.0，同时避免出现第二个系统场景？

来源

2010-02-17 Wally Lawless

“我不想看到我们停留在无止境的重写和永不发射任何东西。“

这就是为什么人们使用Scrum。

定义要构建的东西的积压。
确定优先级，以便导致释放的东西是第一位的。应该固定的是第二。
执行sprint以获得发布。执行发布冲刺。

来源

2010-02-17 14:59:09

感谢您的回答，我选择它是正确的，因为它简洁明了，但可以让工作流程顺利进行。 – 2010-06-16 13:34:05

Scrum不会阻止您创建“第二个系统”。它只是管理你的工作流程。 “二系综合症”主要是一个架构问题。（此外，我不喜欢Scrum）。 – Rolf 2014-01-15 13:49:17

专注于系统架构应该有助于

具有支持子系统
已经记载设计决策之间的“松散耦合”（避免重新散列先前打浆路径）

因此记录的界面，而不打算用于所有出交换，目前的系统可以通过更合适的接口进行“升级”，以帮助未来的发展。

的另一个好方法重点：分配$$$人物每个特征和相应优先;-)

总之，只是我的2分钱小费

来源

2010-02-17 14:56:44 jldupont

难道不是这个问题 - 很容易过分关注重构架构系统，而不是为2.0完成增强/错误修复？ – 2010-02-17 14:58:07

+1“记录的解决方案”（好吧，实际上你说的是文件化的设计决定......）。可以通过不知道如何处理实际系统来实现“第二个系统”。 – Rolf 2014-01-15 13:50:27

尝试专注于短的交付周期，即强迫自己每隔几周或每月向用户提供一些有形和有用的东西。根据客户的价值优先考虑任务。这样，您总能获得满足用户需求的可用功能应用程序，而如果您愿意的话，您可以通过小步骤重构体系结构（如果您可以证明对它的需求 - 也就是对管理层/客户，而不是只是队友！）。

如果您有一套稳定的自动（单元/集成）测试的构建过程，它会有很大帮助。

敏捷开发方法如Scrum这样做，他们是热烈推荐。但当然，在团队中适应这种方法并不总是很容易，甚至不可能。即使你不能，你仍然可以把它的元素应用到你的项目中（也许甚至不需要公开提及“敏捷”或“Scrum”）;-)

来源

2010-02-17 15:02:20

得到至少写过一个人三个系统来领导这个项目。

来源

2010-02-17 15:05:34 Nat

+1聘请已成功构建类似解决方案的人在我的十大最佳项目管理实践中处于领先地位。 – 2010-02-17 15:21:24

除理想情况外，您希望有人编写了同一个系统的三次迭代。有人写了三个“第二系统”，甚至三个“第一系统”，可能并不是你想要的。 – 2016-05-04 03:40:42

确保您尽可能好地记录了要求。显而易见，您还需要管理进入需求的内容以避免过度设计，固定范围有助于防止开发人员跑出想法或镀金需要完成的任务，并且有助于防止管理层或客户引入范围蔓延。定义所有要求以及如何处理范围更改。我所有的开发周期都很短（确保你正在编写测试）和敏捷方法学，但这两者都不能防御二次综合征系统。在某些方面，如果您在短暂冲刺的情况下不停地查看整体图片，则可以更轻松地继续添加功能。使用敏捷实践来构建最简单的工作，然后尽可能简单地添加其他需求。记住YAGNI，因为当你第二次构建一个系统的时候，那就是当你最有可能建立你确定需要的东西的时候，某些事情会使系统“可扩展”，所以永远不需要第三个版本。这是最好的意图，但通往地狱之路等等。

来源

2010-02-17 15:12:26 Tom

Upvoting因为惊讶，更多的答案不提YAGNI。在我看来，限制重写范围的关键是在排除功能和/或支持功能之间找到一个平衡，这些功能一方面不是立即需要以满足硬性要求，而不是“绘画自己进入了一个角落'，关于在以后的日子里增加功能支持的可能性。即。最优重写是一个精简的核心实现，但与“可能”最小的“重构距离”可以在不增加冗余复杂度的情况下实现。 – jlmt 2016-01-24 17:09:19

我上投·洛答案，并希望多增加一些建议：

交付工作的产品给客户尽可能频繁地。持续几周到两个月的迭代是理想的。像Scrum这样的敏捷方法可以很好地适应这一点。
使用FogBugz进行功能和错误跟踪。它的功能对于敏捷项目非常实用。根据发布和优先级，FogBugz允许轻松优先化。如果您的团队为每项任务输入估计的工作量，您也可以使用它来计算合理的发货日期。
根据80/20 rule优先考虑您将开发哪些功能（20％的功能将在80％的时间内使用）以及最差的降压功能。这有助于保持系统尽可能简单，有助于防止feature bloat，并节省开发和测试时间。
当您确定问题的优先级时，对新功能和错误给予类似的考虑。 the Joel Test的一点是“在编写新代码之前是否修复错误？”。在大多数商店中，这不会发生，但不要事后调试系统。此外，保留旧系统的工作副本以与在新系统上发现错误时进行比较。
也是维护和必要时重写现有代码所需工作量的因素。如果你还没有这样做，给团队一些时间来编写他们觉得很难改变的整个文件。如果系统代码第一次难以维护，这只会变得更糟，导致您的团队花更多时间在新功能上。

来源

2010-02-17 15:24:44 David

我已经经历了双方作为客户/赞助商和开发团队的一部分的第二个系统综合征。

问题的根本原因在于团队锁定了第2版的乌托邦愿景，例如希望使新软件“灵活”。在这种情况下，所有东西都被抽象为第n层。例如，不是代表真实世界实体的数据对象，而是创建一个可以表示任何东西的通用“项目”对象。一个有缺陷的想法是，我们可以在软件中构建如此多的灵活性以预测未来的需求，非程序员将能够配置新的功能。通常，诸如“灵活性”之类的一个目标掩盖了所得到的软件无法工作的努力。

对可用性，性能，可扩展性，功能，可维护性和灵活性目标的均衡实际考虑可以使团队重返现实。如果......应该被禁止出现在团队的词汇表中，那就太好了。 Scrum积压是一个好工具，应该听到团队经常说......“让我们积压起来......我们不需要那个版本2.”

来源

2011-06-01 15:06:43

它永远无法完全避免。但谨慎可以缓解这个问题。您应根据定义系统成功的重要参数（最稀缺的资源）制定一些拇指规则。例如，减少潜在的错误数量可能会直接降低运营成本（支持中心的潜在服务呼叫）。但是在其他所有系统中情况可能并非如此。另一个例子，在某些情况下，CPU，内存和其他资源的稀少使用可能会有所帮助，但是可能会有环境可能会大量使用它们。

所以，简单地避免“诱惑”，找准稀缺的资源（时间，精力，金钱$等），只考虑那些超过阈值执行。[F（S1，S2 ...）>阈值]

尽管迭代式发展，我会强调如何处理技术债务。
链接，都与此有关：
Tech Debts: Effort Vs Time
Tech Debt Quadrant

来源

2011-10-30 06:44:22 Lokeshwer

你不能接近第二系统综合症。要么你在里面，要么你远离它。你会知道你在什么时候，但只有在浪费了大量资源之后。

提示是：了解它（所以基本上我们已经得到了覆盖）。知道什么是“第二个系统”是非常宝贵的信息，甚至有更多的经验。我想我们都有一些经验，希望是温和的。

这些知识经常会让你思考三次，你会发现一个解决方案，而不冒险进入第二系统的陷阱。 PS：还知道如何使用您当前的系统，其中包括可能记录的解决方案和其他文档。

来源

2014-01-15 13:47:02 Rolf

避免二次系统综合征的提示

回答

相关问题