J2EE为开发企业级多层应用程序提供了一套很好的架构，开发的思路也很清晰，但是就我的实施经验来说，我觉得层与层之间的耦合度太大了，不便于团队开发。（注：实施人员的分工是按层次来分的，没有按各功能模块来分，如果那样的话，我想,用J2EE做团队开发耦合度更大，效率更低）
一.  做中间控制层（Actions/Events）的开发得完全依赖于SessionBean的方法，如果后台EJB的方法有一点小纰漏，那么做EJB客户端的开发人员（中间控制层/JSP）就吃苦了，因为他们不能确定是他们本身程序有问题还是后台EJB方法有问题，那样的话就会导致两种情况：1.做EJB客户端的开发人员从头测试一遍自己的程序,从而来确定自己传的参数没有问题,是EJB方法的问题，然后再去告诉做EJB方法的开发人员。这样做EJB客户端的开发人员就比较辛苦了。2.做EJB客户端的开发人员和做EJB方法的开发人员频繁交互，从而来确定是哪边的问题，这样两层的开发人员都被拖的比较累。
当然，导致这些情况的出现，做EJB的开发人员没有来得及将所有的方法都完整的测试一遍就发布上去了，或者是做EJB客户端的开发人员没有很准确的理解EJB方法的使用。在具体做项目的时候往往时间都压的比较紧，EJB方法的测试时间都较少，做EJB客户端的开发人员也只是按照系统设计好的步骤去写程序，没有很透彻的理解这些方法具体是做什么的，所以，以上情况的出现是经常的。
二.
时间安排上不能并行开发。做中间控制层必须等EJB开发完了才能开始调试、测试，做JSP必须等中间层开发完了才能调试、测试。这样就导致开发时间加长，效率不高。

不知各位大侠有没有更好的基于J2EE的团队开发的经验，希望能进来指点一二，多谢了。
也欢迎各位就你所在的团队开发谈谈体会。

做单元测试极其重要，首选JUnit，不过你的测试理念可能需要改变，就是不再是写完代码在测试，而是先写测试类，然后边写代码边测试，养成这一习惯带来的优势是显然的。

我觉得你这样按层次分工势必带来接口衔接上的困难，若你的项目时间仓促，强烈建议按功能模块分工。首先生成全部EntityBean，然后一个模块从SessionBean到MVC全由同一个程序员负责，这样接口衔接上的效率大大提高（除了模块与模块之间的接口），坏处就是一对程序员的要求较高，不同层的技术都要掌握，二是每个程序员对构架的理解可能会有出入，造成维护上的困难。这就靠你来权衡利弊了。

先规定好接口，减少改动代码的机会。
先写好中间层，这层相对简单，然后同步展开ejb和jsp.
譬如做jsp测试的时候，如果ejb没写好，可以暂时塞一些假的数据
入中间层而不是通过ejb访问，这样可以做一个大概的测试，当然
仔细点还是等以后ejb写好啦。

上面谈到junit做测试。
我曾经看过一些资料，当然没有太多深入的研究。虽然这个架构很好，
可是暂时对ejb/jsp/servlet的测试还没有很好的方法。
而且这个架构比较多都是基于断言(assertiong)的测试，
那么譬如我一个函数在函数过程中执行了一系列逻辑操作，这样
的测试似乎还是不能进行。

我觉得设计很重要，尤其是详细设计的详细程度
这样设计人员才能基本和coder分离，交互比较少一些

接口设计好，定义好。这一句话很好说，但具体做到的没有多少（我接触的项目）

概要设计和详细设计比较完善，写代码相对容易多了！当然这样设计时期的维护量也大大增加，改动一个地方就要维护很多文档----因此我理想中的文档是少而精干，但又要全面的（有点矛盾--但一个项目的设计尽量使用同一工具可以使用，比如rose等，可以达到这一点）
如果各层的开发人员不同
那么接口中输入输出部分必须定义详细，尤为重要
偶以为

我的看法：

1，开发分工模式是纵向还是横向？
纵向的方式以模块功能分，从ejb到mvc都要管，这样的好处是在于业务熟悉，
接口实现和调用的协调也比较容易。缺点在于需要熟悉各种技术，对程序员
的要求颇高。 赞同Washine(鸟王)的大部分说法。最后一点有不同意见，不
一定所有的程序员都要非常熟悉构架，可以用设计规范来约束程序员，不一
定要求他们理解，但是要求他们遵照，这样在开发过程中培训程序员也是可
行的。
横向的方式以设计层分，一部分人只专注页面逻辑，一部分人管后台的业务
逻辑。这样分工明确，从coding的角度说效率高了。不过在接口的设计和使
用就更需要协调。 
我们希望接口应该在编码前就基本冻结，可这是不现实的。虽然接口变动是
代价很高，可是如果客户需求在变，接口也有可能跟着：（
2.调试  
我觉得页面的调试没有必要真的等到ejb接口正确实现。我们现在的办法也
就是模拟数据对象来测试。
junit我用过，经验还浅，我觉得在代码急剧变化的时候，为了写testcase
工作量几乎double，很是痛苦。jbuilder7集成junit还可以，不过怎么用
test suite我还没时间研究，请方家指点！alink20@sohu.com

是否可以这样
首先设计好各层的传入和传出数据,独立开发各层的时候并不连接到相关的层而只是使用模拟的数据,在最后连接的时候才用真正用相关的层来提供数据和接受技术

纯属设想,没有实践

:}

我认为ZeroC(笨小孩)说的有道理。我觉得团体开发中，接口的设计很总重要。接口确定了，可以开始的功能可以简单一点。比如做一个财务报表的模块，虽然中间的实现很复杂，但是结果只是一张报表。那么，在合作开始的时候，对客户端的请求，只返回一个或几个特定的报表，这样，相关的其他模块就都可以同时进行了。

接口都设计好了,为什么不能同步进行?完全可以模拟数据来做.我们的项目经常遇见这种情况,完全是模拟的来做的,有时侯模拟出来的情况比真实情况还要变态(而且可以考虑到很多细小的情况),可以加强软件的健壮性.
关键是接口设计不要变化,所以初期的设计很重要.

支持cybercell() 的说法。在项目开发前期应该多花时间在接口设计方面的工作，这样后来的开发工作才能同步和按计划的进行。如果开发过程中有问题再进行讨论修改。但是你的公司竟然用JAVA新手来做项目，还要边培训边干活，实在想不通啊。那样还不如用别的技术而不要用J2EE这种对开发人员要求较高的技术呢。

to: alink(阿林) 

急剧变化不止test case工作要double,代码也是,以前的测试(集成and单元)也是,相关文档也是

如果你们的团队可以随随便便的让代码"急剧变化",只能说明你们的测试文档做的实在太少,测试文档变化的代价不能大到让你们放弃急剧变化

如果客观条件逼着你急剧变化,不得不接受的话,那么测试文档的工作量你也只得接受

就怕这种只知道变代码,而放弃文档和测试工作得思想

我觉得设计非常重要，如果，没有充分考虑设计乃至整个设计的细节
这个项目肯定会失败。
需要考虑哪些放在UI层，哪些放在BL层，一定要想的十分清楚。
之后由你的需求确定UI，然后根据UI实现BL接口，最后在设计实现类。

测试可以用假数据，不管有多麻烦，假数据或者变态的不合情理的数据是最好的测试工具。这样就不存在并行开发的冲突。
j2ee的思想很先进，简单说就是对象概念的升华，如果不能很好的将modual,control,view的模式应用起来，那就不是j2ee项目。
另外详细设计的时间再多也不显得多，这样后面的开发才能进展顺利。

依我看，做J2EE的时候，系统分析一定要做的非常好，这个东西关系太大了，只要它出现了问题下面的都要全改。
在分析设计的时候就应该各个层要做的工作全都固定好，最好是制成表，然后发给各个层次的程序员，这样不论是做EJB，做JSP的都不会很乱，很忙，因为标准是统一的，效率上也会提高。其实说白了，跟流水线工作是同一个道理。
团队的开发讲究的就是统一，这样一来就不会出现问题，至少一次开发上是没有问题的，各模块的之间的开发也不会有什么意见。