关于我
我的开源
链滴
B3log敏捷团队协作的加速器——Mingle
转载请保留作者信息：
作者：88250
Blog：http:/blog.csdn.net/DL88250
MSN & Gmail & QQ：[email protected]
一. Mingle 是什么？
Mingle 是一个敏捷项目管理与团队协作工具，它提供给团队一个共享的工作空间。它支持各种各样的敏捷方法，内置了 XP、Scrum、Agile Hybrid 的项目模版。Mingle 也是 ThoughtWorks 7 年多敏捷实践的结晶。而在英文字典中，Mingle 这个词有着“合而为一，混合”的意思。的确，它让整个凝聚在了一起，为了共同的项目目标而努力。
在 Mingle 中，everything is Card!Card(卡
片)是一个很重要的概念，这个概念是众多的敏捷方法学(典型的，XP)中的基本概念。其实，在我们日常生活中也是这样的。比如，身为 QA 组 Lead 的
Vanessa 要使用会议室，她将填写一张会议室使用申请表，填好后将这张表递交给了了项目的 Leand，Daniel。Daniel 看了时间，会议参与
人员等安排后同意了会议的申请。他签了“同意”后由将此表递交给了公司资源组的 Lead，Yu
Zhao。他看完申请后，根据申请表安排了一下会议室硬件使用。到此，Vaness 的会议室使用申请就通过了。如果用 Mingle 来描述这个流程，申请表
就是一张卡片，而整个申请过程(签署与递交)就是卡片状态转换的过程。伴随着这个过程，所有的参与人员都各尽其责，让这个任务最终得到了解决。
当然，上面是一个很简单的例子，Mingle 能做的当然也仅不是“申请会议室”这个简单的任务。下面，让我们进入正题！
二. Mingle 带给我们什么？
1. 团队协作——团队的共享工作空间
一个团队，一个工具
使用 Mingle，团队中的开发人员、测试人员、业务分析人员与项目经理间的“距离”将大大缩短。大家都工作于一个统一的项目工作空间内，这使得信息可以得以及时的共享，大家都可以看到整个项目当前阶段、历史某阶段的输出是什么。
“贴”在Card Wall(卡片墙)上的卡片可以告诉我们很多信息：谁正在做什么，谁已经完成了什么，还有些什么工作正在等待着谁的开始，等等。要改变卡片的状态(例如从“In Progress”改变到"Complete")，只需要在卡片墙内的不同状态泳道间拖拽一下卡片！
关于文档在敏捷项目中的意义问题一直有着激烈的讨论，笔者一直坚信 Martin 文档第一定律(Martin’s First Law of Documentation: Produce
no document unless its need is immediate and
significant)。在项目文档上，Mingle 也正是秉承这一点而设计的。在 Mingle 中，项目相关文档都可以使用 Wiki 的方式来记录。项目
的需求开发、重要的项目信息(Scope, Schedule,
etc.)可以使用 Wiki 记录，这样既可以做到复杂文档的表示，又可以利用 Wiki 的特点做到文档历史的可追踪性，何乐而不为？
当团队里某个成员改变了项目相关的信息时，Mingle 可以把这个消息通知给其他人，让其他人可以快速地知道这个改变。例如，当一张 Story 卡状态变成"Devlopment Complete"时，团队中的测试人员将被通知到。
2. 项目管理——简单化软件交付
自定义项目属性与模版
Mingle 可以针对卡片定制您想要控制的任何信息，这样由于不同的项目就会有各自不同的主要关注点，您就可以把主要精力集中在相应的关注点上。这就是敏捷的做法，需要什么才用什么。在项目中，如果有工具可以支持、捕捉与可视化团队活动的话，还可以保持项目状态的追踪，也方便在项目进行时作出实时的决策。这在很大程度上降低了敏捷项目的交付风险。项目模板可以方便地导出与导入，让您在当前项目成功的基础上继续下一个项目。
工作流是一个很重要的概念在任何项目中，任何任务都需要一个流程来控制。Mingle 允许我们自定义适合自己项目的工作流，定制界面也是相当的友好。例如可以描述一个 Sotry 的处理流程如下：
卡片树！
这是在 Mingle 2.0 中新加入的特性，利用卡片树，您可以层次化地管理项目中的任务，所有操作都是可从界面直接拖拽的！
在一个团队中，不同角色负责不同的任务，履行着不同的职责。所以，在项目中，不同的角色需要以不同的视角、层次化地、直观地看到自己的任务。
例如，在一个项目中：
- 项目经理(Project Manager)可能希望有一个计划树做 WBS(Work Breakdown Structure)
- 业务分析师(Business Analyst)想要用 Story
Tree 将某个 Feature 分解成一组不同且相关的功能 - 设计人员(Designer)想要用使用树型结构分解项目的高层逻辑与 UI 设计
- 测试人员(Testers)想把测试场景分解成更细精度的测试用例
这
样，开发团队能够在更高的视角上审视整个项目的开发过程，同时在需要的时候深入至各种细节。并且，定义的卡片树可以根据您设计的继承关系在任何一个树层次
上进行聚合计算，从而产生度量数据。例如你可能对每个 Story 都有估算，如果一个 Feature 由多个 Story 组成，一个 Story 又由多个 Task
组成，那么查看这个 Story 的大小(size)就可以根据 Task 很方便的自动计算出来，而且 Feature 需要做多少工作也是一目了然的了。
Mingle 可以方便地与其他系统整合，例如 CAS(Central Authentication Service，中心身份认证服务)，LDAP 身份认证服务，Subversion/Perforce源码控制，REST APIs，Cruise 持续集成等等。有了这些支持，Mingle 可以和您已经存在的系统无缝地整合在一起，共同协作，完成项目目标。
三. 您的团队需要 Mingle 吗？
看了上面的特性介绍，相信您对 Mingle 已经有了个大致了解。但要选择这样一个对团队可能有着很大影响的工具需要非常的慎重，下面列出了一些重要的注意点，当您要选择 Mingle 时：
“硬”需求：
- Mingle 是一个商业软件，一个用户的许可(one user license)半年是 318.6 美元，一年是 566.4 美元，而终身是 995 美元。
- Mingle 对系统硬件配置要求比较高。它是第一个构建与 JRuby 上的商业软件，而 JRuby 对系统的消耗是比较大的(希望以后的 JDK 可以再提升 JRuby 的性能)，但前版本的 Mingle 至少需要 2G 的 RAM
- Mingle 目前只支持三种数据库：MySQL 5.0，PostgreSQL 8.1 与 Postgres 8.2。注意，但前的 Mingle 版本(2.0.1)尚不支持 Postgres 8.3
您的团队过程是敏捷过程吗？虽然 Mingle 应该可以支持非敏捷过程的团队，但 Mingle 是为敏捷过程量身定做的，所以，如果您的团队过程是非敏捷的话，最好慎用
您的敏捷团队真正需要它吗？敏捷方法告诉我们，工具不是团队过程的最重要的部分，人才是其核心。如果现在您的团队已经在很好地实施敏捷了，那么在选用 Mingle 以前，请考虑清楚“敏捷与工具”的问题
当然，这里描述的只是在选用 Mingle 上的一些主要注意事项，在清晰了上述问题后，您就可以针对自己团队的情况选用 Mingle 了。
四. Mingle 容易上手吗？
Mingle 的安装方式有两种：
- 使用安装包方式
- 使用 LiveCD 方式
此外，如果您想最快的体验一下 Mingle，可以到使用官方网站提供的 Drive Online 功能，地址是：http://studios.thoughtworks.com/mingle/testdrive
关于 Mingle 的使用与具体配置，相信您在阅读完本文后已经有了一个清晰的认识，这里就不再赘述了。如果您的团队是敏捷团队，您的团队也真正需要这样一个项目管理与协作工具，首选就是 Mingle！