项目背景，一个新的产品，小型项目，纯开发人员3-4人，2名熟练开发人员，1名新手，偶尔会有协助人员。没有技术经理，项目经理身负多个项目，对项目进度关心不足，部门经理会协助进行工作和进度管理。可以看到管理还是比较混乱。

由于项目进度太慢，领导要求从我这边调一个熟练人员协助开发。我也基本了解他们的项目状况，为了不让我的人进去抓瞎，我就和他一起去了解项目情况。

项目状况比较糟糕，介入项目时已经开发了一段时间，保留的文档只有两份，一副数据库说明，一份非常粗略的需求说明，而且还与开发进度不同步，就是没有维护。

我了解了一下项目目前的难度，开发人员和我反映一个是人员熟练程度的问题，二是需求变更的问题。我整体了解了一下项目目前的需求和设计，以及进度。就挑了一个模块询问他们的变更情况，这个模块是一个关键词匹配功能。结果是领导看了他们的页面之后，嫌信息量太少，就要求提供一些更细化的数据展示。开发人员问我有什么意见，我就简单讲了一下页面大概怎么构建。其中有一个点，是用于变更数据范围，即查询的表变更，我一开始觉得使用下拉框就可以，产生了一些意见。有人建议分为不同子模块，或者tab页，或者分为多块并列展示。我想了想，就给他们讲了我认为几种方案的优点缺点及适用范围。

1.       多块并行展示：

多个不同范围的数据在同一页面中分为不同区域以相同形式展示。原因是由于多块数据之间有一定的关联因果关系，或值得对比。适用范围：如购物网站中的多个物品比较。

2.       Tab页：

同一个页面的多个tab页，表示多个tab页中的数据可能在一定的领域概念之下有一定的关联，但关联度不强。因为tab页更重要的是强调一个同步工作的状态，即A tab页查看一定信息，会打开B tab页查看其他信息，中途还会切回A tab页。适用范围：如邮箱中，收件箱和草稿箱。

3.       下拉框

下拉框作为查询条件的一部分，常用于有着常规或固定的可选择内容中（如性别，月份），更多是以过滤的形态出现，即下拉框更适合针对某表的某个字段过滤，如果针对的是数据范围或是对用户需要直观了解的重要业务条件则不太合适。适用范围：如在考试成绩中使用下拉框过滤“男女”或“及格不及格”。

4.       单选框

单选框与下拉框的作用范围相似，但是不同之处在于将被选项全部展示，目的在于能够让用户清楚的了解当前数据显示的实际范围或条件，以及备选的其他范围或条件。更适用于选项与实际业务及当前展示数据关系重要，不同选项可能会引发用户的不同行为。适用范围：如银行系统显示了当前用户下绑定多个帐号时，使用单选框。

经过上述讨论，我们仔细分析了这个模块中用户的实际需求，以及可能后续操作，最终选择的单选框的方案。

目前还没有后续，但是我想我们基于用户真是需求的挖掘和后续操作的认真分析，会让我们在与领导进行需求讨论的时候有更加充分合理的依据。

回来之后我又看了看淘宝的搜索页面，比如就搜索“鞋子”来讲，将品牌这栏设置为单选和下拉将是完全不同的效果，而确定方案的理由则是对于用户的需求和实际行为的深入研究。这个应该是需求分析和调研的结果。将搜索条件以tag的形式标注于页面上，并且可以直接点击X按钮进行删除，我觉得更加可以倾向为用户体验。满足并充分考虑了用户实际需求的是好的需求分析，能够简化并引导用户行为的是好的用户体验。

当我们面临的系统感觉非常难用的时候，往往这时候并非是用户体验差，我们应该检讨的是我们对用户需求有没有好好挖掘，做出来的是不是用户想要、用户能用的系统。

我作为项目经理和技术架构管理人员负责公司一条生产线。讨论之后，首席架构师希望我们能够实施TDD。在实施TDD的过程中，设计实施过程的整体思路就是：单元测试用例文档 - 实施单元测试 - 实施业务代码 – 修改业务代码逻辑。实施人员需要参与每个环节，按照规范编写单元测试用例文档。单元测试我们按照模块（模块与人员基本没有重合）划分包（suite），保证实施起来不会产生干扰。。技术架构决定采用：maven，junit，svn。

技术背景：

技术架构设计上，我们封装了dao层的实现，所以实施人员基本无需涉及dao层的开发。服务层我们采用了JAX-RS的服务规范，对外开发服务接口。

在测试覆盖率方面，我们基本不要求对dao层的单元测试，但要求在服务层的单元测试达到100%。由于服务层是Restful WS的模式，所以我们采用了模拟HTTP请求的方式在测试服务层。

由于需要模拟HTTP的请求，所以我们在单元测试中采用了jetty作为内嵌服务器，单元测试开始时同一启动，完成后关闭。

实施过程：

开发过程中，实际实施的时候发现一个问题，对于测试数据的管理问题。即测试当中需要一定的数据环境来验证业务逻辑。这个数据环境如何建立？

方案一，使用dbunit和hsqldb。在测试启动时重建数据环境。

否决，原因：

1.与实际运行环境差异较大。

2.反复重建数据环境，效率上有缺失。

3.技术架构增加，学习和维护曲线较大。

讨论后决定使用

方案二，独立出一套测试数据库，完整数据环境。考虑到增删改与查询的冲突，制定默认规则，如id在20之内的不允许进行任何改动。以尽量隔离增删改的影响。

针对方案二，有一个较大的问题，如何在开发过程中自由的切换数据库配置呢？由于我们还是用了Hudson作为CI服务器，还要考虑到打包的过程。整体考虑之后，有两个步骤需要注意：

一、开发过程。开发过程中，我们将配置直接指向测试数据库。

二、打包过程。使用了maven，存在单元测试配置与最终产品配置的冲突。

所以最终问题的焦点集中在打包过程的maven配置方案。

搜索之后比较好的资料有

MAVEN:如何为开发和生产环境建立不同的配置文件 --我的简洁方案

（http://www.blogjava.net/scud/archive/2010/10/27/336326.html）

这篇博客是介绍在maven 中使用mvn package -P test 这样的自定义profile来实现的。这样是可行的，但是在Hudson中无法实现一条命令切换两套配置。

于是继续寻找，最终在maven的官方网站找到《Building For Different Environments with Maven 2》（http://maven.apache.org/guides/mini/guide-building-for-different-environments.html）看完文章之后发现，实际maven提供了一个非常好的插件maven-antrun-plugin，以实现某些ant的功能。此处还需要了解的知识就是maven的构建生命周期标准（http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html）。基于上述两个知识点，我们制定出如下方案，在项目中建立测试配置目录及产品配置目录，在maven的package阶段开始前，都使用测试配置，运行集成测试，完成在package阶段前将产品配置覆盖至打包文件夹内，然后进行打包。思路就是这样，下面贴出pom文件的关键部分。

POM.xml

<!—profile 节点定义覆盖文件的方式内容 -->

       <profiles>

              <profile>

                     <id>product</id>

                     <build>

                            <plugins>

                                   <plugin>

                                          <artifactId>maven-antrun-plugin</artifactId>

                                          <executions>

                                                 <execution>

                                                        <id>pre_product</id>

                                                        <phase>prepare-package</phase>

                                                        <goals>

                                                               <goal>run</goal>

                                                        </goals>

                                                        <configuration>

<!—此处与ant的任务相似 -->

                                                               <tasks>

                                                                      <delete file="${project.build.outputDirectory}/spring/dataSourceContext.xml" />

                                                                      <delete file="${project.build.outputDirectory}/log4j.properties" />

                                                                      <copy file="src/product/assembly/log4j.properties" tofile="${project.build.outputDirectory}/log4j.properties" />

                                                                      <copy file="src/product/assembly/spring/dataSourceContext.xml" tofile="${project.build.outputDirectory}/spring/dataSourceContext.xml" />

                                                               </tasks>

                                                        </configuration>

                                                 </execution>

                                          </executions>

                                   </plugin>

                            </plugins>

                     </build>

              </profile>

       </profiles>

<!—构建过程 -->

       <build>

<!—指定资源目录 -->

              <resources>

                     <resource>

                            <directory>src/test/resources</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

                     <resource>

                            <directory>src/test/assembly</directory>

                            <includes>

                                   <include>**/*</include>

                            </includes>

                     </resource>

              </resources>

              <finalName>po</finalName>

<!—指定集成测试配置 -->

              <plugins>

                     <plugin>

                            <groupId>org.apache.maven.plugins</groupId>

                            <artifactId>maven-surefire-plugin</artifactId>

                            <version>2.4.3</version>

                            <configuration>

                                   <junitArtifactName>junit:junit</junitArtifactName>

                                   <forkMode>once</forkMode>

                            </configuration>

                            <executions>

                                   <execution>

                                          <id>default-test</id>

                                          <phase>integration-test</phase>

                                          <goals>

                                                 <goal>test</goal>

                                          </goals>

                                          <configuration>

                                                 <skip>false</skip>

                                                 <includes>

                                                        <include>**/*TestSuitex.java</include>

                                                 </includes>

                                          </configuration>

                                   </execution>

                            </executions>

                     </plugin>

              </plugins>

       </build>

软件企业的技术体系架构包括对软件产品本身及生产过程、软件生产环境及生产者的管理和支持，此架构应当基于下列五项基础建设之上：

l 开发技术架构

l 开发环境架构

l 过程管理架构

l 企业产品架构

l 企业人件架构

下面详细介绍各项架构的内容及特点。

开发技术架构

开发技术架构作为一个软件企业的基石，包括可复用的架构组件、公用的基础代码库等。开发技术框架应当在一个良好的过程管理之下，严格的质量管理与实用性检查，并且鼓励普通技术人员的参与。

1.建立技术架构仓库标准体系与维护模式。建议使用MAVEN作为所有开发技术（包括架构预研与实际项目开发）的基础项目管理工具，实施严格的质量管理和持续集成。

2.选拔组建高素质的架构师队伍，并且鼓励技术人员参与到技术架构仓库的构建和维护。

3.加强技术架构实用性与适用性的检查与改造。

4.架构运营模式的考察，技术架构的改进与预研。技术架构的预研模式比较复杂，多个部门中多个项目可能都会要求进行多个同类框架的考察、比较、环境搭建等工作，若集中在独立架构组可能压力较大。可以考虑架构组内部划分为多个技术领域，如企业基础应用架构、消息中间件、动态化组件、分布式集群等。以技术部门的实施领域作为导向，进行技术架构的预研。

5.开放知识系统的构建（内部wiki，个人博客，视频分享）

根据企业行业背景，需要关注的技术领域包括：企业应用、ESB/SOA、大型分布式架构（在线/离线），自然语言处理。

开发环境架构

包含IDE，编译环境，远程支持，通讯支持与其他大量功能性支持软件，并可以根据不同的工作角色制定不同的环境，以便排除干扰，更加快速有效的进入工作状态。

项目的关键问题是沟通，个性化的工具妨碍——而不是促进沟通。开发和维护公共的通用编程/项目管理工具有很多的好处。

1.建立具有鲜明特色与强大实用性的自有开发环境，展示一个软件龙头企业在企业技术沉淀中的深厚功力和规范性。

2.建立行政流程以规范和约束开发环境管理。

3.划分相关职能以保持对开发环境的维护

4.建立多种培训机制以促进新员工能够迅速投入工作。如固定新员工开发环境熟悉培训机制，建立企业讲解&培训视频库，小组内互助&沟通。

过程管理架构

1.过程方法

对多家企业软件生命周期中使用的过程方法进行调查了解到，大部分优秀的软件企业对于过程方法十分重视，且存在针对不同项目合理运用不同的过程方法。项目经理对于过程方法的理解与运用常常关系到项目的成败。

目前核心的管理模型/过程方法主要分为三大类：CMMI，RUP，敏捷。

CMMI作为软件质量体系的标准，软件企业必须具备的资质，具有文档齐全，流程规范等优势，对于大型核心项目有较大优势，其劣势在于灵活度不足，无法很好的满足日益变化的需求。

RUP由Rational公司（被IBM收购，目前是IBM 软件集团旗下之第五大软件品牌）提出，采用迭代开发模式，四个阶段，九大核心工作流，明确的角色划分与文档规划，可裁剪配置的开发过程。目前被大量的软件厂商作为最核心的过程方法使用。

敏捷（Agile）为了满足队伍小型化和需求快速变化而产生的目前最流行的过程方法。XP（Extreme Programming）通过简单的四个核心价值（沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage））与十二条最佳实践从研发的角度提出了最简单直接的开发方式。XP的形态特殊，从编程的角度描述方法与原则，加入了SCRUM之后，加强了从行政体制方面的支持，从而形成了完整的敏捷开发的过程方法体系。

过程方法一定不是万金油，针对不同的企业特点，甚至不同项目，都有必要对过程方法进行合理的裁剪与整合。对于目前公司的情况，大型核心项目可以使用CMMI，这些往往决定了企业的战略方向，稳健的过程方法最为合适。大部分中小型项目均可采用 RUP+敏捷 的过程方法，即遵守RUP的核心阶段和工作流，但是迭代周期和开发的基本原则根据敏捷，并挑战整合部分敏捷方法中的最佳实践。这样的策略用于面对市场需求的快速变化，同时也能很好的保障企业在软件生产中的产品价值保存和技术经验积累。

2.过程方法自动化支持

针对不同的过程方法，往往有若干的软件产品用以快速自动化的实施。如实施CMMI时所使用到的DEVSUITE产品。完整体系的支持产品往往在应用于某套固定方法有着良好的效果，但容易存在流程生硬，无法与开发环境更好结合形成了信息孤岛，改进困难等缺点。一套优秀的过程方法支持软件，需要和开发环境（如IDE等）良好结合，并且易于调整以应对过程方法的变化，同时没有复杂冗余的过多细节流程以便容易被开发人员学习和掌握。

产品涉及方面：项目计划、项目需求管理、软件配置管理、自动集成、自动产品发布、代码审核、代码质量管理等。

企业产品架构

1.产品/产品需求流程补充，产品立项时的立项报告中应当包含市场、竞争对手、对手产品、风险等分析。

2.领域模型与概念，在特定的行业中可以即使关注领域专家的动态，以便构建正确的领域模型，确定产品的发展方向和形态的正确性。

3.对于特定产品的领域概念及相关技术发展需要深入了解，如舆情分析系统，需要进行了一定的市场调查，跟进了当前领域专家的报告，参考国内外多项相关项目的设计理念和原则。对于目前市场状况、未来的方向、目前的技术实力等要有比较清晰的概念

4.坚持以市场为导向的原则，在商务部门与研发部门之间搭建积极的沟通桥梁，研发部门的计划根据实际市场需求进行调整。产品的发布配合市场的要求，达到利益最大化。

企业人件架构

企业自身环境除了常见的软件（Software），硬件（Hardware）以为，还应当加入人件（Peopleware）。之前的种种，如过程方法、技术架构积累、知识分享等均是为了将整个企业构建成为一部精密的机器，无论缺少什么重要零件均可以快速修复，但是人员流失所造成的损失是巨大的。目前公司有着良好的软硬件环境，技术部门作为发动机，若在针对技术性员工有特别的规划和关心，必然能够增强在整个市场中的竞争力，对企业自身的发展也是有良好的推进作用。

公司可以按照职位和员工自身的情况规划发展路线，明确技术目标。开发进化角色基本按照软考标准，程序员-高级程序员-软件设计师-系统分析师-系统架构师，程序员-高级程序员-项目经理。

在技术部门内部，可以定期组织交流心得、新技术等。（在SCRUM中实际上有一些比较好的行政手段可以借鉴参考）

由于软件技术部门的特殊性，一些应用于生产线的行政制度可能能够讨论出更好的实施方案，避免员工单方面的错误认识引发消极的工作态度。

由于有一定经验，而且公司技术架构建设的需要，能够很好的协助企业进行技术架构全方面的介绍和培训。而且我自身也很希望参与到企业文化的建设工作中去，鼓励技术人员之间的技术交流与沟通。