最近我看到我们的开发团队在规划下一版产品时危险地接近'second system syndrome'类型的想法。虽然我全都是为了改进和消除我们过去的一些错误，但我不愿意看到我们陷入无休止的重写循环中，从不发布任何东西。
是否有一个好的设计/开发方法有助于构建更好的版本2.0，同时避免第二个系统场景？
答案 0 :(得分：15)
作为客户/赞助商和开发团队的一员，我从双方都体验过第二种系统综合症。
问题的根本原因在于团队锁定了版本2的乌托邦愿景，例如希望使新软件“灵活”。在这种情况下，一切都被抽象到第n度。例如，代替表示真实世界实体的数据对象，创建可以表示任何内容的通用“项”对象。一个有缺陷的想法是，我们可以在软件中建立如此大的灵活性以预测未来的需求，非程序员将能够只配置新的功能。通常，诸如“灵活性”之类的目标使得努力达到了最终软件不起作用的程度。
对可用性，性能，可扩展性，功能，可维护性和灵活性目标的平衡实际考虑可以使团队重新回到现实。 “如果...应该被禁止从团队的词汇中被禁止”。 Scrum积压是一个很好的工具，应该经常听到团队说......“让我们积压那些......我们不需要那个版本2.”
答案 1 :(得分：10)
“我不愿意看到我们陷入无休止的重写循环，永远不会发动任何东西。”
这就是人们使用Scrum的原因。
定义要构建的积压事项。
优先考虑，以便首先发布导致发布的内容。应该修复的事情是第二。
执行sprint以获得发布。执行发布冲刺。
答案 2 :(得分：4)
尝试专注于短交付周期，即强迫自己每隔几周或每月向用户提供切实有用的内容。根据客户的价值确定任务的优先顺序。通过这种方式，您总能拥有一个可用的，功能强大的应用程序和满意的用户，而如果您愿意，可以通过小步骤重构体系结构（如果您可以证明需要它 - 也就是说，对管理层/客户，而不是只是队友！）。
如果你有一套稳定的构建过程和一系列自动（单元/集成）测试，那么它会有很大的帮助。
像Scrum这样的敏捷开发方法可以做到这一点，我们热烈推荐这些方法。但当然，在您的团队中调整这种方法并不总是容易的，甚至不可能。即使你做不到，你仍然可以采用它的元素并将其应用到你的项目的好处（甚至可能没有公开提及“敏捷”或“Scrum”; - ）
答案 3 :(得分：3)
找一个至少写过三个系统的人来领导这个项目。
答案 4 :(得分：2)
确保尽可能记录要求。虽然显然您还需要管理满足要求的内容以避免过度设计，但是固定范围有助于防止开发人员想法或镀金需要做什么，这有助于防止管理层或客户引入范围蔓延。定义所有要求以及如何解决范围变更。
我都是短暂的开发周期（确保你正在编写测试）和敏捷方法，但这些都不是防御第二综合症系统的盾牌。在某些方面，如果您在短暂的冲刺中工作而不停下来查看整体图片，则更容易继续添加功能。使用敏捷实践构建最简单的工作方式，然后尽可能简单地添加其他需求。记住YAGNI，因为当你第二次建立一个系统时，那就是当你最有可能建立一些你确定在某些时候需要的东西的时候，这将使系统“可扩展”，所以从来没有必要第三个构建。这是最好的意图，但通往地狱之路以及所有这些。
答案 5 :(得分：2)
你无法接近第二系统综合症。你要么在里面，要么就是远离它。你知道什么时候进入它，但只有在浪费了大量资源之后才会知道。
提示是：了解它（所以基本上我们已经涵盖了这一点）。知道什么是“第二个系统”是非常宝贵的信息，更多的是要有一些经验。我想我们都有一些经验，希望是良性的。
这些知识通常会让你三思而后行，你会找到一个解决方案，而不会冒险进入第二系统的困境。
PS：还知道如何使用您当前的系统，包括可能是文档化的解决方案和其他文档。
答案 6 :(得分：1)
关注系统架构应该有所帮助。
因此，如果不进行全面交换，可以使用更合适的接口“升级”当前系统，以帮助未来增长。
另一种关注的好方法：为每个特征分配一个$$$数字并相应地确定优先级; - ）
无论如何，只是我的2cents
答案 7 :(得分：1)
我对S. Lott的回答进行了投票，并希望增加一些建议：
尽可能频繁地向您的客户提供工作产品。持续数周至2个月的迭代是理想的。敏捷方法，例如Scrum，很适合这一点。
使用FogBugz进行功能和错误跟踪。它的功能对于敏捷项目非常实用。 FogBugz允许根据版本和优先级轻松确定优先级。如果您的团队输入每项任务的估计工作量，您也可以使用它来计算合理的发货日期。
根据80/20 rule确定您将开发哪些功能（20％的功能将在80％的时间内使用）并且最有效。这有助于保持系统尽可能简单，有助于防止feature bloat，并节省开发和测试时间。
在确定问题的优先级时，同样考虑新功能和错误。 the Joel Test的一点是“你在编写新代码之前修复了错误吗？”。在大多数商店中，这种情况不会发生，但是不要在事后调试系统。此外，保留旧系统的工作副本，以便在新系统上发现错误时进行比较。
还要考虑维护现有代码所需的工作量，并在必要时重写现有代码。如果您还没有这样做，请给团队一些时间来检查他们觉得很难改变的整个文件。如果系统的代码第一次难以维护，这只会变得更糟，导致您的团队花费更多时间在新的功能上。
答案 8 :(得分：0)
完全无法避免。但谨慎可以缓解这个问题。 您应该根据定义系统成功的重要参数（最稀缺的资源）制定一些拇指规则。例如，减少潜在的错误数量可能会直接降低运营成本（对支持中心的潜在服务呼叫）。但在其他所有系统中可能并非如此。另一个例子，在某些情况下，很少使用CPU，内存和其他资源可能会有所帮助，但可能存在丰富的环境。
如此简单地避免“诱惑”，找出最稀缺的资源（时间，精力，金钱等）并考虑仅实施那些超过阈值的资源。[f（s1，s2 ...）＆gt;阈]
尽管有迭代开发，但我会强调如何处理技术债务
与此相关的链接：
Tech Debts: Effort Vs Time
Tech Debt Quadrant