|
使用适合团队的协同工具，不但能使工作按预定成本如期顺利推进，而且能实现对团队成员、项目过程以及产品等的分析管理。未经调研就选择别人认为好的工具，很可能遭遇“水土不服”。
谈到团队管理和项目管理，工具是必不可少的一环，本文就来谈谈什么样的工具可以帮助我们提高效能。每家公司的情况不同，选择的工具也不尽相同。所以根据公司自己的需求和情况，选择或开发不同的工具时，不要未经调研就选择别人认为好的工具。工具是为人和团队服务的，它的出现是帮我们解决问题，要从问题出发找解决方案，而不是为了使用某种工具而使用。
本文基于敏捷项目管理介绍我经历的团队和组织使用过的项目管理工具，附带描述一下有利于团队协作的其他工具。
项目管理工具
在多年的敏捷项目管理中，我曾经使用过Rally、JIRA、Trello和物理白板。文中介绍的工具并不代表在某种条件下一定是最好的使用工具，还需根据实际情况来具体考量。
工具选择与使用
Rally的使用场景
- 上千人的研发规模。
- 多层次的团队组织结构。公司的组织上，有不同的产品线和业务线，每一条产品线/业务线也有子的产品线/业务线，每一条子的产品/业务线有多个研发团队组，每一个研发团队组有多个Scrum团队。
- 公司整体的蓝图（RoadMap）需要跨产品线合作和跨团队合作。
- 团队成员跨地域。大概有80%的Scrum团队成员不是在同一个城市。
基于以上这种背景，公司可考虑使用Rally作为项目研发的管理工具，包括项目进度管理和规划、数据统计和缺陷跟踪等。
JIRA的使用场景
- 两百多人的研发团队。
- 公司团队层级比较简单，不同的业务线或产品线下有1~2个Scrum团队。
- 某些项目需要跨团队合作。
- 个别团队成员跨地域。
对于基于以上这种情况的公司，可以使用JIRA+Greenhopper插件作为项目管理工具。
JIRA和Rally有很多相似性，后面将详述彼此的优点和不足。
Trello的使用场景
- 虚拟团队，团队成员在不同的办公室或在家办公。
- 开发步骤相对清晰固定。
- 团队使用Kanban流程。
- 不需要系统管理对外依赖关系。
在很多敏捷社区的虚拟团队中，团队成员使用Trello这种免费的 、操作简单的工具协同工作。
该款工具的主要优点如下。
- 界面简单，上手容易是Trello最大的优点。可以很容易地在主界面中任意的一列添加一个任务，而不需要单独打开某个页面。就算打开某一个任务页面，里面也可以直接进行修改和添加注释。
- 用不同的标签颜色，肉眼容易识别出不同的卡片分类。
- 方便地添加任务负责人，在每一个卡片上创建待办列表。
- 在注释中提到某个人时，则会相应地收到邮件，而且在被提及人打开Trello时也会收到提醒。
对于简单的项目管理来说，Trello非常好用，几乎不需要学习成本，但其本身的功能简单有限，如果需要复杂的管理需求，这款工具就并不合适了。例如任务分解、进度管理、产生报表、自定义视图、依赖关系管理及数据跟踪等这些方面都不支持。
物理白板的使用
这是我最喜欢的一种项目协调方式，它不仅有利于团队协作，对于创建团队氛围也有不可忽视的功劳，其适用于以下场景。
- 上百人或几百人的研发规模，团队结构层级简单。
- 团队成员在同一个办公室而且座位集中在一个区域。
物理白板不是使用某种软件工具，而是在团队的座位附近用一块白板来管理团队的项目。主要优点如下。
- 透明，随时可见。不需要在电脑中打开某个软件系统就可以清晰地看到团队研发的进度、燃尽图、有哪些阻碍因素。尤其是醒目的障碍，每天都会清晰地看到，便于团队跟踪。
- 及时更新。每天站立会议，大家站在附近边说边更新。而用软件工具，则还要提醒工程师们打开软件，更新进度和情况。
- 有利于沟通。经常见到团队成员在白板前讨论某一个用户故事的实施细节。
- 完全自定义。任何一款软件，就算满足大众的要求和某些自定义的要求，做到所有团队的完全支持还是很少。而物理白板则可以让团队根据自己的情况，自己设计白板显示哪些内容，用什么颜色，有多少工序等。
但物理白板在使用上有一定的局限。
- 跨地域团队不合适，无法共享相应的信息。
- 需要自己手工准备数据，例如用户故事、燃尽图、整个项目进度的管理。
- 公司领导需要到白板前了解开发进度，或者团队成员单独制作进度报告向领导报告。有个别公司的领导认为这是一个好工具，他会不时地在办公室走一圈，就了解了所有团队大概的开发进度。
- 做完的用户故事/任务没有管理，整理文档复杂。不过有些专家曾经讨论过做完的用户故事存不存档是否有必要，因为我们可交付的软件已经就是一份文档。不在这里争论孰对孰错，如果你们公司需要这些内容，则这款工具有一定的局限。
JIRA与Rally的优点及局限
JIRA和Rally各有优点和局限，下面从项目管理的需求和使用出发，分别进行描述。
操作与使用
用户故事的查看与修改：如图1所示，在JIRA中，信息都显示在一个页面上，清晰可见，例如负责人、描述、多少任务及状态、哪些依赖关系、多少缺陷、所有人的注释等。个别不常用的信息只有在编辑状态才可以看见。而哪些属于常用信息，哪些属于非常用信息完全可以自己定制。
图1JIRA与Rally的故事查看界面比较
而在Rally中，打开某个用户故事，按照不同的属性页分类，主页显示主要内容，其他属性页显示其他内容。需要一个一个点击才能查看到具体内容，例如该用户故事有多少任务，状态分别是什么等。
在JIRA中打开某一个用户故事，对于常用的内容可以在上面直接编辑，编辑后即保存而无须点击保存按钮。对于不常用的一些编辑，需要用编辑功能打开一个新的页面编辑。
而在Rally中打开某个用户故事必须点击编辑功能，重新打开某个网页才可以进行编辑。对于某些选项需要用搜索功能，而搜索功能需要打开另一个页面查找。例如添加父类信息需要搜素。在这方面JIRA的操作性会比较好。
同时修改多任务：JIRA有批量处理功能，对于一批类似的修改可以通过批量修改实现，例如统一修改多个任务状态为“关闭”，或者统一修改发布时间为同一时间，如果修改多个故事、任务为不同的值，则需要一个一个处理。
Rally支持多个用户故事、任务同时编辑。例如在计划会议中，利用多任务编辑功能可以方便地编辑任务的负责人、故事点，而不需要单独打开这些用户故事、任务页面进行单独编辑，并且可以设定不同的值。
项目结构
JIRA的项目结构没有层级概念，是扁平化的。如图2所示，所有的项目是一层。从某种意义上来讲也就无法实现Scrum of Scrum的开发模式。
图2JIRA与Rally项目结构对比
Rally的项目结构目录支持多层嵌套，公司根据Scrum团队的分布，可以在Rally中创建符合要求的项目目录。例如公司层面下可以看到业务线（BL）→子业务线（SBL）→研发团队组（DG）→研发团队（DT）。
Rally中同样有查询团队和人员的功能，在Track→Team Member Search中，输入某个人或某个团队就可以查询到相应的信息。例如PO、Scrum Master和团队其他成员。
蓝图（RoadMap）、史诗（Epic）与用户故事的关系
在JIRA中，用Greenhopper可以建立史诗（Epic），并在Epic下创建用户故事，然后在用户故事下创建多个任务。但并没有明确的蓝图的概念，不支持多层嵌套结构。
在Rally中支持任务的多层级展示，可以显示公司的蓝图与团队或团队之间任务间的关系。在本公司，每一个业务/产品线会有第一层级的蓝图，子的业务/产品线或者研发团队组会有第二层级蓝图。每一个团队会有自己的史诗（Epic）和用户故事（User Story）以及子的用户故事。对于中间层级的“任务”都会有父类和子类，整个结构就像一棵树一样，有了根就知道枝干，有了枝干知道子枝干，有了子枝干知道叶子……因此也就容易知道整个蓝图的研发情况。
冲刺计划
JIRA和Rally都对冲刺计划提供了很好的支持，通过在界面的简单拖拽就可以放到某一个迭代计划里面。相比之下个人认为JIRA的操作更加方便一些。
- 提供一些快捷键，可以快速地将某一个用户故事放入最顶端或最底端（排优先级很方便），尤其是在产品目录有非常多的条目时。
- 通过拖拽某个迭代条可以快速选择前面多少用户故事为当前迭代，而在Rally中则只能一个一个拖拽某个用户故事到某一个迭代，如图3所示。
图3JIRA与Rally迭代拖拽对比
发布计划
JIRA中只是通过将一部分用户故事放入到某一个发布版本中，通过自定义一些视图和搜索去查看相应的进度。
相比JIRA，Rally能比较好地支持发布计划（Release Planning）。
在做计划时，方便的拖拽可以轻松帮助我们发布计划，并且快速地统计发布计划中的用户故事点，以及查看相应的视图。
质量管理
在JIRA中，缺陷仅作为一个问题类型，通过问题类型过滤的方式可以产生相应的报告和视图，但没有特别为缺陷管理支持相关的功能。
在Rally中，有专门的质量管理一栏，可以做测试计划、测试用例以及产生测试缺陷报告等。
视图面板及自定义
两种软件都支持各种视图和强大的自定义功能，但使用起来不同。
JIRA的视图基于各种小配件和设计过滤条件的结果显示，一个视图中可以显示多个项目的不同数据，并且可以通过各种图表方式表达，例如饼图。
Rally大多基于项目本身的视图面板，在Rally中是先选择哪一个项目，然后所有的视图和功能都是基于这个项目的数据产生。例如燃尽图、用户故事进度等。除非用自定义的脚本去指定哪一个项目的视图（我认为这属于高级应用）。Rally中提供了很多关于敏捷所需要的视图，但自定义一些数据的视图例如饼图之类的就比较麻烦了。
在Rally中可以方便地定义不同用户角色查看项目。例如团队视图、Scrum Master视图、Program Manager视图、PO视图及成员视图等。
内容更新提醒
在JIRA中当用户故事发生变更，例如状态更新从进行中变为开发完成，则相关人员可以及时收到邮件，测试人员就可以进行测试；或者有人对当前的用户故事进行了修改则相关人员可以快速地得到这个信息。而在Rally中目前尚未发现此功能，在某种程度上，大家无法依赖Rally中的进度更新而及时通知到大家，还需要单独告知相关人员。
用户故事的导入与导出
JIRA尚不支持批量导入功能，即将Excel中的用户故事批量导入到系统中。
Rally则支持导入功能，可以将Excel表格按照规定的格式导入系统中，从而省略部分工作。但导入功能有点复杂，需要安装插件，而且Excel中规定的格式比较严格。
JIRA提供了比Rally强大的导出功能，不仅可以导出Excel、XML，甚至可以导出由过滤条件数据中产生的图表。而Rally仅可以导出Excel格式。
小结
Rally和JIRA各有优劣，没有谁一定比谁好。总体来讲，在操作上我认为JIRA更为方便一些，而在功能上则是Rally更胜一筹。此外，在共有的功能上，JIRA在细节方面的用户体验会更好。
文档管理工具
Confluence是一款很好的文档管理工具。这里列举一下我认为比较实用的地方。
- 可以为每一个团队创建自己的空间。
- 协同合作功能不错，例如在收集信息时非常有用，大家可以在同一页面更新。例如头脑风暴产品的反馈意见和设计原型。
- 当有文档变化时，可以通知到相应的人。这使得其他人可以快速地对变动进行预览和注释。有人说邮件也可以达到这种效果，但邮件很难管理和维护。
- 可以对不同的空间、页面进行不同的权限控制，以防团队以外的人误操作。
- 提供了强大的宏，可以自己定义图表或报告，使得文档更加便捷。
- 可以直接打开和操作Word、Excel、 PowerPoint。
其他小工具
一家讲求创新的公司一定会有很多自己研发的工具，这些工具的使用者也是公司内部的员工。在协同工作和辅助方面，有很多有意思的小工具，在这里分享给大家。
组件关系图
当一个组件（或者Service）需要被更新或修改时，势必要影响下游输出或受到上游输入的限制，如何快速地找到相应组件的前后关系和联系人，开发者们也自己研发出了组件关系图这样一个方便使用的小工具，便于大家分析和与相应的团队沟通合作。
办公空间视图（Space View）
公司在全球有很多的办公室，不同地方的人员也会经常出差到其他地方，为了方便地了解其他办公室的环境，想知道相应的人坐在哪里，或者了解会议室的位置，办公室空间视图都是一个很好的工具，可以查询和查看全球所有办公室及人员座位的相应信息。
预定会议室
不同地域的会议非常多，在发会议邀请时，不仅要考虑到本地的会议室，还要考虑到对方的会议室，Outlook中虽然可以预订，但很不方便，尤其是在冲刺计划会议这天，大多数团队都是同一天开计划会议。于是公司员工就开发了一套快速定会议室的系统，只要选择地区、楼层、开会时间就会快速地找到哪些会议室有空闲，可以预订。
总结
现在几乎没有一款软件是靠一个人可以独立完成的，如何让团队成员和团队与团队之间高效协作，管理者们不断谈论的话题。而工具是一种比较行之有效的方法。
另外需要注意，工具是为人和团队服务的，任何一个工具的使用和产生都建立在团队的问题上，结合各种不同的工具可以帮助团队高效合作，尤其是团队与团队之间的协作。如果为了使用工具而使用，往往会得到适得其反的结果。从问题出发，找到或开发适合自己的工具才是王道。
| 
