关于分层架构下的分工问题
关于分层架构下的分工问题
复杂的业务逻辑需要很多类配合来实现。
这些类当然不给由一个人来完成。
可是每个人写若干个类，
那么，不同的人之间如何进行沟通？
需要一个类似于架构师或者设计师这样的角色么？
把本次迭代周期中的类和接口设计出来么？
如果这样，类或者接口要设计的详细到什么程度？
而且，架构师或者设计师的工作量是不是太大了？
一般的多人参与的复杂系统开发是怎么分工的？
[解决办法]
楼主提出的几个问题都不小，而且不同的人可能有不同的看法，正所谓见仁见智。下面简单谈谈我的个人看法，以求抛砖引玉。
复杂的业务逻辑需要很多类配合来实现。这些类当然不给由一个人来完成。
可是每个人写若干个类，那么，不同的人之间如何进行沟通？
沟通的主要手段：设计文档(包括各种UML图、ER图) + 口头交流 + 项目会议
需要一个类似于架构师或者设计师这样的角色么？
最好有专职的架构师，但这不是必须的，看项目的大小和客观条件是否具备。
对于架构的这个词汇，各人的理解也不尽相同，UML用户指南中说的是5个视图便可以描述体系架构，但实际上很多人并不这么看。架构包含的内容很多，而且在不同问题层次上，包含的内容也不相同。
个人认为，作为架构师在技术层面至少需要掌握诸如：
1. UML相关工具，如ROSE、JUDE
2. 数据库建模工具，如ERWin、PowerDesigner
3. 常用的设计模式
4. 具备较强的可用性(Availability)和性能(Performance)方面的意识
把本次迭代周期中的类和接口设计出来么？
普通的类不一定需要很详细地设计出来，但接口或者用作接口的类必须设计出来，而且要尽量详细。这种设计通常都是由架构师(可以兼任)首先提出一个初步的设想，然后由架构师召集相关人员进行面对面地沟通，共同完成其设计，并由架构师记录下来。
之所以这么做，是因为接口所牵涉到的不是某个人或者模块，它影响的是多个人或者模块，因此需要事先需要相关人员(stakeholder)共同完成。普通的类则不同，可以由工程师自己设计，但这种设计最好也要遵守一定的规范(通常是公司或项目级的规范，比如类的命名规则、变量的命名规则、代码中的注释应当如何写等等)
如果这样，类或者接口要设计的详细到什么程度？
而且，架构师或者设计师的工作量是不是太大了？
绝大多数情况下，架构师本身是很难做到详细设计的，正如楼主所言工作量太大，而且如果没有前期代码的支持，也难免会错漏百出。
作为架构师，通常做到概要设计就可以了，如果必要，可以做一小部分详细设计。
概要设计包括的内容主要有：
1. 业务需求经过分析后得到技术需求，即用技术化的语言描述业务需求，诸如可能包括用例图、各种流程图、业务功能分组等等
2. 系统为实现客户需求时，所必须满足的系统功能(所谓系统功能和具体的业务功能没有很大的直接联系，比如数据库访问层这样的功能)
3. 明确系统的性能指标、可用性指标等重要指标
4. 数据结构，包括ER图至少要到逻辑ER视图
5. 系统软、硬件选型及配置要求，包括采用什么编程语言来开发等等
详细设计一般是在概要设计的基础上进行的，诸如类的名称、参数的名称及数据类型等，数据结构要到物理ER视图等等。
一般的多人参与的复杂系统开发是怎么分工的？
要说明这个问题，必须要弄清楚一个项目通常到底需要什么样的角色。
1. 项目经理：负责协调各种资源、各种沟通(客户、公司领导、项目组成员等等)、定期(peroidic)检查和事件触发(event driven)检查
2. 需求分析师：精通相关业务领域知识(domain knowledge)
3. 架构师：和需求分析师一起完成概要设计及部分详细设计
4. 开发工程师：代码和注释
5. 测试工程师：根据业务需求编写测试用例，包括白盒和黑盒测试用例，同时可能还要规划性能测试、代码可维护度测试等(MI)
当然有条件还可以增加一些别的角色，如界面设计师、文档工程师等等。目前国内很多公司，限于各种客观或主观条件，通常一人身兼多种角色，而这并非是一个好的practice
软件开发的确很复杂，因此出现各种软件开发方法论，比较通常用到的有：瀑布、PMBOK中的螺旋迭代法、RUP以及进来流行的敏捷开发(Agile Development，包括XP和SCRUM)，当然还有原型(prototype)开发等等。特别值得注意的是，原型开发很重要，尤其是在做详细设计的时候，我们通常要做一些小规模的代码试验来验证一个想法是否可行，原型法很少单独出现，一般是潜在前面提及的其他软件开发方法里面。
顺便值得一提的是CMM，CMM的精髓就强调可控性(controlable，比如需求可以改变，但不能随意改变，这种改变需要受到控制)和可见性(visible，进度到底怎么样？碰到了什么问题？还包括可预见性即什么时候可以完成什么内容等等)
限于篇幅，以上仅为个人浅见，望大家批评指正。
[解决办法]
沟通的主要手段：设计文档(包括各种UML图、ER图) + 口头交流 + 项目会议
项目会议主要也是要进行Peer Review，评审很重要，如果是多人设计，特别是接口部分要重点评审，因为接口涉及的人相对较多，不一起评审会出现很大问题
概要设计阶段也就是High level design，主要是类图和ER图，这两个做好是最关键，其他的UML图个人觉得一定程度上是帮助理解及验证需求的
详细设计阶段也就是Low level design，就已经细致到具体界面了
另外我看到你说到本次迭代
既然你采用迭代开发，为什么不把工作量限制的小一些，这样一个人不就能负责类的设计，一个人负责数据库的设计了吗（个人的一点经验，负责数据库设计的兄弟可以相对弱一些，评审数据库设计的需要是个高手，而且数据库的设计是根本，数据库一变动影响太大，对项目进度有很大影响，评审要细一些，次数要多一些）
架构师应该是在迭代开发之前进行整体的架构设计，我不太了解你的技术领域是什么，在WEB应用这边架构师考虑的是权限，菜单，页面布局，代码自动生成，配置文件等的设计，另外架构师可能还需要考虑引入Junit单元测试工具，集成Crusecontrol，CVS等配置管理工具，以及系统的安全性（防黑）等问题
BTW：pathuang68说的很好，学习～～
[解决办法]
个人没这方面的经验,个人看法:
那么，不同的人之间如何进行沟通？
楼上大牛说了.看文档,开小型会议.
需要一个类似于架构师或者设计师这样的角色么？
需要.但不要硬性分配,最好小组人员选出来.
把本次迭代周期中的类和接口设计出来么？
需要.优先级为公用,保护,私有
如果这样，类或者接口要设计的详细到什么程度？
名称,参数,返回值.最开始的实现可以是个"假实现",前期改动是很正常的.
而且，架构师或者设计师的工作量是不是太大了？
没经验不好说.
一般的多人参与的复杂系统开发是怎么分工的？
没经验不好说.
建议楼主看代码大全的后几章有关于这方面的小经验.
[解决办法]
这个问题涉及到团队模式和开发模式两个方面。
1、团队模式上的组织形式，人员状况都是需要考虑的，不同的团队，人员，技术能力，个人喜好都不同，必须根据实际情况进行分配和研究。
如果没有什么特殊的了解，可以作一些简单的根据架构模式的人员分配，然后让人员进行分类开发，比如按照简单的MVC模式进行分工，也可以在基本的mvc模式上增加更深一层的架构层模式后再进行分工，不过后者需要一个技术水平和经验相对较高的架构师来支撑，否则很难做到。
2、开发模式上就要看你是什么项目，项目的具体要求，功能分割等来进行考虑了，这些都不是一个帖子或者一个回复能够解决的问题。
你可以去看两本书：
我的那本《软件工程之全程建模实现》，里面有关于模式划分的问题，还有一个我党年的开发实例，提到2002年在南京地税项目上我做的分工和开发实现速度，一个星期5-6个人完成一个完整的业务模块的实现过程。
另一本，不管你是不是java都建议看：《J2ee核心模式》，第一版或者第二版都可以。
另外可以考虑看一下我的交换编程的方法，搜索就可以查到。这些都对于你这个事情是有帮助的。
[解决办法]
有很多项目是按纵向分工的。
这样的项目一般以数据库为中心展开项目。
各个功能模块读写指定的数据库表。
这种分工方式的优点是明显的：
1，便于项目组内成员的共同（功能模块读写指定的数据库表。不需要在模块接口等问题苦恼）
2，项目领导工作较轻松（分好功能模块，设计好表就OK了）
但是这种方式的缺点也是明显的：
1，代码风格不统一，不利于维护。
2，功能的优先级无法排列。（所有模块一起上）
3，没有统一的架构，质量难以保证（特别是非功能性需求）
4，不利用专业分工（DB和UI可是两会事儿，更何况是业务逻辑，你明白多少关于银行，保险，航空，电力的知识）
5，以数据库为中心，是个糟糕的想法。如果数据库变动，影响太大。
6，这样的分工适合前期就能确定全部功能需求的项目。
[解决办法]
【设计】
我觉得设计应该是一层层细分，逐步完善的过程，而不是某个人一下子就全部搞定。
在明确了用户的大致需求后，拎出主要的功能路线，按照功能找出所涉及的部分（硬件、软件）。
先由产品级架构师画系统框架图，主要描述系统环境上下文，也就是系统一级成员，然后要明确接口，如硬件接口、软件接口、通信接口，确定各部件间的通讯交互模式、交互流程。
可以通过各种图及文字来表述这些内容。
到此，即可组织专家进行review
当然需要考虑到约束条件：标准符合性、硬件约束、技术限制等
还有质量方面的，如：可用性、安全性、可维护性、可测性等
完成之后，再下发给相应的下一级软硬件设计人员进行再设计，实际上现在要实现的内容很明确了，就是提供接口或实现某些功能，现在的目标就是如何实现这些接口或功能，如何划分如何组织。
然后，一级级下发、细化，直至开发人员进行详细设计。
[解决办法]
【项目内部】
我所经历的项目无一例外，均是按功能模块进行划分。
当然，相互review、改BUG是必不可少的，这也是为了避免人员流动带来的麻烦。
[解决办法]
不同的人之间如何进行沟通？
——沟通成本巨大，需要架构师，以便减少沟通成本。
需要一个类似于架构师或者设计师这样的角色么？
——绝对需要，理由同上。
把本次迭代周期中的类和接口设计出来么？
如果这样，类或者接口要设计的详细到什么程度？
而且，架构师或者设计师的工作量是不是太大了？
一般的多人参与的复杂系统开发是怎么分工的？
——要回答这些问题，请先弄清你自己所处的情况。简而言之，你的项目是外包还是从无到有的新产品？如果是外包项目，对不起，我真看不出来有多复杂。老外不会把核心的东西外包，而且外包项目发包方都有严格的管理要求，不管CMM什么的都好，你照做就行了，详细到什么程度，怎样分工有文档。
如果是从无到有的新产品，还是从原型做起；我在美国公司打工，正式员工，参与核心代码，这个我非常清楚。这时候就不要相信什么CMM，什么瀑布模型之类的狗屁了。架构师或者核心开发人员（这时候应该没有设计师）绝对是宝贝，只能靠他们。所以比尔曾说，如果在微软的钱和50位核心开发人员中二选一，他绝对会选那50位核心开发人员。
[解决办法]
需要一个类似于架构师或者设计师这样的角色么？
【sammer】需要。架构师决定了一个系统的风格和走向。他决定MVP，那整个系统就是MVP，每一个场景都会有对应的类。他决定整个系统要允许plug-in，那就得让框架支持这一特性，并且这一特性会影响到后期的CM工具，以及如何打包，如何安装。。。
把本次迭代周期中的类和接口设计出来么？
【sammer】不涉及到架构的接口不需要定义。到了项目中期，应该框架基本稳定了，那些业务接口基本和实际应用对应好的，是很明确的。不需要那么费事的定义一遍。除非公司有硬性规定，比如那些CMMIX的公司。
如果这样，类或者接口要设计的详细到什么程度？
【sammer】我觉得为了后来人，只需要记录架构和框架相关的类和接口，同时辅以一个具体的例子用来验证你这个框架是可以正常运作的。就足够了。软件大于复杂文档。
而且，架构师或者设计师的工作量是不是太大了？
【sammer】架构师的工作是保证整个系统的开发风格始终一致，并且在关键问题上提出指导意见。最关键的是他的想法得让每个人都理解和接受。
一般的多人参与的复杂系统开发是怎么分工的
【sammer】怎么分工不要紧，但是最好让你的任务划分为可以演示的。每个任务都会有一个leader。由他负责去实现他可以根据需要从资源池里面选择合作对象。他负责最后的提交和演示。
个人意见，笼统回答一下。复杂系统简单化是关键。
