避免第二系统综合征的提示[关闭]

“我不想看到我们陷入一个无休止的重写循环,永远不会启动任何东西。”

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

1. 定义要构建的积压工作。

2. 排定优先顺序,以使导致发布的事情成为第一。第二个需要修正的是。

3. 执行冲刺以获得发布。执行发布冲刺。

作为客户/赞助人和开发团队的一员,我从双方都经历过第二种系统综合症。

问题的一个根本原因是当团队锁定到版本2的乌托邦愿景时,例如希望使新软件“灵活”。在这个场景中,所有东西都被抽象到第n度。例如,创建一个可以表示任何事物的通用“项”对象,而不是表示现实世界实体的数据对象。一个有缺陷的想法是,我们可以在软件中构建如此多的灵活性来预测未来的需求,这样非程序员就可以配置新的功能。通常,一个目标(如“灵活性”)会使工作蒙上阴影,使结果软件无法工作。

对可用性、性能、可扩展性、特性、可维护性和灵活性目标的平衡实际考虑可以使团队回到现实中。”如果……从团队的词汇中被禁止,那就太好了。Scrum积压工作是一个很好的工具,应该经常听到团队说…”让我们把它积压起来……对于版本2,我们不需要它。”

尽量集中在短的交付周期上,也就是说,每隔几周或几个月就强迫自己向用户交付一些切实有用的东西。根据任务对客户的价值确定任务的优先级。这样,您就可以始终拥有一个可用的、功能性强的应用程序,并满足用户的需求,而如果您愿意的话,您可以通过一个小步骤重构架构(如果您可以证明对架构的需要,也就是说,对管理层/客户,而不仅仅是队友!).

如果您有一个稳定的构建过程和一套良好的自动(单元/集成)测试,那么它会有很大帮助。

敏捷开发方法 Scrum 这样做,他们是热烈推荐。但当然,在您的团队中采用这种方法并不总是容易甚至可能的。即使你不能,你仍然可以将它的元素应用到你的项目中去(甚至不用公开提到“敏捷”或“scrum”)。

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

确保您尽可能地记录需求。显然,您还需要管理进入需求的内容,以避免过度设计,而拥有一个固定的范围有助于防止开发人员放弃想法或镀金需要做的工作,并且有助于防止管理层或客户引入范围渐变。定义所有要求以及如何处理范围变更。

我完全赞成短开发周期(确保编写测试)和敏捷方法论,但这两种方法都不能抵御第二种综合征系统。在某些方面,如果你在短跑中不停地看整体情况,就更容易不断地添加一个又一个特性。使用敏捷实践来构建最简单有效的东西,然后尽可能简单地添加其他需求。记住Yagni,因为当你第二次构建一个系统时,你最有可能在某个时刻构建你确信需要的东西,使系统“可扩展”的东西,这样就不需要第三次构建了。这是最好的意图,但通往地狱的道路和所有这些。

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

提示是: 知道吗? (所以基本上我们已经讨论过了)。知道“第二个系统”是什么是非常宝贵的信息,而且更重要的是有一些相关经验。我想我们都有过这样的经历,希望是良性的。

这些知识常常会让你三思而后行,你会发现一个解决方案,而不会冒险进入第二个系统的边缘。

PS:还知道如何使用您当前的系统,其中包括,可能有文档记录的解决方案和其他文档。

关注系统架构应该有帮助,例如

• 具有支持子系统之间“松耦合”的文档化接口
• 有记录的设计决策(避免重新散列以前被破坏的路径)

因此,在不进行全面交换的情况下,当前系统可以通过更合适的接口进行“升级”,以帮助未来的增长。

另一个集中注意力的好方法:为每个功能分配一个$$$数字,并相应地确定优先级;-)

不管怎样,只有我的2份

我投票赞成S.Lott的回答,并希望添加更多建议:

1. 尽可能频繁地向客户交付有效的产品。持续几周到两个月的迭代是理想的。敏捷方法学,比如Scrum,很适合这样做。

2. 使用 FogBugz 用于功能和错误跟踪。它的特性对于敏捷项目非常实用。FogBugz允许根据发布和优先级轻松地进行优先级排序。如果您的团队为每项任务输入他们的估计工作量,您还可以使用它来计算合理的发货日期。

3. 根据 80/20 rule (20%的功能将被使用80%的时间)和最棒的降压。这有助于使系统尽可能简单,有助于防止 feature bloat 并节省开发和测试时间。

4. 在确定问题的优先级时,对新特性和错误给予类似的考虑。一点 the Joel Test 是“在编写新代码之前修复bug吗?”。在大多数商店,这不会发生,但不会使系统调试成为事后诸葛亮。另外,保留旧系统的工作副本,以便与新系统上发现错误的时间进行比较。

5. 还要考虑维护现有代码所需的工作水平,如果需要,还可以重写现有代码。如果您还没有完成这项工作,请给团队一些时间来代码检查他们发现难以更改的整个文件。如果系统的代码第一次很难维护,这只会变得更糟,并导致您的团队花费更多的时间在新特性上。

这是永远无法避免的。但谨慎可能会缓解问题。 您应该根据定义系统成功的关键参数(稀缺资源)来制定一些经验法则。例如,减少潜在的错误数量可能会直接降低运营成本(潜在的服务呼叫支持中心)。但在其他系统中,情况可能并非如此。另一个例子是,CPU、内存和其他资源的稀缺使用在某些情况下可能是有益的,但在某些环境中,它们可以大量使用。

因此,为了避免“诱惑”,只需确定最稀缺的资源(时间、精力、金钱等),并考虑只实现那些超过阈值的资源。

尽管有迭代开发,我还是会强调如何处理技术债务。
与此相关的链接:
Tech Debts: Effort Vs Time
Tech Debt Quadrant