碰到这个问题，是我的一个合作伙伴提出来的，初期的目标是我们希望能够迅速组建一个二三十人团队，同时在开发几个软件产品。组建团队后，希望能够达到以下目标：（1）保密性：不希望所有人都接触到所有代码，我的另一个合作伙伴曾经发生他的竞争对手竟然是拿着他们的软件跟他们竞争的，因此希望软件开发过程中能减少这样的损失；（2）高效的团队协作：我想这是任何一个公司都希望能高效的；（3）产品具有可持续性：能够迅速进行更新换代，更快响应市场需求，能够提高更多的竞争力。各位，你想想你所在的软件公司存在哪些问题，我们该如何做的更好？
这个问题是一个开放式的，全世界的人，都期望能够建设优秀的团队，这是一个大难题！我在这个文章将首先介绍另一个企业的管理方法，接着，我会介绍我对这个问题的解决方案，希望各位能给予我更多的建议。这个文章的分享是基于我们自有免费开放的产品的解决方案（或者更贴切的说，我们开发的产品是为了更好的支撑团队协作），是在项目实践后的体验，希望有广告过敏的朋友不要有事没事就往这靠，如果认真看的话，我觉应该可以从我们的实践中获取相应的技术架构、管理方法的。
1 一个成熟软件企业
该企业大致的组织架构及相应的职责如下：
（1）战略决策部（我起的名字，因为我还没有这么高层能够接触到这帮变态人物）：负责产品战略目标的定制，它会与市场紧密关联，安排产品各个版本的开发，比如1.0版本、1.0.1版本、1.1版本、2.0版本的发布时间。一般而言，1.0版本到1.0.1版本的过渡仅是一些微小补丁，修复一些小问题；1.0版本到1.1版本，会有功能上的提升，不过整体改进并不是太大；1.0版本到2.0版本，会有大幅度的变化，可能是新一代的产品。
（2）架构组：这个组的人基本都是工作10年以上的超级老鸟，一帮特别变态的老外，非常敬业和专业。他们的任务是技术选型，并为所有的产品组定制统一的软件框架。架构组会定时在其产品网站发布框架编译版本，在框架初期，会征求每一个产品组的意见，每周都有与产品组的例会。该企业的框架采用插件化方式，基础框架会涵盖有统一的界面风格、通用的组件和功能。架构组有架构师、专家级工程师、QA，拥有独立的网站与独立的缺陷系统。
（3）产品组：每一个产品组都是基于架构团队开发的框架基础上构建的一个大的产品插件，产品组负责开发某一个产品，这个产品在开发过程中是访问不到框架的源码的，也访问不到另一个产品的源码。每一个产品组可以独立发布，有自己的项目经理、软件工程师、QA，拥有独立的网站和独立的缺陷系统。
（4）QA：每一个组都有相应的QA，QA工程师在任何一个产品的功能设计阶段会参与，为每一个功能提出自己的意见，并在确定功能设计后，会设计测试计划，然后发给相应的组来Review。
在团队内部，采用Review机制，老鸟带菜鸟，等菜鸟成为老鸟后，继续带菜鸟。每一个菜鸟进公司后，都有相应的文档来学习，也有人来指导。
该公司给我的印象是：（1）战略目标清晰；（2）组织架构合理，分工得当，没有出现重复开发等浪费；（3）团队内部、团队间构建顺畅；（4）清晰的项目管理，从目标、源码、每一个Bug、考核，都是跟平时的工作相关；（5）非常高效，这是因为团队分工得当、技术架构非常合理带来的好处。
2 我的方案
采用与我曾经工作的企业类似的架构和职责，所有产品均采用OSGi.NET实现模块化开发，将软件分为两类：框架和产品。所有的产品都基于统一的框架进行开发，每一个产品都遵循相同的规范，框架能够每年进行一次大版本升级，产品也相应跟上。框架有架构组负责，产品由产品组负责。每一个小组内部均有项目经理、软件工程师和测试工程师，每一个小组均有独立的源码管理、缺陷管理，有一个清晰的目标。
（1）CTO/技术总监/架构师：目标企业并不是很大的公司，显然没有什么战略决策部，可能只有一个CTO兼架构师兼技术总监，它的目标是清晰设计团队架构、团队职责、产品技术选型、产品技术架构。
（2）架构组：负责框架定义。该组的头负责软件的源码管理、框架的目标管理、框架缺陷管理。框架的定义要求优于同类的竞争对手，当然前提是支撑所有产品的高效开发。架构组开发的成果将发布到iOpenWorks平台的插件仓库之上。比如，以下的软件框架包含有：WinForm界面框架、Web界面框架、通用权限管理框架、数据访问框架、分布式通讯框架、硬件通讯协议基础框架等模块。这些基础模块为所有的项目提供了支撑。
框架组的升级包也将发布到iOpenWorks的仓库，一旦发布了升级包，产品组通过插件中心便可以获取到最新版本，保持与框架同步，并且避免未来的集成负债。
架构组发布的插件，一般都将对所有项目成员开放，所有项目的成员均在框架组成员列表中，不过只有读的权限。此外，架构组是没有权利访问产品组的成品或者源码。
（3）产品组：每一个产品组都用于框架发行包的读权限，产品组也可以进一步细分，比如前台、后台，可以拆分不同的项目，由不同的人来进行模块开发，这些人的权限都不一样，他们能够访问的源码和产品都是在某个安全范围内的。产品组独立发布自己的产品，不对外开放源码访问权限，并且团队内部不同的人访问的代码权限也是不同的。举个例子，比如大型公建能耗分析平台这个产品由五个子系统组成：数据采集分析子系统、基础数据配置子系统、上报接收子系统、Web能耗分析子系统、业主查询分析子系统。这五个子系统直接重用了架构组提供的界面框架、权限框架、数据访问框架等通用框架，可以由不同的人来独立开发，并且该产品的业务领域插件、数据模型插件、日志插件等都可以进行产品内的重用。
下图是五个子系统的源码管理。这五个的源码存放在不同的目录，设置了不同的代码访问权限，负责开发采集器的工程师能访问server目录，但是不能访问其它目录，比如configuration和web目录。
这几个目录对应于Subversion里面的不同目录。
他们在Bug系统中也将对应相应的项目（提示：我们的缺陷管理系统是定制过的BugTracker.NET，每一次代码Check in时都必须有关联的BugId而且该Bug必须经过Review，当Check in代码后，Bug状态自动变为checked in，测试人员可以很容易查询到哪些问题已经修复，哪些问题没有修复，项目经理可以清晰看到每一个工程师每天修复了多少Bug，还有多少Bug在手里，基于Bug系统的绩效考核也是蛮有效的方案，当然也有一些问题，比如有工程师为了有更多修复Bug，往往会挑肥拣瘦且容易引入更严重Bug，这时候还是要依赖项目经理的管理水平和火眼金睛）。
下面我们看看负责数据采集的工程师的项目。这个项目的解决方案在server目录下。可以独立运行部署。
负责开发该项目的工程师，打开项目后只能看到以下插件的源码，他不需要关心其它插件比如数据模型、领域模型等源码，这里面的插件由这些工程师来独立维护并且独立的发布到插件仓库，供QA或其他项目人员来访问。
该项目的模块可以独立进行发布到插件仓库。
下图则是该项目在插件仓库中的情况。这个项目的模块及其升级包均在这里独立维护。对每一个项目的维护均需要权限。
下图则是整个项目的情况，这个模块仓库拥有5个项目，每一个项目都有各自的访问权限设置。
发布到插件仓库后的模块及其升级包，都可以在成功登录后通过插件中心来获取到，需要注意的是当前用户无法访问到其它没有权限的项目。
同理，其它项目类似。下面我来总结一下我的方法。
3 总结
我的方法可以总结为以下四条：
（1）组织架构和管理方法类似于前一个公司，架构组 + 产品组；
（2）技术架构和项目的发布由OSGi.NET框架和iOpenWorks平台来实现；
（3）框架源码、框架插件由架构组来维护，在插件仓库中独立发布与测试，在缺陷管理中有独立项目，在源码管理中有单独的源码库，有严格的源码和发布的插件包访问权限；
（4）产品组基于架构组构建的框架来开发，具有统一的样式，复用统一的框架，源码、发布和权限类似于架构组。
组织架构可以这么划分：
（1） 架构组——业务无关的框架设计开发，单独发布与管理，每年进行框架升级
1） 技术架构统一设计
2） 界面框架统一开发
3） 通讯框架统一开发
4） 技术路线统一定义
5） 数据库的分析优化，可以考虑由另一个组来负责
（2） 产品组——业务设计开发，每一个产品一个组，一个组有若干模块（出于保密，隐藏）
1） ×××系统
2） ×××系统
3） ×××系统
4） ×××系统
（3） 架构组与产品组，代码互相隔离，统一管理
1） 基于插件架构
2） 基于iOpenWorks平台实现产品的发布管理与共享
3） 基于SVN + BugTracker.NET
（4） 测试组，从iOpenWorks平台获取测试产品
（5） 每一个项目，均有自己的分享页面
-----------------------------------------------------------------------------
涉及的技术人员大概一下几类：
技术副总（市场 + 技术）
技术总监（技术攻关）
架构师（统一技术、统一架构）
项目经理（客户、团队协作、团队内部管理）
高级程序员
中级程序员
初级程序员
测试经理
测试工程师
-----------------------------------------------------------------------------
因此，按照我的想法，我希望这样的团队拥有统一的架构，团队并行协作和隔离，不存在重复开发，成果能够极大进行复用，管理知识能够形成积累，具有较强的战斗力。不过，我并不是专业学管理做管理的，而是相反，我是搞技术的，因此，希望我的分享能够得到你的建议，各位读者，多出出主意吧，并且如果对你有益的话就不要吝啬来推荐了！
本文转自道法自然博客园博客，原文链接：http://www.cnblogs.com/baihmpgy/p/3565867.html，如需转载请自行联系原作者