不同团队之间的团结程度如何？
我们公司构建了多个（Java）应用程序，这些应用程序通过 Web 服务、远程 EJB 以及偶尔通过数据库中的共享数据相互松散地通信。
每个应用程序都是由自己的团队构建和维护的。较小的应用程序需要 1 到 2 个人，而最大的应用程序则需要近 10 人。开发人员总数约为 25 FTE。
我们面临的一个问题是团队中存在一些自大的人。从历史上看，最大的应用程序团队已经建立了代码约定和一般指南。例如，我们的 IDE 是 Netbeans，我们使用 Hg 进行 SCM，使用 Ant 进行构建，并强调首先尽可能多地使用 Java EE，如果这还不够，则使用外部库，最后才求助于自己编写一些东西。遵循这些指南，几乎不允许编写另一个日志框架、orm、cms 或 web 框架之类的东西。
现在，一些较小的团队反对这一点，开始使用 Eclipse、Git 和 Maven，并采用一种自己编写尽可能多的内容的方法，并且仅在时间紧迫或“只是不想自己编写”时才查看现有的内容'。当主团队使用 log4j 时，其中一个较小的团队刚刚开始编写自己的日志框架。
一直有关于所有团队遵守相同标准的讨论，但这些充其量只是“麻烦”。
现在我想问一个大问题：不同的团队以不同的方式做事真的很重要吗？只要每个单独的应用程序实现其要求并提供商定的接口，我们真的应该强迫每个人都使用 Hg、Ant、相同的代码约定等吗？
Our company builds several (Java) applications that loosely communicate with eachother via web services, remote EJB and occasionally via shared data in a DB.
Each of those applications are build and maintained by their own teams. 1 or 2 persons for the smaller apps, and almost 10 for the largest one. The total amount of developers is approximately 25 FTE.
One problem we're facing is that there are some big egos among the teams. Historically the team of the largest app has set up a code convention and general guide lines. For instance our IDE is Netbeans, we use Hg for SCM, build with Ant and emphasize to first use as much from Java EE as possible, if that doesn't suffice use an external library and only resort to writing something yourself as a last resort. Writing things like yet another logging framework, orm, cms or web framework is pretty much not allowed following these guide lines.
Now some of the smaller teams go against this and start using Eclipse, Git and Maven and have an approach of writing as much as possible themselves and only look at existing things if time is short or they 'just don't feel like writing it themselves'. Where the main team uses log4j, one of the smaller teams just started writing their own logging framework.
There have been talks going on about all teams adhering to the same standards, but these have been 'troublesome' at best.
Now the big question I'd like to ask: does it actually matter that different teams do things differently? As long as each seperate app implements its requirements and provides the agreed upon interfaces, should we really force everyone to use Hg, Ant, the same code conventions, etc etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
让每个团队使用最适合他们的技术并没有多大坏处。事实上，如果你限制团队以“标准”的方式做事，你就会扼杀创新并士气低落。
但你不希望事情出现太大分歧。您可以采取一些措施来防止库和工具失控。第一件事是让团队中的每个成员定期轮换，以交叉传播想法。通过这种方式，最好的想法将在团队中传播。
您还可以强制执行“3 规则”，即可以引入第二个库、工具、日志记录方法等。但一旦你想引入第三个，你就必须删除前两个中的一个。换句话说，有 2 个相互竞争的日志框架是可以的，但如果有 3 个日志框架，请选择一个来杀死。
第三个想法是让开发人员定期向整个开发人员小组进行演示，以展示每种想法或方法的优缺点。鼓励大量讨论和建设性批评。目的是尝试很多事情，让每个人作为一个群体找到最好的方法。
最后，管理 3.0 更深入地讨论了团队如何制定决策。非常值得一读。
There is not much harm in letting each team use the technologies that work best for them. In fact if you restrict teams to the "standard" way of doing things you'll stifle innovation and have bad morale.
But you don't want things to diverge too much. There a few things you can do to prevent libraries and tools getting out of hand. The first thing is to have regular rotation of each member through the teams to cross pollinate ideas. In this way the best ideas will spread through the teams.
You can also enforce a "rule of 3", which simply says it is ok to introduce a second library, tool, logging approach, whatever. But as soon as you want to introduce a 3rd one, you have to remove one of the first two. In other words it is ok to have 2 competing logging frameworks but if there are 3 logging frameworks, choose one to kill.
A 3rd idea is to let developers run regular presentations to the entire developer group to demonstrate the pros and cons of each idea or approach. Encourage lots of discussion and constructive criticism. The purpose is to try many things and let everyone find the best way as a group.
Finally, Management 3.0 talks a lot more in depth about how teams make decisions. Well worth the read.