我们公司构建了几个（Java）应用程序，这些应用程序通过Web服务，远程EJB和偶尔通过数据库中的共享数据相互松散地进行通信。
每个应用程序都由他们自己的团队构建和维护。较小的应用程序为1或2人，最大的应用程序为近10人。开发人员总数约为25 FTE。
我们面临的一个问题是团队中存在一些重要的自负。从历史上看，最大的应用程序团队已经建立了代码约定和一般指南。例如，我们的IDE是Netbeans，我们使用Hg进行SCM，使用Ant构建并强调首先尽可能多地使用Java EE，如果这不足以使用外部库并且仅作为最后的手段自己写一些东西。根据这些指南，几乎不允许编写像另一个日志框架，orm，cms或web框架这样的东西。
现在一些较小的团队反对这个并开始使用Eclipse，Git和Maven，并且尽可能自己编写方法，只有时间很短或者他们感觉不喜欢现有的东西。自己写'。主要团队使用log4j，其中一个较小的团队刚开始编写自己的日志框架。
关于所有遵守相同标准的团队一直在进行谈判，但这些团队充其量只是“麻烦”。
现在我想提出一个重要问题：不同的团队以不同的方式做事真的很重要吗？只要每个单独的应用程序实现其要求并提供商定的接口，我们真的应该强迫每个人使用Hg，Ant，相同的代码约定等等吗？
答案 0 :(得分：0)
让每个团队使用最适合他们的技术并没有太大的危害。事实上，如果你将团队限制在“标准”的做事方式，你就会扼杀创新并且士气低落。
但你不希望事情分歧过多。您可以采取一些措施来防止库和工具失控。第一件事是通过团队定期轮换每个成员以交叉授粉想法。通过这种方式，最好的想法将通过团队传播。
您还可以强制实施“3规则”，只是说可以引入第二个库，工具，日志记录方法等等。但是只要你想引入第三个，就必须删除前两个中的一个。换句话说，拥有2个竞争日志框架是可以的，但是如果有3个日志框架，请选择一个来杀死。
第三个想法是让开发人员定期向整个开发人员小组进行演示，以展示每个想法或方法的优缺点。鼓励大量的讨论和建设性的批评。目的是尝试很多事情，让每个人都找到最好的方式。
最后，Management 3.0更深入地讨论了团队如何做出决策。非常值得一读。