本周一已经投奔ThoughtWorks的Dreamhead因公事回到沈阳，来到我们公司看望以前的同事。他谈到业界的一种说法：ThoughtWorks在"怎么做"上达到了很高的高度，但是在"做什么"上与Google这样的公司相比还有差距。既然ThoughtWorks在"怎么做"方面树立了榜样，那么这个公司推出的产品估计在"怎么做"上对其他公司也会有所指导^_^。Mingle就应该是其中之一。

公司走的是CMMI的体系文件，即所谓的"重过程"管理，这样的过程对项目负责人的要求甚是严格，常常发生与QA之间的"你来我往"，甚至为一个无关轻重的文档"严词讨论"一番；再加上部门在过程工具上的选择比较"保守"，自己感觉部门的管理成本还是很高的，有些时候甚至感觉有些浪费。普通编程人员对各种文档也是有着"抵触"情绪的，特别是在"补"一些"写完即过时"的文档时更是无奈。

程序员都喜欢happy工作，那为什么不选择一个让自己让大家都happy的过程呢？先将CMMI抛在脑后，看看ThoughtWorks推出的这款"敏捷项目管理"工具吧。目前其最新版本是1.1，不过听Dreamhead说，经过性能优化的2.0版本即将出炉了。

Mingle在ThoughtWorks官方站点可以免费下载，且5个用户以下的可以永久免费使用。Mingle是用纯Ruby打造的且运行在JRuby上的一个产品，由于ruby是一门脚本语言，所以其移植性就很好，用其编写的程序安装起来也甚是容易，在Windows、Mac和Unix多种主流平台上跑都是没有问题的；但也正是由于采用ruby编写，Mingle对硬件的要求也甚高，在我这台512M内存的机器上跑是超慢的、让人闹心的，建议还是放到性能好的、单独的服务器上，内存容量官方建议是2G。Mingle后台存储采用数据库方式，目前仅支持mysql和Postgres两种数据库版本，这个比较遗憾，我无法使用现成的Oracle数据库了。

Mingle的安装甚是容易，Windows上有已经编译好的installer程序，unix下有zip包，下载后直接解压即可。Mingle在windows上会将自己设置为一个系统服务，默认开机自启动。如果你的硬件配置不行的话，建议将该服务属性改为手工。Mingle在unix下解压后即可，无需传统程序的configure&make install，也无需pkgadd过程，Mingle可任意放到用户的目录下，无需安装到系统目录下，简单配置后即可启动。在解压后的目录下你会发现mingle.properties 文件，打开该文件修改其中的两个属性即可，其中port是mingserver监听的服务端口；dataDir就是存储项目数据文件的地方，你可以随意指定到你的用户目录下。
mingle.port=8080
mingle.dataDir=$YOUR_DATA_STORE_DIR
配置好以上两项后，在$MINGLE_UNZIP_DIR下，执行./MingleServer start即可。由于MingleServer是一个Shell脚本文件，需要chmod +x一下才能执行。

现在你可以打开Browser，输入"http://server_ip:8080"，你将会看到Mingle的配置界面，因为现在完整的安装过程尚未结束，你还需配置：数据库连接、mail服务器、license信息以及用户帐户信息等。

在配置数据库连接之前你需要首先安装数据库，我在自己的机器上安装了一个MySQL5.0。打开"MySQL Command Line Client"，首先执行"create database mingle"创建一个名字为"mingle"的数据库；建完库后还需要做"用户授权"，Mingle才能连接到该库。执行："grant all on mingle.* to mingle@server_host_ip identified by 'mingle'; 这句是给数据库mingle新增了一个在server_host_ip 上用户/密码为mingle/mingle的用户，我们配置mingle时使用这个用户即可。

配置后，你将进入Mingle的项目List页面，从这里开始你就可以使用Mingle开始"敏捷"的项目流程了。官方站点的Help可以快速的帮你建立和配置好第一个Project，现在你可以开始试用了。

关于"敏捷"，我的认识还不够深刻，但我的目标很明确：如何能从"敏捷"中找到切入点，结合我们产品的特色，找到符合我们"特色"的软件开发流程，让大家在软件开发过程中一路顺畅，没有感到"别扭"的地方。希望能找到。

[附]
简单用了一下，发现如下很好的Features：
- 支持建立"个性化"项目模板，便于复用；
- 附带项目wiki，便于"项目知识积累和管理"；
- 丰富的card properties，使需求驱动的管理流程更加清晰；
- 支持card和源代码之间的link；
… 待挖掘…

上周日和橱柜公司商量好，下午三点到我的房子量尺，橱柜设计师按时到达，拿着一卷尺开始了测量工作。有过装修经历的人都知道：在装修公司进场之前需要橱柜设计师出一份水电改造图，便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通，这不由得让我想起这样一个问题："软件开发领域的"图纸"在哪里呢"?

"图纸"是建筑行业的标准的共同语言，它能让设计师与施工者无缝沟通，同时由于建筑图纸的形象性，普通人看了基本也能了解一二，这样普通用户和设计师沟通起来也是很容易的，即使是一个外国设计师设计的图纸，只要使用了标准的图纸符号，中国的施工者也可以完美的将之实现出来，反之中国设计师的作品，外国施工人员也亦然可以实现之。软件行业的人总喜欢拿软件开发与建筑行业做比较，设计模式就是其中最典型的例子。不过这么多年来，软件开发过程仍然无法达到建筑业的那么"精确"，这里的精确不是指过程和进度的精确，而是沟通的"精确"。

软件开发领域的"报怨声"已经持续了几十年了，需求分析人员无法获取用户的准确需求、系统设计人员无法将自己的全部设计思想很好的传达给编程实现人员，人们都在抱怨：缺少一种"共同语言"，能让他们之间"无缝的沟通"。软件业的大师们绞尽脑汁、费尽心思、提出了多种沟通语言，以试图解决这个问题。这里面最著名的莫过于由OMG组织于20世纪末推出的"统一建模语言(UML)"了，顾名思义，UML试图统一软件开发领域所有过程阶段的"沟通标准"，需求阶段有Use Case图；设计阶段有组件图、类图；部署阶段有部署图，另外还有序列图、状态图、活动图作为辅助。UML到目前为止也从1.0发展到了2.0版本，但其实际应用情况如何呢？乐观点说是：没有"图纸"在建筑领域应用的那么广；如果从我了解的和接触的实际情况来看，UML已经过了其高峰期，开始变得"不瘟不火"。

程序员多数喜欢简单化、个性化和形象化的表达思想，一块白板，无拘无束。虽然UML在形象化上做的还不错，但是却始终无法打动程序员的心扉。从另一个事实来讲，图纸是建筑行业的门槛或者说是基础，而与之对应，代码才是软件行业的门槛。这样一来似乎代码才应该是一种共同的语言，在"敏捷软件开发"的附录中就有这样一篇文章："源代码即设计"。那是否说："代码"就是"软件业的图纸"呢？"代码"在设计开发人员之间可以说是基本无缝的，但是对于普通客户而言，代码似乎太专业了。其实在建筑行业"图纸"也多在设计师和设计师、设计师与施工人员之间做沟通之用，大项目中少有客户与设计师沟通时使用"图纸"，多数会用外观效果图。这样一来似乎软件开发领域的"代码"与建筑业"图纸"的概念达到了一定的一致性。"代码"作为沟通媒介的前提是：代码和设计的统一。为了达到这一目的，需要代码结构清晰，可读性，可沟通性要好，这也势必需要实现人员提高编码技艺。都说编程是一门艺术，从这里来看，名符其实。如果承认"代码"这一地位，那么实际上是确定了一个方向，以后向这个方向努力就是了，众所周知的"敏捷"在这个方向上做出了努力。

上面也已经说过，"代码"过于专业，并不能作为"统一沟通媒介"来统一整个软件开发过程，看来我们只能继续期待头脑中理想的"图纸"的出现了，也许它会诞生于将来的一个突破性的"发明"或"发现“；也可能它将是一个永远的"梦"。