1.
碰到这个问题，是我的一个合作伙伴提出来的，初期的目标是我们希望能够迅速组建一个二三十人团队，同时在开发几个软件产品。组建团队后，希望能够达到以下目标：（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目录下。可以独立运行部署。
有没有什么网站分享源码
负责开发该项目的工程师，打开项目后只能看到以下插件的源码，他不需要关心其它插件比如数据

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。