本文共 2934 字，大约阅读时间需要 9 分钟。
声明：本文是作者触感而发，不存在抄袭，如果有雷同，实属巧合，如果有不同的意见，请及时给作者留言。 作者一直从事与网站开发有关的项目，本文所述的高效快速反应的研发团队组成元素并非放之四海而皆准，也与网站开发项目有关，并且只是理论求证阶段，作者尚未有实际的实践证明，如果有不足或者欠缺之处，请指教。 在三层架构风靡IT
界的当今，仍然有不少的公司对三层架构置之不理，具体原因不得而知。下面列出的场景不全面，但是也可以说明冰山一角。 1.
时间紧张，任何一个项目的客户都非常着急，公司也可以理解，程序员作为服务的最终实现人也比较着急，交付不了产品，客户不满意，公司受损失，个人的奖金也有相关的级联。为了DeadLine
，不管怎样，把产品交付验收之后，公司拿到钱就皆大欢喜了。在这种利益驱使下，没有办法不抓紧时间以最快的速度实现产品代码的编写。那好吧，不择手段、分层不清晰、野路子、有问题百度一下等八仙过海，各显神通，之后就去喝庆功酒了，留下一堆只有自己才能勉强理解的代码。 2.
技术部组织结构不健全。公司为了节省成本，招聘过多的初级程序员，缺少高级职称的人带领指导项目的完成。初级程序员比较多这个问题基本上不是大的问题，公司在组建之初，都会考虑找一个信得过、技术比较好的人担任技术总监，掌控负责软件产品的技术方面。接到一个项目后，经过简单的需求调研，项目经理把项目划分为子项目按人头分配任务，要求按期完成任务交给QA
部门就万事大吉了。 还有更多的场景有待大家共同研究，在IT
的项目管理中，组建项目团队是技术总监或者项目经理必须要做的一件事情。诸多书籍中都讲过，组建项目团队需要考虑项目团队需要什么样的角色，根据角色挑选合适的人才，大多数书籍中也讲解了如何面试潜在的团队成员。其中关键的部分，也是每个技术总监或者项目经理都需要思考的问题却无法一一说明白，即团队需要什么样的角色，如何确定这些角色，这些角色之间存在什么样的关系，每个角色最终需要交付什么样的产品，以及如何确保交付产品的质量。这个问题在不同的行业，不同的团队中有不同的答案，没有统一的答案，因团队的性质和规模不同而有差异。因此任何一本IT
项目管理书籍都不会描述这个问题，因其不可能找到一个普遍的答案。以下是作者在开发基于SSH
框架的WEB
应用程序中关于团队角色的一些思考。 1.
需求调研角色。在中小企业项目应用中，一般在销售把项目谈下来之后，客户想尽快的看到项目的效果，因此需要尽快的出来一个原型。客户对原型确认之后，项目团队也许会根据这个原型进行继续开发，或者重新制作，原型可以用原型工具生成。因此，需要一个需求分析角色对项目的整体需求进行把关和确认。这个角色一般是项目经理或者由项目经理直接指派的队友，其主要的作用是对客户的需求进行整理和确认，把客户的需求用程序员可以读懂的语言描述出来，其提交的内容为用户需求文档，要求无二义性，准确，并能被程序员实现。 2.
美工，美工的作用显而易见，就是设计漂亮的UI
界面，让用户看起来赏心悦目，从感性上能有一个好的印象，最好能让用户感觉这个特别为他设计的界面比别人的好，钱没有白花，或许能在上级面前邀功。 3. UI
工程师，这个角色的主要任务是根据美工设计的界面制作出静态网页，提交的内容为HTML
集和一些JS
代码，由于一些效果的特殊性，因此必须借助于JS
来实现。一般的美工设计人员对于编程不熟悉，他们的使用PS
等工具切割生成的HTML
代码也不精简，或者样式需要重构等，UI
工程师必须对这些代码进行重新整理，并对循环的代码块进行注释，以便于界面开发人员使用。提交的产品应该代码简介，格式明确，方便阅读。 4. action
工程师，根据业务的需求写Action
类（兼配置文件）以控制用户数据交互，主要依据UI
工程师的结果并调用Service
工程师写的接口。在Action
中不执行业务逻辑，只做一些简单的界面逻辑判断和数据封装。比如把页面提交的数据封装为类的实例，或者从会话中取得用户的状态。 5. service
工程师，根据业务的需求写service
接口和实现（兼配置文件），供Action
工程师调用，service
的实现依赖于dao
工程师的接口。在service
层，把action
的调用作为一个业务进行封装，并返回业务执行的结果，比如，在action
层调用登陆验证，在service
层进行验证，验证成功后填写用户登录日志。是否填写用户登录日志这样的业务对于action
的调用者是未知的，action
只调用service
的接口并对返回结果进行判断。 6. dao
工程师，顾名思义，dao
工程师提供dao
接口和实现（兼配置文件），供service
层使用，dao
层只关注的数据的存取，并返回封装后的结果。在dao
层不应该包含任何业务逻辑判断的代码。 7. db
工程师，根据业务需求设计满足业务需求的数据库定义，并对数据库进行相应的优化，提交的内容为数据库定义的Sql
语句、相应的说明文档，以及包含测试数据的sql
语句。 8. test
工程师，测试工程师的主要工作是对action
层，service
层，dao
层，数据库写测试代码，包括测试类和测试的sql
语句。 9.
综合管理角色（可以为团队中的任何人），主要工作为开发环境的搭建，代码版本控制，编程规范扩展，代码规范执行检查，争端仲裁，进度控制，技术选择。并随时准备为团队中遇到困难的成员解决问题。这个角色很重要，必须能有单独的一个人能有足够的时间解决团队的问题，并为团队中的成员提供技术支持等服务，这个角色在某些特定的场景下可以由团队中的任何人承担，尤其在技术咨询方面，部分团队成员对某一个特定问题的理解更深刻。 以上9
种角色可以进行合并，在中小软件公司中，由于资源的限制，不得不合并一些角色。美工可以担任部分UI
工程师角色，service
工程师可以同时担任dao
，db
，test
工程师角色，action
工程师担任部分UI
工程师，项目经理担任综合管理和需求调研角色。在需求确定的情况下，一个用例经过充分沟通后，应该产生以下几种类型的文档：数据库设计，dao
接口，service
接口，action
类，UI
数据交互，界面设计，测试代码。这些文档需要团队成员共同讨论并确认，以此形成项目任务，作为制定项目计划的参考。 无论团队人员有多少，对于一个好的项目实现来说，研发团队中应该包含以上角色。这样做的好处是：团队成员任务明确，分工精细，责任到位，合作愉快，方便制定计划。这样写出来的程序方便扩展和维护，遇到问题时可以快速定位并进行响应，有利于制定代码规范，新团队成员能较快的融入团队，增强项目的可延续性（部分团队成员的流动不会对程序的开发造成大的损失，很少出现只有一个成员了解某些代码逻辑的情况）。Good Luck
，祝愿你所在的团所有成员合作愉快。 本文转自凌辉博客51CTO博客，原文链接 http://blog.51cto.com/tianli/213915如需转载请自行联系原作者