本周一已经投奔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；
… 待挖掘…

每天早晨都是坐公司的班车上班的，从家到公司大约需要40分钟，这段时间不短也不长。为了打发时间，也曾经想过要充分利用这段时间，我选择过听音乐、看书。但音乐听时间长了就听烦了；在车上看书时间长了还有些头晕，所以多数时间我还是选择"思考"。"思考"的同时，眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。

建筑物上的几扇"破窗户"，很多人即使注意了，也会不以为然。但是对于看过 Andrew Hunt 和David Thomas合著的"程序员修炼之道"一书的程序员们也许都会"见景生情"，因为在工作中身为程序员的我们时常(甚至总是)和"破窗户"打交道。

万事万物都是有其共同的规律的：建筑物上的破窗户、牙齿上的"小洞"、软件中的低劣设计、糟糕代码的等等，在其出现的初期也许并未显现出问题，但是如果你没有及时修复，建筑物上也许会出现更多破窗户、被丢了很多垃圾、被胡乱的信手涂鸦；牙齿上的洞洞越来越大，周围的牙齿也受到牵连，开始出现"小洞"；软件中低劣的设计风格被继承、糟糕的代码被复制并被散布到系统的方方面面，以至于到最后无法控制，或者是花费很大力气来修复。

面对"破窗户"，常有这样几类情形：
1) 无法识别"破窗户"；
2) 识别出"破窗户"，但不愿修复；
3) 识别出"破窗户"，有修复意愿，但"破窗户"难于修复，或者修复成本太高，或外部因素(时间、人员、成本)导致资源不足以修复这些"破窗户"；
4) 遇到"破窗户"，立即修复。
前两种情况，一个是水平问题；另一个就是职业素养问题了，这里不多说；我们常遇到的情况往往是最后两种，如果是最后一种，其实你是幸运的，多数这种情形下你从事的一个新的系统或者项目，没有太多的遗留代码，一切都在自己的控制之下，通过重构可以达到修复"破窗户"的目的；但是如果是第三种情况，那往往是最让人痛苦的-自己无法控制，即使有渴望有热情有能力去修复那些"破窗户"，但迫于系统庞大，业务复杂，时间有限而不敢轻易出手，更让人痛心的是，系统中"破窗户"的设计和代码渐渐传染给新人，新人在维护系统时就会"以丑为美"，继续在系统上"涂鸦"，引入更多"破窗户"。由此可见及时的修复"破窗户"还兼有"整治歪风邪气"之作用。

在有"破窗户"的项目上增量开发风险很大，特别是当系统业务复杂、架构复杂时，添加一个很小的功能都应谨慎，最好能有完善的单元测试Case做保障。说到单元测试Case，设计起来又谈何容易，特别是对于由C写成的复杂业务系统，C语言本身就缺乏足够理想的单元测试工具，或者说像C这样的语言好似天生就和"单元测试"的概念无法和谐共生。对于复杂的业务单元，我们很难或者无法从纷繁芜杂的业务逻辑中剥离，或者说还是由于代码设计上的"破窗户"导致的不可测性，让"破窗户"得以延续。除非管理层狠下决心，重写系统。现在开始觉得与编写上层复杂业务逻辑相比，能编写一个独立底层库或者实现某种算法算是幸福了，因为你会有一种"可控"的感觉，而不是写完代码心里发虚的很；至于在有"破窗户"的系统上写业务逻辑，那就会又多出另外一种感觉-无奈了。