关于分层架构下的分工有关问题
关于分层架构下的分工问题
关于分层架构下的分工问题
复杂的业务逻辑需要很多类配合来实现。
这些类当然不给由一个人来完成。
可是每个人写若干个类，
那么，不同的人之间如何进行沟通？
需要一个类似于架构师或者设计师这样的角色么？
把本次迭代周期中的类和接口设计出来么？
如果这样，类或者接口要设计的详细到什么程度？
而且，架构师或者设计师的工作量是不是太大了？
一般的多人参与的复杂系统开发是怎么分工的？
------解决方案--------------------
楼主提出的几个问题都不小，而且不同的人可能有不同的看法，正所谓见仁见智。下面简单谈谈我的个人看法，以求抛砖引玉。
复杂的业务逻辑需要很多类配合来实现。这些类当然不给由一个人来完成。
可是每个人写若干个类，那么，不同的人之间如何进行沟通？
沟通的主要手段：设计文档(包括各种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模式上增加更深一层的架构层模式后再进行分工，不过后者需要一个技术水平和经验相对较高的架构师来支撑，否则很难做到。
关于分层架构下的分工问题
复杂的业务逻辑需要很多类配合来实现。
这些类当然不给由一个人来完成。
可是每个人写若干个类，
那么，不同的人之间如何进行沟通？
需要一个类似于架构师或者设计师这样的角色么？
把本次迭代周期中的类和接口设计出来么？
如果这样，类或者接口要设计的详细到什么程度？
而且，架构师或者设计师的工作量是不是太大了？
一般的多人参与的复杂系统开发是怎么分工的？
------解决方案--------------------
楼主提出的几个问题都不小，而且不同的人可能有不同的看法，正所谓见仁见智。下面简单谈谈我的个人看法，以求抛砖引玉。
复杂的业务逻辑需要很多类配合来实现。这些类当然不给由一个人来完成。
可是每个人写若干个类，那么，不同的人之间如何进行沟通？
沟通的主要手段：设计文档(包括各种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模式上增加更深一层的架构层模式后再进行分工，不过后者需要一个技术水平和经验相对较高的架构师来支撑，否则很难做到。